AFAIK tcptraceroute est le meilleur outil pour vérifier si un pare-feu bloque la connexion tcp à un service. (Si vous connaissez un meilleur outil, merci de laisser un commentaire)
Certains houblons ne répondent pas. Voir * * *
remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
1 * * *
2 172.18.56.12 0.407 ms 0.222 ms 0.230 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 10.102.1.1 32.017 ms 31.728 ms 31.486 ms
8 * * *
9 10.101.7.124 [open] 31.728 ms 32.391 ms 33.549 msY a-t-il un terme pour le comportement de ces houblons ?
Comment appeler cela, si le hop ne répond pas, et que je vois * * * dans la sortie ?
(Malheureusement je n'ai pas 300 réputations et ne peux pas créer le nouveau tag "tcptraceroute")
Le contexte : Je voudrais dire aux personnes responsables du réseau qu'elles devraient utiliser des routeurs qui font MAINTENANT-IL-MAINTENANT-LE-MAGIC-TERME.
2 votes
Cela peut être causé par un réseau MPLS avec des VPN L2/L3 ou par des pare-feu qui sont configurés pour ne pas renvoyer de paquets ICMP.
0 votes
AFAIK, il n'existe pas de terme générique.
0 votes
@Tom comment appeler ce comportement ?
0 votes
Comme l'a dit Zoredache, il n'y a pas de terme spécifique pour cela. De même, il arrive que les pare-feu n'abaissent pas le TTL, de sorte qu'ils n'apparaissent pas comme un saut dans le chemin du trafic. Il n'y a pas non plus de nom pour cela.
0 votes
Cela se produit simplement lorsqu'un hôte ne répond pas au paquet TCP SYN. tcptraceroute incrémente alors le TTL après un certain temps, pour atteindre l'hôte suivant.
3 votes
@Tom
tcptracerouten'utilise pas du tout ICMP (c'est pourquoi c'est un bon outil, de loin supérieur àpingytraceroute) et seulement TCP : il fait un TCP SYN, puis il reçoit soit : pas de réponse, ou TCP RST, ou TCP SYN+ACK0 votes
@PatrickMevzek L'un des plus grands défis de l'histoire de l'humanité.
tracerouteLes implémentations disponibles sur Ubuntu peuvent également envoyer des paquets TCP SYN. Autant que je me souvienne, c'est celle qui est installée par défaut.0 votes
@guettli Le mot que j'utiliserais pour décrire ce comportement est "mal configuré".
0 votes
Je suis allé lire les RFC pertinentes, et il s'avère qu'en IPv4, il est facultatif pour les routeurs de répondre, mais en IPv6, c'est obligatoire. Dans IPv4 : "La passerelle mai notifie également l'hôte source via le message de dépassement de temps." RFC 792 . En IPv6 : "Si un routeur reçoit un paquet avec une limite de saut de zéro, ou si un routeur décrémente la limite de saut d'un paquet jusqu'à zéro, il MUST rejeter le paquet et envoyer un message ICMPv6 Time Exceeded avec le code 0 à la source du paquet". RFC 4443 .
0 votes
@kasperd "L'une des implémentations de traceroute disponibles sur Ubuntu peut également envoyer des paquets TCP SYN. Autant que je me souvienne, c'est celle qui est installée par défaut. " ce qui n'est pas le point comme par défaut (sans options spécifiques),
traceroutefera du UDP, ce qui n'est pas bon pour de nombreux dépannages. Les personnes connaissant les choses sauront quels sont les drapeaux appropriés (tcptracerouten'est souvent qu'une enveloppe autour detracerouteavec les drapeaux appropriés`, mais si vous dites simplement "utiliser traceroute", les gens ne feront pas la bonne chose par défaut.0 votes
@PatrickMevzek Je préfère blâmer ceux qui configurent les réseaux d'une manière qui casse les outils de débogage plutôt que de blâmer les outils de débogage ou les utilisateurs.
0 votes
@kasperd " Je préférerais blâmer ceux qui configurent les réseaux de manière à casser les outils de débogage " Je ne suis pas du tout d'accord avec cette hypothèse. Si vous voulez dépanner un serveur web, l'outil de débogage approprié est une requête TCP sur le port 80, si c'est SMTP alors c'est le port TCP 25, si c'est DNS il utilise TCP ET UDP sur le port 53, etc. En bref, traceroute en utilisant UDP n'est presque jamais l'outil de débogage approprié... c'est seulement si vous déboguez un service basé sur UDP. Dans les autres cas, vous devez dépanner en utilisant TCP.