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.
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.
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.
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.
J'ai vu aussi le match pysdev de iptables.
Comment dois-je procéder pour m'en sortir en gardant le bridge
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.
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.
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.
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.
J'ai vu aussi le match pysdev de iptables.
Comment dois-je procéder pour m'en sortir en gardant le bridge
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.
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.
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.
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.
J'ai vu aussi le match pysdev de iptables.
Comment dois-je procéder pour m'en sortir en gardant le bridge
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.
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.
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.
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
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
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
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.
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.
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...
>
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 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...
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) ?
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) ?
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) ?
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) ?
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) ?
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) ?
Je ne sais pas si c'est important mais je n'ai pas activé STP sur le
bridge...
Je ne sais pas si c'est important mais je n'ai pas activé STP sur le
bridge...
Je ne sais pas si c'est important mais je n'ai pas activé STP sur le
bridge...
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.
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.
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.
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.
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.
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 ?
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.
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.
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 ?
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.
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.
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 ?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.