Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 045-icmpv4:020-erreurs [le 04/10/2025 à 15:53] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ 045-icmpv4:020-erreurs [le 04/10/2025 à 15:53] (Version actuelle) – ↷ Page déplacée de 055-icmpv4:020-erreurs à 045-icmpv4:020-erreurs prof
@@ Ligne 1: / Ligne 1: @@
+====== Destinataire inaccessible  ======
+Il y a une très grande variété de raisons pour qu'un destinataire soit inaccessible. Il peut:
+  * exister mais ne pas avoir le port concerné ouvert;
+  * ne pas exister du tout;
+  * exister, mais inaccessible à cause d'un défaut de routage;
+  * exister mais refuser le dialogue;
+  * le réseau, tout simplement, n'est pas accessible;
+  * etc.
+Dans ces cas de figure, le type ICMP = 3, c'est le code qui va définir la nature de l'échec. Voici quelques exemples:
+===== Host unreachable =====
+Premier exemple où ''192.168.60.252'' cherche à faire un ping sur ''192.168.65.1''. C'est une adresse privée, pas routable sur le net et n'existant pas sur le réseau local. Rappelons que 192.168.60.0/24 dispose de la passerelle par défaut ''192.168.60.254''. Voici (en résumé) ce que capture Wireshark sur l'action:
+<html><pre class="code">
+No.   Source                Destination           Protocol Info
+    <span class="hly">192.168.60.252</span>        <span class="hlo">192.168.65.1</span>          ICMP     Echo (ping) request
+    <span class="bhln">192.168.60.254</span>        <span class="hly">192.168.60.252</span>        ICMP     Destination unreachable
+Internet Control Message Protocol
+<span class="hlg">    Type: 3 (Destination unreachable)
+    Code: 1 (Host unreachable)</span>
+</pre</html>
+C'est la passerelle qui répond que la destination n'est pas accessible, ce que l'on savait compte tenu de ce qui a été dit plus haut. Ici nous avons le type 3 avec le code 1.
+Cependant, toutes ces erreurs ne seront pas forcément signalées par ICMP. Par exemple si l'on cherche a établir une connexion TCP sur le port 80 d'un nœud qui n'a pas ouvert ce port, c'est TCP qui signalera le problème avec un [RST-ACK] en réponse au [SYN] envoyé par le client.
+Une station du réseau local 192.168.60.0/24 cherche à joindre un serveur HTTP sur 192.168.60.252, mais il n'y a pas de serveur HTTP ouvrant le port 80 sur ce nœud. Si un client web cherche à joindre ''http://192.168.60.252'', il recevra, certes, un message d'erreur. Cependant wireshark voit passer ceci:
+<html><pre class="code">
+No. Source             Destination      Protocol  Info
+  192.168.60.47      192.168.60.252   <span class="bhly">TCP       56196 → 80 [SYN]</span>
+  192.168.60.252     192.168.60.47    <span class="bhlo">TCP       80 → 56196 [RST, ACK]</span>
+</pre></html>
+Pas besoin de développer davantage, tout se passe par TCP.
+===== Port unreachable =====
+Si l'on y ajoute maintenant un un pare-feu((avec ''iptables'', en ajoutant la règle ''iptables -A INPUT -p tcp -m tcp --dport 80 -j REJECT''. Nous verrons lors de l'étude d'un pare-feu qu'il est possible de renvoyer à peu près tous les codes ICMP relatifs au type 3)) qui rejette explicitement les connexions sur le port 80. Voici ce que voit (en résumé) Wireshark sur l'action:
+<html><pre class="code">
+<span class="hly"><b>No.  Source         Destination           Protocol  Info
+  192.168.60.47  192.168.60.252        TCP       47882 → 80 [SYN]</b>
+Internet Protocol Version 4, Src: 192.168.60.47, Dst: 192.168.60.252
+Transmission Control Protocol, Src Port: 47882, Dst Port: 80, Seq: 0, Len: 0
+    Source Port: 47882
+    Destination Port: 80</span>
+<span class="hlo"><b>No.  Source          Destination           Protocol Info
+  192.168.60.252  192.168.60.47         ICMP     Destination unreachable (Port unreachable)</b>
+<b>Internet Protocol</b> Version 4, Src: 192.168.60.252, Dst: 192.168.60.47
+Internet Control Message Protocol
+<b>    Type: 3 (Destination unreachable)
+    Code: 3 (Port unreachable)</b>
+    Transmission Control Protocol, Src Port: 47882, Dst Port: 80, Seq: 1180073534</span>
+</pre></html>
+Ici nous avons toujours le type 3, mais avec le code 3.
+===== TTL expired =====
+Sans développer le fonctionnement de la commande ''traceroute'', voyons ce que Wireshark capture sur le premier «hop» d'un ''traceroute www.debian.org'':
+<html><pre class="code">
+No.  Source           Destination           Protocol Info
+  192.168.60.252   <span class="hly"><b>130.89.148.77</b>         UDP</span>      39659 → 33434 Len=32
+  <span class="hlo"><b>192.168.60.254</b>   192.168.60.252        <b>ICMP</b></span>     Time-to-live exceeded
+</pre></html>
+La source (''192.168.60.252'')envoie un datagramme (UDP) sur la cible ''130.89.148.77'' et la passerelle par défaut (''192.168.60.254'') répond avec un message ICMP ''Time-to-live exceeded''
+//**???**//
+Dans le datagramme de départ il y a au niveau IP:
+<html><pre class="code">
+<span class="hly">Internet Protocol Version 4, Src: 192.168.60.252, Dst: 130.89.148.77</span>
+    ...
+    <span class="bhly">Time to Live: 1</span>
+    ...
+    Protocol: UDP (17)
+</pre></html>
+Rappelons-nous ce champ «Time-to-mive» dans les paquets IP. Ici le pauvre, il n'a qu'un point de vie :-(. Nous avions dit que la première chose que faisait un routeur, c'était de décrémenter ce TTL quand le paquet arrivait et de prévenir la source si ce TTL devenait nul.
+C'est ce qu'il se passe ici sur la première passerelle rencontrée, c'est-à-dire notre passerelle par défaut ''192.168.60.254''.
+Observons le détail ICMP de la réponse:
+<html><pre class="code">
+<span class="hly">Internet Control Message Protocol</span>
+    <span class="bhlo">Type: 11</span> (Time-to-live exceeded)
+    <span class="bhlo">Code: 0</span> (Time to live exceeded in transit)
+    ...
+    <span class="hly">Internet Protocol Version 4, Src: 192.168.60.252, Dst: 130.89.148.77</span>
+    ...
+</pre></html>
+Notre passerelle par défaut a donc fait son travail, elle a décrémenté le TTL du paquet UDP, qui est tombé à 0 et donc la passerelle nous en a informé avec le message ICMP de type 11 et de code 0: «Temps de vie du datagramme dépassé».
+Voilà le principe de base du tracé de route. Le coup suivant, la source va envoyer encore un datagramme UDP vers la cible, mais avec un TTL de 2, etc.