https://irp.nain-t.net/ 2026-04-29T17:30:23+00:00 https://irp.nain-t.net/ https://irp.nain-t.net/lib/exe/fetch.php/wiki:dokuwiki.svg text/html 2025-04-05T16:40:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:10-fonction?rev=1743871256&do=diff Le cœur du système Netfilter est un cadriciel (framework) implémentant un pare-feu au sein du noyau Linux à partir de la version 2.4 de ce dernier. Il prévoit des accroches (hooks) dans le noyau pour l'interception et la manipulation des paquets réseau lors des appels des routines de réception ou d'émission des paquets des interfaces réseau. text/html 2025-04-04T07:00:36+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:20-iptables?rev=1743750036&do=diff IPtables Pour manipuler les poignées de Netfilter, les outils «iptables» ont été développés à partir du noyau Linux 2.4, à partir de 1998. Avant ça, il y a eu d'abord «ipfwadm» avec les noyaux 2.0, très rudimentaire, puis «ipchains» avec les noyaux 2.2. text/html 2025-10-04T15:53:19+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:30-masquerade?rev=1759593199&do=diff Le suivi de connexions Le module kernel «conntrack» est absolument essentiel pour Netfilter. Il entre en jeudans de nombreuses situations: * le masquage d'adresses bien sûr, * 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. text/html 2025-10-04T16:00:07+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:30-nftables?rev=1759593607&do=diff Nftables Le couple Netfilter/Iptables dont le projet fut initié par Paul “Rusty” Russell au tout début de ce siècle. Si Netfilter reste d'actualité en évoluant au fil du temps, Iptables, de l'aveu même de son initiateur en était arrivé à un point où toute évolution devenait problématique, le code devenant difficile à maintenir et les commandes trop nombreuses (iptables, ip6tables, ebtables, arptables text/html 2025-06-20T14:39:05+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:600-reprise-sous-reseau?rev=1750430345&do=diff Et un routeur Reprenons une maquette classique: [Serveur HTTP public] Notre modem transmet au routeur NAT une unique adresse IPv4 et une délégation /64 IPv6. L'ensemble Modem/8outeur NAT/switch ressemble furieusement à ce qui est habituellement inclus dans une «Box», mais nous allons nous en passer pour pouvoir maîtriser complètement cet ensemble. text/html 2025-06-20T14:38:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:610-netfilter-plus?rev=1750430331&do=diff Le NAT D'une manière générale, le NAT est utile surtout en IPv4, puisqu'en IPv6, chaque nœud est potentiellement directement connecté à l'internet. Le MASQUERADE (masquage d'adresse) est donc un «source NAT» un peu plus sophistiqué puisqu'il doit gérer correctement les retours. C'est text/html 2025-03-29T09:57:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://irp.nain-t.net/doku.php/130netfilter:start?rev=1743242233&do=diff Netfilter, Iptables, Nftables Au début était «ipfwadm» avec les noyaux 2.0, très rudimentaire, puis ipchains avec les noyaux 2.2. Très rapidement, ce dernier a montré ses limites conceptuelles et a laissé la place au couple Netfilter/Iptables à partir du noyau 2.4, Iptables pouvant être présenté comme la face avant de Netfilter, et qui est dorénavant remplacé par 130netfilter index