Sous etch (amd64 noyau 2.6.18 "stock kernel") je rencontre un problème
de configuration réseau :
une machine "m64" derrière une livebox qui fait passerelle
routeur/firewall/serveur dhcp pour un réseau (ethernet) interne
comprenant deux machines ss Win XP.
Cette configuration ne m'a jamais posée de pb jusque là mais il s'agit
d'une réinstallation complète.
Deux cartes ethernet : eth0 reliée à la livebox et eth1 reliée au réseau
interne. L'interface eth0 a une adresse interne 192.168.1.20 et eth1
192.168.2.20, le réseau interne étant 192.168.2.0/24.
Le problème est que depuis la passerelle je peux pinger la livebox,
accéder au net, faire fonctionner le serveur web mais ne peut pinger
aucune des deux cartes ni même "localhost" :
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
...
3 packets transmitted, 0 received, 100% packet loss, time 2009ms
même résultats pour eth0 et eth1. Et ceci *avec* ou *sans* règles netfilter.
Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)
Du réseau interne je ne peux pinger la machine "m64" et encore moins la
livebox. Mais ces machines obtiennent tout de même leur adresse IP grâce
au dhcpd de la machine "m64" (elles ont une adresse IP fixe) !!!
Les éléments :
/etc/network/interfaces :
auto lo
iface lo inet loopback
# la carte ethernet LAN
allow-hotplug eth1
iface eth1 inet static
address 192.168.2.20
netmask 255.255.255.0
broadcast 192.168.2.255
network 192.168.2.0
iptables-save :
:PREROUTING ACCEPT [62:13541]
:POSTROUTING ACCEPT [205:13027]
:OUTPUT ACCEPT [354:28185]
-A POSTROUTING -s 192.162.2.21 -o eth0 -j SNAT --to-source 192.168.1.20
-A POSTROUTING -s 192.162.2.23 -o eth0 -j SNAT --to-source 192.168.1.20
COMMIT
# Completed on Fri Jan 5 15:38:53 2007
# Generated by iptables-save v1.3.6 on Fri Jan 5 15:38:53 2007
*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]
-A INPUT -i ! eth0 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
(*)-A FORWARD -i eth1 -o eth0 -m state --state
NEW,RELATED,ESTABLISHED,UNTRACKED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.
Où ai-je fait une erreur ? je fais du SNAT à la place du masquerade car
l'ip est fixe sur le (pre)routeur avant la livebox mais en activant le
masquerading plutôt que le SNAT j'observe le meme comportement...
Et le fait d'avoir cette interdiction de pinger toute interface
netfilter actif ou pas me fait penser à une erreur de configuration
réseau mais là...je ne vois pas...
Merci de vos lumières.
P.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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...) :
Super... Merci beaucoup pour tous ces renseignements. Et le lien. P.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg a écrit :
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...) :
Super...
Merci beaucoup pour tous ces renseignements. Et le lien.
P.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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...) :
Super... Merci beaucoup pour tous ces renseignements. Et le lien. P.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Michel OLTRA
Bonjour,
Le samedi 06 janvier 2007, Pascal Hambourg a écrit...
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...) :
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bonjour,
Le samedi 06 janvier 2007, Pascal Hambourg a écrit...
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...) :
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le samedi 06 janvier 2007, Pascal Hambourg a écrit...
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...) :
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
