Différences

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

--- 130netfilter:30-masquerade [le 02/04/2025 à 15:01] – [Masquerading] 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:
@@ Ligne 50: / Ligne 50: @@
 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 [[055-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.
+  * 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 ?
@@ Ligne 88: / Ligne 88: @@
     Data (48 bytes)
 </pre></html>
-Nous avons évoqué [[055-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é.
+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:
@@ Ligne 109: / Ligne 109: @@
 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.