Parce que ton br0 ne fait pas partie du bridge.
Br0 EST le bridge.
Et le bridge peut avoir son adresse ip, puisque c’est l’interface de ta machne qui est destinée à causer au réseau en IP.
Les interfaces physiques eth peuvent aussi avoir une ip, ta config en est la preuve, mais ce n’est pas une config logique. Normalement, tu ne devrais pas avoir besoin d’utiliser l’ip sur ton eth0, puisque ton trafic ip pour ta machine est sensé passer par ton bridge.
[edit: je viens de voir que ce que je dis n’a aucun interet, vu que c’est le wifi qui est dans le pont.]
c’est quand même pas simple tout çà !! Mais çà vaut mieux que d’enchainer une suite de commandes sans savoir ce qu’on fait !
Je n’ai pas le répertoire bridge
root@serveur-debian:/proc/sys/net# ls
core ipv4 ipv6 netfilter nf_conntrack_max unix
Faut-il créer ce fichier ? proc/sys/net/bridge/bridge-nf-call-iptables
En fait br0 peut être vue comme l’interface réseau virtuelle qui relie le pont aux couches réseau supérieures du système.
Exactement.
On ne peut pas créer ni supprimer de fichiers dans /proc. /proc n’est pas un système de fichiers normal, c’est une interface avec le noyau, comme /sys.
Je découvre grâce à toi qu’il y a eu un changement dans le noyau de Stretch (c’est aussi pour cela que je participe à des forums). La fonction de filtrage par netfilter dans un pont a été déportée dans un nouveau module br_netfilter. Il faut que ce module soit chargé pour que /proc/sys/net/bridge existe. Il est chargé automatiquement si on crée une règle iptables utilisant la correspondance “physdev”.
Pour rappel, la correspondance “physdev” d’iptables permet de tester si un paquet est vu par iptables dans un pont ainsi que son interface physique (“port”) d’entrée ou de sortie, l’interface logique vue par “-i” ou “-o” étant l’interface du pont lui-même, br0 ici.
Donc si tu n’as pas besoin de cette fonctionnalité et si le module br_netfilter n’est pas chargé, le modèle est simplifié.
Le pont est comme un switch virtuel qui serait hors du système et aurait trois ports matérialisés par trois interfaces :
- eth1 relié au réseau LAN ethernet physique
- wlan0 relié au point d’accès wifi
- br0 relié en interne au système
La couche IP du système, et notamment iptables, ne voit pas les paquets qui passent dans le pont tant qu’ils n’entrent ou ne sortent pas par l’interface br0. Tu peux considérer la passerelle comme un simple routeur avec deux interfaces, br0 côté LAN et eth0 côté box. Dans tes règles iptables seules ces interfaces seront mentionnées, et tu n’auras pas besoin de la correspondance “physdev”.
Dans ce modèle, tu peux encore faire du filtrage simple des trames qui passent dans le pont avec ebtables si tu le souhaites. Mais si tu veux utiliser iptables pour faire ce filtrage (ce que je déconseille sauf nécessité absolue), alors le modèle change radicalement et les choses se compliquent.
Citation : trouvée là : https://www.ordinoscope.net/index.php/Informatique/Linux/R%C3%A9seau/Netfilter-iptables/Recettes/Bridge_ethernet_et_iptables
[quote]Iptables ne filtre que les paquets IP, c’est à dire qu’il ne traite que les paquets de couche 3 (OSI). Or, un bridge ne fonctionne qu’en couche 2, en clair ethernet ou MAC address.
Depuis le kernel 2.6, iptables intègre le module physdev, permettant de capturer le trafic depuis et vers un membre d’un bridge et de traiter les paquets comme s’ils étaient routés, c’est à dire comme en couche 3. [/quote]
Donc en clair, plus besoin de eptables !?!
Tu veux parler de la table NAT et la chaine pre-routing ou de la table filter et la chaine FORWARD ? Je me lance : je pense que c’est la chaine FORWARD de la table Filter.
A ce stade il faut un ptit schéma 
Ext --- Livebox ----------- Eth0 -------------Br0 -------------- LAN
192.168.1.1 192.168.1.10 172.16.10.1 172.16.10.0/28
Tu dis : [quote=“PascalHambourg, post:24, topic:74938”]
l’interface logique vue par “-i” ou “-o” étant l’interface du pont lui-même, br0 ici.
[/quote]
Donc intégré au schéma on aurait un truc comme çà :
----------------------------------------------Wlan0
Ext — Livebox ---- Eth0 -----br0 (-o)-----------(-i) br0 ----- LAN
-----------------------------------------------Eth1
Où br0 (-o) et br0 (-i) sont les interfaces virtuelles de sortie et d’entrée du pont virtuel qui relie le bridge à la couche 3 (ip).
Les tables Mangle et Nat interviennent à la sortie de Eth0, non ? Juste avant le premier routage (je ne sais toujours pas de quoi on parle dans ce doc ?).[quote=“PascalHambourg, post:24, topic:74938”]
La couche IP du système, et notamment iptables, ne voit pas les paquets qui passent dans le pont tant qu’ils n’entrent ou ne sortent pas par l’interface br0.
[/quote]
On peut donc considérer Br0 comme une boîte noire étanche située un étage en-dessous dans une maison qui en comporterait 3 (la maison étant le système). Du coup deux escaliers permettraient d’accéder à cet étage : les deux interfaces virtuelles de br0.[quote=“PascalHambourg, post:24, topic:74938”]
Tu peux considérer la passerelle comme un simple routeur avec deux interfaces, br0 côté LAN et eth0 côté box.
[/quote]
Dans mon modèle, les paquets entreraient dans br0 par la porte (-o) virtuelle. Ebtables permettrait de diriger les paquets à l’intérieur de la boîte (br0) soit vers eth1, soit vers Wlan0. Ils seraient ensuite dirigés vers la porte (-i) du pont pour aller sur le LAN.
Très approximatif.
-
physdev n’est pas un module mais une correspondance pour iptables et ip6tables. Le module correspondant s’appelle xt_physdev.
-
Il est inexact à deux titres que ce module permet de “capturer le trafic depuis et vers un membre d’un bridge et de traiter les paquets comme s’ils étaient routés”.
-
D’une part la fonctionnalité dont il s’agit, baptisée bridge-nf, permet simplement de faire appel à iptables pour traiter les paquets IP transportés dans les trames ethernet reçues par une interface faisant partie d’un pont. Il n’est pas question de “capturer du trafic” ni de “traiter les paquets comme s’ils étaient routés”.
-
D’autre part ce n’est pas le module xt_physdev qui réalise cette fonction. Dans les anciens noyaux, elle faisait partie du module bridge qui gère le pontage ethernet. Dans les noyaux récents elle est déportée dans le module br_netfilter.
-
Comme je l’ai déjà écrit, la correspondance physdev permet seulement à une règle iptables de tester si le paquet est ponté et par quel “port” (interface physique) le paquet est entré ou va sortir. Elle ne fonctionne que si /proc/sys/net/bridge/bridge-nf-call-iptables=1 (valeur par défaut quand br_netfilter est chargé).
Si on utile iptables pour traiter les paquets pontés (couche 2, liaison), on peut se passer d’ebtables, bien qu’ebtables doit avoir quelques fonctionnalités qu’iptables n’a pas (je n’ai pas d’exemple en tête mais j’utilise peu ebtables). Mais si on utilise en même temps iptables pour traiter les paquets IP routés dans la couche 3 (réseau), il faut faire attention aux règles mises en place car les mêmes règles s’apliquent aux deux types de paquets.
D’aucune en particulier. Toutes les tables et les chaînes sont concernées, celles-ci comme les autres.
Ton schéma n’est pas très clair. Je ne vois pas à quoi s’attachent wlan0 et eth1. Il faudrait peut-être le faire en “ASCII art” dans un bloc de code.
Et je ne vois pas pourquoi tu différencies l’interface br0 en fonction de la direction des paquets.
Je ne comprends pas le sens de ta question. Les tables interviennent pour tous les paquets traités par iptables, quelle que soit leur interface d’entrée ou de sortie.
Il n’y a qu’un seul routage, avant les chaînes OUTPUT pour les paquets émis ou après les chaînes PREROUTING pour les paquets reçus. Il peut y avoir un reroutage en sortie après les chaînes OUTPUT après certaines modifications dans la table mangle ou nat, mais je ne vois pas le rapport avec ta configuration.
Oui.
Encore une fois, je ne vois pas pourquoi tu sépares br0 selon le sens. Une interface est bidirectionnelle.
Je suppose que tu veux parler des paquets sortants de la couche IP vers la couche liaison par l’interface br0. Il vaut mieux éviter de dire qu’ils entrent, car ils techniquement ils sortent même si on peut les considérer comme entrant dans le pont par l’interface br0 (qui n’est pas vraiment un port comme les interfaces physiques).
Pour iptables, un tel paquet correspond à “-o br0”. Pour ebtables, à “-o eth1” ou “-o wlan0” selon l’interface physique de sortie.
Ce n’est pas directement ebtables qui détermine le port de sortie des paquets ethernet, pas plus qu’iptables ne détermine directement l’interface de sortie des paquets IP. C’est la table de correspondance entre les ports et les adresses MAC (équivalent de la table de routage IP mais pour les trames ethernet), construite dynamiquement à partir des adresses MAC source des trames reçues. De la même façon qu’iptables peut modifier l’adresse IP destination d’un paquet et influer sur son routage, ebtables peut modifier l’adresse MAC destination d’une trame ethernet et donc influer sur le choix du port de sortie.
Donc les paquets routés ne sont pas les mêmes que les paquets pontés.
Je ne connais pas le mode “ASCII art”. C’est une police ?
'Wlan0 et eth1 ’ sont les deux interfaces pontées dans la couche 2. Elles n’ont donc directement aucunes interfaces reliées physiquement dans la couche 3. C’est Br0 qui est relié respectivement à eth0 et LAN par ses deux interfaces virtuelles " -o br0 et -i br0.
A ce stade je pense avoir compris ce qu’était une passerelle et le fonctionnement du bridge.
Les données (trames ?) de mon LAN circulent entre elles grâce à la couche 2 ? Je veux envoyer un message du pc1 172.16.10.3/28 au pc2 172.16.10.5/28, tout se passe sur la couche 2.
Mais si je veux envoyer un message de mon pc1 vers mon serveur-debian 192.168.1.10/24 je ne peux plus le faire sur la couche 2. Je dois passer par la couche 3 (IP) et donc utiliser la passerelle. Elle se situe entre l’interface eth0 et Br0.
C’est bien çà ? Ou alors je ne comprends plus rien…
Dans mon cas, je peux communiquer avec mon serveur-debian depuis mon netbook 172.16.10.9/28 en ssh. N’ayant qu’une seule règle dans mon iptables, il doit s’agir de la règle MASQUERADE !
Hé hé, je l’avais dis des le départ, nananère.
Pour une fois, j’en savais plus que toi @PascalHambourg !
Les paquets routés sont forcément des paquets IPv4 ou IPv6. Les paquets pontés peuvent avoir n’importe quell type de contenu : IPv4, IPv6, ARP, PPPoE… Un paquet IP entré par une interface physique faisant partie d’un pont est initialement ponté mais peut devenir routé s’il est destiné à la machine elle-même du point de vue Ethernet, donc selon son adresse MAC destination (et non son adresse IP destination).
Comme on peut le voir dans le diagramme de netfilter, lorsque le filtrage des paquets pontés est activé, un tel paquet passe par les chaînes PREROUTING d’iptables en tant que paquet ponté, puis dans les chaînes INPUT (s’il est destiné à la machine selon son adresse IP destination) ou FORWARD en tant que paquet routé.
L’ASCII art est l’art de faire des dessins avec des caractères ASCII de base (ceux du clavier QWERTY américain) dans une police à espacement fixe pour que le rendu soit identique dans tous les terminaux.
Oui (et en dessous) sauf aux extrémités du chemin, les paquets passant par la couche IP de la pile réseau des machines source et destinataire.
L’adresse 192.168.1.10 appartient à la passerelle, donc c’est pareil que pour communiquer avec une autre machine du LAN. Le paquet passe par la couche IP de la source et du destinataire. Ce serait différent avec une autre destination extérieure, par exemple la box : les paquets passeraient par la couche IP de la source, de la passerelle (et de chaque routeur intermédiaire) et de la destination.
Oui, cette règle est nécessaire car la box ne connaît pas le réseau du LAN.
Pas vraiment. Tu avais écrit :
Cette fonctionnalité a été introduite dans les noyaux 2.6 mais le module br_netfilter n’existait pas dans les noyaux 2.6. Il est apparu quelque part entre le noyau 3.16 de Jessie et le noyau 4.9 de Stretch. Je rechercherai la version précise du noyau dans les changelogs plus tard.
Je pense que je dois maintenant mettre le nez dans le routage pour y voir un peu plus claire. Car je ne sais pas vraiment ce que çà veut dire…et encore moins une table de routage même si à première vue çà ressemble à un gps auquel on aurait donné les adresses de destination.
Le routage IP, c’est l’aiguillage des paquets IP principalement en fonction de leur adresse IP destination (routage de base), de la table de routage et d’autres critères comme le marquage (routage avancé).
La décision de routage se fait à trois endroits :
- pour les paquets reçus, après les chaînes PREROUTING.
- pour les paquets émis localement, avant les chaînes OUTPUT puis après au cas où la table nat aurait modifié l’adresse de destination mangle ou la table mangle aurait modifié un champ servant au routage avancé (marque, TOS…).
Comment est-ce possible sans intervention de la table NAT ? Le serveur-debian et pc1 ne sont pas dans le même reseau d’ip et n’ont pas le même masque. Ils ne peuvent donc pas communiquer par la couche IP ! Or je n’ai pas de règle NAT d’enregistré sauf la règle concernant la cible MASQUERADE de la table NAT qui si j’ai bien compris est POST-ROUTING ; c’est à dire qu’elle intervient sur les paquets à la sortie de la passerelle (eth0) pour ensuite sortir sur l’extérieur.
Si tu m’avais dit qu’elles correspondaient par la couche 2 j’aurais compris mais ce n’est pas le cas :
Donc un truc m’échappe toujours.
Bien sûr que si. Comment crois-tu qu’internet, cette interconnexion de différents réseaux, fonctionne ? C’est précisément à cela que sert le routage.
La table nat n’a rien à voir là-dedans.
Le poste client a une route pour router l’adresse 192.168.1.10 (la route par défaut) qui lui dit d’envoyer ces paquets à la passerelle, qui est dans le même réseau.
La passerelle reçoit le paquet, examine l’adresse de destination, voit que c’est pour une de ses propres adresses (peu importe que ce soit l’adresse de l’interface qui a reçu le paquet ou d’une autre interface) et l’envoie à travers la chaîne INPUT à la couche réseau supérieure en function de son protocole (SCTP, TCP, UDP…).
Tu as dis plus haut que :
Si je te suis, on n’est pas encore du côté box dans mon exemple ?
Donc l’adresse de la passerelle est 172.16.10.1 et elle est dans le même reseau que pc1. Lorsque les paquets traversent eth0 ils quittent le reseau LAN et prennent une adresse dans le reseau box ? 192.168.1.10
Je pourrais donc me connecter à ma passerelle sur l’adresse 172.16.10.1 en ssh depuis pc1 ?!?
Ah ben oui, tiens çà marche aussi avec cette adresse-là ! C’est rigolo 
Ben voilà, je suis perdu parceque je ne maîtrise pas le vocabulaire !!
Qui a dit çà au poste client ? C’est marqué où ? Là ?
root@debian9:/home/toto69# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 172.16.10.1 0.0.0.0 UG 600 0 0 wlp5s0b1
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp5s0b1
172.16.10.0 0.0.0.0 255.255.255.240 U 600 0 0 wlp5s0b1[quote=“toto69, post:35, topic:74938”]
Donc l’adresse de la passerelle est 172.16.10.1 et elle est dans le même reseau que pc1. [/quote]
Ben oui. La passerelle est forcément dans le même réseau puisque son rôle est de permettre d’atteindre d’autres réseaux.
Oui, à cause de la règle MASQUERADE. C’est indépendant du routage proprement dit.
Oui, si le service SSH écoute sur cette adresse.
C’est marqué dans la route par défaut, qui est ici la meilleure route (car la seule) correspondant à l’adresse de destination :
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 172.16.10.1 0.0.0.0 UG 600 0 0 wlp5s0b1
Qui a créé cette route, c’est soit le programme de configuration du réseau si l’interface est configurée en statique, soit le client DHCP qui a reçu cette information du serveur DHCP si l’interface est configurée automatiquement par DHCP.
Je voulais voir le chemin des trames de la couche 3 avec wireshark mais çà ne fonctionne pas 
couldn’t run /usr/bin/dumpcap in child process: permission non accordée.
J’ai autorisé le programme a fonctionner avec user et j’ai ajouté userau group wireshark.
J’aurais bien voulu voir les adresses ip sources et destination.
Wireshark et ses semblables ne voient les paquets qu’au niveau des interfaces réseau, pas à l’intérieur de la pile réseau. Pour visualiser le chemin des paquets à travers les chaînes iptables qui s’insèrent dans la couche IP, tu peux utiliser la cible TRACE ou la cible LOG. Attention, ça peut générer beaucoup de logs du noyau en function du trafic.
Mais je ne sais pas faire çà !!!