Différences

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

--- 130netfilter:30-masquerade [le 02/04/2025 à 13:31] – prof
+++ 130netfilter:30-masquerade [le 04/10/2025 à 15:53] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. prof
@@ Ligne 7: / Ligne 7: @@
 ===== Masquerading =====
-La cible «MASQUERADE» du «POSTROUTING», c'est du NAT (Network Address Translation) juste un peu plus sophistiqué.  Il mérite que l'on se penche sur son fonctionnement en partant d'un exemple simple. Une station de notre LAN vert 192.168.61.101 effectue un ping sur 172.127.20.195 et dans le même temps, une autre station: 192.168.61.102 fait la même chose, mais sur 51.68.121.59. Les paquets doivent donc transiter par notre routeur NAT qui dispose de l'adresse 192.168.61.1 dans le LAN vert et de 192.168.60.200 dans le LAN orange.
+La cible «MASQUERADE» du «POSTROUTING», c'est du NAT (Network Address Translation) et plus précisément du DNAT (Destination NAT) juste un peu plus sophistiqué.  Il mérite que l'on se penche sur son fonctionnement en partant d'un exemple simple. Une station de notre LAN vert 192.168.61.101 effectue un ping sur 172.127.20.195 et dans le même temps, une autre station: 192.168.61.102 fait la même chose, mais sur 51.68.121.59. Les paquets doivent donc transiter par notre routeur NAT qui dispose de l'adresse 192.168.61.1 dans le LAN vert et de 192.168.60.200 dans le LAN orange.
 Wireshark espionne ce qu'il se passe sur les deux côtés du routeur:
 <html><pre class="code">
 No. Source            Destination        Info
-  192.168.61.102    51.68.121.59       Echo (ping) request
+<span class="hly"> 3  192.168.61.102    51.68.121.59       Echo (ping) request</span>
-  192.168.60.200    51.68.121.59       Echo (ping) request)
+<span class="hlo"> 1  192.168.60.200    51.68.121.59       Echo (ping) request)
-  51.68.121.59      192.168.60.200     Echo (ping) reply
+  51.68.121.59      192.168.60.200     Echo (ping) reply</span>
-  51.68.121.59      192.168.61.102     Echo (ping) reply
+<span class="hly"> 4  51.68.121.59      192.168.61.102     Echo (ping) reply</span>
+<span class="hlb"> 6  192.168.61.101    172.217.20.195     Echo (ping) request</span>
- No. Source            Destination        Info
+<span class="hlg"> 5  192.168.60.200    172.217.20.195     Echo (ping) request
-  192.168.61.101    172.217.20.195     Echo (ping) request
+  172.217.20.195    192.168.60.200     Echo (ping) reply</span>
-  192.168.60.200    172.217.20.195     Echo (ping) request
+<span class="hlb"> 7  172.217.20.195    192.168.61.101     Echo (ping) reply</span>
-  172.217.20.195    192.168.60.200     Echo (ping) reply
-  172.217.20.195    192.168.61.101     Echo (ping) reply
 </pre></html>
 Les trames ont été reclassées pour faciliter la lecture.
   - La première trame  (ping request) est vue du côté vert:
-    * la source est bien la station  51.68.121.59,
+    * la source est bien la station 192.168.61.102 ,
-    * la cible est bien le nœud 194.177.211.216.
+    * la cible est bien le nœud 51.68.121.59.
   - La deuxième trame , c'est toujours le ping request, mais vu du côté orange:
     * la cible est bien toujours 51.68.121.59,
     * la source a changé, c'est maintenant 192.168.60.200, donc l'adresse du routeur dans le LAN orange.\\  Il y a eu masquage de l'adresse de la vraie source par celle de la sortie du routeur.
   - la troisième trame, c'est la réponse de la cible (ping reply) mais elle s'adresse au routeur côté orange
-  - la quatrième trame, c'est toujours la réponse de la cible, cette fois-ci à la vraie source.
+  - la quatrième trame, c'est toujours la réponse de la cible, cette fois-ci à la vraie source. Le système de masquage a bien repéré que cette réponse ne concernait pas le serveur mais la station initiale, il change donc l'adresse de destination et passe le paquet transformé.
 Dans le même temps le même processus se produit entre 192.168.61.101 et 172.217.20.195 et le routeur ne mélange pas les deux processus qui sont pourtant formellement identiques. Par quel prodige ?
-C'est le module «conntrack» qui fait le travail
+C'est le module «conntrack» qui fait le travail et il existe un outil spécifique, nommé justement ''conntrack'':
-Il existe un outil spécifique, nommé ''conntrack'':
 //The  conntrack utility provides a full-featured userspace interface to the Netfilter connection tracking system...//
-Il va permettre d'y voir plus clair en affichant la table des suivis de connexion du module kernel «conntrack»
+Celui-ci va permettre d'y voir plus clair en affichant la table des suivis de connexion du module kernel «conntrack»
 <html><pre class="code">
 <b>conntrack --dump --any-nat</b>
-icmp     1 19 src=192.168.61.101 dst=172.217.20.195 type=8 code=0 id=613 src=172.217.20.195 dst=192.168.60.200 type=0 code=0 id=613 mark=0 use=1
+<b>icmp</b>     1 19 <span class="hly">src=192.168.61.101</span> <span class="hlg">dst=172.217.20.195</span> <span class="hly">type=8 code=0</span> <span class="hlr">id=613</span> <span class="hlg">src=172.217.20.195</span> <span class="hly">dst=192.168.60.200</span> <span class="hlg">type=0 code=0</span> <span class="hlr">id=613</span> mark=0 use=1
 icmp     1 18 src=192.168.61.102 dst=51.68.121.59   type=8 code=0 id=889 src=51.68.121.59   dst=192.168.60.200 type=0 code=0 id=889 mark=0 use=1
 </pre></html>
+Chaque ligne correspond à un échange spécifique.
+Déjà, conntrack a repéré qu'il s'agit d'une trame contenant de l'ICMP et identifie dans les deux cas.
+La première ligne concerne l'échange entre  192.168.61.101 et 172.217.20.195:
+  * dans la première moitié de la ligne type=8 code=0 correspond au ping request [[045-icmpv4:005-messages|(déjà oublié ?)]]. On ne sait pas encore ce qu'est ce ''id=613'' que l'on retrouve identique dans la seconde moitié de la ligne.
+  * La seconde moitié, avec type=0 code=0 indique que c'est le ping reply.
+Dans la seconde ligne, nous retrouvons l'équivalent pour le couple 192.168.61.101 - 172.217.20.195, mais avec un id=889. Pas besoin de chercher longtemps pour comprendre que c'est cet identifiant qui permet à conntrack de ne pas se mélanger les adresses. Mais d'où vient cet identifiant ?
+<html><pre class="code">
+<b>Frame 6:</b>
+...
+Internet Protocol Version 4, Src: 192.168.61.101, Dst: 172.217.20.195
+...
+<span class="hly">    Source Address: 192.168.61.101
+    Destination Address: 172.217.20.195</span>
+...
+Internet Control Message Protocol
+<span class="hly">    Type: 8 <b>(Echo (ping) request)</b>
+    Code: 0</span>
+    Checksum: 0x83bf [correct]
+<span class="bhlr">    Identifier (BE): 613 (0x0265)</span>
+    Identifier (LE): 25858 (0x6502)
+    Sequence Number (BE): 1 (0x0001)
+    Sequence Number (LE): 256 (0x0100)
+    <b>[Response frame: 7]</b>
+    Timestamp from icmp data: Apr  1, 2025 11:27:40.000000000 CEST
+    Data (48 bytes)
+<b>Frame 7:</b>
+...
+Internet Protocol Version 4, <span class="hlg">Src: 172.217.20.195, Dst: 192.168.61.101</span>
+...
+Internet Control Message Protocol
+<span class="hlg">    Type: 0 <b>(Echo (ping) reply)</b>
+    Code: 0</span>
+    Checksum: 0x8bbf [correct]
+<span class="bhlr">    Identifier (BE): 613 (0x0265)</span>
+    Identifier (LE): 25858 (0x6502)
+    Sequence Number (BE): 1 (0x0001)
+    Sequence Number (LE): 256 (0x0100)
+    Timestamp from icmp data: Apr  1, 2025 11:27:40.000000000 CEST
+    Data (48 bytes)
+</pre></html>
+Nous avons évoqué [[045-icmpv4:005-messages|plus haut]] que les en-têtes ICMP variaient en fonction du message. Il apparaît que dans le cas du ping, un champ «Sequence Number» y est ajouté.
+En résumé, conntrack dans cet exemple:
+  - identifie un message ICMP de type ping,
+  - relève son numéro de séquence,
+  - relève les adresses source et cible
+  - les met en relation dans sa table de données pour ne pas mélanger les connexions.
+En réalisant une étude similaire , nous pourrons mettre en évidence les stratégies pour un dialogue UDP ou TCP
+Le client 192.168.61.102 effectue une requête http sur 51.68.121.59 puis interroge le DNS 8.8.8.8. Les traces se retrouvent dans le conntrack:
+<html><pre class="code">
+<b>conntrack --dump --any-nat</b>
+<span class="hly">udp      17 25 src=192.168.61.102 dst=8.8.8.8 <b>sport=36512</b> dport=53 src=8.8.8.8 dst=192.168.60.200 sport=53 <b>dport=36512</b> mark=0 use=1
+udp      17 25 src=192.168.61.102 dst=8.8.8.8 <b>sport=50725</b> dport=53 src=8.8.8.8 dst=192.168.60.200 sport=53 <b>dport=50725</b> mark=0 use=1
+udp      17 25 src=192.168.61.102 dst=8.8.8.8 <b>sport=48203</b> dport=53 src=8.8.8.8 dst=192.168.60.200 sport=53 <b>dport=48203</b> mark=0 use=1</span>
+<span class="hlo">tcp      6 38 TIME_WAIT src=192.168.61.102 dst=51.68.121.59 <b>sport=56092</b> dport=80 src=51.68.121.59 dst=192.168.60.200 sport=80 <b>dport=56092</b> [ASSURED] mark=0 use=1</span>
+conntrack v1.4.7 (conntrack-tools): 4 flow entries have been shown.
+</pre></html>
+Aussi bien en UDP qu'en TCP, les numéro de port de la source sont suffisants pour identifier les couples qui discutent.
+Bien entendu, la table de suivi de connexions se rafraîchit avec les nouvelles connexions, mais efface également celles qui n'ont plus été utilisées pendant «un certain temps»
+L'outil ''conntrack'' permet d'étudier encore plus en profondeur ce que le kernel voit passer à la condition que des règles de filtrage mettant en œuvre le suivi de connexions soient activées. Si le cœur vous en dit:
+  apt install conntrack
+  man conntrack
+-)
+===== Les connexions «RELATED» =====
+C'est un cas relativement peu fréquent, qui n’apparaît qu'avec certains protocoles applicatifs comme FTP où une connexion assure les commandes FTP et que ces dernières peuvent initier des connexion annexes pour le transfert de données. Voir l'étude du protocoel FTP pour plus de détails.