Salut !

Je ne sais pas ou trouver des geeks a propos de netfilter:

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

Ca marche parfaitement pour quelques dizaines de postes et serveurs,
sauf que:

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

Quelqu'un a une idée ?

Moi, j'en ai plus. :-(


--
c'est pas moi

LLogicoss wrote:
> 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é...
Que faire ?
Y a un truc pour que le bridge ne soit pas poreux ?

--
c'est pas moi

Salut,

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

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 ?

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

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.

Pascal Hambourg wrote:
> 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

C'est bien ça.

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

Exact !

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

Bien vu ! et j'ai bien CONFIG_BRIDGE_NETFILTER=y

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

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

Merci pour ses suggestions.

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.

Merci

--
c'est pas moi

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

Méconnaissance de quoi ?

>> Le pont a-t-il une adresse IP ?
>
> Le pont n'a pas d'IP.

Je m'en doutais, sinon il me semble qu'on n'aurait pas observé ce
comportement, les paquets ethernet n'auraient pas traversé le pont.

>> 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 peux le comprendre, surtout si tu as besoin de cette option avec ton
pont filtrant.

> Je prefere deplacer le bridge sur un autre serveur.

Séparer le routage+NAT IP et le pontage ethernet sur des machines
différentes est une sage initiative, ça évite tout risque d'interférence
entre les deux fonctions. Au fait, quel genre de filtrage ce pont fait-il ?

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

En même temps, faire du NAT IP sur un pont ce serait plutôt crade.

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

Je ne vois guère en quoi ebtables pourrait aider, ni ce que tu entends
par "poreux". Ceci dit le pont filtrant est un domaine nouveau pour moi,
sur lequel je me suis penché seulement après avoir lu ton message
(j'avais un peu de temps). Et ma première impression après quelques
tests est que cette option CONFIG_BRIDGE_NETFILTER est un hack assez
immonde.

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

Pascal Hambourg wrote:

> Méconnaissance de quoi ?

Du réseau tout simplement )

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

> Je ne vois guère en quoi ebtables pourrait aider, ni ce que tu entends
> par "poreux".

"poreux" parce que la 1er fois que j'ai vu un paquet passant par le
bridge et atterissant dans ma table INPUT, alors que rien ne l'y invite,
je me suis dit qu'il y avait un trou quelque part ;-)


> 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

BRAVO !
Ca resout mon problème.
En plus ca rejoint ma premiere analyse du problème ;-)
Et encore en plus, ca me soulage du tracking du bridge, dont je n'ai que
faire.

J'etais passé a côté de cette table 'raw'... comme quoi, j'ai bien des
lacunes sur le sujet ;-)

Encore Merci

--
c'est pas moi

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

ebtables peut filtrer sur les ports TCP et UDP. Si la QoS est basée sur
le marquage de paquets (cible MARK), ebtables le permet aussi. Tout ça
pour dire que dans ton cas le filtrage par iptables dans le pont (et
donc l'option CONFIG_BRIDGE_NETFILTER) n'est peut-être pas indispensable.

>> iptables -t raw -A PREROUTING -i br0 -j NOTRACK
>
> BRAVO !
> Ca resout mon problème.

J'aime les histoires qui finissent bien. C'est mon côté midinette. :')

Je n'avais pas testé, il était tard, j'allais me coucher et j'aurais
attendu le lendemain pour répondre si cette idée ne m'était pas venue
subitement. Non pas que ce soit urgent, mais j'avais peur de l'oublier
pendant mon sommeil. ;-)

> En plus ca rejoint ma premiere analyse du problème ;-)

Oui, bonne intuition que je n'ai fait qu'étayer.

> J'etais passé a côté de cette table 'raw'... comme quoi, j'ai bien des
> lacunes sur le sujet ;-)

A ta décharge, je crois que la table 'raw' et sa cible NOTRACK sont très
peu connues. J'en profite pour mentionner que la cible NOTRACK introduit
un nouvel état de suivi connexion (si on peut dire) des paquets qu'elle
traite : UNTRACKED.