[Résolu] Choix d'un modem/routeur WiFi

[Minikea]

sinon, un simple tcpdump côté routeur fait l'affaire. et justement les routeurs un peu ouverts (ou tout openwrt) peuvent le faire.

[Nozalys]

En effet j'ai vu qu'il y a un outil graphique "Packet Capture" dans le routeur, et sinon la possibilité de le faire en CLI :

show interfaces ethernet eth1 capture

sudo tcpdump -i eth1 -n host 192.168.10.3

Je ne connais pas encore tcpdump (le manpage est énorme...) Je vais essayer de regarder ça ce weekend.

[Nozalys]

On 20/11/2020 at 09:34, Nozalys a écrit :

Je vais essayer de regarder ça ce weekend.

Hum hum... un problème avec la notion du temps ? 🙂

 

Bon j'ai trouvé le temps d'essayer tcpdump ce matin : j'ai désactivé mes règles de blocage DNS de pihole pour les bornes Wifi : en ~10 minutes je vois bien une vingtaine de requêtes autorisées sur le log de pihole, mais pas de communication vers les domaines ciblés et listés un peu plus haut vus par tcpdump.

En revanche j'ai des communications périodiques (toutes les 5 minutes) avec AWS :

tcpdump: listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:19:25.824022 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.3, length 46
11:19:25.824112 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at <mac_addr> (oui Unknown), length 28
11:19:25.824392 IP (tos 0x0, ttl 64, id 7940, offset 0, flags [DF], proto TCP (6), length 85)
    192.168.10.3.60748 > ec2-52-51-94-140.eu-west-1.compute.amazonaws.com.https: Flags [P.], cksum 0x36c6 (correct), seq 1033188425:1033188458, ack 652211079, win 1078, options [nop,nop,TS val 238488456 ecr 1788533542], length 33
11:19:25.955087 IP (tos 0x0, ttl 228, id 11243, offset 0, flags [DF], proto TCP (6), length 52)
    ec2-52-51-94-140.eu-west-1.compute.amazonaws.com.https > 192.168.10.3.60748: Flags [.], cksum 0xa68a (correct), ack 33, win 145, options [nop,nop,TS val 1788768875 ecr 238488456], length 0
11:19:25.955659 IP (tos 0x0, ttl 64, id 7941, offset 0, flags [DF], proto TCP (6), length 111)
    192.168.10.3.60748 > ec2-52-51-94-140.eu-west-1.compute.amazonaws.com.https: Flags [P.], cksum 0xde88 (correct), seq 33:92, ack 1, win 1078, options [nop,nop,TS val 238488469 ecr 1788768875], length 59
11:19:26.050108 IP (tos 0x0, ttl 228, id 11244, offset 0, flags [DF], proto TCP (6), length 52)
    ec2-52-51-94-140.eu-west-1.compute.amazonaws.com.https > 192.168.10.3.60748: Flags [.], cksum 0xa5eb (correct), ack 92, win 145, options [nop,nop,TS val 1788768962 ecr 238488469], length 0
11:19:26.072034 IP (tos 0x0, ttl 228, id 11245, offset 0, flags [DF], proto TCP (6), length 109)
    ec2-52-51-94-140.eu-west-1.compute.amazonaws.com.https > 192.168.10.3.60748: Flags [P.], cksum 0x34b0 (correct), seq 1:58, ack 92, win 145, options [nop,nop,TS val 1788768985 ecr 238488469], length 57
11:19:26.072430 IP (tos 0x0, ttl 64, id 7942, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.3.60748 > ec2-52-51-94-140.eu-west-1.compute.amazonaws.com.https: Flags [.], cksum 0xa1ea (correct), ack 58, win 1078, options [nop,nop,TS val 238488481 ecr 1788768985], length 0
11:19:30.966091 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.3 tell 192.168.10.1, length 28
11:19:30.966366 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.3 is-at <mac_addr> (oui Unknown), length 46
11:20:43.617517 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has pihole tell 192.168.10.3, length 46

La première question que je me pose c'est comment se fait-il que le domaine ec2-52-51-94-140.eu-west-1.compute.amazonaws.com n'apparaisse pas dans les requêtes DNS de pihole ?

La seconde question c'est pourquoi les bornes feraient-elles des requêtes de résolution de nom de domaine sans communiquer avec ces domaines ?

La troisième question c'est aussi pourquoi tcpdump ne "voit pas" ces requêtes DNS ?

Ensuite, la raison de cette communication avec AWS... peut-être est-ce lié à la fonction de sauvegarde/restauration des paramètres des bornes dans le cloud de TP-Link (tplinkcloud.com)

 

Et, heu.. on est d'accord que je n'expose aucune donnée identifiante dans ce log tcpdump ?

[Minikea]

1. peut-être que ec2-52-51-94-140.eu-west-1.compute.amazonaws.com est un autre nom (alias) d'un des serveurs qui te posent problème, il te faudrait la requête/réponse DNS correspondante pour savoir
2. peut-être qu'elles font une recherche DNS juste pour leur cache (vu que ce sont des serveurs très souvent utilisés, les avoir en cache permet de gagner quelques millisecondes)
3. aucune idée. il faudrait comparer les logs à la seconde du PiHole et du tcpdump pour comparer.
4. Non, y'a rien à part l'IP privée d'une de tes bornes et de ton serveur DNS (aucun risque) et j'ai l’impression que tu as enlevé les adresses MAC de tes équipements (ce qui de toute façon n'offre pas vraiment de risque non plus)

[Nozalys]

Merci pour tes réponses. Je les reprend dans l'ordre :

1. Je n'ai pas accès à la requête DNS correspondante car justement je ne vois pas transiter les requêtes DNS des bornes wifi. Je pense que c'est parce que les bornes et le pihole sont sur le même subnet, sur mon switch, et que c'est le switch qui s'occupe localement du routage direct. J'imagine que dans ce cas le routeur n'intervient pas.
2. Peut-être en effet. Ou une méthode basique pour détecter l'accès à Internet ? Mais je n'ai ni LED rouge ni alarme sur l'application de configuration Android pour approuver cette thèse.
3. Ça me semble difficile car les timestamp de tcpdump ne correspondent à rien.. Ce log, je l'ai capturé entre midi et midi 20. Et puis pihole me remonte une requête DNS toutes les 30 secondes, tcpdump cette communication toutes les 5 minutes. Je ne vois rien à tirer de ces 2 informations en fait.
4. Cool (oui j'avais juste retiré les 2 adresses MAC.

Next step : j'envoie un mail au support technique de TP-Link pour leur demander plus de précisions. Mais vu la portée des questions je ne m'attends pas à une réponse éclairante.

[Minikea]

Il y a 4 heures, Nozalys a écrit :

Ce log, je l'ai capturé entre midi et midi 20

les horaires correspondent, ils sont juste en UTC (alors que 12h20 c'est UTC+1, heure d'hiver en France) mais pour le reste tu dois pouvoir limiter la communication au port 53 mais effectivement si les bornes communiquent directement avec le pihole sur le même subnet, tu ne verra pas transiter les requêtes DNS sur le routeur, à part celles que le pihole ne connais pas déjà et va demander à son serveur DNS de référence.

[Lyaume]

On 17/11/2020 at 12:43, Nozalys a écrit :

Autre point, critique AMHA : j'ai pu voir, grâce aux logs du PiHole que ces bornes se connectent toutes seules (sans aucun périphérique connecté dessus) et périodiquement (toutes les 2 minutes en gros) à plusieurs domaines : a.root-servers.net, reddit.com, live.com, youtube.com, bing.com, facebook.com, google.com, linkedin.com.

Le premier peut se comprendre, encore que, en théorie elles devraient se baser sur les infos fournies par le routeur. Mais alors les 7 autres c'est scandaleux. Je bloque donc toutes les requêtes sur ces domaines provenant des @IP des 3 bornes vers ces domaines. Mais le concept de fond me déplait fortement.

Pour ce point, donc, je ne recommande pas ces bornes. TPLINK est d'ailleurs blacklisté dans ma tête.

Hello @Nozalys,

J'ai suivi ton post car j'étais dans un cas un peu similaire.

Et puis finalement j'ai tout laissé tomber et j'ai juste acheter un bon routeur que j'ai mis derrière la Livebox pour le réseau de domicile.
J'ai pris un routeur TP-Link et après avoir vu ton expérience, et bien je voulais savoir s'il agissait de manière similaire à tes bornes.

Le PiHole enregistre bien une activité similaire et le routeur se connecte au même domaine que ceux que tu cites. Ça se passe surtout la nuit lorsque le réseau est très peu encombré.

Du coup, ni une ni deux, je contacte le support pour leur faire part de mon étonnement.

Voici leur réponse :

Citer

Bonjour,

 

Merci d'avoir contacté le support technique TP-Link

 

C'est le mécanisme de détection de connexion "online detection", en effet, le routeur ne fait que de  resolution DNS pour ces domaines , si la résolution réussie, le voyant internet  s'allume en vert. Donc simplement le routeur vérifie si le DNS peut résoudre ces noms de domaine sans visiter ces sites ce qui ne pose pas des problèmes à votre réseau .

 

Nous espérons avoir répondu à votre demande de support, et solutionné votre problème .

En l'absence de réponse de votre part nous pourrons être amenés à clore le ticket en l'état.

Vous pouvez à tout moment procéder à une réouverture de votre ticket depuis http://tp-link.com/fr/contact

Cordialement,

 TEAM SUPPORT TECHNIQUE

Téléphone : +33 1 82 88 35 35 (numéro non surtaxé) joignable uniquement avec votre numéro de dossier/ticket préalablement ouvert

Site Web: http://www.tp-link.com/fr/contact

D'un côté ça me rassure, d'un autre je ne sais pas trop quoi en penser. Est-ce les seuls à le faire? je n'en sais rien.

Cependant je suis plutôt satisfait du routeur et de son interface plutôt bien foutue.

[Minikea]

Il y a 6 heures, Lyaume a écrit :

Voici leur réponse :

du coup, ça rejoint ce qu'on disait: interrogation DNS uniquement afin de vérifier la connexion internet.

pas super propre de faire ça comme ça mais ça doit être le plus simple.

[Nozalys]

Hello,

Tu m'as coupé l'herbe sous le pied, ils m'ont fait peu ou prou la même réponse :

Citer

[...]

Ces paquets proviennent de la fonction de détection en ligne ,  Lorsque les Deco sont allumés, ils enverront des paquets NTP ou DNS pour détecter la connexion Internet. En fait, tous les paquets seront limités à quelques Mo de trafic par jour, et cette quantité de trafic n’aura pas beaucoup d’influence sur votre réseau.

[...]

Je leur ai demandé en réponse s'il était possible de désactiver cette fonction, et suggéré une telle option dans une future mise à jour mais mon ticket est resté sans réponse depuis.

 

En fait, c'est rassurant et on s'en doutait un peu, certes. Mais d'un autre côté ça ne dit pas tout : mes bornes Wifi continue de s'allumer "en vert" alors qu'elles n'ont plus accès à aucune requête externe.. Mon PiHole bloque toutes les requêtes DNS, et les bornes fonctionnent parfaitement bien. Ou alors ça veut dire que les bornes ont aussi la capacité à se connecter à une IP fixe (qui donc doit être considérée comme valide Ad vitam æternam). Et c'est là, je pense, qu'intervient la requête périodique en HTTPS vers "ec2-52-51-94-140.eu-west-1.compute.amazonaws.com". Je pense que l'IP 52.51.94.140 est forgée en dur dans le firmware, ce qui expliquerait que PiHole ne voit jamais de requête DNS sur ce nom de domaine, mais que le tcpdump du routeur le voit.

Et puis je trouve malgré tout plutôt "limite" leurs choix des noms de domaines.