problème réseau

Serge Cavailles

05/01/2007 à 17:30

Le Vendredi 05 Janvier 2007 15:51, pascal a écrit :

Bonjour la liste,

Bonjour

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.

[snip]
La config est OK.

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" :

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'obt iens
alors le même message (ping: sendmsg: Operation not permitted)

Que donne dans ce cas un "iptables -L" ?
Que donne un "echo /proc/sys/net/ipv4/ip_forward" ?

[snip]

Où ai-je fait une erreur ? je fais du SNAT à la place du masquerade c ar
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...

Le SNAT est fait pour permettre l'utilisation d'un pool (groupe?) d'IPs par
le routeur, le masquerading peut être vu comme le cas particulier ou le
pool est réduit à une seule IP, celle du routeur. Dans le cas présent , vous
utilisez le SNAT pour faire du masquerading. Le fonctionnement est
équivalent.

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...

Personnellement, je trouve difficilement compréhensible et trompeuse la
sortie de iptables -L ou de iptables-save. La liste des commandes iptables
lancées me serait plus parlante.

Merci de vos lumières.

lueurs simplement

--
Serge

Pascal Hambourg

05/01/2007 à 18:00

Salut,

pascal a écrit :
[...]

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" :

Un hôte ne pingue pas une interface réseau, et encore moins les siennes
(s'il envoie un ping destiné à lui-même par une de ses interfaces vers
l'extérieur, comment diable espère-t-il obtenir une réponse). Il pingue
une adresse IP. Ce qui est parfois mal compris est qu'un paquet envoyé
par un hôte à une des ses adresses locales, quelle que soit l'interface
à laquelle cette adresse est affectée, passe par l'interface de loopback
"lo". Par conséquent, il faut que lo soit activée et configurée et que
les paquets soient autorisés en entrée et en sortie sur celle-ci.

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.

L'interface lo est-elle activée et configurée (ifconfig) ?
Le trafic en INPUT et OUTPUT sur lo est-il autorisé par iptables ?

Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)

Que veut dire "sans règles" exactement ? Quelles sont les politiques par
défaut dans ce cas ? Si elles sont à DROP, alors forcément sans règle
rien ne passe.

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) !!!

Il est possible que le démon DHCP utilise un accès réseau de bas niveau
et court-circuite ainsi le routage IP normal et iptables.

iptables-save :

[...]

*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]

Si ça reste comme ça sans règles, rien ne passera.

-A INPUT -i ! eth0 -j ACCEPT

Dangeureux. Il vaut mieux lister explicitement les interfaces que l'on
veut prendre en compte plutôt que le contraire avec une inversion.

-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

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?
Encore une fois, il vaut mieux lister explicitement les états qu'on
souhaite prendre en compte plutôt que le contraire avec une inversion.

--
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

Salut,

pascal a écrit :
[...]

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" :

Un hôte ne pingue pas une interface réseau, et encore moins les siennes
(s'il envoie un ping destiné à lui-même par une de ses interfaces vers
l'extérieur, comment diable espère-t-il obtenir une réponse). Il pingue
une adresse IP. Ce qui est parfois mal compris est qu'un paquet envoyé
par un hôte à une des ses adresses locales, quelle que soit l'interface
à laquelle cette adresse est affectée, passe par l'interface de loopback
"lo". Par conséquent, il faut que lo soit activée et configurée et que
les paquets soient autorisés en entrée et en sortie sur celle-ci.

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.

L'interface lo est-elle activée et configurée (ifconfig) ?
Le trafic en INPUT et OUTPUT sur lo est-il autorisé par iptables ?

Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)

Que veut dire "sans règles" exactement ? Quelles sont les politiques par
défaut dans ce cas ? Si elles sont à DROP, alors forcément sans règle
rien ne passe.

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) !!!

Il est possible que le démon DHCP utilise un accès réseau de bas niveau
et court-circuite ainsi le routage IP normal et iptables.

iptables-save :

[...]

*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]

Si ça reste comme ça sans règles, rien ne passera.

-A INPUT -i ! eth0 -j ACCEPT

Dangeureux. Il vaut mieux lister explicitement les interfaces que l'on
veut prendre en compte plutôt que le contraire avec une inversion.

-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

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?
Encore une fois, il vaut mieux lister explicitement les états qu'on
souhaite prendre en compte plutôt que le contraire avec une inversion.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Salut,

pascal a écrit :
[...]

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" :

Un hôte ne pingue pas une interface réseau, et encore moins les siennes
(s'il envoie un ping destiné à lui-même par une de ses interfaces vers
l'extérieur, comment diable espère-t-il obtenir une réponse). Il pingue
une adresse IP. Ce qui est parfois mal compris est qu'un paquet envoyé
par un hôte à une des ses adresses locales, quelle que soit l'interface
à laquelle cette adresse est affectée, passe par l'interface de loopback
"lo". Par conséquent, il faut que lo soit activée et configurée et que
les paquets soient autorisés en entrée et en sortie sur celle-ci.

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.

L'interface lo est-elle activée et configurée (ifconfig) ?
Le trafic en INPUT et OUTPUT sur lo est-il autorisé par iptables ?

Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)

Que veut dire "sans règles" exactement ? Quelles sont les politiques par
défaut dans ce cas ? Si elles sont à DROP, alors forcément sans règle
rien ne passe.

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) !!!

Il est possible que le démon DHCP utilise un accès réseau de bas niveau
et court-circuite ainsi le routage IP normal et iptables.

iptables-save :

[...]

*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]

Si ça reste comme ça sans règles, rien ne passera.

-A INPUT -i ! eth0 -j ACCEPT

Dangeureux. Il vaut mieux lister explicitement les interfaces que l'on
veut prendre en compte plutôt que le contraire avec une inversion.

-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

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?
Encore une fois, il vaut mieux lister explicitement les états qu'on
souhaite prendre en compte plutôt que le contraire avec une inversion.

--
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

05/01/2007 à 19:30

Serge Cavailles a écrit :

Que donne un "echo /proc/sys/net/ipv4/ip_forward" ?

Bonne idée de vérifier ce réglage, mais il ne peut affecter que les
communication entre les postes du réseau interne et la Livebox ou le
reste du monde. Il n'a aucun effet sur les communication entre la
passerelle et les postes du réseau interne.

Le SNAT est fait pour permettre l'utilisation d'un pool (groupe?) d'IPs par
le routeur, le masquerading peut être vu comme le cas particulier ou le
pool est réduit à une seule IP, celle du routeur.

Non, MASQUERADE est bien plus qu'un cas particulier de SNAT réduit à une
seule adresse. MASQUERADE utilise l'adresse IP de l'interface de sortie,
et dans certains cas l'adresse que la machine utiliserait pour
communiquer avec la destination via cette interface de sortie. Il a (ou
avait, je ne suis pas sûr que cette fonctionnalité soit maintenue dans
les noyaux récents) la particularité de nettoyer les connexions masquées
existantes liées à une interface lorsque cette dernière change d'état.
Il est donc particulièrement utile quand cette adresse est dynamique,
non connue à l'avance et susceptible de changer.

Personnellement, je trouve difficilement compréhensible et trompeuse la
sortie de iptables -L ou de iptables-save.

Je suis d'accord concernant iptables -L, surtout si on omet l'option -v
car cela cache certaines options capitales. Par contre j'aime bien le
format de sortie d'iptables-save très proche de la syntaxe des règles
iptables, malgré parfois quelques bugs d'affichage comme des "!"
(inversions) manquants.

La liste des commandes iptables lancées me serait plus parlante.

A condition que cette liste reflète fidèlement les règles réellement en
place.

--
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

Serge Cavailles a écrit :

Que donne un "echo /proc/sys/net/ipv4/ip_forward" ?

Bonne idée de vérifier ce réglage, mais il ne peut affecter que les
communication entre les postes du réseau interne et la Livebox ou le
reste du monde. Il n'a aucun effet sur les communication entre la
passerelle et les postes du réseau interne.

Le SNAT est fait pour permettre l'utilisation d'un pool (groupe?) d'IPs par
le routeur, le masquerading peut être vu comme le cas particulier ou le
pool est réduit à une seule IP, celle du routeur.

Non, MASQUERADE est bien plus qu'un cas particulier de SNAT réduit à une
seule adresse. MASQUERADE utilise l'adresse IP de l'interface de sortie,
et dans certains cas l'adresse que la machine utiliserait pour
communiquer avec la destination via cette interface de sortie. Il a (ou
avait, je ne suis pas sûr que cette fonctionnalité soit maintenue dans
les noyaux récents) la particularité de nettoyer les connexions masquées
existantes liées à une interface lorsque cette dernière change d'état.
Il est donc particulièrement utile quand cette adresse est dynamique,
non connue à l'avance et susceptible de changer.

Personnellement, je trouve difficilement compréhensible et trompeuse la
sortie de iptables -L ou de iptables-save.

Je suis d'accord concernant iptables -L, surtout si on omet l'option -v
car cela cache certaines options capitales. Par contre j'aime bien le
format de sortie d'iptables-save très proche de la syntaxe des règles
iptables, malgré parfois quelques bugs d'affichage comme des "!"
(inversions) manquants.

La liste des commandes iptables lancées me serait plus parlante.

A condition que cette liste reflète fidèlement les règles réellement en
place.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

pascal

05/01/2007 à 20:00

Pascal Hambourg a écrit :

Salut,

Bonsoir

Un hôte ne pingue pas une interface réseau, et encore moins les siennes
(s'il envoie un ping destiné à lui-même par une de ses interfaces vers
l'extérieur, comment diable espère-t-il obtenir une réponse). Il pingue
une adresse IP. Ce qui est parfois mal compris est qu'un paquet envoyé
par un hôte à une des ses adresses locales, quelle que soit l'interface
à laquelle cette adresse est affectée, passe par l'interface de loopback
"lo". Par conséquent, il faut que lo soit activée et configurée et que
les paquets soient autorisés en entrée et en sortie sur celle-ci.

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

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.

L'interface lo est-elle activée et configurée (ifconfig) ?
Le trafic en INPUT et OUTPUT sur lo est-il autorisé par iptables ?

sortie de ifconfig :

eth0 Lien encap:Ethernet HWaddr xxxxx
inet adr:192.168.1.20 Bcast:192.168.1.255
Masque:255.255.255.0
adr inet6: xxxxx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9404 errors:0 dropped:0 overruns:0 frame:0
TX packets:9128 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:5149805 (4.9 MiB) TX bytes:1637192 (1.5 MiB)
Interruption:233 Adresse de base:0x4000

eth1 Lien encap:Ethernet HWaddr xxxx
inet adr:192.168.2.20 Bcast:192.168.2.255
Masque:255.255.255.0
adr inet6: xxxx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9578 errors:0 dropped:1053 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:635007 (620.1 KiB) TX bytes:6114 (5.9 KiB)
Interruption:66 Adresse de base:0xac00

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:448 (448.0 b) TX bytes:448 (448.0 b)

Ce qui laisse penser que "lo" est active.

Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)

Que veut dire "sans règles" exactement ? Quelles sont les politiques par
défaut dans ce cas ? Si elles sont à DROP, alors forcément sans règle
rien ne passe.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -P INPUT ACCEPT
iptables -t nat -F

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) !!!

Il est possible que le démon DHCP utilise un accès réseau de bas niveau
et court-circuite ainsi le routage IP normal et iptables.

Je me doutais d'un truc dans le genre.

iptables-save :

[...]
*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]

Si ça reste comme ça sans règles, rien ne passera.

-A INPUT -i ! eth0 -j ACCEPT

Dangeureux. Il vaut mieux lister explicitement les interfaces que l'on
veut prendre en compte plutôt que le contraire avec une inversion.

ok aussi.

-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

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -m state --state !
INVALID -j ACCEPT

Encore une fois, il vaut mieux lister explicitement les états qu'on
souhaite prendre en compte plutôt que le contraire avec une inversion.

Et finalement...Merci car les pings remarchent une fois le traffic
autorisé en sortie sur "lo"...
Merci à S. Cavailles pour sa réponse et à vous pour la solution...
Bonne soirée et ...Je modifie mon script en tenant compte de vos conseils.
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 :

Salut,

Bonsoir

Un hôte ne pingue pas une interface réseau, et encore moins les siennes
(s'il envoie un ping destiné à lui-même par une de ses interfaces vers
l'extérieur, comment diable espère-t-il obtenir une réponse). Il pingue
une adresse IP. Ce qui est parfois mal compris est qu'un paquet envoyé
par un hôte à une des ses adresses locales, quelle que soit l'interface
à laquelle cette adresse est affectée, passe par l'interface de loopback
"lo". Par conséquent, il faut que lo soit activée et configurée et que
les paquets soient autorisés en entrée et en sortie sur celle-ci.

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

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.

L'interface lo est-elle activée et configurée (ifconfig) ?
Le trafic en INPUT et OUTPUT sur lo est-il autorisé par iptables ?

sortie de ifconfig :

eth0 Lien encap:Ethernet HWaddr xxxxx
inet adr:192.168.1.20 Bcast:192.168.1.255
Masque:255.255.255.0
adr inet6: xxxxx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9404 errors:0 dropped:0 overruns:0 frame:0
TX packets:9128 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:5149805 (4.9 MiB) TX bytes:1637192 (1.5 MiB)
Interruption:233 Adresse de base:0x4000

eth1 Lien encap:Ethernet HWaddr xxxx
inet adr:192.168.2.20 Bcast:192.168.2.255
Masque:255.255.255.0
adr inet6: xxxx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9578 errors:0 dropped:1053 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:635007 (620.1 KiB) TX bytes:6114 (5.9 KiB)
Interruption:66 Adresse de base:0xac00

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:448 (448.0 b) TX bytes:448 (448.0 b)

Ce qui laisse penser que "lo" est active.

Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)

Que veut dire "sans règles" exactement ? Quelles sont les politiques par
défaut dans ce cas ? Si elles sont à DROP, alors forcément sans règle
rien ne passe.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -P INPUT ACCEPT
iptables -t nat -F

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) !!!

Il est possible que le démon DHCP utilise un accès réseau de bas niveau
et court-circuite ainsi le routage IP normal et iptables.

Je me doutais d'un truc dans le genre.

iptables-save :

[...]

*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]

Si ça reste comme ça sans règles, rien ne passera.

-A INPUT -i ! eth0 -j ACCEPT

Dangeureux. Il vaut mieux lister explicitement les interfaces que l'on
veut prendre en compte plutôt que le contraire avec une inversion.

ok aussi.

-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

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -m state --state !
INVALID -j ACCEPT

Encore une fois, il vaut mieux lister explicitement les états qu'on
souhaite prendre en compte plutôt que le contraire avec une inversion.

Et finalement...Merci car les pings remarchent une fois le traffic
autorisé en sortie sur "lo"...
Merci à S. Cavailles pour sa réponse et à vous pour la solution...
Bonne soirée et ...Je modifie mon script en tenant compte de vos conseils.
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

Vous avez filtré cet utilisateur ! Consultez son message

Pascal Hambourg a écrit :

Salut,

Bonsoir

Un hôte ne pingue pas une interface réseau, et encore moins les siennes
(s'il envoie un ping destiné à lui-même par une de ses interfaces vers
l'extérieur, comment diable espère-t-il obtenir une réponse). Il pingue
une adresse IP. Ce qui est parfois mal compris est qu'un paquet envoyé
par un hôte à une des ses adresses locales, quelle que soit l'interface
à laquelle cette adresse est affectée, passe par l'interface de loopback
"lo". Par conséquent, il faut que lo soit activée et configurée et que
les paquets soient autorisés en entrée et en sortie sur celle-ci.

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

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.

L'interface lo est-elle activée et configurée (ifconfig) ?
Le trafic en INPUT et OUTPUT sur lo est-il autorisé par iptables ?

sortie de ifconfig :

eth0 Lien encap:Ethernet HWaddr xxxxx
inet adr:192.168.1.20 Bcast:192.168.1.255
Masque:255.255.255.0
adr inet6: xxxxx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9404 errors:0 dropped:0 overruns:0 frame:0
TX packets:9128 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:5149805 (4.9 MiB) TX bytes:1637192 (1.5 MiB)
Interruption:233 Adresse de base:0x4000

eth1 Lien encap:Ethernet HWaddr xxxx
inet adr:192.168.2.20 Bcast:192.168.2.255
Masque:255.255.255.0
adr inet6: xxxx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9578 errors:0 dropped:1053 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:635007 (620.1 KiB) TX bytes:6114 (5.9 KiB)
Interruption:66 Adresse de base:0xac00

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:448 (448.0 b) TX bytes:448 (448.0 b)

Ce qui laisse penser que "lo" est active.

Sans règles je ne peux même plus pinger la livebox. J'obtiens alors le
même message (ping: sendmsg: Operation not permitted)

Que veut dire "sans règles" exactement ? Quelles sont les politiques par
défaut dans ce cas ? Si elles sont à DROP, alors forcément sans règle
rien ne passe.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -P INPUT ACCEPT
iptables -t nat -F

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) !!!

Il est possible que le démon DHCP utilise un accès réseau de bas niveau
et court-circuite ainsi le routage IP normal et iptables.

Je me doutais d'un truc dans le genre.

iptables-save :

[...]
*filter
:INPUT DROP [14:1884]
:FORWARD DROP [0:0]
:OUTPUT DROP [17:1955]

Si ça reste comme ça sans règles, rien ne passera.

-A INPUT -i ! eth0 -j ACCEPT

Dangeureux. Il vaut mieux lister explicitement les interfaces que l'on
veut prendre en compte plutôt que le contraire avec une inversion.

ok aussi.

-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

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

A noter que le "UNTRACKED" de la règle (*) n'est pas de moi et semble
rajouté par netfilter.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -m state --state !
INVALID -j ACCEPT

Encore une fois, il vaut mieux lister explicitement les états qu'on
souhaite prendre en compte plutôt que le contraire avec une inversion.

Et finalement...Merci car les pings remarchent une fois le traffic
autorisé en sortie sur "lo"...
Merci à S. Cavailles pour sa réponse et à vous pour la solution...
Bonne soirée et ...Je modifie mon script en tenant compte de vos conseils.
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

05/01/2007 à 21:10

pascal a écrit :

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

Quand je disais que ce point était souvent mal compris. ;-)

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1

Ce qui laisse penser que "lo" est active.

Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
pour lo, mais pas pour une interface ethernet classique). Une interface
réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
toutes les chaînes de la table 'filter'.

iptables -P INPUT ACCEPT
iptables -t nat -F

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
pourquoi la communication entre la machine et le LAN est impossible.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

Hé, on ne me la fait pas comme ça à moi. ;-)

Un petit détail concernant les règles de NAT source :

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.
Ici, les paquets vont sortir sans être NATés et les réponses vont se
perdre dans la nature si la Livebox n'a pas la route qui va bien pour
les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
passer à cause de l'erreur dans les règles SNAT.

--
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 a écrit :

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

Quand je disais que ce point était souvent mal compris. ;-)

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1

Ce qui laisse penser que "lo" est active.

Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
pour lo, mais pas pour une interface ethernet classique). Une interface
réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
toutes les chaînes de la table 'filter'.

iptables -P INPUT ACCEPT
iptables -t nat -F

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
pourquoi la communication entre la machine et le LAN est impossible.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

Hé, on ne me la fait pas comme ça à moi. ;-)

Un petit détail concernant les règles de NAT source :

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.
Ici, les paquets vont sortir sans être NATés et les réponses vont se
perdre dans la nature si la Livebox n'a pas la route qui va bien pour
les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
passer à cause de l'erreur dans les règles SNAT.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

pascal a écrit :

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

Quand je disais que ce point était souvent mal compris. ;-)

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1

Ce qui laisse penser que "lo" est active.

Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
pour lo, mais pas pour une interface ethernet classique). Une interface
réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
toutes les chaînes de la table 'filter'.

iptables -P INPUT ACCEPT
iptables -t nat -F

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
pourquoi la communication entre la machine et le LAN est impossible.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

Hé, on ne me la fait pas comme ça à moi. ;-)

Un petit détail concernant les règles de NAT source :

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.
Ici, les paquets vont sortir sans être NATés et les réponses vont se
perdre dans la nature si la Livebox n'a pas la route qui va bien pour
les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
passer à cause de l'erreur dans les règles SNAT.

--
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

Serge Cavailles

05/01/2007 à 21:10

Le Vendredi 05 Janvier 2007 19:19, Pascal Hambourg a écrit :

Serge Cavailles a écrit :
> Que donne un "echo /proc/sys/net/ipv4/ip_forward" ?

Bonne idée de vérifier ce réglage, mais il ne peut affecter que les
communication entre les postes du réseau interne et la Livebox ou le
reste du monde. Il n'a aucun effet sur les communication entre la
passerelle et les postes du réseau interne.

La question n'apparait pas en effet au bon endroit, elle venait en répons e à
la constatation suivante qui a disparue dans ma réponse:
Le Vendredi 05 Janvier 2007 15:51, pascal a écrit :

Du réseau interne je ne peux pinger la machine "m64" et encore moins la
livebox.

== fin citation ==

Non, MASQUERADE est bien plus qu'un cas particulier de SNAT

...

Il est donc particulièrement utile quand cette adresse est dynamique,
non connue à l'avance et susceptible de changer.

Je l'avais perdu de vue.

> Personnellement, je trouve difficilement compréhensible et trompeuse la
> sortie de iptables -L ou de iptables-save.

Je suis d'accord concernant iptables -L, surtout si on omet l'option -v
car cela cache certaines options capitales. Par contre j'aime bien le
format de sortie d'iptables-save très proche de la syntaxe des règles
iptables, malgré parfois quelques bugs d'affichage comme des "!"
(inversions) manquants.

:-)

Merci pour ces commentaires.

--
Serge

pascal

05/01/2007 à 23:30

Pascal Hambourg a écrit :

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

Quand je disais que ce point était souvent mal compris. ;-)

A juste titre donc...

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1

Ce qui laisse penser que "lo" est active.

Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
pour lo, mais pas pour une interface ethernet classique). Une interface
réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.

ok. Du coup j'avais également des problèmes avec gnome celui-ci
utilisant vraisemblablement différentes sockets pour sa cuisine interne
fort gènées par la fermeture de l'interface loopback. C'est également
résolu.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
toutes les chaînes de la table 'filter'.

iptables -P INPUT ACCEPT
iptables -t nat -F

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Je connaissais le premier point puisque si non précisé la table "filter"
est la table par défaut. Par contre j'ignorais le second et je pensais
naïvement que le flush concernait aussi les politiques par défaut.

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
pourquoi la communication entre la machine et le LAN est impossible.

re bien vu.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

Hé, on ne me la fait pas comme ça à moi. ;-)

Oui je m'en suis aperçu.

Un petit détail concernant les règles de NAT source :
-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.
Ici, les paquets vont sortir sans être NATés et les réponses vont se
perdre dans la nature si la Livebox n'a pas la route qui va bien pour
les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
passer à cause de l'erreur dans les règles SNAT.

Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...
Si l'erreur est corrigée ils seront bien Natés tout de même, non ?

Voili voilà. Encore merci pour toutes ces précisions.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un 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 :

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

Quand je disais que ce point était souvent mal compris. ;-)

A juste titre donc...

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1

Ce qui laisse penser que "lo" est active.

Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
pour lo, mais pas pour une interface ethernet classique). Une interface
réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.

ok. Du coup j'avais également des problèmes avec gnome celui-ci
utilisant vraisemblablement différentes sockets pour sa cuisine interne
fort gènées par la fermeture de l'interface loopback. C'est également
résolu.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
toutes les chaînes de la table 'filter'.

iptables -P INPUT ACCEPT
iptables -t nat -F

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Je connaissais le premier point puisque si non précisé la table "filter"
est la table par défaut. Par contre j'ignorais le second et je pensais
naïvement que le flush concernait aussi les politiques par défaut.

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
pourquoi la communication entre la machine et le LAN est impossible.

re bien vu.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

Hé, on ne me la fait pas comme ça à moi. ;-)

Oui je m'en suis aperçu.

Un petit détail concernant les règles de NAT source :

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.
Ici, les paquets vont sortir sans être NATés et les réponses vont se
perdre dans la nature si la Livebox n'a pas la route qui va bien pour
les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
passer à cause de l'erreur dans les règles SNAT.

Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...
Si l'erreur est corrigée ils seront bien Natés tout de même, non ?

Voili voilà. Encore merci pour toutes ces précisions.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un 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

Vous avez filtré cet utilisateur ! Consultez son message

Pascal Hambourg a écrit :

Oui oui ....je me suis très mal exprimé. Je parlais en fait de ping sur
les adresses des deux cartes ethernet. Je ne savais pas que tout passait
par lo.

Quand je disais que ce point était souvent mal compris. ;-)

A juste titre donc...

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1

Ce qui laisse penser que "lo" est active.

Oui, comme en témoigne le drapeau UP. Et configurée avec une adresse IP,
ce qui assure qu'elle est liée à la pile IP (c'est peut-être implicite
pour lo, mais pas pour une interface ethernet classique). Une interface
réseau n'a pas forcément besoin d'avoir une adresse IP pour être liée à
la pile IP, mais dans ce cas il faut vérifier qu'il existe un répertoire
portant le nom de l'interface dans /proc/sys/net/ipv4/conf/.

ok. Du coup j'avais également des problèmes avec gnome celui-ci
utilisant vraisemblablement différentes sockets pour sa cuisine interne
fort gènées par la fermeture de l'interface loopback. C'est également
résolu.

Par "sans règle" j'entendais à la suite de :

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

Note : on peut remplacer ces trois commandes par "iptables -F" qui vide
toutes les chaînes de la table 'filter'.

iptables -P INPUT ACCEPT
iptables -t nat -F

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Je connaissais le premier point puisque si non précisé la table "filter"
est la table par défaut. Par contre j'ignorais le second et je pensais
naïvement que le flush concernait aussi les politiques par défaut.

Je ne vois pas de règle autorisant le trafic sur lo en sortie.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN. Ça expliquerait
pourquoi la communication entre la machine et le LAN est impossible.

re bien vu.

Ce serait étonnant qu'iptables se permette de rajouter des trucs comme
ça. Tu n'aurais pas plutôt une règle avec "-m state --state ! INVALID" ?

Bien vu !

Hé, on ne me la fait pas comme ça à moi. ;-)

Oui je m'en suis aperçu.

Un petit détail concernant les règles de NAT source :
-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.
Ici, les paquets vont sortir sans être NATés et les réponses vont se
perdre dans la nature si la Livebox n'a pas la route qui va bien pour
les renvoyer vers la passerelle. D'ailleurs c'est ce qui devait se
passer à cause de l'erreur dans les règles SNAT.

Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...
Si l'erreur est corrigée ils seront bien Natés tout de même, non ?

Voili voilà. Encore merci pour toutes ces précisions.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un 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

06/01/2007 à 00:20

pascal a écrit :

iptables -P INPUT ACCEPT

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN.

[...]

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !

Tu l'as dit. Quelle honte que je n'aie pas vu ça lors de ma première
réponse...

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.

[...]

Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...

Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
de leur comportement particulier (elles ne voient passer que le premier
paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
expose à des effets de bord. En particulier la création et la
suppression de règles NAT n'ont aucune influence sur les paquets
appartenant ou liés aux connexions déjà établies : les paquets des
connexions existantes continuent d'être NATés de la même façon.

Exemple pratique :
Pendant que la règle SNAT est en place, l'utilisatrice établit une
connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
la règle SNAT est supprimée. Malgré cela, tant que la connexion
existante reste établie, la translation d'adresse et de port mise en
place pour elle par le passage du premier paquet reste active et
l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.

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.

Si l'erreur est corrigée ils seront bien Natés tout de même, non ?

Oui, bien sûr.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?

Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
2004, et je n'ai jamais participé à des discussions sur ces sites.

--
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 a écrit :

iptables -P INPUT ACCEPT

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN.

[...]

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !

Tu l'as dit. Quelle honte que je n'aie pas vu ça lors de ma première
réponse...

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.

[...]

Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...

Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
de leur comportement particulier (elles ne voient passer que le premier
paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
expose à des effets de bord. En particulier la création et la
suppression de règles NAT n'ont aucune influence sur les paquets
appartenant ou liés aux connexions déjà établies : les paquets des
connexions existantes continuent d'être NATés de la même façon.

Exemple pratique :
Pendant que la règle SNAT est en place, l'utilisatrice établit une
connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
la règle SNAT est supprimée. Malgré cela, tant que la connexion
existante reste établie, la translation d'adresse et de port mise en
place pour elle par le passage du premier paquet reste active et
l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.

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.

Si l'erreur est corrigée ils seront bien Natés tout de même, non ?

Oui, bien sûr.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?

Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
2004, et je n'ai jamais participé à des discussions sur ces sites.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

pascal a écrit :

iptables -P INPUT ACCEPT

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'ai oublié de dire que je ne voyais pas non plus de règle autorisant le
trafic en sortie sur eth1, l'interface vers le LAN.

[...]

-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

^^^
Je pense qu'il y a une petite erreur de frappe dans les adresses des
options -s : 192.162 au lieu de 192.168.

Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles
pareilles !

Tu l'as dit. Quelle honte que je n'aie pas vu ça lors de ma première
réponse...

Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ?
Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le
faire dans les règles de filtrage plutôt que dans les règles de NAT.

[...]

Hé bien primitivement, c'était sous cette forme qu'était rédigée la
règle concernant ces deux postes. Mais voilà : comme ils appartiennent à
deux jeunes filles d'âges différents je voulais pouvoir agir sur ces
postes de façon différente grâce à une ligne dans la crontab...

Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
de leur comportement particulier (elles ne voient passer que le premier
paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
expose à des effets de bord. En particulier la création et la
suppression de règles NAT n'ont aucune influence sur les paquets
appartenant ou liés aux connexions déjà établies : les paquets des
connexions existantes continuent d'être NATés de la même façon.

Exemple pratique :
Pendant que la règle SNAT est en place, l'utilisatrice établit une
connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
la règle SNAT est supprimée. Malgré cela, tant que la connexion
existante reste établie, la translation d'adresse et de port mise en
place pour elle par le passage du premier paquet reste active et
l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.

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.

Si l'erreur est corrigée ils seront bien Natés tout de même, non ?

Oui, bien sûr.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?

Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
2004, et je n'ai jamais participé à des discussions sur ces sites.

--
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

06/01/2007 à 03:00

Pascal Hambourg a écrit :

pascal a écrit :

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'avais corrigé...A tel point que je n'avais même pas vu l'erreur.

Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
de leur comportement particulier (elles ne voient passer que le premier
paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
expose à des effets de bord. En particulier la création et la
suppression de règles NAT n'ont aucune influence sur les paquets
appartenant ou liés aux connexions déjà établies : les paquets des
connexions existantes continuent d'être NATés de la même façon.

Exemple pratique :
Pendant que la règle SNAT est en place, l'utilisatrice établit une
connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
la règle SNAT est supprimée. Malgré cela, tant que la connexion
existante reste établie, la translation d'adresse et de port mise en
place pour elle par le passage du premier paquet reste active et
l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.

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 :-)
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

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 ? Et il n' y a pas là de
redondance, alors ?
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 ?

Merci encore pour ton attention.
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.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?

Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
2004, et je n'ai jamais participé à des discussions sur ces sites.

OK. Au temps pour moi.
Hé bien bonne nuit...Ou ce qu'il en reste.
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 :

pascal a écrit :

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'avais corrigé...A tel point que je n'avais même pas vu l'erreur.

Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
de leur comportement particulier (elles ne voient passer que le premier
paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
expose à des effets de bord. En particulier la création et la
suppression de règles NAT n'ont aucune influence sur les paquets
appartenant ou liés aux connexions déjà établies : les paquets des
connexions existantes continuent d'être NATés de la même façon.

Exemple pratique :
Pendant que la règle SNAT est en place, l'utilisatrice établit une
connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
la règle SNAT est supprimée. Malgré cela, tant que la connexion
existante reste établie, la translation d'adresse et de port mise en
place pour elle par le passage du premier paquet reste active et
l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.

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 :-)
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

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 ? Et il n' y a pas là de
redondance, alors ?
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 ?

Merci encore pour ton attention.
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.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?

Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
2004, et je n'ai jamais participé à des discussions sur ces sites.

OK. Au temps pour moi.
Hé bien bonne nuit...Ou ce qu'il en reste.
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

Vous avez filtré cet utilisateur ! Consultez son message

Pascal Hambourg a écrit :

pascal a écrit :

Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas
modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque
le trafic sortant et routé.

Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.

J'avais corrigé...A tel point que je n'avais même pas vu l'erreur.

Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans
la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes
de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu
de leur comportement particulier (elles ne voient passer que le premier
paquet d'une nouvelle connexion), s'en servir pour faire du filtrage
expose à des effets de bord. En particulier la création et la
suppression de règles NAT n'ont aucune influence sur les paquets
appartenant ou liés aux connexions déjà établies : les paquets des
connexions existantes continuent d'être NATés de la même façon.

Exemple pratique :
Pendant que la règle SNAT est en place, l'utilisatrice établit une
connexion avec un logiciel de messagerie instantanée. Arrive l'heure où
la règle SNAT est supprimée. Malgré cela, tant que la connexion
existante reste établie, la translation d'adresse et de port mise en
place pour elle par le passage du premier paquet reste active et
l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure.

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 :-)
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

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 ? Et il n' y a pas là de
redondance, alors ?
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 ?

Merci encore pour ton attention.
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.

Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y
a de celà quelques années...Il y a un lien ?

Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été
2004, et je n'ai jamais participé à des discussions sur ces sites.

OK. Au temps pour moi.
Hé bien bonne nuit...Ou ce qu'il en reste.
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

06/01/2007 à 12:40

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

--
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 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

--
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

Vous avez filtré cet utilisateur ! Consultez son message

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

--
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

problème réseau

10 réponses

Veuillez sélectionner un problème