Règles iptables + pont ethernet : HELP !

Salut,

Lolotte a écrit :

J'ai ajouté une interface wlan0 et ai créé un pont ethernet (bridge) br0
composé de eth0 et wlan0.

Bêtement j'ai pensé que je devais juste changer dans mes règles iptables
eth0 en br0 et que tout allait bien fonctionner.

Ça peut être suffisant, selon les options du noyau (voir plus bas).

J'ai juste ajouter une
regle FORWARD de br0 vers br0 pour que les machines côté wlan0 puissent
causer aux machines côté eth0 et inversement.

En fonction des options du noyau (voir plus bas), ça pourrait ne même
pas être nécessaire.

Bon en fait -j'aurais dû m'en douter- ça marche pas, les trames ethernet
se perdent dans le pont et des règles iptables ne fonctionnent pas.

Les communications non pontées avec le routeur via eth0 ou wlan0
fonctionnent-elles ?

J'ai fouillé le WEB avec mon ami Google et j'ai vu ebtables qui doit
servir à corriger tout ça mais je n'ai rien compris du tout.

Non, ebtables sert à filtrer ou altérer les trames qui passent par un
pont. Si tu veux juste les laisser passer, pas besoin d'ebtables.

J'ai vu aussi le match pysdev de iptables.

Utile pour filtrer avec iptables un paquet IP qui passe par un pont en
fonction du "port" (interface physique" d'entrée et/ou de sortie. Je ne
pens pas que ce soit ton cas.

Comment dois-je procéder pour m'en sortir en gardant le bridge

Deux choses.

1) Rappel : si le noyau est compilé avec l'option BRIDGE_NETFILTER=y
(bridge-nf) disponible par défaut dans la série 2.6 ou grâce à un patch
dans la série 2.4, alors les trames ethernet contenant des paquets IPv4
qui passent par un pont sont soumises aux règles iptables. Idem pour les
trames contenant des paquets IPv6 avec ip6tables, et celles contenant
des paquets ARP avec arptables.

C'est très pratique si on veut faire un pont filtrant plus élaboré que
ce que permet ebtables, l'outil naturel de filtrage des trames ethernet
passant par un pont. Cependant quand veut juste un pont transparent dans
une machine qui fonctionne en routeur filtrant, l'interaction entre les
règles iptables et le trafic du pont peut vite devenir très pénible.

Le plus simple est alors de désactiver la prise en charge par iptables
(resp. ip6tables, arptables) des trames IPv4 (resp. IPv6, ARP) passant
par un pont. Pour cela, mettre à 0 le ou les sysctls (paramètres noyau)
concernés qui sont par défaut à 1 :

/proc/sys/net/bridge/bridge-nf-call-iptables
/proc/sys/net/bridge/bridge-nf-call-ip6tables
/proc/sys/net/bridge/bridge-nf-call-arptables

Note : ils n'existent que si le module 'bridge' est chargé, donc pas
forcément au moment où le fichier /etc/sysctl.conf est lu au démarrage.

Néanmoins une règle iptables supplémentaire dans FORWARD autorisant les
paquets avec "-i br0 -o br0" devrait laisser passer le trafic ponté.
D'où peut-être le 2).

2) Certains adaptateurs wifi ne se prêtent pas au pontage car ils ne
permettent pas d'émettre une trame avec une adresse MAC source
différente de leur propre adresse MAC, ou ne le permettent qu'avec un
firmware spécial. Or cette possibilité est nécessaire au pontage.
Cf.
<http://www.linuxfoundation.org/en/Net:Bridge#It_doesn.27t_work_with_my_Wireless_card.21>

Précédemment, Pascal Hambourg a écrit :

Salut,

Lolotte a écrit :

J'ai ajouté une interface wlan0 et ai créé un pont ethernet (bridge) br0
composé de eth0 et wlan0.

Bêtement j'ai pensé que je devais juste changer dans mes règles iptables
eth0 en br0 et que tout allait bien fonctionner.

Ça peut être suffisant, selon les options du noyau (voir plus bas).

J'ai juste ajouter une
regle FORWARD de br0 vers br0 pour que les machines côté wlan0 puissent
causer aux machines côté eth0 et inversement.

En fonction des options du noyau (voir plus bas), ça pourrait ne même
pas être nécessaire.

Bon en fait -j'aurais dû m'en douter- ça marche pas, les trames ethernet
se perdent dans le pont et des règles iptables ne fonctionnent pas.

Les communications non pontées avec le routeur via eth0 ou wlan0
fonctionnent-elles ?

J'ai fouillé le WEB avec mon ami Google et j'ai vu ebtables qui doit
servir à corriger tout ça mais je n'ai rien compris du tout.

Non, ebtables sert à filtrer ou altérer les trames qui passent par un
pont. Si tu veux juste les laisser passer, pas besoin d'ebtables.

J'ai vu aussi le match pysdev de iptables.

Utile pour filtrer avec iptables un paquet IP qui passe par un pont en
fonction du "port" (interface physique" d'entrée et/ou de sortie. Je ne
pens pas que ce soit ton cas.

Comment dois-je procéder pour m'en sortir en gardant le bridge

Deux choses.

1) Rappel : si le noyau est compilé avec l'option BRIDGE_NETFILTER=y
(bridge-nf) disponible par défaut dans la série 2.6 ou grâce à un patch
dans la série 2.4, alors les trames ethernet contenant des paquets IPv4
qui passent par un pont sont soumises aux règles iptables. Idem pour les
trames contenant des paquets IPv6 avec ip6tables, et celles contenant
des paquets ARP avec arptables.

C'est très pratique si on veut faire un pont filtrant plus élaboré que
ce que permet ebtables, l'outil naturel de filtrage des trames ethernet
passant par un pont. Cependant quand veut juste un pont transparent dans
une machine qui fonctionne en routeur filtrant, l'interaction entre les
règles iptables et le trafic du pont peut vite devenir très pénible.

Le plus simple est alors de désactiver la prise en charge par iptables
(resp. ip6tables, arptables) des trames IPv4 (resp. IPv6, ARP) passant
par un pont. Pour cela, mettre à 0 le ou les sysctls (paramètres noyau)
concernés qui sont par défaut à 1 :

/proc/sys/net/bridge/bridge-nf-call-iptables
/proc/sys/net/bridge/bridge-nf-call-ip6tables
/proc/sys/net/bridge/bridge-nf-call-arptables

Note : ils n'existent que si le module 'bridge' est chargé, donc pas
forcément au moment où le fichier /etc/sysctl.conf est lu au démarrage.

Néanmoins une règle iptables supplémentaire dans FORWARD autorisant les
paquets avec "-i br0 -o br0" devrait laisser passer le trafic ponté.
D'où peut-être le 2).

2) Certains adaptateurs wifi ne se prêtent pas au pontage car ils ne
permettent pas d'émettre une trame avec une adresse MAC source
différente de leur propre adresse MAC, ou ne le permettent qu'avec un
firmware spécial. Or cette possibilité est nécessaire au pontage.
Cf.

<http://www.linuxfoundation.org/en/Net:Bridge#It_doesn.27t_work_with_my_Wireless_card.21>

Bonjour,

Du côté de l'interface eth0 ça marche très bien (à noter qu'elle a la même
adresse MAC que br0).
Quand une machine sur le réseau Wifi (entrée par l'interface wlan0) cause
au serveur ça va pas mal si c'est à son initiative. Idem si elle cause à
une machine du réseau ethernet.
Là où ça pêche c'est quand un process du serveur essaie de parler à une
machine du reseau wlan.
Un simple ping vers une machine du réseau wifi a un comportement
aléatoire, les echo-request ne semblent sortir que quand elles veulent (en
fait a priori quand cette machine vient de parler).
Idem si on ping depuis le réseau ethernet vers le réseau wifi (donc on
FORWARD dans le serveur).
J'ai aussi le soucis quand depuis cette machine j'accède au WEB via le
proxy squid installé sur le serveur, les réponses n'arrivent pas à revenir
entre le proxy et cette machine.

Un tcpdump montre plein de requêtes ARP de la part du serveur babasse qui
cherche minus (la machine en wifi)... :
19:16:53.181908 ARP, Request who-has minus tell babasse.familledecher.com,
length 28

Ce qu'il me semble, c'est que le serveur a du mal à savoir comment
s'appellent (adresses MAC) les machines côté interface wlan0 et il ne le
sait pas tant que ces machines ne causent pas (comme elles sont sous
windows, elles causent de temps en temps alors ça l'aide mais il perd vite
leurs coordonnées) et rien ne sort tant qu'il ne les retrouve pas....

Merci de votre aide.

Lolotte
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...

Lolotte a écrit :

Un tcpdump montre plein de requêtes ARP de la part du serveur babasse
qui cherche minus (la machine en wifi)... :
19:16:53.181908 ARP, Request who-has minus tell
babasse.familledecher.com, length 28

Les symptômes que tu as décris font effectivement penser à un problème
d'ARP (sauf pour le proxy). Serait-il possible de faire une capture de
trafic sur un poste en wifi, en incluant l'en-tête MAC des paquets ?

Le problème pourrait être dû au fait que l'adaptateur wifi envoie les
trames et notamment les requêtes ARP avec sa propre adresse MAC source
au lieu de l'adresse MAC du pont ou du poste ethernet, et par conséquent
les réponses ARP ne sont pas envoyées à la bonne adresse.

Précédemment, Pascal Hambourg a écrit :

Lolotte a écrit :

Un tcpdump montre plein de requêtes ARP de la part du serveur babasse
qui cherche minus (la machine en wifi)... :
19:16:53.181908 ARP, Request who-has minus tell
babasse.familledecher.com, length 28

Les symptômes que tu as décris font effectivement penser à un problème
d'ARP (sauf pour le proxy). Serait-il possible de faire une capture de
trafic sur un poste en wifi, en incluant l'en-tête MAC des paquets ?

Le problème pourrait être dû au fait que l'adaptateur wifi envoie les
trames et notamment les requêtes ARP avec sa propre adresse MAC source
au lieu de l'adresse MAC du pont ou du poste ethernet, et par conséquent
les réponses ARP ne sont pas envoyées à la bonne adresse.

Je regarderai ce soir, j'ai vu des utilitaires comme tcpdump pour
windows...

Si c'est cela, comment puis-je m'en sortir ?
Avec une règle ebtables SNAT en POSTROUTING (ce sachant que je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...) ?
En modifiant l'adresse MAC de la carte Wifi pour la faire correspondre à
celle de la carte Ethernet (là je me demande si tout ne va pas se perdre
encore plus) ?
Mettre l'adresse MAC de la carte Wifi plutôt que celle de la carte
ethernet (si c'est possible) sur le bridge avec "ifconfig br0 hw ether
00:22:B0:75:A0:9A" (encore faudra-t-il qu'il la garde au reboot) ?

Sinon j'ai toujours la possibilité de faire 2 réseaux séparés avec le
serveur comme passerelle entre les 2 mais ça va me compliquer la conf de
tout ce qu'il y a dessus...

Merci en tout cas.

Lolotte

--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...

>
Je regarderai ce soir, j'ai vu des utilitaires comme tcpdump pour
windows...

Si c'est cela, comment puis-je m'en sortir ?
Avec une règle ebtables SNAT en POSTROUTING (ce sachant que je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...) ?
En modifiant l'adresse MAC de la carte Wifi pour la faire correspondre à
celle de la carte Ethernet (là je me demande si tout ne va pas se perdre
encore plus) ?
Mettre l'adresse MAC de la carte Wifi plutôt que celle de la carte
ethernet (si c'est possible) sur le bridge avec "ifconfig br0 hw ether
00:22:B0:75:A0:9A" (encore faudra-t-il qu'il la garde au reboot) ?

Sinon j'ai toujours la possibilité de faire 2 réseaux séparés avec le
serveur comme passerelle entre les 2 mais ça va me compliquer la conf de
tout ce qu'il y a dessus...

Je ne sais pas si c'est important mais je n'ai pas activé STP sur le
bridge...

Lolotte
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...

Lolotte a écrit :

Précédemment, Pascal Hambourg a écrit :

Le problème pourrait être dû au fait que l'adaptateur wifi envoie les
trames et notamment les requêtes ARP avec sa propre adresse MAC source
au lieu de l'adresse MAC du pont ou du poste ethernet, et par
conséquent les réponses ARP ne sont pas envoyées à la bonne adresse.

Si c'est cela, comment puis-je m'en sortir ?
Avec une règle ebtables SNAT en POSTROUTING (ce sachant que je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...) ?
En modifiant l'adresse MAC de la carte Wifi pour la faire correspondre à
celle de la carte Ethernet (là je me demande si tout ne va pas se perdre
encore plus) ?

Non, car si j'ai vu juste de toute façon l'adaptateur wifi ignore
l'adresse source du paquet que le pilote lui demande de transmettre et
utilise la sienne de toute façon donc ce serait sans effet.

Mettre l'adresse MAC de la carte Wifi plutôt que celle de la carte
ethernet (si c'est possible) sur le bridge avec "ifconfig br0 hw ether
00:22:B0:75:A0:9A" (encore faudra-t-il qu'il la garde au reboot) ?

Autre méthode pour que br0 ait l'adresse MAC de wlan0 au lieu de celle
d'eth0, inverser l'ordre dans lequel les deux interfaces sont ajoutées
au pont. Normalement le pont prend l'adresse MAC de la première
interface ajoutée. Cela devrait résoudre les problèmes de communication
entre le serveur et le réseau wifi, mais pas entre le réseau ethernet et
le réseau wifi.

Une autre idée consisterait à ajouter une règle ebtables DNAT pour
remplacer l'adresse MAC destination des réponses ARP reçues par wlan0
par l'adresse de broadcast ethernet. Ainsi toutes les machines du réseau
local la recevraient, y compris l'émettrice de la requête
correspondante. Reste à vérifier si elle accepterait une réponse en
broadcast.

Lolotte a écrit :

Je ne sais pas si c'est important mais je n'ai pas activé STP sur le
bridge...

Non. Le protocole Spanning Tree ne sert que dans un réseau comprenant
plusieurs switches ou ponts interconnectés avec des boucles.

Précédemment, Pascal Hambourg a écrit :

Si c'est cela, comment puis-je m'en sortir ?
Avec une règle ebtables SNAT en POSTROUTING (ce sachant que je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...) ?
En modifiant l'adresse MAC de la carte Wifi pour la faire correspondre à
celle de la carte Ethernet (là je me demande si tout ne va pas se perdre
encore plus) ?

Non, car si j'ai vu juste de toute façon l'adaptateur wifi ignore
l'adresse source du paquet que le pilote lui demande de transmettre et
utilise la sienne de toute façon donc ce serait sans effet.

OK

Mettre l'adresse MAC de la carte Wifi plutôt que celle de la carte
ethernet (si c'est possible) sur le bridge avec "ifconfig br0 hw ether
00:22:B0:75:A0:9A" (encore faudra-t-il qu'il la garde au reboot) ?

Autre méthode pour que br0 ait l'adresse MAC de wlan0 au lieu de celle
d'eth0, inverser l'ordre dans lequel les deux interfaces sont ajoutées
au pont. Normalement le pont prend l'adresse MAC de la première
interface ajoutée. Cela devrait résoudre les problèmes de communication
entre le serveur et le réseau wifi, mais pas entre le réseau ethernet et
le réseau wifi.

Je viens d'essayer en inversant les insersions des interfaces dans le
bridge : il prend systématiquement l'adresse MAC la plus petite (ce qui
correspond à ce que j'ai vu dans des forums).
Si j'essaie de modifier à la main l'adresse MAC de br0, quand je relance
les interfaces, elle refuse de démarrer en me disant que l'adresse MAC
n'est pas celle attendue...
=> Je laisse tomber cette piste.

Une autre idée consisterait à ajouter une règle ebtables DNAT pour
remplacer l'adresse MAC destination des réponses ARP reçues par wlan0
par l'adresse de broadcast ethernet. Ainsi toutes les machines du réseau
local la recevraient, y compris l'émettrice de la requête
correspondante. Reste à vérifier si elle accepterait une réponse en
broadcast.

Comme je ne trouve pas ebtables, j'ai bien peur de finir par faire 2
réseaux... et ça ne me satisfait pas.
Tiens d'ailleurs, dans cette configuration avec 2 réseaux, si je forward
tout entre les 2 interfaces eth0 (ip 192.168.2.1) et wlan0 (ip
192.168.3.1) dans les 2 sens, suis-je obligé de faire écouter mes services
sur le serveur sur les 2 interfaces, ou je peux me contenter de tout
laisser comme ça ?

Imaginons que la machine Wifi 192.168.3.34 avec passerelle par défaut
192.168.3.1 s'adresse à un service sur l'ip 192.168.2.1, est-ce que les
paquets vont entrer par wlan0, aller sur eth0, entrer dans le serveur par
eth0, être filtrés par les règles iptables contenant -i eth0 et arriver
sur le service qui écoute sur eth0 ?
Typiquement, j'ai un bind qui écoute sur 192.168.2.1 et 127.0.0.1 et un
autre qui écoute sur l'ip Internet, vais-je devoir lui demander au premier
d'écouter aussi sur 192.16.3.1 ? Idem pour mon apache qui écoute soit sur
l'ip 192.168.2.1, soit sur l'ip Internet, devra-t-il aussi écouter sur
192.168.3.1 ?

Enfin, je vais déjà voir ce soir les paquets sur la machine Wifi...
peut-être que le problème n'est pas là du tout...


Merci

Lolotte

--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...

Lolotte a écrit :

Mettre l'adresse MAC de la carte Wifi plutôt que celle de la carte
ethernet (si c'est possible) sur le bridge avec "ifconfig br0 hw
ether 00:22:B0:75:A0:9A" (encore faudra-t-il qu'il la garde au reboot) ?

Tout ce que fait ifconfig est volatil, comme probablement toutes les
commandes de configuration qui n'écrivent pas dans un fichier. Pour que
la modification soit permanente, il faut la refaire à chaque fois après
la création de l'interface.

Autre méthode pour que br0 ait l'adresse MAC de wlan0 au lieu de celle
d'eth0, inverser l'ordre dans lequel les deux interfaces sont ajoutées
au pont. Normalement le pont prend l'adresse MAC de la première
interface ajoutée.

Je viens d'essayer en inversant les insersions des interfaces dans le
bridge : il prend systématiquement l'adresse MAC la plus petite (ce qui
correspond à ce que j'ai vu dans des forums).

Tu as raison, je viens de vérifier. Pourtant dans mon souvenir c'était
différent, j'avais peut-être mal vu...

Si j'essaie de modifier à la main l'adresse MAC de br0, quand je relance
les interfaces, elle refuse de démarrer en me disant que l'adresse MAC
n'est pas celle attendue...

Comment ça ? Qu'entends-tu par "relancer les interfaces" ? Comment
crées-tu le pont, à la main ou dans un script perso avec brctl ou avec
les fichiers de configuration réseau de la distribution ?

Nota :
A partir du noyau 2.6.22, on peut attribuer n'importe quelle adresse MAC
à un pont. Avant on ne pouvait utiliser que les adresses des interfaces
qui en font partie.
A partir du noyau 2.6.27, l'adresse attribuée manuellement à un pont est
conservée lors de l'ajout ou de la suppression d'une interface. Avant,
elle était inconditionnellement recalculée.

=> Je laisse tomber cette piste.

Attends, pas si vite ! Une autre possibilité serait de modifier
l'adresse MAC d'eth0 avec une valeur supérieure ou égale à celle de
wlan0 avant de l'ajouter au pont. Mais de toute façon cela ne règlera
pas le problème des communications entre ethernet et wifi.

Comme je ne trouve pas ebtables, j'ai bien peur de finir par faire 2
réseaux... et ça ne me satisfait pas.

Je n'ai pas de Mandriva 2009 (.0) opérationnelle sous la main
immédiatement (j'ai enlevé l'alim et le disque de la machine pour faire
des essais ailleurs), je regarderai ce soir.

Tiens d'ailleurs, dans cette configuration avec 2 réseaux, si je forward
tout entre les 2 interfaces eth0 (ip 192.168.2.1) et wlan0 (ip
192.168.3.1) dans les 2 sens, suis-je obligé de faire écouter mes
services sur le serveur sur les 2 interfaces, ou je peux me contenter de
tout laisser comme ça ?

A l'exception de services "bas niveau" particuliers comme DHCP, radvd...
qui écoutent directement sur une interface, les services normaux
écoutent sur des adresses, pas des interfaces. Et par défaut sous Linux
on peut communiquer avec n'importe quelle adresse sur n'importe quelle
interface (weak host model) à condition de ne pas bloquer avec iptables.

Imaginons que la machine Wifi 192.168.3.34 avec passerelle par défaut
192.168.3.1 s'adresse à un service sur l'ip 192.168.2.1, est-ce que les
paquets vont entrer par wlan0,

Oui.

aller sur eth0,

Non. Ça n'aurait aucun sens puisque l'adresse de destination appartient
à la machine.

entrer dans le serveur

Oui.

par eth0,

Non, par wlan0.

être filtrés par les règles iptables contenant -i eth0 et

Non, -i wlan0.

arriver sur le service qui écoute sur eth0 ?

Généralement un service qui écoute sur 192.168.2.1 se fiche de
l'interface par où ça arrive. La pile TCP/IP elle-même s'en fiche.
Toutes les adresses IP de la machines sont accessible et utilisables par
toutes les interfaces. Il faut considérer qu'une adresse IP appartient
globalement à la machine, pas à une interface particulière.

Typiquement, j'ai un bind qui écoute sur 192.168.2.1 et 127.0.0.1 et un
autre qui écoute sur l'ip Internet, vais-je devoir lui demander au
premier d'écouter aussi sur 192.16.3.1 ?

Si tu as spécifié "listen-on { any; };" ce n'est pas nécessaire, BIND
scanne périodiquement les interfaces et leurs adresses. De toute façon
il reste accessible par 192.168.2.1 depuis wlan0 (modulo iptables).

Idem pour mon apache qui écoute
soit sur l'ip 192.168.2.1, soit sur l'ip Internet, devra-t-il aussi
écouter sur 192.168.3.1 ?

Pas nécessairement, comme BIND.

Précédemment, Pascal Hambourg a écrit :

Lolotte a écrit :

Mettre l'adresse MAC de la carte Wifi plutôt que celle de la carte
ethernet (si c'est possible) sur le bridge avec "ifconfig br0 hw
ether 00:22:B0:75:A0:9A" (encore faudra-t-il qu'il la garde au reboot) ?

Tout ce que fait ifconfig est volatil, comme probablement toutes les
commandes de configuration qui n'écrivent pas dans un fichier. Pour que
la modification soit permanente, il faut la refaire à chaque fois après
la création de l'interface.

Quand je la change entre un ifdown et un ifup, il ne me dit rien. Mais
j'ai pas essayé de causer avec une machine wifi, je suis pas chez moi =>
ce soir.

Par contre, je l'ai mise dans /etc/sysconfig/network-scripts/icfg-br0 et
c'est en rebootant (c'est ça que j'ai appelé relancer les interfaces) que
je me suis fait engueuler, il m'a dit qu'il était pas d'accord.

Comment ça ? Qu'entends-tu par "relancer les interfaces" ? Comment
crées-tu le pont, à la main ou dans un script perso avec brctl ou avec
les fichiers de configuration réseau de la distribution ?

A l'origine j'ai construit le bridge à la main avec brctl puis j'ai mis
les config qui vont bien dans /etc/sysconfig/networking-scripts pour qu'au
boot ça se fasse tout seul.

Nota :
A partir du noyau 2.6.22, on peut attribuer n'importe quelle adresse MAC
à un pont. Avant on ne pouvait utiliser que les adresses des interfaces
qui en font partie.
A partir du noyau 2.6.27, l'adresse attribuée manuellement à un pont est
conservée lors de l'ajout ou de la suppression d'une interface. Avant,
elle était inconditionnellement recalculée.

=> Je laisse tomber cette piste.

Attends, pas si vite ! Une autre possibilité serait de modifier
l'adresse MAC d'eth0 avec une valeur supérieure ou égale à celle de
wlan0 avant de l'ajouter au pont. Mais de toute façon cela ne règlera
pas le problème des communications entre ethernet et wifi.

Je n'y avais pas pensé, je vais essayer ce soir (faut bien que je pense à
bidouiller udev qui à tous les coups va me la renommer eth2).

aller sur eth0,

Non. Ça n'aurait aucun sens puisque l'adresse de destination appartient
à la machine.

entrer dans le serveur

Oui.

par eth0,

Non, par wlan0.

être filtrés par les règles iptables contenant -i eth0 et

Non, -i wlan0.

Je m'en doutais (il faisait pareil avec eth0 et loopback et déjà). Je vais
devoir dupliquer mes règles iptables, c'est pas léger ça...

Idem pour mon apache qui écoute
soit sur l'ip 192.168.2.1, soit sur l'ip Internet, devra-t-il aussi
écouter sur 192.168.3.1 ?

Pas nécessairement, comme BIND.

Pas si sûr car j'ai des vhosts... mais bon si il y a juste apache...


Faut vraiment que je regarde les adresses MAC des paquets reçus sur la
machine Wifi parce que si ça se trouve le problème n'est même pas là...

Merci

Lolotte


--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...