L'Internet Rapide et Permanent

NetFilter avec IPtables n'a pas du tout la même architecture, le fonctionnement est différent, même si la syntaxe d'IPtables peut paraître proche de celle d'IPchains.

En particulier, les chaînes INPUT et OUTPUT ne contrôlent pas tout ce qui entre et sort de la passerelle, routage compris, mais uniquement ce qui entre en direction de la passerelle elle-même et sort de la passerelle elle-même. Entendez par là que tout le trafic entre le réseau privé masqué par le NAT et l'Internet ne sera aucunement influencé par ces deux chaînes. Nous verrons en détail plus loin pourquoi et comment.

Finalement, le meilleur conseil à donner aux utilisateurs d'IPchains, c'est d'oublier purement et simplement tout ce qu'ils savent sur le sujet…

Avec les versions 2.2.x, nous avions l'excellent outil gfcc qui permettait de faire à peu près tout ce qu'il était possible de faire avec IPchains. Malheureusement, avec IPtables, je n'ai pas encore trouvé d'outil équivalent à l'heure où j'écris ces lignes. Essayez de voir avec knetfilter, mais ce n'est pas du tout la même chose.

La machine Linux dispose de deux interfaces Ethernet. Ici :

• Eth0 sur le réseau local (privé) ;
• Eth1 sur l'Internet via le modem câble du fournisseur d'accès. Cette interface, le plus souvent, sert de support à PPPoE.

Il faut bien comprendre qu'a priori, il peut entrer et sortir des données de chaque interface.

• Il peut entrer et sortir des données par Eth0, parce qu'un client du réseau local établit une connexion avec un service installé sur la passerelle, Samba par exemple, pour le partage de fichiers avec Windows ;
• Il peut entrer et sortir des données par Eth1 (ou la connexion ppp qui y est associée) parce qu'un client situé sur le Net établit une connexion avec un service installé sur la passerelle, une session SSH ou telnet par exemple (SSH, c'est mieux…). Il peut se faire aussi que cette connexion s'établisse à votre insu, parce qu'un pirate est en train de prendre possession de votre machine (mais ceci est une autre histoire, développée au chapitre de la sécurité) ;
• Il peut se faire également qu'une connexion s'établisse entre un poste du réseau privé et un serveur situé sur le Net. Dans ce cas, les paquets entreront par une interface et sortiront par l'autre.
• En toute rigueur, il est également possible qu'une connexion s'établisse entre un client situé sur le Net et un serveur situé sur votre réseau privé (si si, c'est possible aussi, bien que dans le cadre d'un réseau domestique, ce ne soit pas nécessaire, ni même souhaitable). Là aussi, les paquets qui entrent par une interface sortiront par l'autre.

Quel que soit le cas de figure vu plus haut, dans ce qui suit, nous ne ferons pas de ségrégation sur l'interface par laquelle les paquets entrent ni l'interface par laquelle les paquets sortent. Cette ségrégation interviendra éventuellement dans les règles que nous écrirons avec IPtables.

En tout état de cause, dans l'explication qui suit, quelles que soient l'origine et la destination des paquets, ils vont entrer dans la pile de protocoles IP par le même point et en sortir par le même autre point.  Netfilter se présente comme une série de 5 « hooks » (points d'accrochage), sur lesquels des modules de traitement des paquets vont se greffer. Ces points sont :

• NF_IP_PRE_ROUTING ;
• NF_IP_LOCAL_IN ;
• NF_IP_FORWARD ;
• NF_IP_POSTROUTING ;
• NF_IP_LOCAL_OUT.

La branche gauche représente le trajet des paquets qui entrent et qui sortent vers et depuis un processus local (SMB, FTP, HTTP, etc.). La branche de droite représente le trajet des paquets qui  traversent notre passerelle dans sa fonction de routeur.

Que l'on peut représenter autrement ainsi :

Attention toutefois, ces diagrammes sont faux, dans la mesure où ils sont largement simplifiés. Leur but est uniquement de montrer où Netfilter vient interagir avec la pile IP, en aucun cas, il ne représente l'architecture complète de la pile IP.

À travers ces cinq points d'insertion, Netfilter va être capable :

• d'effectuer des filtrages de paquets, principalement pour assurer des fonctions de Firewall. On pourra par exemple interdire à tous les paquets venant de l'Internet et s'adressant au port 80 (HTTP) de passer. Notre serveur APACHE est un serveur Intranet et ne doit pas être accessible depuis l'extérieur ;
• d'effectuer des opérations de NAT (Network Address Translation). Ces fonctions sont particulièrement utiles lorsque l'on veut faire communiquer tout ou partie d'un réseau privé, monté avec des adresses IP privées (192.168.x.x par exemple) avec l'Internet ;
• d'effectuer des opérations de marquage des paquets, pour leur appliquer un traitement spécial. Ces fonctionnalités sont particulièrement intéressantes sur une passerelle de réseau d'entreprises, un peu moins pour notre cas de réseau domestique.

Netfilter dispose d'une commande à tout faire : IPtables. Cette commande va permettre, entre autres, d'écrire des chaînes de règles dans des tables. Il y a dans Netfilter trois tables qui correspondent aux trois principales fonctions vues plus haut.

Cette table va contenir toutes les règles qui permettront de filtrer les paquets. Cette table contient trois chaînes :

• la chaîne INPUT.
  Cette chaîne décidera du sort des paquets entrant localement sur l'hôte ;
• la chaîne OUTPUT.
  Ici, ce ne sont que les paquets émis par l'hôte local qui seront filtrés ;
• la chaîne FORWARD.
  Enfin, les paquets qui traversent l'hôte, suivant les routes implantées, seront filtrés ici.

Cette table permet d'effectuer toutes les translations d'adresses nécessaires.

• La chaîne PREROUTING.
  Elle permet de faire de la translation d'adresse de destination. Cette méthode est intéressante si l'on veut faire croire au monde extérieur, par exemple, qu'il y a un serveur WEB sur le port 80 de la passerelle, alors que celui-ci est hébergé par un hôte du réseau privé, sur le port 8080.
• La chaîne POSTROUTING.
  Elle permet de faire de la translation d'adresse de la source, comme du masquage d'adresse, la méthode classique pour connecter un réseau privé comme client de l'Internet, avec une seule adresse IP publique.
• La chaîne OUTPUT.
  Celle-ci va permettre de modifier la destination de paquets générés localement (par la passerelle elle-même).

Cette table permet le marquage des paquets entrants (PREROUTING) et générés localement (OUTPUT). Le marquage de paquets va permettre un traitement spécifique des paquets marqués dans les tables de routage avec IPROUTE 2. Ceci nous mènerait trop loin. Si vous êtes intéressé par cette question, voyez à ce sujet le document : Linux Advanced Routing and Traffic Control HOWTO.

Depuis la version 2.4.18 du noyau, d'autres tables ont été rajoutées sur tous les hooks. Nous avons ainsi à notre disposition les tables supplémentaires INPUT, POSTROUTING et FORWARD

Les chaînes sont des ensembles de règles que nous allons écrire dans chaque table. Ces chaînes vont permettre d'identifier des paquets qui correspondent à certains critères.

Les cibles enfin sont des sortes d'aiguillages qui dirigeront les paquets satisfaisant aux critères . Les cibles préconstruites sont :

• ACCEPT
  Les paquets qui satisfont aux critères sont acceptés, ils continuent leur chemin dans la pile ;
• DROP
  Les paquets qui satisfont aux critères sont rejetés, on les oublie, on n'envoie même pas de message ICMP. Un trou noir, quoi ;
• LOG
  C'est une cible particulière qui permet de tracer au moyen de syslog les paquets qui satisfont aux critères ;

Suivant les contextes, d'autres cibles deviennent accessibles, comme REJECT (similaire à DROP, mais avec envoi d'un message d'erreur ICMP à la source du paquet rejeté), RETURN, REDIRECT, SNAT, DNAT, MASQUERADE…

En français, nous pourrons faire des choses de ce genre :

• par défaut, tous les paquets qui entrent sont rejetés (DROP) ;
• les paquets qui entrent par le port 80 sur l'interface eth0 sont acceptés ;
• les paquets qui sortent par le port 80 sur l'interface eth0 sont acceptés ;
• etc.

Nous verrons cela plus en détail dans les divers exemples.

Le principe du suivi de connexion permet de réaliser un « firewall statefull », c'est-à-dire qu'il va réagir intelligemment sur une connexion donnée, suivant son état. Voyez éventuellement à ce propos le chapitre sur la sécurité. Comme ce n'est pas très simple d'expliquer ça, nous allons observer un exemple sur le terrain. Nous allons établir une connexion TCP à partir du protocole HTTP :

No. Time        Source       Destination  Protocol Info
10 10.181832   192.168.0.10  212.27.35.1  TCP      4252 > http [SYN]
11 10.204707   212.27.35.1   192.168.0.10 TCP      http > 4252 [SYN, ACK]
12 10.204848   192.168.0.10  212.27.35.1  TCP      4252 > http [ACK]
13 10.205333   192.168.0.10  212.27.35.1  HTTP     GET / HTTP/1.1

L'établissement d'une connexion TCP suit un protocole strict :

• une requête de synchronisation [SYN] de la part de l'initiateur du dialogue (le client) ;
• une réponse d'accusé de réception de la synchronisation [SYN, ACK] de la part du serveur ;
• un accusé de réception du client [ACK].

Observons également les sockets.

• Trame n°10 :
  Le client [192.168.0.10] s'adresse au serveur [212.27.35.1] sur le port http (80). Il attend une réponse sur le port 4252. C'est un numéro pris plus ou moins au hasard. A priori, personne ne peut le deviner à l'avance ;
• Trame n°11 :
  Le serveur, bien élevé, répond au client sur le port demandé (4252)

La même chose, mais plus détaillée, ce qui donne l'occasion de voir l'ensemble des « flags » exploitables au niveau TCP :

Frame 10 (62 bytes on wire, 62 bytes captured)
...
Transmission Control Protocol
    Source port: 4252 (4252)
    Destination port: http (80)
    Sequence number: 3290220049
    Header length: 28 bytes
    Flags: 0x0002 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
...
 
Frame 11 (62 bytes on wire, 62 bytes captured)
...
Transmission Control Protocol
    Source port: http (80)
    Destination port: 4252 (4252)
    Sequence number: 1602605975
    Acknowledgement number: 3290220050
    Header length: 28 bytes
    Flags: 0x0012 (SYN, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
 ...
 
Frame 12 (54 bytes on wire, 54 bytes captured)
...
Transmission Control Protocol
    Source port: 4252 (4252)
    Destination port: http (80)
    Sequence number: 3290220050
    Acknowledgement number: 1602605976
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 16944
    Checksum: 0xe79b (correct)

De ces premières observations, nous pouvons déduire quelques choses intéressantes. En considérant des échanges TCP entre deux sockets toujours les mêmes :

• lorsqu'un paquet TCP contient le flag SYN, c'est que c'est une nouvelle connexion qui commence ;
• lorsqu'un paquet TCP contient les flags SYN et ACK, c'est que la connexion est acceptée, elle est donc établie ;
• lorsqu'un paquet ne contient que le flag ACK, c'est que la connexion se continue.

Mais voyons un peu plus loin…

No. Time       Source        Destination  Protocol Info
29 10.427697   192.168.0.10  212.27.35.1  TCP      4252 > http [ACK]
30 10.731147   192.168.0.10  212.27.35.1  TCP      span class="bhly">4253 > http span class="bhly">[SYN]
31 10.752981   212.27.35.1   192.168.0.10 TCP      http > 4253 [SYN, ACK]
32 10.753165   192.168.0.10  212.27.35.1  TCP      4253 > http [ACK]
33 10.753707   192.168.0.10  212.27.35.1  HTTP     GET /images/titre.gif HTTP/1.1
34 10.780941   192.168.0.10  212.27.35.1  TCP      4252 > http [FIN, ACK]

Ce que nous observons ici, c'est l'établissement d'une nouvelle connexion TCP entre les mêmes protagonistes. Bien entendu pour éviter les mélanges, le port du client n'est plus le même. C'est cette fois-ci 4253.

Autrement dit, le même client (192.168.0.10) ouvre une nouvelle connexion TCP sur le même serveur (212.27.35.1), toujours sur le port 80, mais attend les réponses sur un nouveau port, alors que la connexion précédente existe toujours.

Le client met fin à la précédente (trame 34) avec le flag [FIN] une fois seulement que la seconde connexion est établie.

Dans ces conditions, il est pertinent de penser que cette nouvelle connexion est en relation directe avec la première. Nous dirons que c'est une connexion en relation avec la première.

Si l'on met en place un système capable de mémoriser ce qu'il se passe sur la couche TCP, alors il va devenir possible de savoir si une connexion est dans l'un de ces états :

• NEW
  nouvelle connexion (elle contient le flag SYN) ;
• ESTABLISHED
  connexion déjà établie, elle ne devrait pas contenir de SYN ni de FIN ;
• RELATED
  la connexion présente une relation directe avec une connexion déjà établie ;
• INVALID
  la connexion n'est pas conforme, contient un jeu de flags anormal, n'est pas classable dans l'une des trois catégories précédentes.

Ceci est intéressant, parce que l'on pourra interdire a priori à toute connexion NEW d'entrer dans notre installation, il n'y a aucune raison qu'il en rentre si nous n'avons pas de serveur. Éventuellement, nous pourrons par exemple créer des exceptions pour les ports SSH, si nous souhaitons accéder à notre machine depuis le Net.

En revanche, toute connexion ESTABLISHED ou RELATED devra pouvoir entrer depuis le Net.

Dans l'autre sens, du LAN vers le Net, les paquets NEW doivent pouvoir passer, de même, bien entendu que les ESTABLISHED et les RELATED.

Les paquets INVALID pourront éventuellement être tracés dans les logs.

Alors, avant d'aller plus loin, faites la manip suivante sur votre passerelle Linux 2.6.x.

Pour bien montrer que les chaînes INPUT et OUTPUT n'interviennent pas dans le routage, nous allons tout simplement leur mettre DROP comme règle par défaut. Attention, il faut que vos clients utilisent un DNS situé ailleurs que sur votre passerelle Linux, sinon, ça ne fonctionnera pas à cause du DNS.

Tapez les commandes suivantes :

  iptables -P INPUT DROP
  iptables -P OUTPUT DROP
  iptables -L

(pour vérifier que INPUT et OUTPUT « droppent » bien tout ce qui passe).

• Vérifiez que, depuis votre passerelle Linux, vous n'avez plus accès au Net (ni à votre réseau privé d'ailleurs) ;
• Vérifiez que, depuis un poste de votre réseau privé, vous avez toujours l'accès au Net.

Convaincu ? INPUT et OUTPUT n'interviennent absolument pas dans le routage. Toutes les règles que vous pourrez y mettre ne concerneront que la sécurité de la passerelle elle-même, mais pas de votre réseau privé.

Dans un datagramme, en plus des données, on trouve également quelques informations concernant le protocole utilisé et des identificateurs de l'émetteur et du destinataire. Ce sont ces identificateurs qui nous intéressent :

• l'adresse IP du destinataire ;
• le port du service utilisé sur le destinataire.

Ces informations constituent une « socket », elles sont indispensables pour arriver à joindre le bon service sur le bon serveur, par exemple le service HTTP du serveur www.developpez.com.

• L'adresse IP de l'émetteur ;
• Le port de réponse.

Ces informations constituent une autre « socket », elles sont indispensables pour que l'émetteur d'un paquet puisse espérer recevoir une réponse.

Avec les fonctions NAT de Netfilter, lorsqu'un paquet transite par notre passerelle, nous allons pouvoir bricoler ces sockets absolument comme on le désire. Par exemple, nous pourrons changer l'adresse de l'émetteur ou le port de l'émetteur ou les deux. Nous pouvons aussi changer l'adresse du destinataire, ou le port du destinataire, ou les deux.

Ça sert à une quasi-infinité de choses. Parmi les plus intéressantes, citons :

V-A-2-a. Le masquage d'adresse▲

V-A-2-b. Le NAT de destination▲

Ici, c'est pour résoudre les problèmes qui apparaissent dans l'autre sens. Les clients sont sur le Net et les serveurs sont sur le réseau privé.

Imaginons que nous n'ayons qu'une seule IP valide sur le Net et que nous voulions tout de même offrir des services tels que HTTP, FTP, SMTP, POP et peut-être d'autres encore. Comment faire ? La réponse triviale consiste à dire : « J'ai droit à une seule IP, donc je place tous ces serveurs sur la même machine, celle qui a la seule IP à laquelle j'ai droit. »

Oui, mais la démarche est simpliste :

• comment assurer un minimum de sécurité sur une machine ouverte de tous les côtés ?
• comment faire pour assurer une disponibilité suffisante à chaque service dans les montées en charge ?

Cette solution ne paraît finalement pas très acceptable, mais comment faire autrement ? Tout simplement avec NAT. La machine frontale sera un simple routeur NAT. Côté Internet, elle possède la seule IP valide disponible, elle va faire croire que tous les services sont dessus, mais en réalité, lorsqu'elle va recevoir un paquet dont le socket de destination est 62.161.96.47:80, elle va remplacer ça vite fait par 192.168.0.1:80 et router le paquet vers le serveur HTTP. Lorsque la réponse du serveur va lui parvenir, elle remplacera le socket de l'émetteur (192.168.0.1:80) par 62.161.96.47:80 et enverra ça sur le Net. Tout le monde n'y verra que du feu.

Bien entendu, le routeur NAT est capable de faire ça pour chacun des autres serveurs :

• ce qui lui arrivera sur les ports 20 et 21 sera redirigé sur le serveur FTP (en réalité, le cas du FTP est bien plus difficile à résoudre que ça. Il faudra d'abord lire le chapitre sur FTP) ;
• ce qui lui arrivera sur le port 25 sera redirigé sur le serveur SMTP/POP3 service SMTP ;
• ce qui lui arrivera sur le port 110 sera redirigé sur le serveur SMTP/POP3 service POP3.

V-A-2-c. Le cas du proxy transparent▲

Pour commencer, nous allons tout fermer au niveau de la passerelle dans la table filter.

Nous vidons les chaînes :

iptables -F

Nous supprimons d'éventuelles chaînes personnelles :

iptables -X

Nous les faisons pointer par défaut sur DROP :

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Nous faisons de même avec toutes les autres tables, à savoir nat et mangle, mais en les faisant pointer par défaut sur ACCEPT. Ça ne pose pas de problème puisque tout est bloqué au niveau filter :

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT

Notez que dans tout ça, on n'a pas changé grand-chose par rapport à l'état de ces tables telles qu'on le trouve après un boot de la machine, sans modification particulière des scripts de démarrage, hormis la cible par défaut des règles de la table filter que l'on a passée à DROP. Tout de même, cette manipulation préliminaire a eu pour conséquences :

• que l'on est parfaitement sûr de l'état de Netfilter ;
• que l'on a commencé à se familiariser un peu avec le langage IPtables.

VII-A-1-a. Où en sommes-nous ?▲

Nous considérons que la machine elle-même est sûre et que les processus locaux peuvent communiquer entre eux via l'interface locale :

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Nous considérons que notre réseau local est également sûr (ce qui n'est pas forcément vrai, d'ailleurs).

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT

À ce stade, nous avons la situation suivante :

• si, sur votre passerelle, vous faites ping 127.0.0.1, ça répond ;
• si, sur votre passerelle, vous faites un ping sur un hôte du réseau privé, ça répond ;
• si, sur un hôte du réseau privé, vous faites un ping sur la passerelle, ça répond aussi.

Mais…

• Si, depuis la passerelle, on fait des pings n'importent où sur le Net, ça ne répondra pas, à cause du DROP sur OUTPUT par défaut ;
• Si, depuis n'importe où sur le Net, on fait des pings sur votre passerelle, ça ne répondra pas non plus, à cause du DROP sur INPUT par défaut ;

• si, depuis un hôte de votre réseau, on fait un ping n'importe où sur le Net, ça ne répondra encore pas, pour deux raisons :

  • nous n'avons pas placé de règle de NAT entre le réseau local et le Net,
  • FORWARD fait DROP sur tout ce qui passe.

Translation d'adresses pour tout ce qui traverse la passerelle en sortant par ppp0 :

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Nous pourrions ici restreindre le NAT à une plage d'IP du réseau local :

iptables -t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE

Ou même à une liste d'IP bien définies :

iptables -t nat -A POSTROUTING -s 192.168.0.10 -o ppp0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.11 -o ppp0 -j MASQUERADE

Ceci peut être utile, surtout en sachant que vous pouvez détruire une règle et une seule :

iptables -t nat -D POSTROUTING -s 192.168.0.11 -o ppp0 -j MASQUERADE

Ainsi, si vous avez, par exemple, des enfants qui usent de votre connexion permanente de façon un peu trop permanente, vous pourrez aisément, avec l'aide du démon cron n'accorder l'accès au Net que pour certaines plages horaires.

Mais ça ne suffit pas encore pour fonctionner, les pings depuis le réseau local vers le Net ne passent toujours pas. Normal, FORWARD fait toujours DROP sur tout ce qui passe. Nous devons accorder des autorisations de passage sur FORWARD.

Le suivi de connexion est intéressant, bien qu'il consomme un peu plus de ressources sur votre passerelle. Nous l'avons vu, son avantage est qu'il permet d'obtenir des informations sur toute connexion en cours. Ces informations sont principalement :

• NEW
  Une nouvelle connexion est établie ;
• ESTABLISHED
  La connexion analysée a déjà été établie ;
• RELATED
  La connexion est en relation avec une autre connexion déjà établie (par exemple, dans le FTP actif) ;
• INVALID
  Le paquet n'appartient à aucune des trois catégories précédentes. Il est possible, par exemple, de n'accepter dans les deux sens (vers et depuis l'Internet) que les connexions déjà établies ou en relation avec des connexions déjà établies et de n'accepter des nouvelles connexions que depuis notre installation vers l'Internet. De cette manière, notre réseau local pourra se connecter sur tout serveur Internet, mais aucune nouvelle connexion ne pourra être créée depuis le Net vers notre installation.

En français, nous allons faire :

• toutes les connexions : nouvelles, établies et associées à une connexion établie qui entrent par eth0 (réseau local) et veulent sortir par ppp0 (le Net), peuvent passer ;
• toutes les connexions : établies et associées à une connexion établie qui entrent par ppp0 et veulent aller vers eth0 pourront également passer.

En langage IPtables : toutes les connexions qui sortent du LAN vers le Net sont acceptées :

iptables -A FORWARD -i eth0 -o ppp0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Nous aurions aussi bien pu écrire :

iptables -A FORWARD -i eth0 -o ppp0 -m state --state ! INVALID -j ACCEPT

Seules les connexions déjà établies ou en relation avec des connexions établies sont acceptées venant du Net vers le LAN :

iptables -A FORWARD -i ppp0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

ping ul.grenouille.com (par exemple) se met à fonctionner.

VII-A-4-a. Le chapeau magique▲

tcp 6 14 CLOSE_WAIT
            src=192.168.0.10 dst=213.186.35.33 sport=1102 dport=80
            src=213.186.35.33 dst=80.8.130.97 sport=80 dport=1102 [ASSURED] use=1
 
tcp 6 431991 ESTABLISHED
            src=192.168.0.10 dst=213.186.35.33 sport=1103 dport=80
            src=213.186.35.33 dst=80.8.130.97 sport=80 dport=1103 [ASSURED] use=1
 
tcp 6 73 TIME_WAIT
            src=192.168.0.10 dst=213.186.35.33 sport=1104 dport=80
            src=213.186.35.33 dst=80.8.130.97 sport=80 dport=1104 [ASSURED] use=1
 
tcp 6 82 SYN_SENT
            src=192.168.0.10 dst=213.186.35.33 sport=1105 dport=80 [UNREPLIED]
            src=213.186.35.33 dst=80.8.130.97 sport=80 dport=1105 use=1
 
tcp 6 51 CLOSE_WAIT
            src=192.168.0.10 dst=213.186.35.33 sport=1106 dport=80
            src=213.186.35.33 dst=80.8.130.97 sport=80 dport=1106 [ASSURED] use=1

VII-A-4-b. Où en sommes-nous ?▲

VII-A-5-a. Un DNS local▲

iptables -A OUTPUT -o ppp0 -p udp --sport 1024: --dport 53 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i ppp0 -p udp --sport 53 --dport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT

VII-A-5-b. Un SMTP local▲

iptables -A OUTPUT -o ppp0 -p tcp --sport 1024: --dport 25 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --sport 25 --dport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o ppp0 -p tcp --sport 1024: -d smtp.wanadoo.fr --dport 25 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp -s smtp.wanadoo.fr --sport 25 --dport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT

VII-A-5-c. Un accès SSH depuis le Net▲

iptables -A INPUT -p tcp --dport ssh -i ppp0 -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o ppp0 -j ACCEPT

VII-A-5-d. ICMP, c'est parfois utile▲

iptables -A INPUT -p icmp  -m state --state RELATED -j ACCEPT