La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: Steph le 25 avril 2024 à 11:59:50
-
Bonjour,
Ce matin, j'ai eu une misère pour accéder à l'un de mes switchs à travers mon VPN.
Après investigation, j'ai compris que le switch en question (Netgear GS308E), répond avec un TTL au départ égal à celui de la demande. Du coup, pas accessible de l'extérieur du réseau local.
ping depuis le lan
ping -n 1 -i 128 switch-bas.home
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données :
Réponse de switch-bas.home : octets=32 temps=5 ms TTL=128
ping -n 1 -i 1 switch-bas.home
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données :
Réponse de switch-bas.home : octets=32 temps=3 ms TTL=1
J'ai mis un peu de temps à trouver car un autre switch GS605E répond avec un TTL de départ "normal" à 64 et tous les autres équipements du réseau répondent correctement.
Dans le traceroute depuis l'extérieur du lan à travers le VPN, cela fait un saut de plus en time-out et je ne comprenais pas quel était ce mystérieux équipement (tous mes équipements répondent aux ping).
De plus, bien que répondant au ping, ce switch n'est pas accessible en http à travers le VPN.
Tracert et ping de l'extérieur du lan à travers openvpn en mode routage
tracert switch-bas.home
Détermination de l’itinéraire vers switch-bas.home
avec un maximum de 30 sauts :
1 2 ms 3 ms 2 ms nas.vpn
2 * * * Délai d’attente de la demande dépassé.
3 5 ms 5 ms 5 ms switch-bas.home
Itinéraire déterminé.
ping -n 1 -i 128 switch-bas.home
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données :
Réponse de switch-bas.home : octets=32 temps=5 ms TTL=126
C'est courant cette façon de faire en réseau? Le TTL de réponse = au TTL de la demande?
D'avance merci.
Cordialement
-
C'est courant cette façon de faire en réseau? Le TTL de réponse = au TTL de la demande?
réponse courte : Non
réponse plus longue :
je n'ai jamais vu ça, il n'y a rien de ce genre dans le RFC 792 (je sais, c'est vieux).
Les systèmes Linux "modernes" permettent de fixer la valeur par défaut, tu peux vérifier par : $ sysctl -n net.ipv4.ip_default_ttl
64
Sans surprise c'est aussi cette valeur qu'utilise ma FreeBox :
$ ping -c 1 -4 _gateway
PING (192.168.1.254) 56(84) bytes of data.
64 bytes from _gateway (192.168.1.254): icmp_seq=1 ttl=64 time=5.44 ms
--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.439/5.439/5.439/0.000 ms
-
Merci.
Ça m'a bien foiré mon compte de hop ce TTL variable au départ!
Sans Wireshark, je crois que je me demanderais encore ce qui se passe.
C'est vicieux de tromper ainsi un traceroute, d'avoir réponse au ping et pas de réponse http, alors qu'en local, tout marche bien.
Edit : j'ai pas de console sur le GS308E switch manageable grand public, seulement un http.
-
J'ai jeté un œil sur le forum Netgear.
Il y a des gens qui ont le même problème de non accès à l'interface web à travers un VPN.
Seule réponse proposée : https://community.netgear.com/t5/Plus-and-Smart-Switches-Forum/GS308E-Refusing-Connection-while-on-VPN/m-p/2334492
"Here again, the very basic IP stack on the micro controller is not able to handle smaller MTU than the default, these switches don't understand PMTUD."
Ce qui me parait bien louche.
-
J'ai aussi fait un Wireshark sur la connexion http.
Le PC qui initie la connexion sur le switch ne reçoit que des [RST, ACK] en réponse à ses [SYN].
-
As-tu regardé si tu voyais des paquets ICMP "Destination Unreachable" / "Fragmentation Needed and Don't Fragment was Set" dans ta trace pour voir s'il s'agit bien de ce sujet Path MTU Discovery? (et si les paquets SYN envoyés par le PC contiennent le bit do not fragment positionné ?)
Pour moi, si c'était un cas lié à PMTUD, tu ne verrais même pas de TCP RST.
L'implémentation IP a l'air un peu fantaisiste sur cet équipement, ça pourrait être autre chose (ex : ne pas autoriser les connexions entrantes http d'une provenance hors du LAN).
-
As-tu regardé si tu voyais des paquets ICMP "Destination Unreachable" / "Fragmentation Needed and Don't Fragment was Set" dans ta trace pour voir s'il s'agit bien de ce sujet Path MTU Discovery?
Aucun paquet de ce type.
Je n'y croyais pas trop à cette option du "guru".
(et si les paquets SYN envoyés par le PC contiennent le bit do not fragment positionné ?)
Il l'est.
Pour moi, si c'était un cas lié à PMTUD, tu ne verrais même pas de TCP RST.
Je le vois très bien des deux cotés du tunnel.
PC TCP SYN
Switch bizarre : TCP RST
L'implémentation IP a l'air un peu fantaisiste sur cet équipement, ça pourrait être autre chose (ex : ne pas autoriser les connexions entrantes http d'une provenance hors du LAN).
C'est bien possible.
Dans la doc : "Connect your computer to the same network as the switch."
Mais il ne parle pas des tunnels.
Et le GS305 répond correctement TCP SYN ACK contrairement au GS308 qui répond TCP RST pour une même situation.
Je comprends bien cette réponse sécuritaire TCP RST à des demandes hors du LAN de config du Switch.
Par contre je ne comprends pas bien la réponse ICMP Reply avec le TTL positionné à la valeur du TTL recu avec le ICMP Request.
-
Dans la doc : "Connect your computer to the same network as the switch."
Mais il ne parle pas des tunnels.
Et le GS305 répond correctement TCP SYN ACK contrairement au GS308 qui répond TCP RST pour une même situation.
Je comprends bien cette réponse sécuritaire TCP RST à des demandes hors du LAN de config du Switch.
it is not a bug, it is a feature (read the f...g manual) ... Implémentation à 2 balles d'une mesure de "sécurité"
Par contre je ne comprends pas bien la réponse ICMP Reply avec le TTL positionné à la valeur du TTL recu avec le ICMP Request.
implémentation à 2 balles de la couche IP, en répondant au paquet reçu en ne se donnant pas la peine de créer une nouvelle entête IP pour la réponse, mais juste reprise des champs du paquet IP reçu en inversant les adresses IP src et dst.
-
Par contre je ne comprends pas bien la réponse ICMP Reply avec le TTL positionné à la valeur du TTL recu avec le ICMP Request.
Certains OS ont des valeurs par défaut différente pour le champs TTL des ICMP REQUEST et ICMP REPLY. D'autres répondent avec le TTL vu lors de la réception.
https://community.cisco.com/t5/routing/why-ttl-in-ping-request-packet-and-ping-response-not-the-same/td-p/3918734
-
Et du coup, cela foire les traceroute, puisque le réponse n'arrive pas à revenir.
-
Et du coup, cela foire les traceroute, puisque le réponse n'arrive pas à revenir.
Et oui. C'est le "bug" dans ce cas le TTL de l'ICMP REPLY ne peut pas parvenir.
Et je te confirme que sur une pile TCP de référence de FreeBSD ou la RACK ça répond avec le TTL par défaut l'OS ou spécifié dans cet OS.
-
Cette idée de positionner le TTL de la réponse à celui du paquet reçu n'a aucune justification et est une violation notamment du RFC 1700 (https://datatracker.ietf.org/doc/html/rfc1700).
Extrait (ça a 30 ans) :
IP TIME TO LIVE PARAMETER
The current recommended default time to live (TTL) for the
Internet Protocol (IP) (...) is 64.
Ca partait du constat à l'époque que le "diamètre" d'Internet en nombre de hops était de quelques dizaines.
Il faut se rappeler qu'au départ (càd aux débuts d'Internet), le TTL dans l'en-tête IP vise à éviter qu'une circularité dans des tables de routage provoque un engorgement du réseau par des paquets qui y restent indéfiniment.
L'utilisation du TTL dans la commande traceroute (ou ses dérivés) est juste la programmation d'une "astuce" technique, pour exploiter les messages ICMP TTL Exceeded permettant de détecter les anomalies de routage.
Ca n'est en rien une "norme", d'ailleurs, par défaut, traceroute Windows envoie des messages ICMP alors que les versions Unix s'appuient sur UDP.
(désolé de faire encore mon ancien combattant)
-
Je ne comprends pas bien ce que veut dire "TTL du reply = TTL du request". Il n'y a aucun moyen de connaître le TTL du request: l'ICMP request part de la source avec une certaine valeur (64 par ex.), qui est ensuite décrémentée de 1 à chaque routeur traversé. Et le réseau ne peut pas savoir combien de routeurs ont été traversés.
Si tu essayes de forcer un TTL plus grand au départ (commande ping -? pour avoir les différents paramètres possibles) est-ce que ça change quelque chose ?
Si tu as toujours un TTL de 1, c'est que cette valeur est forcée quelque part dans la chaine.
-
Je ne comprends pas bien ce que veut dire "TTL du reply = TTL du request".
Tu as mal lu le premier message de Steph dans ce fil (extrait ci-dessous) et désolé de mon raccourci
C'est courant cette façon de faire en réseau? Le TTL de réponse = au TTL de la demande?
Ce qu'on évoque ici, c'est un équipement qui retourne un ICMP Echo Reply en mettant dans l'en-tête IP le TTL qu'il a "vu" dans l'ICMP Echo Request qu'il a reçu.
Bien sûr, impossible de savoir à combien était positionné le TTL au départ de l'ICMP Echo Request sur la machine à partir de laquelle le ping ou tracert a été fait.
-
Le ping est fait dans le même sous réseau (mon lan) depuis un PC vers le switch bizarre.
ping -n 1 -i 128 switch-bas.home
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données : # 1 ICMP ECHO REQUEST avec TTL au départ de 128
Pas de routeur à traverser, le paquet arrive sur le switch avec un TTL de 128
Réponse de switch-bas.home : octets=32 temps=5 ms TTL=128 # Réponse de ICMP ECHO REPLY avec un TTL à 128, pas de routeur à traverser, donc le TTL pas décrémenté.
ping -n 1 -i 1 switch-bas.home
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données :
Réponse de switch-bas.home : octets=32 temps=3 ms TTL=1
ping -n 1 -i 255 switch-bas.home
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données :
Réponse de switch-bas.home : octets=32 temps=3 ms TTL=255
C'est systématique.
J'ai mis un peu de temps à le mettre en évidence car je connectais à travers un VPN qui rajoute naturellement un hop.
Et avec ce switch, j'ai un hop de trop, time-out, d'un routeur qui n'existe pas dans le réseau!
Avec le tunnel :
tracert switch-bas.home
Détermination de l’itinéraire vers switch-bas.home
avec un maximum de 30 sauts :
1 2 ms 3 ms 2 ms nas.vpn
2 * * * Délai d’attente de la demande dépassé.
3 5 ms 5 ms 5 ms switch-bas.home
Itinéraire déterminé.
ping -n 1 -i 128 switch-bas.home # emission ave TTL de 128
Envoi d’une requête 'ping' sur switch-bas.home avec 32 octets de données :
Arrive à TTL 127 sur le switch
Réponse au départ du switch à TTL 127
Réponse de switch-bas.home : octets=32 temps=5 ms TTL=126 # réponse arrivée à TTL 126.
Une fois qu'on le sait, c'est facile.
J'ai presqu'envie de poser le problème comme énigme dans le bistrot. :)
-
à défaut de résoudre le problème, peut être qu'un reverse proxy sur le même subnet que ton switch résoudrait l'affaire.
ce n'est pas résoudre la cause, cependant il semble futile de vouloir faire corriger des anomalies.
-
J'ai essayé et ça permet l'accès à la page de login.
Par contre, impossible de loguer, on retombe toujours sur la page de login sans plus d'explication.
-
Que dit une trace (wireshark) entre le reverse proxy et le switch ?
As-tu regardé les champs X-Real-IP et X-Forwarded-For dans la requête http ?
-
une piste?
https://community.netgear.com/t5/Plus-and-Smart-Switches-Forum/working-Nginx-config-for-ProSAFE-plus-switches/td-p/1850420 (https://community.netgear.com/t5/Plus-and-Smart-Switches-Forum/working-Nginx-config-for-ProSAFE-plus-switches/td-p/1850420)
dans ce cas c'était une histoire de cookie.
proxy_set_header Cookie $http_cookie;
-
Merci.
Ça me fais penser que les Adblocks font aussi parfois des misères.
Je regarde ces pistes.
-
Que dit une trace (wireshark) entre le reverse proxy et le switch ?
As-tu regardé les champs X-Real-IP et X-Forwarded-For dans la requête http ?
Identique à mon IP privé de routeur.
En fait, cela marche si je reste en HTTP:80 de chaque coté du proxy.
Quand je règle le proxy HTTPS:443 <-> HTTP:80, cela ne marche pas.
une piste?
https://community.netgear.com/t5/Plus-and-Smart-Switches-Forum/working-Nginx-config-for-ProSAFE-plus-switches/td-p/1850420 (https://community.netgear.com/t5/Plus-and-Smart-Switches-Forum/working-Nginx-config-for-ProSAFE-plus-switches/td-p/1850420)
dans ce cas c'était une histoire de cookie.
proxy_set_header Cookie $http_cookie;
YES!
Testé et fonctionnel.
Merci.
Je ne dirais pas que j'ai tout compris le pourquoi du comment.