mail <\/a>!<\/li>\n<\/ul>\nEcho \/ Echo Response : Le ping !<\/h2>\nC’est quoi ?<\/h3>\n
Si vous pratiquez IP, vous ne pouvez pas ignorer le fameux PING<\/strong> ! Tous les administrateurs IP, et m\u00eame les utilisateurs, sont des \u00ab\u00a0pingueurs fous\u00a0\u00bb ! La commande PING issue du monde Unix, permet de tester l’accessibilit\u00e9 d’un \u00e9quipement IP.<\/strong><\/p>\nSur pratiquement toutes les stations IP vous pouvez entrer la commande PING<\/strong> <adresse IP de destination<\/em>>. Vous recevrez ensuite des informations \u00e0 l’\u00e9cran, dont le format varie en fonction des diff\u00e9rentes impl\u00e9mentations. Ces informations vous renseignent sur votre capacit\u00e9 \u00e0 joindre ou non l’adresse vis\u00e9e.<\/p>\nSi vous ne connaissez pas cette fonction, un petit exemple, vaut mieux qu’un grand discours ! Si vous utilisez un PC sous Windows. Cherchez dans le menu D\u00e9marrer, la fonction Commande MSDOS (souvent dans les accessoires). Dans la fen\u00eatre (noire !), qui s\u00a0\u00bbaffiche entrez : ping 127.0.0.1 (vous pinguez qui l\u00e0 ? … Si vous ne savez pas r\u00e9pondre, vous \u00eates recal\u00e9 au partiel !<\/em>). En r\u00e9ponse vous obtiendrez selon le cas :<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/PING_DOS.gif\")
<\/p>\n
\n- Request Timout<\/strong> : Pas de chance ! Le serveur ne r\u00e9pond pas ! C’est du moins ce que l’on dit souvent, mais c’est un peu simpliste ! Nous allons y revenir ! Dans notre cas, vous n’obtiendrez ce r\u00e9sultat que si vous n’avez pas de stack IP d’initialis\u00e9, ce qui m’\u00e9tonnerai beaucoup puisque vous \u00eates connect\u00e9 \u00e0 Internet pour lire cette page !<\/li>\n
- 127.0.0.1<\/strong> et des choses derri\u00e8re … : Le serveur r\u00e9pond ! Vous obtenez \u00e9galement des informations sur le d\u00e9lai d’aller-retour pour atteindre le serveur.<\/li>\n<\/ul>\n
Comment \u00e7a marche ?<\/h3>\n
Lorsque vous entrez la commande PING <@IP>, votre stack IP demande \u00e0 ICMP d’\u00e9mettre un paquet Echo<\/strong> vers l’adresse destination :<\/p>\n\n- l’\u00e9metteur formate un paquet ICMP_Echo<\/strong> comportant un num\u00e9ro d’identification, un num\u00e9ro de s\u00e9quence et quelques octets de donn\u00e9es al\u00e9atoires. Selon les impl\u00e9mentations, vous pouvez modifier les options de nombre d’octets pour visualiser le comportement du r\u00e9seau sur l’\u00e9mission de gros paquets. Par exemple, sous Windows vous pouvez modifier la taille par l’option -l.<\/li>\n
- le paquet ICMP est plac\u00e9 dans un paquet IP<\/strong>, d’adresse destination \u00e9gale \u00e0 celle que vous avez indiqu\u00e9 et d’adresse source \u00e9gale \u00e0 celle de l’\u00e9metteur.<\/li>\n
- lorsque le paquet est \u00e9mis, votre applicatif \u00ab\u00a0pingueur\u00a0\u00bb enclenche un timer<\/strong><\/li>\n
- puis il \u00e9met un nouveau paquet ICMP_Echo<\/strong> du m\u00eame format que le premier mais ayant un num\u00e9ro d’identification diff\u00e9rent. Il enclenche \u00e9galement \u00e0 son \u00e9mission un timer associ\u00e9 au paquet. Il peut r\u00e9p\u00e9ter cette op\u00e9ration plusieurs fois. Sur Windows de base, le programme \u00e9met trois paquets, cependant avec l’option -n vous pouvez modifier ce nombre<\/em>.<\/li>\n<\/ul>\n
Pour conna\u00eetre toutes les options du Ping de Windows, entrez simplement \u00ab\u00a0ping\u00a0\u00bb et validez sous les Commandes MSDOS :<\/p>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/LISTE_PING.gif\")
<\/p>\n
Les paquets ICMP_Echo, encapsul\u00e9s dans des paquets IP, sont v\u00e9hicul\u00e9s \u00e0 travers le r\u00e9seau jusqu’au destinataire. Quand le r\u00e9cepteur re\u00e7oit les paquets ICMP_Echo, il les transf\u00e8re \u00e0 son programme ICMP. Celui-va r\u00e9pondre :<\/p>\n
\n- il v\u00e9rifie le checksum<\/strong>. Si celui-ci est correct, il n’y a pas d’erreur ! (Sans blagues ?<\/em>). Il passe donc \u00e0 la s\u00e9quence suivante, sinon il jette le paquet et ne r\u00e9pond pas.<\/li>\n
- il formate un paquet ICMP_Echo_Response<\/strong> ayant les m\u00eames num\u00e9ros d’identification et de s\u00e9quence ainsi que les m\u00eames donn\u00e9es que le paquet Echo auquel il r\u00e9pond. Le num\u00e9ro d’identification permet de diff\u00e9rencier des s\u00e9quences Echo simultan\u00e9ment lanc\u00e9es depuis la m\u00eame machine vers le m\u00eame destinataire (hyper rare !<\/em>). Le num\u00e9ro de s\u00e9quence permet \u00e0 l’\u00e9metteur de rep\u00e9rer quel timer est associ\u00e9 \u00e0 l’Echo_Response re\u00e7u. L’adresse IP source du paquet IP permet de diff\u00e9rencier plusieurs \u00e9metteurs d’Echo pour un m\u00eame destinataire.<\/li>\n
- le paquet ICMP est ensuite plac\u00e9 dans un paquet IP<\/strong> d’adresse source \u00e9gale \u00e0 l’adresse de la station (le r\u00e9cepteur du paquet Echo.. Je pr\u00e9cise pour ceux qui aurait du mal \u00e0 suivre !) et d’adresse destination \u00e9gale \u00e0 l’adresse source du paquet Echo pr\u00e9c\u00e9demment re\u00e7u (qui ait l’adresse de l’\u00e9metteur du ICMP_Echo… Je pr\u00e9cise parce que j’en vois avec des yeux ronds dans le fond \u00e0 cot\u00e9 du radiateur !<\/em>).<\/li>\n<\/ul>\n
Le paquet ICMP_Echo_Response, encapsul\u00e9 dans un paquet IP, est v\u00e9hicul\u00e9 \u00e0 travers le r\u00e9seau jusqu’au destinataire. Quand celui-ci re\u00e7oit le paquet :<\/p>\n
\n- il examine le checksum<\/strong> pour v\u00e9rifier qu’il n’y a pas eu d’erreur. S’il d\u00e9tecte un erreur, le paquet est d\u00e9truit, le timer associ\u00e9 est interrompu et vous obtenez une ligne \u00ab\u00a0Request TimeOut\u00a0\u00bb.<\/li>\n
- si le checksum est bon, il examine le timer associ\u00e9<\/strong> : si le timer est arriv\u00e9 \u00e0 expiration, le paquet est d\u00e9truit. Une ligne Request Time Out aura \u00e9t\u00e9 pr\u00e9alablement retourn\u00e9 imm\u00e9diatement \u00e0 expiration du timer.<\/li>\n
- si le timer est toujours valide, le programme retourne une ligne vous indiquant la valeur du timer \u00e0 la r\u00e9ception du paquet<\/strong>. Vous obtenez ainsi le d\u00e9lai de transit aller-retour du paquet.<\/li>\n<\/ul>\n
La m\u00eame op\u00e9ration est r\u00e9p\u00e9t\u00e9e pour tous les paquets.<\/p>\n
Certaines impl\u00e9mentations d’IP retournerons une ligne \u00e0 la fin de l’\u00e9mission de tous les paquets. Celle-ci indiquera le nombre de paquets perdus (non revenus avant expiration du timer) ainsi que la valeur la plus faible, la plus grande et la moyenne du d\u00e9lai de transit.<\/p>\n
La valeur du timer est souvent param\u00e9trable, elle est par contre la m\u00eame pour tous les paquets d’une m\u00eame s\u00e9quence de \u00ab\u00a0ping\u00a0\u00bb. En effet dans certains cas il peut \u00eatre n\u00e9cessaire d’adapter ce timer (cas des liaisons satellites par exemple) \u00e0 la configuration du r\u00e9seau, sous peine de n’obtenir que des Request TimeOut, les paquets arrivant tous apr\u00e8s expiration d’un timer trop court !<\/p>\n
A quoi \u00e7a sert ?<\/h3>\n
Nous l’avons d\u00e9j\u00e0 dit : Le \u00ab\u00a0ping\u00a0\u00bb sert essentiellement \u00e0 tester l’accessibilit\u00e9 d’un \u00e9quipement IP<\/strong>. Si vous avez des r\u00e9ponses positives \u00e0 un \u00ab\u00a0ping\u00a0\u00bb vous savez que la route \u00ab\u00a0aller\u00a0\u00bb dans le r\u00e9seau, l’\u00e9quipement vis\u00e9 et la route \u00ab\u00a0retour\u00a0\u00bb (qui peut \u00eatre diff\u00e9rente de la route \u00ab\u00a0aller\u00a0\u00bb !<\/em>) sont actifs.<\/p>\nPar contre si vous n’avez pas de r\u00e9ponses vous ne savez pas lequel de ces trois \u00e9l\u00e9ments pr\u00e9sente un d\u00e9faut. Dans ce cas, vous allez \u00e9tudier les tables de routage des passerelles pour d\u00e9terminer les chemins emprunt\u00e9s et vous allez ensuite \u00ab\u00a0pinguer\u00a0\u00bb chaque \u00e9lement (passerelle<\/em>) de la route jusqu’\u00e0 ce que vous trouviez lequel ne r\u00e9pond pas !<\/p>\nATTENTION<\/strong> <\/span>: IP fonctionne en mode non connect\u00e9 et souvent on impl\u00e9mente dans le r\u00e9seau des politiques de routage dynamique. Ceci suppose que les passerelles choisissent les routes en fonction de crit\u00e8res qui leurs sont propres. En cons\u00e9quence, une route \u00ab\u00a0aller\u00a0\u00bb et une route \u00ab\u00a0retour\u00a0\u00bb pour une m\u00eame destination peuvent \u00eatre diff\u00e9rentes. La recherche d’un \u00e9l\u00e9ment d\u00e9faillant dans le r\u00e9seau (routeur ou lien<\/em>) par des \u00ab\u00a0ping\u00a0\u00bb peut, dans ce cas, s’av\u00e9rer trompeuse si on ne ma\u00eetrise pas parfaitement le routage. Vous pouvez penser qu’un lien \u00ab\u00a0aller\u00a0\u00bb vers un routeur est hors service, alors que c’est le lien \u00ab\u00a0retour\u00a0\u00bb, comme dans l’exemple ci-dessous :<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/PING_TOURNE.gif\")
<\/p>\n
\n- Le \u00ab\u00a0ping<\/strong>\u00a0\u00bb depuis A vers B ne marche pas !<\/li>\n
- Vous \u00ab\u00a0pinguez\u00a0\u00bb R1 sur son interface E0, il r\u00e9pond (normal vous \u00eates sur le m\u00eame r\u00e9seau local !)<\/li>\n
- Vous \u00ab\u00a0pinguez\u00a0\u00bb R2 sur son interface E0, il ne r\u00e9pond pas !<\/li>\n
- Vous en d\u00e9duisez que le probl\u00e8me se situe sur le lien entre R1 et R2 ou \u00e9ventuellement sur R2 !<\/li>\n<\/ul>\n
\n
C’est faux ! En fait, le probl\u00e8me se situe sur le retour R3 ! En effet R2 contacte le r\u00e9seau 10.0.0.0 via R3 !<\/p>\n
Donc … Prudence avec les localisations de d\u00e9fauts par le \u00ab\u00a0ping\u00a0\u00bb !<\/p>\n
Autres cas d’utilisation<\/h3>\n
Le ping peut \u00e9galement \u00eatre utilis\u00e9 pour :<\/p>\n
\n- mesurer des d\u00e9lais de transit<\/strong> : Il existe des outils d’administrations qui demandent \u00e0 des routeurs d’\u00e9mettre des \u00ab\u00a0ping\u00a0\u00bb et rel\u00e8vent les r\u00e9sultats de d\u00e9lais de transit pour dresser des tableaux de bords, par exemple.<\/li>\n
- mesurer une fiabilit\u00e9<\/strong> : En \u00e9mettant des longues s\u00e9quences de plusieurs centaines ou milliers de paquets cons\u00e9cutifs (attention aux capacit\u00e9s de gestion des timers simultan\u00e9s<\/em>), vous pouvez mesurer le nombre de paquets perdus et en d\u00e9duire une fiabilit\u00e9 ou un taux de perte de paquets.<\/li>\n
- simuler une charge r\u00e9seau<\/strong> pour \u00e9valuer l’impact sur les d\u00e9lais de transit et accessoirement en d\u00e9duire une bande passante bout en bout.<\/li>\n<\/ul>\n
REMARQUES SUR LE DERNIER CAS<\/strong> :<\/p>\nPour ce type de mesure on pr\u00e9f\u00e9re souvent FTP, mais dans le cas des nouvelles architectures ATM ce n’est pas toujours le meilleur choix ! En effet :<\/p>\n
\n- vous ne contr\u00f4lez pas la taille des paquets \u00e9mis par FTP<\/strong>, celui-ci ayant tendance \u00e0 remplir au maximum les segments TCP en fonction de la taille de la MTU locale (celle du LAN sur lequel l’\u00e9metteur est plac\u00e9). Cette taille peut \u00eatre diff\u00e9rente de celle qu’utilise votre application usuelle et dont vous voulez simuler le comportement. Par des \u00ab\u00a0ping\u00a0\u00bb vous pouvez fixer la taille des paquets afin de vous rapprocher de la taille de ceux \u00e9mis par votre application.<\/li>\n
- En ATM, la gestion de la bande passante est dynamique<\/strong>, c’est \u00e0 dire que vous avez un d\u00e9bit minimum garanti mais vous pouvez le d\u00e9passer (on parle de \u00ab\u00a0bursts\u00a0\u00bb<\/em>). Pour cela vous remplissez plus ou moins de cellules ATM dans le train binaire qui se pr\u00e9sente. Par contre si vous d\u00e9passez trop longtemps le d\u00e9bit mini, vos cellules sont marqu\u00e9es comme candidates \u00e0 la suppression (on dit qu’on les \u00ab\u00a0tag\u00a0\u00bb<\/em>). Si le r\u00e9seau est surcharg\u00e9, ces cellules sont supprim\u00e9es (on dit qu’on les \u00ab\u00a0drop\u00a0\u00bb<\/em>). Or si une cellule manque, le paquet IP est corrompu (ne parlons pas de la couche AAL5 !<\/em>), le segment TCP v\u00e9hiculant le FTP est donc corrompu, et il y a retransmission au niveau TCP ! Mais en ATM les cellules sont toutes petites (48 ou 47 octets utiles selon le cas<\/em>) et si votre paquet a \u00e9t\u00e9 coup\u00e9 en 10 cellules et qu’une seule a \u00e9t\u00e9 \u00ab\u00a0dropp\u00e9e\u00a0\u00bb, vous perdez le tout et il faut tout r\u00e9\u00e9mettre ! Votre transfert FTP prend donc plus de temps, donc votre d\u00e9bit utile vous semble plus petit ! En fait, vous avez simplement d\u00e9pass\u00e9 votre contrat de trafic et vous avez enclench\u00e9 les m\u00e9canismes de limitations (on appelle \u00e7a du \u00ab\u00a0shapping\u00a0\u00bb<\/em>) ! Si vous faites le m\u00eame test en TFTP (support\u00e9 par UDP, en mode non connect\u00e9, sans reprise sur erreur<\/em>) ou en utilisant le \u00ab\u00a0ping\u00a0\u00bb ICMP il est fort probable que vous mesuriez une bande passante plus cons\u00e9quente !! Etonnant non ?<\/li>\n<\/ul>\n
Destination inaccessible !<\/h2>\n
Nous avons vu dans les chapitres pr\u00e9c\u00e9dents, que les ma\u00eetres du routage dans un r\u00e9seau IP, sont les routeurs<\/strong> (ou passerelles<\/em>). Ceux-ci routent les paquets en se construisant des tables de routage qui dressent la cartographie du r\u00e9seau. Le routeur est un \u00ab\u00a0bison fut\u00e9<\/em>\u00ab\u00a0, il sait \u00e0 tous moments quelle est la meilleure route pour atteindre une destination !<\/p>\nMais parfois \u00ab\u00a0bison fut\u00e9<\/em>\u00a0\u00bb a des d\u00e9faillances ! Vous avez tous, un jour de grande affluence, au moment des d\u00e9parts en vacance, suivi un \u00ab\u00a0Itin\u00e9raire Vert\u00a0\u00bb. Certes il \u00e9tait vert dans le sens o\u00f9 il vous a amen\u00e9 en pleine campagne ! Mais vous avez ensuite vu rouge quand il vous a largu\u00e9 en plein milieu de \u00ab\u00a0Trou de nulle part<\/em>\u00a0\u00bb sans aucun panneau pour retrouver son chemin ! Et bien, IP c’est pareil ! Un paquet peut tr\u00e8s bien aboutir sur une passerelle qui ignore tout du chemin \u00e0 emprunter pour atteindre le r\u00e9seau inscrit en adresse destination !<\/p>\nMais la passerelle sait reconna\u00eetre ses erreurs (ce qui n’est pas le cas de \u00ab\u00a0bison pas fut\u00e9\u00a0\u00bb !<\/em>), elle envoie \u00e0 l’\u00e9metteur un paquet ICMP Destination Unreachable<\/strong> !!<\/p>\nL’\u00e9metteur est ainsi inform\u00e9 que le paquet n’a pas pu \u00eatre d\u00e9livr\u00e9 et que la destination est incontactable. Que fait IP ? … Rien ! S’en fiche ! Selon l’impl\u00e9mentation il pourra \u00e9ventuellement informer la couche sup\u00e9rieure que son correspondant est parti se coucher ! A elle de d\u00e9cider ce qu’elle veut faire ! TCP va insister grossi\u00e9rement en relan\u00e7ant ses informations jusqu’\u00e0 ce qu’il admette enfin que le destinataire est VRAIMENT<\/strong> incontactable. UDP, un peu fain\u00e9ant ne fera rien !<\/p>\nLe paquet ICMP Destination Unreachable permet d’informer plus pr\u00e9cis\u00e9ment l’\u00e9metteur sur la cause de la non d\u00e9livrance du paquet. Un octet de code dans le paquet permet d’indiquer :<\/p>\n
R\u00e9seau inaccessible<\/strong> (code 0) : si la destination est inaccessible parce que le r\u00e9seau n’est pas d\u00e9clar\u00e9 dans une table de routage d’une des passerelles travers\u00e9 par le paquet IP<\/p>\nHost inaccessible<\/strong> (code 1) : si la station de destination est incontactable. Le paquet a bien atteint le r\u00e9seau de destination, mais aucune station n’a r\u00e9pondu \u00e0 la requ\u00eate ARP de la passerelle du r\u00e9seau de destination.<\/p>\nProtocole inaccessible<\/strong> (code 2) : retourn\u00e9 par la station de destination, si le champ Protocole du paquet IP indique un protocole de niveau sup\u00e9rieur non g\u00e9r\u00e9 par la station. Par exemple si vous envoyez des donn\u00e9es IGRP (protocole de routage) \u00e0 une station qui n’est pas un routeur Cisco !<\/p>\nPort inaccessible<\/strong> (code 3) : retourn\u00e9 par une station qui re\u00e7oit un paquet IP, v\u00e9hiculant un message TCP ou UDP dont le num\u00e9ro de port destination est inconnu de la station (L\u00e0, c’est du niveau 4 ! Laissez tomber …<\/em>).<\/p>\nFragmentation n\u00e9cessaire, mais interdite<\/strong> (code 4) : retourn\u00e9 par une passerelle qui doit fragmenter un paquet, pour pouvoir l’encapsuler dans une trame dont la MTU est inf\u00e9rieure \u00e0 la taille du paquet, mais qui ne peut le faire car le bit DF<\/strong> (Don’t Fragment) du paquet est positionn\u00e9 \u00e0 1 ! Le paquet est jet\u00e9, et le paquet ICMP est envoy\u00e9 \u00e0 la station. Cette technique est utilis\u00e9e par TCP<\/strong> lorsqu’il tente de d\u00e9couvrir la taille minimum de la MTU sur une route (j’en ai bri\u00e9vement parler dans le chapitre pr\u00e9c\u00e9dent !<\/em>). TCP \u00e9met d’abord un paquet \u00e0 la taille de la MTU du r\u00e9seau local, s’il re\u00e7oit un ICMP Destination Unreachable code 4, il diminue la taille et ainsi de suite !<\/p>\nEchec du source routing<\/strong> (code 5) : laissez tomber ! Ce sera trop long !<\/em> Sachez que ce message est li\u00e9 au champ Option du paquet IP qui permet de mettre en place un routage impos\u00e9 par la source. L’\u00e9metteur indique par quelles passerelles doit passer le paquet … Bref ! Assez peu utilis\u00e9 !<\/p>\nPas mal ICMP Destination Unreachable ? On en apprend des choses, hein<\/em> ?<\/p>\nTime Out : Le TTL est mort !<\/h2>\nC’est quoi ?<\/h3>\n
Nous avons vu pr\u00e9c\u00e9demment que l’ent\u00eate du paquet IP pr\u00e9sentait un champ nomm\u00e9 TTL<\/strong> (T<\/strong>ime T<\/strong>o L<\/strong>ive). Lorsque dans le chapitre pr\u00e9c\u00e9dent nous avons \u00e9tudi\u00e9 la fragmentation, nous avons \u00e9voqu\u00e9 ce champ et la mani\u00e8re dont il \u00e9tait g\u00e9r\u00e9 par les machines IP. Pour rappel :<\/p>\n\n- le TTL permet d’indiquer une dur\u00e9e de vie \u00e0 un paquet IP<\/strong> afin d’\u00e9viter que le r\u00e9seau continue d’acheminer des paquets perdus<\/li>\n
- ce TTL est g\u00e9n\u00e9ralement fix\u00e9 \u00e0 255<\/strong> mais peut \u00eatre g\u00e9r\u00e9 par l’\u00e9metteur pour diminuer la port\u00e9e d’un paquet<\/li>\n
- un routeur d\u00e9cr\u00e9mente de 1 le TTL<\/strong> de tous paquets qui le traversent<\/li>\n
- lorsqu’un paquet est plac\u00e9 en file d’attente, que ce soit dans un routeur ou dans une station \u00e0 l’\u00e9mission ou \u00e0 la r\u00e9ception, le TTL est d\u00e9cr\u00e9ment\u00e9 de 1 toutes les secondes<\/strong>.<\/li>\n
- La machine qui passe \u00e0 0 le TTL d\u00e9truit le paquet correspondant<\/strong>.<\/li>\n<\/ul>\n
En cons\u00e9quence, une station ou un routeur peut avoir \u00e0 passer le TTL d’un paquet \u00e0 0. Celui qui r\u00e9alise cette op\u00e9ration enverra un paquet ICMP_TIME_OUT \u00e0 l’\u00e9metteur du paquet pour l’informer de sa destruction. Encore une fois, ce n’est pas IP qui r\u00e9agira, il transmettra l’information aux couches sup\u00e9rieures qui d\u00e9cideront de la conduite \u00e0 tenir.<\/p>\n
L’application au Trace Route<\/h3>\n
Nous avons pr\u00e9c\u00e9demment \u00e9voqu\u00e9 le \u00ab\u00a0ping<\/strong>\u00a0\u00bb comme une commande tr\u00e8s utile pour l’administration d’un r\u00e9seau IP. Une autre commande tr\u00e8s utilis\u00e9e par les fous d’IP, est le TRACE ROUTE<\/strong>.<\/p>\nLe \u00ab\u00a0trace route\u00a0\u00bb, comme son nom l’indique, permet de tracer la route emprunt\u00e9e par un paquet IP pour atteindre sa destination. En lan\u00e7ant cette commande vous recevez en r\u00e9ponse, la liste des passerelles par lesquelles est pass\u00e9 le paquet. Ce programme utilise la gestion du TTL et le m\u00e9canisme de l’ICMP_TIME_OUT <\/strong>!<\/p>\nLe principe est le suivant :<\/p>\n
\n- vous entrez sur votre \u00e9quipement IP la commande trace route <@IPdest><\/strong><\/li>\n
- le programme Trace route formate un paquet IP<\/strong> d’@IPsource \u00e9gale \u00e0 votre station et d’@IPdest \u00e9gale \u00e0 celle indiqu\u00e9e dans la ligne de commande. Le TTL du premier paquet est fix\u00e9 \u00e0 1<\/strong> (au lieu de 255).<\/li>\n
- le paquet est \u00e9mis vers la Gateway Default<\/strong> de votre station pour \u00eatre rout\u00e9 dans le r\u00e9seau<\/li>\n
- quand le routeur re\u00e7oit le paquet il d\u00e9cr\u00e9mente de 1 le TTL<\/strong>. Il le passe donc \u00e0 0, puisqu’il \u00e9t\u00e9 fix\u00e9 \u00e0 1 !<\/li>\n
- le routeur d\u00e9truit donc le paquet et \u00e9met un paquet ICMP_TIME_OUT<\/strong> vers l’\u00e9metteur du paquet. Ce paquet est encapsul\u00e9 dans un paquet IP ayant pour adresse source l’adresse de l’interface de sortie du routeur vers votre station.<\/li>\n
- l’\u00e9metteur re\u00e7oit le paquet ICMP \u00e9mis dans le paquet IP<\/strong>. Le paquet IP a pour adresse source l’adresse de la passerelle qui a d\u00e9truit le paquet. Il peut donc vous renvoyez une ligne \u00e0 l’\u00e9cran vous indiquant l’adresse de la premi\u00e8re passerelle travers\u00e9e par le paquet.<\/li>\n
- puis l’\u00e9metteur formate un deuxi\u00e8me paquet IP avec un TTL fix\u00e9 \u00e0 2<\/strong>. Cette fois le premier routeur va passer le TTL \u00e0 1 et enverra le paquet au prochain routeur indiqu\u00e9 dans sa table de routage, pour la route concern\u00e9e par le paquet IP.<\/li>\n
- le deuxi\u00e8me routeur passe le TTL \u00e0 0<\/strong> et retourne donc un ICMP_TIME_OUT qui sera re\u00e7u par l’\u00e9metteur, etc …<\/li>\n
- le process est termin\u00e9e lorsque le paquet atteint la station de destination<\/strong>. En effet dans ce cas, l’adresse source du paquet IP v\u00e9hiculant le paquet ICMP_TIME_OUT est la m\u00eame que l’adresse indiqu\u00e9e dans la ligne de commande du \u00ab\u00a0trace route\u00a0\u00bb.<\/li>\n<\/ul>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/TRACE_ROUTE.gif\")
<\/p>\n
Chaque passerelle de la route emprunt\u00e9e par les paquets IP pour atteindre l’adresse destination, aura donc, au final, transmis un paquet ICMP_TIME_OUT dans un paquet IP ayant pour adresse source l’adresse de l’interface de sortie du routeur. Vous avez ainsi le chemin emprunt\u00e9<\/strong> !<\/p>\nQuelques petites pr\u00e9cisions<\/h3>\n
Lorsque le programme \u00ab\u00a0trace route\u00a0\u00bb \u00e9met un paquet il lui associe un timer (un peu comme dans le ping). Ce timer permet de mesurer le d\u00e9lai aller-retour pour atteindre la passerelle qui placera le TTL \u00e0 0. Vous pouvez ainsi obtenir le d\u00e9lai de transit, tron\u00e7on par tron\u00e7on pour une direction donn\u00e9e<\/strong>. Le timer permet \u00e9galement de stopper le processus lorsque la route est invalide et que les passerelles ne r\u00e9pondent pas (dans ce cas m\u00eame un \u00ab\u00a0ping\u00a0\u00bb ne passerai pas, bien s\u00fbr !<\/em>).<\/p>\nLa station \u00e9mettrice peut \u00e9mettre simultan\u00e9ment des paquets IP de donn\u00e9es et des paquets relevant pas du programme trace route pour une m\u00eame destination. Ces paquets pourrait tr\u00e8s bien avoir leur TTL plac\u00e9 \u00e0 0 pendant le trajet, pour une raison quelconque. La machine IP qui passerai ce TTL \u00e0 0, retournera \u00e9galement un ICMP_TIME_OUT ! Comment l’\u00e9metteur peut-il diff\u00e9rencier les ICMP_TIME_OUT relevant du process \u00ab\u00a0trace route\u00a0\u00bb des paquets relevant du transfert de donn\u00e9es utiles ? En fait, lorsqu’une station formate un ICMP_TIME_OUT elle recopie dans ce paquet l’ent\u00eate et les 8 premiers octets du paquet IP qu’elle d\u00e9truit<\/strong>. Il y a donc suffisamment d’information dans ce paquet pour que la station \u00e9mettrice du paquet d\u00e9truit puisse identifier le paquet concern\u00e9.<\/p>\nLe message ICMP_TIME_OUT permet de diff\u00e9rencier deux causes de destruction<\/strong> du paquet par expiration du TTL, gr\u00e2ce \u00e0 un octet de code :<\/p>\n\n- Champ TTL \u00e9puis\u00e9<\/strong> (code 0) : est indiqu\u00e9 lorsqu’une machine IP a re\u00e7u le paquet avec un TTL \u00e0 1 et a donc d\u00fb le placer \u00e0 0. On suppose qu’une boucle dans le r\u00e9seau a fait tourn\u00e9 le paquet trop longtemps.<\/li>\n
- Attente trop longue au r\u00e9-assemblage<\/strong> (code 1) : est indiqu\u00e9 par une machine qui d\u00e9truit un paquet IP parce qu’elle n’a pas re\u00e7u dans les temps tous les fragments permettant de le reconstituer. Ce code est donc forc\u00e9ment \u00e9mis par le destinataire du paquet (et pas par une passerelle) puisque seul le destinataire op\u00e8re le r\u00e9-assemblage.<\/li>\n<\/ul>\n
Redirect : Tu te trompes de route !<\/h2>\nLa Gateway de sortie du LAN<\/h3>\n
Nous avons \u00e9tudi\u00e9 au chapitre 5, les bases du routage IP. Dans le paragraphe \u00ab\u00a0Sortir du r\u00e9seau<\/strong>\u00a0\u00bb nous avons expliqu\u00e9 comment une station contactait sa passerelle de sortie (Gateway Default<\/em>) pour \u00e9mettre des paquets en dehors du r\u00e9seau local.<\/p>\nMais que se passe-t-il s’il y a plusieurs routeurs sur le LAN<\/strong>, chacun d’eux desservant une ou des destination(s) particuli\u00e8re(s) ?<\/p>\nPeu de stations offrent la possibilit\u00e9 de d\u00e9clarer une passerelle sp\u00e9cifique pour une route donn\u00e9e ! A ma connaissance, seules les stations Unix (et s\u00fbrement Linux !<\/em>) permettent de d\u00e9finir une table de routage au sein d’un host IP qui n’est pas une passerelle :<\/p>\n\n- En environnement Windows 95 vous ne pouvez d\u00e9finir qu’une passerelle par d\u00e9faut<\/strong> qui sera syst\u00e9matiquement utilis\u00e9e pour acheminer le trafic sortant du LAN (