Re: problème réseau
pascal a écrit :
Il faut plutôt introduire ces adresses dans les règles de filtrage de la
chaîne FORWARD, y compris celles gérant l'état ESTABLISHED,RELATED sinon
les connexions existantes continueront à passer. Et lors de la coupure
utiliser la cible REJECT au lieu de DROP afin de signaler que le
connexion est coupée, c'est plus poli.
Ca me parle cet exemple :-)
C'est étudié pour. :-)
Et en plus j'avais (au moins) assimilé cet aspect du NAT. Néanmoins...
Heu en fait elles y sont ces règles. Mais bon comme je craignais
qu'elles fassent double emplois et pour ne pas aggraver mon cas je ne
les ai pas présentées içi. Oui je sais...
Mais là, à cette heure, je ne suis plus à ça près ...
En plus (faut pas taper) elles n'ont pas la bonne forme :
iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -m state --state !
INVALID -j ACCEPT
iptables -A FORWARD -i $INET_IFACE -o $LAN_IFACE -m state --state
ESTABLISHED,RELATED -j ACCEPT
Ces deux règles étaient bien présentes dans ton premier message, si je
ne m'abuse. Mais elles ne prennent pas en compte les adresses autorisées
à sortir.
Et si je ne craignais pas d'abuser...
Il faut donc que ces deux systèmes de règle soient présents (l'un pour
le SNAT et l'autre pour le filtrage) à la fois ?
Il faut des règles pour filtrer/autoriser et des règles pour NATer.
Et il n' y a pas là de redondance, alors ?
Non, car elles ont des rôles bien distincts.
Mais dans la chaîne FORWARD de la table filter, puis-je distinguer les
deux machines (via "-s") ou suis-je contraint comme dans les lignes
précédentes à raisonner en termes d'interface d'entrée et de sortie du
routeur ?
Les interfaces d'entrée et de sortie restent indispensables mais ne
suffisent pas pour traiter des adresses particulières. Tu peux tout à
fait utiliser les options -s pour les paquets sortants et -d pour les
paquets entrants. En partant des deux règles ci-dessus, tu pourrais les
remplacer par :
# NAT source du LAN vers l'extérieur
iptables -t nat -A POSTROUTING -o eth0 -s 192.162.2.0/24 \
-j SNAT --to-source 192.168.1.20
# pour autoriser 192.168.2.21 à communiquer avec l'extérieur
iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.2.21 \
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INET_IFACE -o $LAN_IFACE -d 192.168.2.21 \
-m state --state ESTABLISHED,RELATED -j ACCEPT
# pour autoriser 192.168.2.23 à communiquer avec l'extérieur
iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.2.23 \
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INET_IFACE -o $LAN_IFACE -d 192.168.2.23 \
-m state --state ESTABLISHED,RELATED -j ACCEPT
Mais c'est un peu lourd. On peut alléger avec des chaînes utilisateur :
# NAT source du LAN vers l'extérieur
iptables -t nat -A POSTROUTING -o eth0 -s 192.162.2.0/24 \
-j SNAT --to-source 192.168.1.20
iptables -N fwd_out
iptables -N fwd_in
iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE \
-m state --state NEW,ESTABLISHED,RELATED -j fwd_out
iptables -A FORWARD -i $INET_IFACE -o $LAN_IFACE \
-m state --state ESTABLISHED,RELATED -j fwd_in
iptables -A FORWARD -j REJECT
# pour autoriser 192.168.2.21 à communiquer avec l'extérieur
iptables -A fwd_out -s 192.168.2.21 -j ACCEPT
iptables -A fwd_in -d 192.168.2.21 -j ACCEPT
# pour autoriser 192.168.2.23 à communiquer avec l'extérieur
iptables -A fwd_out -s 192.168.2.23 -j ACCEPT
iptables -A fwd_in -d 192.168.2.23 -j ACCEPT
D'accord, il y a plus de règles que dans la première version mais elles
sont plus courtes donc plus lisibles et plus rapides à créer, effacer et
exécuter. Les deux règles à créer ou supprimer pour autoriser ou
interdire à une adresse de communiquer avec l'extérieur sont très
simples et n'ont pas besoin de connaître les noms des interfaces. Et on
peut traiter avec REJECT les paquets non acceptés.
En fait je crois avoir du mal à m'imaginer les relations exactes et
précises liant les tables aux chaînes. A m'en faire une représentation
mentale. Ca n'est pas très clair pour moi. Malgré mes lectures.
Les tables sont indépendantes les unes des autres. Les chaînes de même
nom et de tables différentes sont traversées dans un ordre bien défini
qui peut changer selon le nom des chaînes. En fait le nom des chaînes
est purement arbitraire. Par exemple le fait que les chaînes traversées
par un paquet émis localement aient le même nom OUTPUT dans toutes les
tables résulte d'un choix arbitraire fait pour des raisons pratiques.
En réalité Netfilter définit 5 points d'ancrage ("hooks") où peuvent
s'accrocher les différentes tables. Et chaque table est libre d'exécuter
les chaînes qu'elles veut à chaque point d'ancrage. C'est par convention
que les chaînes des différentes tables exécutées à un même point
d'ancrage ont le même nom.
J'avais déjà publié le schéma suivant qui montre les "positions" des
chaînes des différentes tables les unes par rapport aux autres et par
rapport aux autres opérations de la pile IP (fragmentation, décision de
routage...) :
http://www.plouf.fr.eu.org/bazar/netfilter/schema_netfilter.txt
Reply to: