Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
| 130netfilter:30-masquerade [le 01/04/2025 à 15:46] – prof | 130netfilter:30-masquerade [le 04/10/2025 à 15:53] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. prof | ||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| - | ====== Le masquage d' | + | ====== Le suivi de connexions ====== |
| - | La cible «MASQUERADE» du «POSTROUTING», | + | Le module kernel «conntrack» est absolument essentiel pour Netfilter. Il entre en jeudans de nombreuses situations: |
| + | * le masquage d' | ||
| + | * la détection des états de connexions NEW, RELATED, ESTABLISHED et ceci aussi bien sur des «vraies» connexions en mode TCP que dans des «fausses» en UDP, puisque l'on sait que les datagrammes sont envoyés sans préavis si accusé-réception. «Deviner» une pseudo connexion UDP n'est donc pas évident. | ||
| + | |||
| + | Quelques manipulations permettront de mieux comprendre le processus. | ||
| + | ===== Masquerading | ||
| + | |||
| + | La cible «MASQUERADE» du «POSTROUTING», | ||
| Wireshark espionne ce qu'il se passe sur les deux côtés du routeur: | Wireshark espionne ce qu'il se passe sur les deux côtés du routeur: | ||
| < | < | ||
| No. Source | No. Source | ||
| - | 3 192.168.61.102 | + | <span class=" |
| - | | + | <span class=" |
| - | | + | |
| - | | + | <span class=" |
| - | + | <span class=" | |
| - | No. Source | + | <span class=" |
| - | 6 192.168.61.101 | + | |
| - | | + | <span class=" |
| - | | + | |
| - | | + | |
| </ | </ | ||
| Les trames ont été reclassées pour faciliter la lecture. | Les trames ont été reclassées pour faciliter la lecture. | ||
| - La première trame (ping request) est vue du côté vert: | - La première trame (ping request) est vue du côté vert: | ||
| - | * la source est bien la station | + | * la source est bien la station |
| - | * 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 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 cible est bien toujours 51.68.121.59, | ||
| * la source a changé, c'est maintenant 192.168.60.200, | * la source a changé, c'est maintenant 192.168.60.200, | ||
| - la troisième trame, c'est la réponse de la cible (ping reply) mais elle s' | - la troisième trame, c'est la réponse de la cible (ping reply) mais elle s' | ||
| - | - 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' |
| 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 ? | 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 |
| - | + | ||
| - | Il existe un outil spécifique, | + | |
| //The conntrack utility provides a full-featured userspace interface to the Netfilter connection tracking system...// | //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 |
| < | < | ||
| < | < | ||
| - | 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</ |
| icmp 1 18 src=192.168.61.102 dst=51.68.121.59 | icmp 1 18 src=192.168.61.102 dst=51.68.121.59 | ||
| </ | </ | ||
| + | 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' | ||
| + | * dans la première moitié de la ligne type=8 code=0 correspond au ping request [[045-icmpv4: | ||
| + | * La seconde moitié, avec type=0 code=0 indique que c'est le ping reply. | ||
| + | Dans la seconde ligne, nous retrouvons l' | ||
| + | < | ||
| + | < | ||
| + | ... | ||
| + | Internet Protocol Version 4, Src: 192.168.61.101, | ||
| + | ... | ||
| + | <span class=" | ||
| + | Destination Address: 172.217.20.195</ | ||
| + | ... | ||
| + | Internet Control Message Protocol | ||
| + | <span class=" | ||
| + | Code: 0</ | ||
| + | Checksum: 0x83bf [correct] | ||
| + | <span class=" | ||
| + | Identifier (LE): 25858 (0x6502) | ||
| + | Sequence Number (BE): 1 (0x0001) | ||
| + | Sequence Number (LE): 256 (0x0100) | ||
| + | < | ||
| + | Timestamp from icmp data: Apr 1, 2025 11: | ||
| + | Data (48 bytes) | ||
| + | | ||
| + | < | ||
| + | ... | ||
| + | Internet Protocol Version 4, <span class=" | ||
| + | ... | ||
| + | Internet Control Message Protocol | ||
| + | <span class=" | ||
| + | Code: 0</ | ||
| + | Checksum: 0x8bbf [correct] | ||
| + | <span class=" | ||
| + | Identifier (LE): 25858 (0x6502) | ||
| + | Sequence Number (BE): 1 (0x0001) | ||
| + | Sequence Number (LE): 256 (0x0100) | ||
| + | Timestamp from icmp data: Apr 1, 2025 11: | ||
| + | Data (48 bytes) | ||
| + | </ | ||
| + | Nous avons évoqué [[045-icmpv4: | ||
| + | | ||
| + | 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: | ||
| + | < | ||
| + | < | ||
| + | <span class=" | ||
| + | udp 17 25 src=192.168.61.102 dst=8.8.8.8 < | ||
| + | udp 17 25 src=192.168.61.102 dst=8.8.8.8 < | ||
| + | <span class=" | ||
| + | conntrack v1.4.7 (conntrack-tools): | ||
| + | </ | ||
| + | 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' | ||
| + | apt install conntrack | ||
| + | man conntrack | ||
| + | 8-) | ||
| + | ===== Les connexions «RELATED» ===== | ||
| + | C'est un cas relativement peu fréquent, qui n’apparaît qu' | ||
Le suivi de connexions: Dernière modification le: 01/04/2025 à 15:46 par prof