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.