Avec les outils classiques, LOG et tcpdump, je vois juste les paquets
arrivés dans la chaine PREROUTING, et puis ils arrivent inaltérés dans
la chaine INPUT ! Alors qu'il devrait être NATé et partir dans la chaine
FORWARD !!
Avec les outils classiques, LOG et tcpdump, je vois juste les paquets
arrivés dans la chaine PREROUTING, et puis ils arrivent inaltérés dans
la chaine INPUT ! Alors qu'il devrait être NATé et partir dans la chaine
FORWARD !!
Avec les outils classiques, LOG et tcpdump, je vois juste les paquets
arrivés dans la chaine PREROUTING, et puis ils arrivent inaltérés dans
la chaine INPUT ! Alors qu'il devrait être NATé et partir dans la chaine
FORWARD !!
J'ai 1 machine qui fait Firewall classique:
eth0 : WAN
eth1 : LAN
et elle fait aussi bridge pour un pool de serveurs:
eth2 : WAN
eth3 : le pool de serveurs
Sur le Firewall, j'ai de classique règle de NAT pour quelques postes, de
eth0 (WAN) vers eth1 (LAN).
La terre entiere peut se connecter a ces ports NATés, sauf, les serveurs
qui sont sur le bridge !
Apparement, les regles de NAT sont simplement pas appliqué pour ces
serveurs.
Je soupconne que 'conntrack', ou je ne sais quoi, se mélange entre les
connexions sur le Bridge et les connexions sur le eth0 et eth1.
Avec les outils classiques, LOG et tcpdump, je vois juste les paquets
arrivés dans la chaine PREROUTING, et puis ils arrivent inaltérés dans
la chaine INPUT ! Alors qu'il devrait être NATé et partir dans la chaine
FORWARD !!
En fait, je viens de me rendre compte que les paquets arrivent
directement par les interfaces du bridge (eth2 ou eth3) pour atteindre
la chaine INPUT de l'interface eth0 ...
Donc, la règle de NAT en PREROUTING est jamais appliqué...
J'ai 1 machine qui fait Firewall classique:
eth0 : WAN
eth1 : LAN
et elle fait aussi bridge pour un pool de serveurs:
eth2 : WAN
eth3 : le pool de serveurs
Sur le Firewall, j'ai de classique règle de NAT pour quelques postes, de
eth0 (WAN) vers eth1 (LAN).
La terre entiere peut se connecter a ces ports NATés, sauf, les serveurs
qui sont sur le bridge !
Apparement, les regles de NAT sont simplement pas appliqué pour ces
serveurs.
Je soupconne que 'conntrack', ou je ne sais quoi, se mélange entre les
connexions sur le Bridge et les connexions sur le eth0 et eth1.
Avec les outils classiques, LOG et tcpdump, je vois juste les paquets
arrivés dans la chaine PREROUTING, et puis ils arrivent inaltérés dans
la chaine INPUT ! Alors qu'il devrait être NATé et partir dans la chaine
FORWARD !!
En fait, je viens de me rendre compte que les paquets arrivent
directement par les interfaces du bridge (eth2 ou eth3) pour atteindre
la chaine INPUT de l'interface eth0 ...
Donc, la règle de NAT en PREROUTING est jamais appliqué...
J'ai 1 machine qui fait Firewall classique:
eth0 : WAN
eth1 : LAN
et elle fait aussi bridge pour un pool de serveurs:
eth2 : WAN
eth3 : le pool de serveurs
Sur le Firewall, j'ai de classique règle de NAT pour quelques postes, de
eth0 (WAN) vers eth1 (LAN).
La terre entiere peut se connecter a ces ports NATés, sauf, les serveurs
qui sont sur le bridge !
Apparement, les regles de NAT sont simplement pas appliqué pour ces
serveurs.
Je soupconne que 'conntrack', ou je ne sais quoi, se mélange entre les
connexions sur le Bridge et les connexions sur le eth0 et eth1.
Avec les outils classiques, LOG et tcpdump, je vois juste les paquets
arrivés dans la chaine PREROUTING, et puis ils arrivent inaltérés dans
la chaine INPUT ! Alors qu'il devrait être NATé et partir dans la chaine
FORWARD !!
En fait, je viens de me rendre compte que les paquets arrivent
directement par les interfaces du bridge (eth2 ou eth3) pour atteindre
la chaine INPUT de l'interface eth0 ...
Donc, la règle de NAT en PREROUTING est jamais appliqué...
Pour que ce soit bien clair, ton firewall a deux interfaces reliées au
même réseau WAN comme sur le schéma ci-dessous ?
WAN
--+-----------+--
| |
+---|-----------|---+
| eth0 eth2 |
| | | |
| routage+NAT pont |
| | | |
| eth1 eth3 |
+---|-----------|---+
| |
--+-- --+--
LAN serveurs
Si oui, pourquoi cette architecture avec deux interfaces sur le WAN
plutôt que d'utiliser l'interface bridge à la place de eth0 ?
Le pont a-t-il une adresse IP ?
Si je comprends bien, les paquets partent des serveurs, entrent par
eth3, traversent le pont, ressortent par eth2, parcourent le WAN et
rentrent à nouveau par eth0 dans le but d'être DNATés ?
Si le noyau Linux de la machine a été compilé avec l'option
CONFIG_BRIDGE_NETFILTER activée, les paquets ethernet traversant le pont
et contenant des paquets IP traversent les chaînes iptables comme le
feraient des paquets IP routés (PREROUTING -> FORWARD -> POSTROUTING).
Ce faisant ils sont vus une première fois par le suivi de connexion de
Netfilter. Lorsque les paquets reviennent par eth0, le suivi de
connexion les reconnaît donc comme appartenant à une connexion existante
et ils sautent les chaînes de la table 'nat'. Les règles de NAT liées à
eth0 sont donc inopérantes sur ces paquets. Je sais bien, ce n'est pas
optimal.
Si tu n'as pas besoin du filtrage d'iptables sur le pont (par exemple
ebtables suffit), tu peux recompiler le noyau sans l'option
CONFIG_BRIDGE_NETFILTER.
Sinon, tu peux essayer de faire en sorte que les règles NAT soient
appliquées aussi lors de la traversée du pont (avec -m physdev), mais je
ne garantis rien.
Sinon, si le pont n'a pas d'adresse IP tu peux aussi essayer de lui en
donner une, même bidon. Ainsi les paquets entrant par eth3 destinés à
l'adresse de eth0 ne traverseront pas le pont mais seront livrés
directement à la pile IP via l'interface pont. Il faudra donc que les
règles de NAT appliquées à eth0 s'appliquent aussi à cette interface.
Pour que ce soit bien clair, ton firewall a deux interfaces reliées au
même réseau WAN comme sur le schéma ci-dessous ?
WAN
--+-----------+--
| |
+---|-----------|---+
| eth0 eth2 |
| | | |
| routage+NAT pont |
| | | |
| eth1 eth3 |
+---|-----------|---+
| |
--+-- --+--
LAN serveurs
Si oui, pourquoi cette architecture avec deux interfaces sur le WAN
plutôt que d'utiliser l'interface bridge à la place de eth0 ?
Le pont a-t-il une adresse IP ?
Si je comprends bien, les paquets partent des serveurs, entrent par
eth3, traversent le pont, ressortent par eth2, parcourent le WAN et
rentrent à nouveau par eth0 dans le but d'être DNATés ?
Si le noyau Linux de la machine a été compilé avec l'option
CONFIG_BRIDGE_NETFILTER activée, les paquets ethernet traversant le pont
et contenant des paquets IP traversent les chaînes iptables comme le
feraient des paquets IP routés (PREROUTING -> FORWARD -> POSTROUTING).
Ce faisant ils sont vus une première fois par le suivi de connexion de
Netfilter. Lorsque les paquets reviennent par eth0, le suivi de
connexion les reconnaît donc comme appartenant à une connexion existante
et ils sautent les chaînes de la table 'nat'. Les règles de NAT liées à
eth0 sont donc inopérantes sur ces paquets. Je sais bien, ce n'est pas
optimal.
Si tu n'as pas besoin du filtrage d'iptables sur le pont (par exemple
ebtables suffit), tu peux recompiler le noyau sans l'option
CONFIG_BRIDGE_NETFILTER.
Sinon, tu peux essayer de faire en sorte que les règles NAT soient
appliquées aussi lors de la traversée du pont (avec -m physdev), mais je
ne garantis rien.
Sinon, si le pont n'a pas d'adresse IP tu peux aussi essayer de lui en
donner une, même bidon. Ainsi les paquets entrant par eth3 destinés à
l'adresse de eth0 ne traverseront pas le pont mais seront livrés
directement à la pile IP via l'interface pont. Il faudra donc que les
règles de NAT appliquées à eth0 s'appliquent aussi à cette interface.
Pour que ce soit bien clair, ton firewall a deux interfaces reliées au
même réseau WAN comme sur le schéma ci-dessous ?
WAN
--+-----------+--
| |
+---|-----------|---+
| eth0 eth2 |
| | | |
| routage+NAT pont |
| | | |
| eth1 eth3 |
+---|-----------|---+
| |
--+-- --+--
LAN serveurs
Si oui, pourquoi cette architecture avec deux interfaces sur le WAN
plutôt que d'utiliser l'interface bridge à la place de eth0 ?
Le pont a-t-il une adresse IP ?
Si je comprends bien, les paquets partent des serveurs, entrent par
eth3, traversent le pont, ressortent par eth2, parcourent le WAN et
rentrent à nouveau par eth0 dans le but d'être DNATés ?
Si le noyau Linux de la machine a été compilé avec l'option
CONFIG_BRIDGE_NETFILTER activée, les paquets ethernet traversant le pont
et contenant des paquets IP traversent les chaînes iptables comme le
feraient des paquets IP routés (PREROUTING -> FORWARD -> POSTROUTING).
Ce faisant ils sont vus une première fois par le suivi de connexion de
Netfilter. Lorsque les paquets reviennent par eth0, le suivi de
connexion les reconnaît donc comme appartenant à une connexion existante
et ils sautent les chaînes de la table 'nat'. Les règles de NAT liées à
eth0 sont donc inopérantes sur ces paquets. Je sais bien, ce n'est pas
optimal.
Si tu n'as pas besoin du filtrage d'iptables sur le pont (par exemple
ebtables suffit), tu peux recompiler le noyau sans l'option
CONFIG_BRIDGE_NETFILTER.
Sinon, tu peux essayer de faire en sorte que les règles NAT soient
appliquées aussi lors de la traversée du pont (avec -m physdev), mais je
ne garantis rien.
Sinon, si le pont n'a pas d'adresse IP tu peux aussi essayer de lui en
donner une, même bidon. Ainsi les paquets entrant par eth3 destinés à
l'adresse de eth0 ne traverseront pas le pont mais seront livrés
directement à la pile IP via l'interface pont. Il faudra donc que les
règles de NAT appliquées à eth0 s'appliquent aussi à cette interface.
Si oui, pourquoi cette architecture avec deux interfaces sur le WAN
plutôt que d'utiliser l'interface bridge à la place de eth0 ?
Par méconnaissance :-)
Le pont a-t-il une adresse IP ?
Le pont n'a pas d'IP.
Si tu n'as pas besoin du filtrage d'iptables sur le pont (par exemple
ebtables suffit), tu peux recompiler le noyau sans l'option
CONFIG_BRIDGE_NETFILTER.
Mais je ne suis pas chaud pour recompiler.
Je prefere deplacer le bridge sur un autre serveur.
Sinon, tu peux essayer de faire en sorte que les règles NAT soient
appliquées aussi lors de la traversée du pont (avec -m physdev), mais
je ne garantis rien.
Je crois avoir déjà essayé...
J'avais plutot dans l'idee de trouver des regles salvatrices avec
'ebtables' pour rendre le filtre plus ou moins poreux... mais sans
succès pour l'instant.
Si oui, pourquoi cette architecture avec deux interfaces sur le WAN
plutôt que d'utiliser l'interface bridge à la place de eth0 ?
Par méconnaissance :-)
Le pont a-t-il une adresse IP ?
Le pont n'a pas d'IP.
Si tu n'as pas besoin du filtrage d'iptables sur le pont (par exemple
ebtables suffit), tu peux recompiler le noyau sans l'option
CONFIG_BRIDGE_NETFILTER.
Mais je ne suis pas chaud pour recompiler.
Je prefere deplacer le bridge sur un autre serveur.
Sinon, tu peux essayer de faire en sorte que les règles NAT soient
appliquées aussi lors de la traversée du pont (avec -m physdev), mais
je ne garantis rien.
Je crois avoir déjà essayé...
J'avais plutot dans l'idee de trouver des regles salvatrices avec
'ebtables' pour rendre le filtre plus ou moins poreux... mais sans
succès pour l'instant.
Si oui, pourquoi cette architecture avec deux interfaces sur le WAN
plutôt que d'utiliser l'interface bridge à la place de eth0 ?
Par méconnaissance :-)
Le pont a-t-il une adresse IP ?
Le pont n'a pas d'IP.
Si tu n'as pas besoin du filtrage d'iptables sur le pont (par exemple
ebtables suffit), tu peux recompiler le noyau sans l'option
CONFIG_BRIDGE_NETFILTER.
Mais je ne suis pas chaud pour recompiler.
Je prefere deplacer le bridge sur un autre serveur.
Sinon, tu peux essayer de faire en sorte que les règles NAT soient
appliquées aussi lors de la traversée du pont (avec -m physdev), mais
je ne garantis rien.
Je crois avoir déjà essayé...
J'avais plutot dans l'idee de trouver des regles salvatrices avec
'ebtables' pour rendre le filtre plus ou moins poreux... mais sans
succès pour l'instant.
Méconnaissance de quoi ?
Au fait, quel genre de filtrage ce pont fait-il ?
Je ne vois guère en quoi ebtables pourrait aider, ni ce que tu entends
par "poreux".
Ah, je viens d'avoir une autre idée. Si le problème est le suivi de
connexion IP dans le pont, si tu n'en as pas besoin pour tes règles de
pont filtrant, et si ton noyau supporte la cible iptables NOTRACK de la
table 'raw' (en standard à partir de la version 2.6.6), tu pourrais
tenter de l'utiliser pour inhiber le suivi de connexion IP lors de la
traversée du pont. Ça donnerait quelque chose comme ceci, si br0 est le
nom de l'interface bridge :
iptables -t raw -A PREROUTING -i br0 -j NOTRACK
Méconnaissance de quoi ?
Au fait, quel genre de filtrage ce pont fait-il ?
Je ne vois guère en quoi ebtables pourrait aider, ni ce que tu entends
par "poreux".
Ah, je viens d'avoir une autre idée. Si le problème est le suivi de
connexion IP dans le pont, si tu n'en as pas besoin pour tes règles de
pont filtrant, et si ton noyau supporte la cible iptables NOTRACK de la
table 'raw' (en standard à partir de la version 2.6.6), tu pourrais
tenter de l'utiliser pour inhiber le suivi de connexion IP lors de la
traversée du pont. Ça donnerait quelque chose comme ceci, si br0 est le
nom de l'interface bridge :
iptables -t raw -A PREROUTING -i br0 -j NOTRACK
Méconnaissance de quoi ?
Au fait, quel genre de filtrage ce pont fait-il ?
Je ne vois guère en quoi ebtables pourrait aider, ni ce que tu entends
par "poreux".
Ah, je viens d'avoir une autre idée. Si le problème est le suivi de
connexion IP dans le pont, si tu n'en as pas besoin pour tes règles de
pont filtrant, et si ton noyau supporte la cible iptables NOTRACK de la
table 'raw' (en standard à partir de la version 2.6.6), tu pourrais
tenter de l'utiliser pour inhiber le suivi de connexion IP lors de la
traversée du pont. Ça donnerait quelque chose comme ceci, si br0 est le
nom de l'interface bridge :
iptables -t raw -A PREROUTING -i br0 -j NOTRACK
Au fait, quel genre de filtrage ce pont fait-il ?
Aprés le hack d'un serveur qu'on heberge (et que nous n'administrons
pas), le bridge controle juste l'association IP et adresse MAC avec
'ebtables'.
Avec IpTables, on DROP certains ports pour les serveurs Windows, et on
applique un QoS a 2 cents.
iptables -t raw -A PREROUTING -i br0 -j NOTRACK
BRAVO !
Ca resout mon problème.
En plus ca rejoint ma premiere analyse du problème ;-)
J'etais passé a côté de cette table 'raw'... comme quoi, j'ai bien des
lacunes sur le sujet ;-)
Au fait, quel genre de filtrage ce pont fait-il ?
Aprés le hack d'un serveur qu'on heberge (et que nous n'administrons
pas), le bridge controle juste l'association IP et adresse MAC avec
'ebtables'.
Avec IpTables, on DROP certains ports pour les serveurs Windows, et on
applique un QoS a 2 cents.
iptables -t raw -A PREROUTING -i br0 -j NOTRACK
BRAVO !
Ca resout mon problème.
En plus ca rejoint ma premiere analyse du problème ;-)
J'etais passé a côté de cette table 'raw'... comme quoi, j'ai bien des
lacunes sur le sujet ;-)
Au fait, quel genre de filtrage ce pont fait-il ?
Aprés le hack d'un serveur qu'on heberge (et que nous n'administrons
pas), le bridge controle juste l'association IP et adresse MAC avec
'ebtables'.
Avec IpTables, on DROP certains ports pour les serveurs Windows, et on
applique un QoS a 2 cents.
iptables -t raw -A PREROUTING -i br0 -j NOTRACK
BRAVO !
Ca resout mon problème.
En plus ca rejoint ma premiere analyse du problème ;-)
J'etais passé a côté de cette table 'raw'... comme quoi, j'ai bien des
lacunes sur le sujet ;-)