TP – Partage d’une connexion en utilisant SQUID & IPTABLES

Objectifs :

SQUID est un proxy (mandataire) capable de réaliser :

- -

la translation d’adresses permettant l’utilisation d’une seule adresse routable, l'optimisation de la bande passante en utilisant un mécanisme de cache (notamment utile lorsque les utilisateurs accèdent aux mêmes objets statiques), le contrôle et le filtrage de l'accès, particulièrement, l’authentification qui n’est pas possible avec IPTABLES.

IPTABLES est un firewall logiciel capable de réaliser les fonctions de translation d’adresses et de filtrage, mais aussi, il permet la modification de champs dans les entêtes TCP/IP. Grâce à IPTABLES, il est possible de réaliser la translation d’adresses indépendamment des protocoles applicatifs (contrairement à SQUID qui se limite à des protocoles bien déterminés comme HTTP ou FTP). Grâce Il est aussi possible de réaliser la translation d’adresse sur l’adresse source mais aussi sur l’adresse destination (ce qui n’est pas le cas avec SQUID). IPTABLES et SQUID peuvent être utilisés conjointement pour mettre en place un serveur proxy transparent. Sans chercher à couvrir toutes les possibilités qu’offrent ces deux outils, à travers un certain nombre de manipulations, nous allons nous familiariser avec ces deux outils et apprendre à utiliser et mettre en place certaines configurations usuelles :

- mise en place d’un serveur proxy SQUID pour le partage d’une connexion à l’Internet, - - - -

configuration du cache SQUID, authentification et filtrage avec SQUID, consultation des fichiers logs et utilisation d’IPTABLES pour rendre un proxy transparent, pour améliorer les possibilités de filtrage et pour permettre l’accès à partir de l’internet à un serveur ayant une adresse privée.

Barème : 2.5 par question.

Environnement matériel et logiciels

Quatre machines dont trois virtuelles, en réseau, sont installées sur un même ordinateur de travail (en utilisant VMware) : trois machines Linux et une MS Windows Server. Ces machines sont les mêmes utilisées que pour le TP déploiement des réseaux IP avec les mêmes mots de passe. Il faut savoir que dans le cadre d’une exploitation réelle, la configuration matérielle de la machine (en termes notamment d’espace mémoire et d’espace disque), sur laquelle est déployé un serveur proxy SQUID influe considérablement sur les temps de réponses de ce serveur.

Configurer les différentes machines comme le décrit la figure suivante (appliquer le masque par défaut) :

- Squid1 devrait être la machine Fedora, Squid2 la machine OpenSuse et le client 192.168.1.2 la machine Ubuntu, - Paquetages SQUID et IPTABLES installés à la fois sur Squid1 et Squid2 - Serveur Web (IIS) installés à la fois sur 193.95.0.1 (Windows Server), - Le paquetage htpasswd pour la gestion des mots de passe, - Navigateur Web installé sur toutes les machines, - Serveur Telnet installé sur Fedora.

Nous allons commencer par se familiariser avec certains fichiers et effectuer certaines vérifications.

TP RL/ II2-ENSI

Page :1

1) Consulter le fichier /etc/squid/squid.conf

Chercher dans ce fichier la directive cache_dir afin de déterminer l’emplacement du répertoire de cache, la taille du cache (en Mo), le nombre de répertoires et de sous répertoires. Il est possible de trouver cette directive plusieurs fois, la taille totale est alors la somme des différentes occurrences. Afin d'accélérer les temps de recherche, SQUID essaie de répartir les objets qu'il place dans le cache de manière uniforme dans plusieurs répertoires. Il utilise une fonction de répartition (fonction de « hash ») qui indique dans quel répertoire se trouve un objet. La recherche dans ce répertoire se fait donc plus rapidement, car les objets sont répartis de manière équilibrée dans tous les répertoires du cache, qui devraient donc être relativement peu « peuplés ». Il utilise un découpage à deux niveaux, les répertoires du deuxième niveau étant répartis dans les répertoires du premier niveau.

SQUID est incapable de démarrer si les répertoires de caches ne sont pas créés. Grâce à la commande ls vérifier que ces répertoires sont bien créés. Il est possible aussi de les créer ou de les reconstruire (par exemple, à la suite d’un arrêt brutal de squid, le cache peut devenir « corrompu » et doit être reconstruit) en tapant : rm -rf /var/spool/squid/*

// si déjà créés

squid -z

En ayant consulté squid.conf, préciser les informations suivantes :

Chemin vers le répertoire de Swap : ……....................................................................................................................

Taille du répertoire de Swap : …………………...................................................................................................................

Noms des répertoires :……………………………...................................................................................................................

Noms des sous-répertoires :……………………...................................................................................................................

…………………………………………………………………………...................................................................................................................

Déterminer si SQUID est déjà lancé en utilisant l’une des commandes suivantes : Fedora# ps aux | grep [s]quid ou Fedora# /etc/init.d/squid status

Une première configuration simple

2) Nous allons permettre à toutes les machines du réseau 192.168.0.0 d’accéder à l’internet (représenté par le serveur

Web 193.95.0.1) via Squid1. A cet effet et dans le fichier squid.conf, reproduire les définitions suivantes :

############################## # SERVEUR PROXY CACHE – Squid1 ##############################

Port du proxy http_port 192.168.0.2:8080

# Paramétrage du cache cache_dir ufs /var/spool/squid 100 16 256 cache_log /var/log/squid/cache.log

Taille mémoire vive utilisée pour cache, augmenter si trop de messages Warning #“Exceeded cache_mem…” cache_mem 16 MB

régler cache_mem_low et cache_mem_high qui sont les valeurs limites de remplissage du # cache mémoire. Par défaut les valeurs sont 75 % et 90 %. A 90 % le cache se vide # jusqu'à 75 %.

Taille maximale des objets stockés dans le cache maximum_object_size 4 MB

TP RL/ II2-ENSI

Page :2

Taille minimale des objets stockés dans le cache minimum_object_size 0 KB

# Messages d'erreurs du proxy en français (pas forcement nécessaire), vérifier que le # répertoire existe et le consulter. error_directory /usr/share/squid/errors/fr

# Nom visible dans les messages d'erreurs visible_hostname Squid1

Déclaration des ACL (Access Control List) acl localhost src 127.0.0.1/32 acl reseau1 src 192.168.0.0/24 acl all src all #Internet

# Protocoles d'accès au cache et ports (ne pas définir les ports à interdire # # et à autoriser présenterait une faille de sécurité) acl manager proto cache_object acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports …

# Autorisation d'accès

Accès au manager à partir de localhost seulement http_access allow manager localhost http_access deny manager

Interdiction des ports douteux http_access deny !Safe_ports

# Autorisation d'accès direct aux services du proxy http_access allow localhost http_access allow reseau1 http_access deny all

- Des règles multiples de http_access sont comparées par des OU, elles sont traitées dans l’ordre d’écriture et se

terminent dès qu’une correspondance est établie.

- Tous les éléments d’une même entrée d’accès sont associés par un ET.

Lancer Wireshark sur Fedora.

Démarrer/redémarrer SQUID :

/etc/init.d/squid restart

A partir de OpenSuse (Squid2 considéré en tant que client) et travers le navigateur tenter d’accéder à l’URL : http://193.95.0.1/. Que faut-il réaliser comme paramétrage pour que l’accès puisse se réaliser ?

……………………………………………………………………………………………....………………………………………………………...................................

Remarque importante : dans tous le TP ne pas accéder à des pages HTML (inutilement) tant que ceci n’a pas été demandé. Cette recommandation est importante pour garder la mémoire cache à un état bien déterminé et pouvoir ainsi obtenir les résultats escomptés.

Après avoir réalisé un premier accès à travers le navigateur (à partir de OpenSuse), décrire les messages échangés entre la machine cliente et le serveur Squid1 d’une part et entre le serveur Squid1 et le serveur Web d’autre part. A cet effet TP RL/ II2-ENSI

Page :3

compléter la figure ci-dessus. Il n’est pas demandé de représenter les messages de fermeture de connexions TCP. Arrêter la capture de trame.

Authentification

Dans cette question nous nous intéressons à la fonction d’authentification. Il existe plusieurs méthodes disponibles pour authentifier les utilisateurs d’un proxy SQUID. Elles font appel à l’un des programmes suivants :

smb_auth : utilise un serveur SMB comme SAMBA ou Windows NT

ldap_auth : se base sur le protocole Linux Lightweight Directory Access

- - ncsa_auth : utilise un fichier de noms d'utilisateur et de mots de passe de style NCSA - - msnt_auth : utilise l'authentification de domaine Windows NT - PAM : utilise les modules Linux "Pluggable Authentication Modules" - getpwam : utilise le fichier passwd de Linux.

3) Dans ce qui suit nous allons utiliser ncsa_auth.

Créer un fichier password

touch /etc/squid/passwd

Ajouter un utilisateur grâce à htpasswd:

htpasswd -b /etc/squid/passwd <nom> <mot de passe>

Dans le fichier squid.conf, au lieu de http_access allow reseau1

Utiliser les directives suivantes :

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd

acl pass proxy_auth REQUIRED

http_access allow pass reseau1

TP RL/ II2-ENSI

Page :4

Valider le bon fonctionnement de cette règle.

Autres règles de filtrage (question bonus)

Afin de limiter le nombre de connexions différentes qu'un utilisateur peut effectue, rajouter dans /etc/squid/squid.conf

Nombre maximal de sessions simultanées à partir de différentes adresses IP à 1 (pour # un même utilisateur)« -s » pour un fonctionnement strict (sinon aléatoire) acl maxauth max_user_ip -s 1

Nombre de connexion simultanés limité à 5 acl numconn maxconn 5 # duree de validite de l'authentification authenticate_ttl 30 minute

Règles d'accès http_access deny maxauth http_access deny reseau1 numconn http_access allow pass reseau1 Valider le bon fonctionnement de ce paramétrage. Décrire les tests effectués.

Autres restrictions typiques :

ACL pour une restriction journalière/horaire : # M:Monday T:Tuesday W:Wednesday H:Thursday F:Friday A:Saturday S:Sunday acl semaine time MTWHF 08:30-17h30

ACL de restrictions par mot passant dans l'url (utilisation d'un fichier contant les # mots interdits)) acl mots_interdits urlpath_regex "/etc/squid/mots_interdits"

ACL de restrictions par url (utilisation d'un fichier contenant les URLs interdites) acl urls_interdites url_regex "/etc/squid/url_interdites"

# Application, par le refus, de ces ACLs http_access deny !semaine http_access deny mot_interdit http_access deny urls_interdites

Tester le bon fonctionnement de ces règles et donner une autre alternative à la règle qui permet la restriction journalière/horaire avec authentification et uniquement à partir du réseau1 en utilisant « allow » et non « deny ». Tester le bon fonctionnement de cette règle.

Proxy transparent

Dans cette question nous cherchons à mettre en place un proxy transparent. Suivant ce mode de fonctionnement, l’authentification n’est plus possible. Seul HTTP (port 80) est supporté en mode transparent. Grâce à un tel mode, il n’est plus nécessaire de paramétrer les navigateurs avec l’adresse IP/port du proxy.

4) Le proxy est supposé être installé sur la machine qui joue le rôle de la passerelle par défaut. Sur Squid1 :

activer le routage :

- echo "1" > /proc/sys/net/ipv4/ip_forward - Grâce à IPTABLES, rediriger le port 80 vers le port de SQUID (8080) iptables -t nat -I PREROUTING -p TCP --dport 80 -j REDIRECT --to-port 8080 - Reste à résoudre le problème suivant : le client envoie une requête HTTP directe à un serveur httpd et non à un proxy. Les méthodes utilisées ne sont pas les mêmes. Afin que le proxy fonctionne de façon transparente, il faut rajouter au niveau de la directive http_port le terme « transparent »:

##Port du proxy http_port 192.168.0.2:8080 transparent

Décrire le reste des opérations à réaliser pour le test du fonctionnement du proxy transparent et réaliser ce test. (Pour les tests n’oublier pas de vider le cache du navigateur)

TP RL/ II2-ENSI

Page :5

……………..………………………………………………………………………………………………………………………………….…...................................

Hiérarchie de caches et liaison inter-cache

La fonction cache permet d’éviter de ramener un document plusieurs fois.

Un document est généralement stocké dans le cache en fonction (particulièrement) de :

- une date d'expiration (en-tête HTTP expire),

- une durée de vie estimée à partir des dates de dernière modification (en-tête HTTP Last-Modified),

-la fréquence d'utilisation du document (LFU : « Least Frequently Used »),

- un rapport entre un paramètre coût (le temps de réponse du serveur d’origine) et la taille du document, les documents ayant le plus petit rapport sont supprimés d’abord (GDS : « Greedy Dual Size »).

Les documents dynamiques ne doivent jamais être cachés (CGI, PHP,..). Lorsqu’un document est supprimé tous les documents aussi récents ou moins récents sont supprimés.

Afin d’augmenter les performances des proxy-caches, une coopération entre caches peut-être configurée. Les caches SQUID peuvent être organisés suivant une hiérarchie de caches. Exemple :

On distingue particulièrement 2 types de relations de parenté :

- les relations hiérarchiques « parent » où un parent (considéré comme père) répond à son fils s'il possède le document, sinon, il cherche le document et le délivre au fils; les mises à jour s'effectuent en cascade : un père est un point de concentration.

- les relations transversales « sibling », dans ce cas, si le document n’est pas dans le cache du parent (considéré comme frère) la requête n’est pas relayée, le cache origine de la requête doit lui-même chercher l’objet. Cette relation est particulièrement intéressante dans le cas où les frères sont proches.

Le taux de succès des accès au cache risquent d’être très aléatoires. Ces relations de parenté devraient être instaurées entre caches en cas d'homogénéité de communauté (réseau de caches thématiques). Les endroits dans le réseau (où devraient figurer les caches) et le dimensionnement des caches sont des éléments de configuration qui font partie des problèmes à traiter dans la mise en œuvre d’une hiérarchie de caches.

5) Nous allons commencer par configurer Squid1 entant que cache père et Squid2 en tant que cache fils. Pour simplifier la manipulation, préparer les fichiers squid.conf (de Squid1 et Squid2) de façon à réduire les contrôles d’accès (pas d’authentification …).

Remarque : la version de Squid sur Squid2 est différente de celle de Squid1, les mêmes directives déjà étudiées existent, les paramètres par défaut sont différents. Sans devoir réécrire le fichier squid.conf sur Squid2 modifier le fichier existant en agissant sur les directives appropriées.

Dans le fichier squid.conf de Squid2, taper la directive suivante (le port utilisé par le protocole inter-cache ICP, directive icp_port, est supposé être configuré à 3130) :

TP RL/ II2-ENSI

Page :6

cache_peer 192.168.0.2 parent 8080 3130

Sur Squid1 et dans le fichier squid.conf activer le port 3130

icp_port 3130

Vider le cache de Squid1 et Squid2 (grâce à la commande de reconstruction, cf. plus haut). Effectuer une requête d’accès depuis Ubuntu à l’URL http://193.95.0.1/lien1. Consulter le fichier access.log de Squid2 et de Squid1. Reproduire les lignes traduisant les différents événements conséquents à l’accès à la page.

A partir d’un navigateur sur OpenSuse accéder à l’URL http://193.95.0.1/lien1. Consulter le fichier access.log de Squid1. Reproduire les lignes traduisant les différents événements conséquents à l’accès à la page.

Nous allons maintenant configurer Squid2 entant que cache frère de Squid1. Garder le cache de Squid1 non vide. Ensuite, dans le fichier squid.conf de Squid2, taper la directive suivante :

cache_peer 192.168.0.2 sibling 8080 3130

A partir d’un navigateur sur Ubuntu accéder à http://193.95.0.1/lien2. Décrire le résultat obtenu pour chacun de ces accès. Illustrer ces résultats.

l’URL http://193.95.0.1/lien1 et ensuite à

l’URL

IPTABLES : généralités

Alors que SQUID est capable de réaliser la translation d’adresse et le contrôle d’accès au niveau applicatif, IPTABLES réalise ces fonctions aux niveaux réseaux et transport. Il est incapable d’exploiter pas les particularités des protocoles applicatifs. De plus, il ne met pas en œuvre un mécanisme de cache. Néanmoins, grâce à IPTABLES il est possible de réaliser la translation d’adresses sans être limité à des protocoles applicatifs bien déterminés (comme c’est le cas pour SQUID). En outre, en plus de la translation d’adresse qui s’effectue généralement du coté client, un autre type de translation d’adresse du coté serveur est aussi possible (sur lequel nous reviendrons dans la suite du TP).

TP RL/ II2-ENSI

Page :7

Avant d’aborder les manipulations, il est nécessaire de connaître les notions de base régissant le fonctionnement de IPTABLES. La couche réseau Linux présente plusieurs points d'accès (en anglais hook). Netfilter (module système destiné au filtrage) dispose de fonctions de rappel (callback) sous la forme de suites d'instructions qui précisent les traitements à réaliser lorsqu’un événement survient. IPTABLES permet la configuration de Netfilter. La figure suivante précise les points d’accès existants.

Il est ainsi possible d’agir avant (PREROUTING), durant (FORWARD) ou après le routage (POSTROUTING), il est aussi possible d’agir sur les paquets issus des processus locaux (OUTPUT) ou sur les paquets destinés à ces processus (INPUT). A ces points d’accès sont associées des chaines de traitements désignées par les termes précisés ci-avant. Ces chaines sont regroupées en 3 tables : FILITER pour le filtrage, NAT pour la translation d’adresses et MANGLES pour pouvoir modifier certains des entêtes TCP/IP.

Une chaîne est une liste de règles. Si les conditions de la règle s’appliquent sur un paquet, la règle précise la cible (ACCEPT, DROP, REJECT, SNAT, DNAT, MASQUERADE, LOG un saut vers une chaîne utilisateur), sinon, la règle suivante de la chaîne est examinée. Le tableau suivant donne une description des différentes cibles prédéfinies.

CIBLE

DESCRIPTION

un paquet envoyé vers cette cible sera accepté et pourra poursuivre son cheminement au travers des couches réseaux.

DROP

Cette cible permet de jeter des paquets

REJECT

Permet d'envoyer une réponse à l'émetteur pour lui signaler que son paquet a été refusé

MASQUERADE

Cible valable uniquement dans la chaîne POSTROUTING de la table NAT. Elle change l'adresse IP de l'émetteur par celle courante de la machine pour l'interface spécifiée. Cela permet de masquer des machines et de faire par exemple du partage de connexion

SNAT

DNAT

LOG

Également valable pour la chaîne POSTROUTING de la table NAT seulement. Elle modifie aussi la valeur de l'adresse IP de l'émetteur en la remplaçant par la valeur fixe spécifiée.

Valable uniquement pour les chaînes PREROUTING et OUTPUT de la table NAT. Elle modifie la valeur de l'adresse IP du destinataire en la remplaçant par la valeur fixe spécifiée

Demande au noyau d'enregistrer des informations sur le paquet courant.

Arrêter Squid Sur OPenSuse et Fedora.

TP RL/ II2-ENSI

Page :8

6) Nous allons commencer par présenter quelques commandes utiles pour visualiser les règles, les supprimer, les

sauvegarder, les restaurer et fixer la politique par défaut : - Pour lister les règles courantes des chaines de la table FILTER, taper

iptables –L

- Pour vider les chaines, taper

Iptables –F

- Pour sauvegarder les règles courantes, taper :

iptables-save > /etc/iptables-save - Pour restaurer les règles à partir du fichier /etc/iptables-save, taper : iptables-restore < /etc/iptables-save

Vider les chaines, lister à nouveau les règles et vérifier que la politique par défaut pour les différentes chaines est ACCEPT (Policy ACCEPT) : politique permissive. Il est possible d’agir sur la politique par défaut (qui sera appliquée en dernier ressort si aucune règle ne s’applique) :

iptables -P INPUT –j ACCEPT iptables -P OUTPUT –j ACCEPT iptables -P FORWARD –j ACCEPT

Pour instaurer une politique restrictive il suffit de remplacer dans les lignes (ci-dessus) ACCEPT par DROP.

IPTABLES : exemple de filtrage

7) Activer le routage sur OpenSuse et mettre-à-jour les tables de routages pour que tout équipement puisse pinger sur

tout autre équipement : echo "1" > /proc/sys/net/ipv4/ip_forward Nous voulons interdire qu’un équipement dans le réseau 192.168.1.0 puisse « pinguer » sur un équipement se trouvant dans le réseau 192.168.0.0. A cet effet et sur OpenSuse, saisir la règle suivante :

iptables –A FORWARD –p icmp --icmp-type echo-request –s 192.168.1.0/24 –d 192.168.0.0/24 -j REJECT

Vérifier qu’avant la saisie de la règle, le ping pouvait se faire et qu’après la saisie ceci n’est plus possible. Est-ce qu’il est possible de pinger à partir de Fedora sur l’adresse 192.168.1.2 ? Expliquer.

IPTABLES : Translation de l’adresse source

SQUID n’effectue pas la translation des adresses sources pour permettre aux stations locales de « pinguer » sur l’extérieur (trafic ICMP). Ce même problème se pose pour d’autres trafics tels que POP ou SMTP. Dans ce qui suit, nous allons utiliser IPTABLES pour permettre aux stations dans les réseaux 192.168.0.0 de « pinguer » sur des machines externes (193.95.0.1).

Rajouter sur OpenSuse une route par défaut à travers 192.168.0.2.

8) Sur le serveur Squid1 saisir la règle suivante :

iptables –t nat –A POSTROUTING –s 192.168.0.0/24 –p icmp --icmp-type echo-request -j SNAT -–to-source 193.95.0.2 Expliquer à quoi correspond cette règle.

Visualiser les règles des chaines de la table NAT en tapant : iptables –L POSTROUTING –t nat Vérifier qu’il est possible de pinger à partir d’OpenSuse sur 193.95.0.1.

TP RL/ II2-ENSI

Page :9

IPTABLES : translation de l’adresse destination

Il est possible de permettre l’accès à une machine ayant une adresse privée à partir de l’extérieur (l’internet) en utilisant la translation le l’adresse destination (utile, par exemple, pour une caméra, munie d’un serveur Web, à domicile à laquelle on veut accéder à partir d’un quelconque endroit sur l’Internet). A cet effet nous allons réserver le port 2222 pour désigner la machine interne (la caméra avec son serveur Web) ayant comme adresse IP 192.168.0.1 (OpenSuse). Vérifier que le serveur Web est bien activé sur OpenSuse.

9) Sur le serveur Fedora activer le routage. Sur OpenSuse, créer une route par défaut à travers 192.168.0.2. Sur

Fedora, saisir la règle suivante : iptables –t nat –A PREROUTING –s 0.0.0.0/0 –-protocol tcp -–dport 2222 -j DNAT –-to 192.168.0.1:80

Expliquer à quoi correspond cette règle. A partir d’un navigateur sur Windows, accéder à l’URL 193.95.0.2 :2222 .

IPTABLES : « statefull Inspection » (question bonus)

Dans ce qui suit nous cherchons à permettre aux utilisateurs du réseau 192.168.1.0 de pouvoir effectuer un telnet sur les machines qui se trouvent dans le réseau 192.168.0.0 sans que ces derniers ne puissent faire un telnet sur les machines du réseau 192.168.1.0. Vérifier que le telnet est bien activé sinon l’activer sur Fedora. Vérifier que le routage est bien activé sur OpenSuse. Créer les routes nécessaires pour permettre aux machines des réseaux 192.168.0.0 et 192.168.1.0 d’échanger des paquets. Vider toutes les règles iptables sur OpenSuse mais aussi Fedora et Ubuntu).

10) Sur OpenSuse, saisir les règles suivantes :

Iptables –P FORWARD DROP iptables -A FORWARD -p TCP -s 192.168.1.0/24 -d 192.168.0.0/24 --dport 23 -j ACCEPT iptables -A FORWARD -p TCP -s 192.168.0.0/24 --sport 23 -d 192.168.1.0/24 -j ACCEPT Est-ce qu’il est possible d’effectuer à partir de 192.168.1.2 un ping sur 192.168.0.2 (Fedora). Est-ce qu’il est possible d’effectuer à partir de 192.168.1.2 un telnet sur 192.168.0.2 (Fedora). Quel est le problème qui se pose ?

IPTABLES permet le suivi des «communications» en se basant sur les états suivants:

– NEW : premier paquet, – ESTABLISHED : réponse et suivants relatifs à une même communication, – RELATED : signifie que le paquet initie une nouvelle connexion, mais qu'il est associé avec une

communication existante, comme un transfert de données FTP ou une erreur ICMP. INVALID : signifie que le paquet n'est associé à aucune connexion connue

–

Remplacer la dernière règle par (vider et re saisir)

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Quel est l’intérêt de cette règle ?

TP RL/ II2-ENSI

Page :10