ping et TTL

Le 12/05/2011 14:45, Kevin Denis a écrit :

Bonjour,

Bonjour,

lorsque je fais un ping, j'ai un TTL qui s'affiche:
$ ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttlT time7.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttlT time6.1 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 36.107/36.900/37.693/0.793 ms

Ce TTL correspond précisément à quoi?
-Au TTL des paquets envoyés par ma machine vers 8.8.8.8?
-Au TTL des paquets envoyés par 8.8.8.8 vers ma machine?

2ème réponse... Il s'agit du TTL des paquets qui reviennent. Un simple
test sur différentes machines montrera d'ailleurs que ça varie en
fonction de la pile IP qui est en face et du nombre de "hops" sur le
trajet, test comme celui que vous faites d'ailleurs dans la suite du
message.

J'ai en fait un état assez surprenant avec trois routeurs:
Poste - routeur A - routeur B - routeur C - gateway.
Si je ping routeur A, j'ai un TTL de 128

A priori normal jusque là, le routeur doit être un machin sous Windows
ou assimilé ? Le TTL par défaut de Windows est 128.

Si je ping routeur B, j'ai un TTL de 255

Ca, en revanche, c'est beaucoup plus curieux. Un TTL de 255 correspond
typiquement à une machine Solaris ou qqchose du genre, mais en toute
rigueur, avec un autre routeur devant, ça aurait dû être 254, sauf si le
roureur a est une espèce de firewall avec une config particulière
destinée à le rendre plus ou moins "invisible" ? Le TTL étant sur un
octet, il est impossible qu'il ait été à 256 avant le passage de A ! :-)

Si je ping routeur C, j'ai un TTL de 61

Encore plus bizarre. ;-) On peut imaginer que le TTL initial soit de 64,
typique d'une machine sous Linux, mais pourquoi -3 ? En toute rigueur
les routeurs sont censés décrémenter un TTL de 1 juste après avoir routé
un paquet (en sortie, donc), et encore -1 à chaque seconde qui passe,
mais ça m'étonnerait quand-même que vous ayez des délais si importants,
sauf si A et B sont des satellites géostationnaires (Inmarsat, VSAT ?),
ou qqchose du même acabit.

Si je ping gateway, j'ai un TTL de 127

De plus en plus fort. ;-) Vous êtes sûr du chemin pris par vos paquets
quand vous pinguez les routeurs qui ne sont pas directement sur le même
brin réseau que votre machine ?

Je sais que les routeurs ont une liberté totale quant à la modification
de ce champ, mais on peut s'attendre à ce que chaque routeur ne fasse
que décrémenter de 1 sa valeur?

Je ne sais plus où j'avais lu qu'il y avait décrémentation de 1
également à chaque seconde, mais je ne suis pas certain que tous les
routeurs implémentent cela.

Vous savez quels sont les machines qui se "cachent" derrière A, B et C ?
Là j'ai fait des suppositions, mais bien entendu, le TTL par défaut peut
être modifié simplement sur pas mal de piles IP, à commencer par Linux,
donc vous avez peut-être aussi affaire à des gens qui se sont amusés à
ça. Le seul cas qui reste curieux est quand-même le TTL de 255 de B,
difficilement explicable en dehors de l'hypothèse d'un routage par un
firewall qui veut rester discret...

Cordialement,

--
Bruno Tréguier

Le 12-05-2011, Bruno Tréguier a écrit :

-Au TTL des paquets envoyés par 8.8.8.8 vers ma machine?

2ème réponse... Il s'agit du TTL des paquets qui reviennent. Un simple
test sur différentes machines montrera d'ailleurs que ça varie en
fonction de la pile IP qui est en face et du nombre de "hops" sur le
trajet, test comme celui que vous faites d'ailleurs dans la suite du
message.

Ok

Si je ping gateway, j'ai un TTL de 127

De plus en plus fort. ;-) Vous êtes sûr du chemin pris par vos paquets
quand vous pinguez les routeurs qui ne sont pas directement sur le même
brin réseau que votre machine ?

Justement, je ne suis sur de rien pour le coup. Le réseau des routeurs
m'est inaccessible. J'ai la main sur la gateway et le poste final, le
reste non.

Je sais que les routeurs ont une liberté totale quant à la modification
de ce champ, mais on peut s'attendre à ce que chaque routeur ne fasse
que décrémenter de 1 sa valeur?

Je ne sais plus où j'avais lu qu'il y avait décrémentation de 1
également à chaque seconde, mais je ne suis pas certain que tous les
routeurs implémentent cela.

j'avais lu que c'était une légende urbaine :-)

Vous savez quels sont les machines qui se "cachent" derrière A, B et C ?
Là j'ai fait des suppositions, mais bien entendu, le TTL par défaut peut
être modifié simplement sur pas mal de piles IP, à commencer par Linux,
donc vous avez peut-être aussi affaire à des gens qui se sont amusés à
ça. Le seul cas qui reste curieux est quand-même le TTL de 255 de B,
difficilement explicable en dehors de l'hypothèse d'un routage par un
firewall qui veut rester discret...

J'en arrive à cette hypothèse. J'ai l'impression qu'il y a des
équipements qui "trafiquent" les flux réseaux, mais comme je n'y ai
pas accès, il est difficile de conclure.

J'ai aussi des comportements plus que suspects liés à la MTU ce qui
me conforte dans l'hypothèse de l'existence d'un équipement particulier
(sonde IDS/IPS? firewall? bridge filtrant?)
--
Kevin

Le 12/05/2011 à 17:48, Kevin Denis a écrit :

Si je ping gateway, j'ai un TTL de 127

De plus en plus fort. ;-) Vous êtes sûr du chemin pris par vos paquets
quand vous pinguez les routeurs qui ne sont pas directement sur le même
brin réseau que votre machine ?

Justement, je ne suis sur de rien pour le coup. Le réseau des routeurs
m'est inaccessible. J'ai la main sur la gateway et le poste final, le
reste non.

Vous avez essayé un traceroute juste pour voir ? Si le routeur B se
comporte en firewall "invisible", vous ne devriez pas le voir apparaître
dans la suite des routeurs traversés (c'est un peu le but ;-) ).

Je ne sais plus où j'avais lu qu'il y avait décrémentation de 1
également à chaque seconde, mais je ne suis pas certain que tous les
routeurs implémentent cela.

j'avais lu que c'était une légende urbaine :-)

C'est tout à fait possible, personnellement je ne vois pas l'intérêt de
cette double décrémentation...

Vous savez quels sont les machines qui se "cachent" derrière A, B et C ?
Là j'ai fait des suppositions, mais bien entendu, le TTL par défaut peut
être modifié simplement sur pas mal de piles IP, à commencer par Linux,
donc vous avez peut-être aussi affaire à des gens qui se sont amusés à
ça. Le seul cas qui reste curieux est quand-même le TTL de 255 de B,
difficilement explicable en dehors de l'hypothèse d'un routage par un
firewall qui veut rester discret...

J'en arrive à cette hypothèse. J'ai l'impression qu'il y a des
équipements qui "trafiquent" les flux réseaux, mais comme je n'y ai
pas accès, il est difficile de conclure.

J'ai aussi des comportements plus que suspects liés à la MTU ce qui
me conforte dans l'hypothèse de l'existence d'un équipement particulier
(sonde IDS/IPS? firewall? bridge filtrant?)

Très possible, voire probable en effet... Quels sont les effets observés
en matière de MTU ?

Cordialement,

--
Bruno Tréguier

Le 12-05-2011, Bruno Tréguier a écrit :

Justement, je ne suis sur de rien pour le coup. Le réseau des routeurs
m'est inaccessible. J'ai la main sur la gateway et le poste final, le
reste non.

Vous avez essayé un traceroute juste pour voir ? Si le routeur B se
comporte en firewall "invisible", vous ne devriez pas le voir apparaître
dans la suite des routeurs traversés (c'est un peu le but ;-) ).

Oui, et c'est encore plus surprenant. La machine a une IP
172.16.c.d avec une gateway en 172.16.c.254
le traceroute me montre en first hop une IP en 192.168 (!!)

J'ai aussi des comportements plus que suspects liés à la MTU ce qui
me conforte dans l'hypothèse de l'existence d'un équipement particulier
(sonde IDS/IPS? firewall? bridge filtrant?)

Très possible, voire probable en effet... Quels sont les effets observés
en matière de MTU ?

Avec le ping et l'option -s et -M.
De 0 à 1450: le ping passe
de 1450 à 1500-1600(variable): j'ai le message frag needed et flag don't
fragment set
Au delà: aucun ping passe et aucun message.

Quoi qu'il en soit, avec une MTU de 1400 tout fonctionne, donc bon.
--
Kevin

Le 12/05/2011 à 22:07, Kevin Denis a écrit :

Vous avez essayé un traceroute juste pour voir ? Si le routeur B se
comporte en firewall "invisible", vous ne devriez pas le voir apparaître
dans la suite des routeurs traversés (c'est un peu le but ;-) ).

Oui, et c'est encore plus surprenant. La machine a une IP
172.16.c.d avec une gateway en 172.16.c.254
le traceroute me montre en first hop une IP en 192.168 (!!)

Ah oui, marrant... Si A est effectivement un équipement ne décrémentant
pas le TTL, ça doit donc correspondre à une IP de l'équipement B ? Quand
vous parlez de la "gateway", ça correspond à la gateway positionnée dans
la table de routage de votre poste, ou s'agit-il de l'équipement dénommé
"gateway" sur le schéma ?

J'ai aussi des comportements plus que suspects liés à la MTU ce qui
me conforte dans l'hypothèse de l'existence d'un équipement particulier
(sonde IDS/IPS? firewall? bridge filtrant?)

Très possible, voire probable en effet... Quels sont les effets observés
en matière de MTU ?

Avec le ping et l'option -s et -M.

Ping de la machine dénommée gateway sur le schéma j'imagine ?

De 0 à 1450: le ping passe
de 1450 à 1500-1600(variable): j'ai le message frag needed et flag don't
fragment set
Au delà: aucun ping passe et aucun message.

Hmmm. Là, j'ai beau retourner le problème dans tous les sens, je ne vois
pas ce qui peut provoquer ça... :-( J'ai bien essayé en faisant quelques
hypothèses sur des MTU différents sur les équipements A, B et C, et des
configurations de filtrage ICMP plus ou moins cassées (ou pas), ce qui
donne assez classiquement ce genre de symptôme, mais là, je sèche.
J'arriverais à expliquer un truc genre:

0-1450: ok
1450-1600: aucun message
+ de 1600: message fragmentation needed

Mais que les deux derniers soient inversés, là... Après un gros dodo
peut-être ? ;-)

Quoi qu'il en soit, avec une MTU de 1400 tout fonctionne, donc bon.

Y'a des fois, on est obligés de faire comme ça. Pour un lien satellite,
récemment, j'ai dû fixer arbitrairement le MTU à 1300 sur une petite
appliance à bord d'un bateau, sur conseil de l'opérateur qui ne savait
pas bien me dire si le MTU Path Discovery fonctionnerait (1300 ça paraît
bas, mais on a un certain nombre de tunnels et d'encapsulations dans
l'affaire ;-) )...

Cordialement,

--
Bruno Tréguier

Le 12/05/2011 17:04, Bruno Tréguier nous fit lire :

Je sais que les routeurs ont une liberté totale quant à la modification
de ce champ, mais on peut s'attendre à ce que chaque routeur ne fasse
que décrémenter de 1 sa valeur?

Je ne sais plus où j'avais lu qu'il y avait décrémentation de 1
également à chaque seconde, mais je ne suis pas certain que tous les
routeurs implémentent cela.

Dans la RFC sur IP (791), le TTL est en nombre de seconde.
Chaque intermediaire doit le décrementer d'au moins 1.

Dans la pratique, en dehors des liens via satellite, il est rare de
trouver un lien de plus d'une seconde, donc tout le monde décrémente de 1.
(et les rétentions internes de plus d'une seconde, je ne demande si ça
peut encore se voir (dans le cas d'un passage par une liaison lente
genre modem 9.6k ?)

Tout le monde ? Pas tout à fait.
Les tunnels utilisant leur propre TTL (ou n'en ayant pas) peuvent
(doivent ?) diviser par 2 le TTL lors de la décapsulation du paquet
qu'ils remettent en circulation.


Pour rappel, la trame Ethernet, en l'absence de Jumbo, est au mieux de
1518 octets (au niveau le plus bas). ça laisse une taille utile pour le
ping (entete IP compris) de 1500.

Si il y a quelques tunnels dans d'autres tunnels, que la MTU descende à
1450 n'est pas choquant. (IPv4 dans IPv4 nécessite au moins 20 octets
pour un nouvel entête, voire plus si il y a des options: supposons un
réglage avec 2 tunnels l'un dans l'autre.. déjà 40 octets au minimum)
(et peut être quelques octets de plus)

Pourquoi vouloir le faire alors que c'est dangereux ?
Je ne sais pas. Pour satisfaire une curiosité morbide,
par volonté nihiliste, pour ruiner le mariage d'une ex,
c'est à vous de décider maintenant.

Il est probable que de 1450 à 1500 l'une des entrée du tunnel se plaigne
si DF est levé.

Et normalement, sauf à jouer avec le réglage de la MTU en local, une
charge utile Ethernet de plus de 1500 ne devrait même pas sortir.

Et pour les trace route... ils ignorent les tunnels traversés.

D'où je déduis que la gateway 172.16.c.254 est une entrée de tunnel qui
ne décrémente pas le TTL (mode simplissime de passeur de paquet: elle
met ou enleve l'habillage en fonction du sens, mais c'est tout).
Ou bien l'adresse en 192.168 est celle de son autre interface.

Le TTL de 255 pourrait bien être le ping d'une sortie de tunnel (ou une
machine vraiment sur le LAN), avec le tunnelier qui ne touche pas le TTL
(ça le regarde, c'est mal, mais si il ne fait que du pontage de paquet,
il ignore le protocole IP et donc ne peut pas décrémenter le TTL).

Le 13/05/2011 à 18:57, Le Forgeron a écrit :

Le 12/05/2011 17:04, Bruno Tréguier nous fit lire :

Je sais que les routeurs ont une liberté totale quant à la modification
de ce champ, mais on peut s'attendre à ce que chaque routeur ne fasse
que décrémenter de 1 sa valeur?

Je ne sais plus où j'avais lu qu'il y avait décrémentation de 1
également à chaque seconde, mais je ne suis pas certain que tous les
routeurs implémentent cela.

Dans la RFC sur IP (791), le TTL est en nombre de seconde.
Chaque intermediaire doit le décrementer d'au moins 1.

Ah ben voilà. Donc ce n'est pas une légende urbaine finalement, mais
cela dit, il y a de grandes chances que peu de dispositifs implémentent
vraiment ce truc.

Dans la pratique, en dehors des liens via satellite, il est rare de
trouver un lien de plus d'une seconde, donc tout le monde décrémente de 1.

Et même dans le cas des satellites, ça doit rester assez exceptionnel:
avec un satellite géostationnaire et 1 seul rebond, le ping typique (ou
le "RTT" pour les puristes) est de 700 ms environ, en tout cas c'est ce
que j'observe la plupart du temps, et ça représente donc l'aller *et* le
retour, ce qui nous donne donc 350 ms pour un trajet. Pas de quoi
bouleverser un TTL, en somme. ;-)

J'ai actuellement 1 liaison qui transite par 2 satellites (soit un
superbe ping de 1,4 s (!), et même là, donc, on est à 700 ms par trajet.

(et les rétentions internes de plus d'une seconde, je ne demande si ça
peut encore se voir (dans le cas d'un passage par une liaison lente
genre modem 9.6k ?)

Avec du V23bis genre modem de minitel, à 75 bps en sens montant, on doit
pouvoir y arriver... :-)

Tout le monde ? Pas tout à fait.
Les tunnels utilisant leur propre TTL (ou n'en ayant pas) peuvent
(doivent ?) diviser par 2 le TTL lors de la décapsulation du paquet
qu'ils remettent en circulation.

Ah ? Jamais observé ça. Je viens de faire le test avec 2 liens que nous
avons avec l'outre-mer, et j'observe un TTL de 253 dans les 2 cas, pour
un serveur sous Solaris en face. Visiblement, ces TTL n'ont pas été
divisés par 2. Mais je prends note de cette possibilité, merci ! Ca
pourrait expliquer des trucs dans certains cas.

Cela dit, quelle est la raison technique d'un tel fonctionnement ?

Si il y a quelques tunnels dans d'autres tunnels, que la MTU descende à
1450 n'est pas choquant. (IPv4 dans IPv4 nécessite au moins 20 octets
pour un nouvel entête, voire plus si il y a des options: supposons un
réglage avec 2 tunnels l'un dans l'autre.. déjà 40 octets au minimum)
(et peut être quelques octets de plus)

Pourquoi vouloir le faire alors que c'est dangereux ?

C'est dangereux ? :-)

Je ne sais pas. Pour satisfaire une curiosité morbide,
par volonté nihiliste, pour ruiner le mariage d'une ex,
c'est à vous de décider maintenant.

Euh... Parce que parfois on est obligés ? Allez, j'ai un cas d'école
capillotracté mais bien réel: j'utilise un lien satellite reliant un
bâtiment (hydro-océanographique, au hasard) à notre réseau interne. La
mise en oeuvre du lien satellite lui-même n'est pas de notre
responsabilité, nous en sommes de simples utilisateurs, par truchement.
C'est la Marine qui s'en occupe, en fait (avec toute la tripaille qui va
avec: changement de satellite en cours de route, changements de bande
donc changement de tête d'émission/réception, gestion du masquage dû à
la mâture, nécessitant parfois des changements de route, etc., bref, que
du bonheur).

Plusieurs réseaux cohabitent, à bord. Chacun de ces réseaux utilise son
propre tunnel chiffré afin d'être étanche par rapport aux autres, on y
rajoute la VoIP, et le tout est réencapsulé dans un tunnel (chiffré lui
aussi) qui passe par la liaison satellite. Il y a donc déjà, à ce
niveau, une double encapsulation (sauf pour la VOiP). Pour des raisons
de responsabilités, entre autres, le réseau que nous relions à notre
réseau interne n'est pas côte à côte avec les autres, mais encapsulé (en
IPSec) dans l'un d'eux: du coup triple encapsulation. De quoi faire un
vrai vaudeville à partir l'une de vos hypothèses ci-dessus. ;-)

C'est également sur ce lien-là qu'actuellement, j'ai 2 rebonds
satellites, avec désencapsulation/réencapsulation du 1er tunnel au
niveau du téléport intermédiaire, et le fameux ping de 1,4 seconde.

Vous voulez savoir le pire ? Ben ça marche... Sauf que pour éviter tout
problème de MTU Path Discovery, notre opérateur au niveau de la marine
nous a conseillé de ne pas compter sur ICMP et du coup de fixer un MTU
"rase-motte" à 1300 octets. On perd un peu en bande passante utile, mais
bon, de toute façon l'idée n'était pas de faire de la visioconf dessus
non plus, hein.

Il est probable que de 1450 à 1500 l'une des entrée du tunnel se plaigne
si DF est levé.

Et normalement, sauf à jouer avec le réglage de la MTU en local, une
charge utile Ethernet de plus de 1500 ne devrait même pas sortir.

Et pour les trace route... ils ignorent les tunnels traversés.

Oui, logique effectivement, c'est transparent pour eux.

D'où je déduis que la gateway 172.16.c.254 est une entrée de tunnel qui
ne décrémente pas le TTL (mode simplissime de passeur de paquet: elle
met ou enleve l'habillage en fonction du sens, mais c'est tout).

Un truc qui fait du proxy-arp, en gros, quoi ?

Ou bien l'adresse en 192.168 est celle de son autre interface.

Le TTL de 255 pourrait bien être le ping d'une sortie de tunnel (ou une
machine vraiment sur le LAN), avec le tunnelier qui ne touche pas le TTL
(ça le regarde, c'est mal, mais si il ne fait que du pontage de paquet,
il ignore le protocole IP et donc ne peut pas décrémenter le TTL).

Ca semble cohérent...

Bonne fin de soirée !

Cordialement,

--
Bruno Tréguier