Le pontage Linux ne transmet pas les paquets

visiteur · Mars 17, 2026, 6:20

J’essaie de configurer un pont Linux avec 2 interfaces Ethernet et je n’arrive pas à le faire fonctionner correctement. J’utilise Gentoo Linux et je pensais que ce serait facile. Le pont est créé, les interfaces sont ajoutées, mais les paquets ne traversent pas le pont. Les machines de chaque côté ne peuvent pas se pinger.

admin · Mars 17, 2026, 6:20

Il est possible que les périphériques réseau sous-jacents sur l’hôte n’aient pas le mode promiscuité activé. Dans VMWare, par exemple, si le commutateur virtuel sous-jacent n’a pas le mode promiscuité activé, le pontage ne fonctionnera pas car les paquets destinés à d’autres adresses MAC seront supprimés avant d’atteindre le pont.

Vérifiez également que net.bridge.bridge-nf-call-iptables est défini à 0 pour éviter qu’iptables ne filtre les trames pontées :

sysctl net.bridge.bridge-nf-call-iptables=0

AyiNEDJIMI · Mars 17, 2026, 6:22

Bonjour,

Le problème de pontage réseau Linux qui ne transmet pas les paquets dans un environnement Windows Server est un sujet classique de dépannage réseau hybride. Ce type de problème combine des aspects de configuration Linux (bridge, iptables, netfilter) et de communication avec des systèmes Windows. Voici un guide de diagnostic et de résolution complet.

Comprendre le fonctionnement du pontage Linux

Un bridge Linux (pont réseau) fonctionne en couche 2 (liaison de données) du modèle OSI. Il interconnecte plusieurs interfaces réseau et retransmet les trames Ethernet entre elles en se basant sur les adresses MAC, similairement à un switch.

Cependant, plusieurs mécanismes Linux peuvent bloquer cette transmission, notamment :

iptables / nftables appliqués aux paquets pontés
ebtables (filtrage de trames Ethernet)
Le paramètre noyau net.bridge.bridge-nf-call-iptables
STP (Spanning Tree Protocol) activé sur le bridge
Problèmes de forwarding IP

Diagnostic initial

Vérifier l’état du bridge

# Afficher les bridges existants et leurs interfaces membres
bridge link show
brctl show

# Vérifier l'état détaillé du bridge
ip link show type bridge

# Vérifier les interfaces membres
bridge fdb show

Vérifier le forwarding IP

# Vérifier si le forwarding IP est activé (essentiel pour le routage)
cat /proc/sys/net/ipv4/ip_forward
# Doit retourner 1

# Si 0, activer temporairement
echo 1 > /proc/sys/net/ipv4/ip_forward

# Pour rendre permanent (ajouter dans /etc/sysctl.conf)
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

Vérifier les paramètres bridge-nf (source principale du problème)

# Vérifier si iptables est appliqué sur le trafic ponté
cat /proc/sys/net/bridge/bridge-nf-call-iptables
cat /proc/sys/net/bridge/bridge-nf-call-ip6tables
cat /proc/sys/net/bridge/bridge-nf-call-arptables

# Si ces valeurs sont à 1, les règles iptables s'appliquent au trafic bridgé
# C'est souvent la cause principale du problème

Cause principale n°1 : iptables bloque le trafic ponté

Le problème bridge-nf-call-iptables

Lorsque bridge-nf-call-iptables = 1, tout le trafic transitant par le bridge passe par les chaînes iptables (FORWARD, INPUT, OUTPUT). Si une règle iptables DROP ou REJECT est présente, le trafic sera bloqué même si aucune règle n’est spécifiquement censée affecter le bridge.

# Vérifier les règles iptables actuelles
iptables -L -v -n
iptables -L FORWARD -v -n

# Vérifier si la politique FORWARD est DROP
iptables -L FORWARD | head -5
# Si "policy DROP" apparaît, le trafic ponté est bloqué par défaut

Solution : autoriser le trafic FORWARD pour le bridge

# Option 1 : Autoriser tout le trafic sur le bridge (moins sécurisé)
iptables -A FORWARD -i br0 -o br0 -j ACCEPT

# Option 2 : Désactiver bridge-nf pour ce bridge (recommandé si filtrage non nécessaire)
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables

# Rendre permanent
cat >> /etc/sysctl.conf << 'EOF'
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
sysctl -p

# Option 3 : Utiliser physdev pour cibler spécifiquement le trafic bridgé
iptables -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT

Note : Sur les systèmes récents (nftables), le module br_netfilter doit être chargé pour que ces paramètres prennent effet.

# Charger le module br_netfilter si nécessaire
modprobe br_netfilter
lsmod | grep br_netfilter

# Rendre permanent
echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf

Cause principale n°2 : Spanning Tree Protocol bloque les ports

Le STP peut mettre les ports du bridge en état Listening ou Blocking pendant 30 à 50 secondes lors d’un changement de topologie. Dans certains cas, un port peut rester bloqué indéfiniment.

# Vérifier l'état STP des ports du bridge
brctl showstp br0

# Les états possibles des ports :
# forwarding = normal, trafic transmis
# blocking   = bloqué par STP
# listening  = phase d'apprentissage (transition)
# learning   = apprentissage des MACs
# disabled   = désactivé

Solutions pour le STP

# Option 1 : Désactiver complètement STP (recommandé si pas de boucles réseau)
brctl stp br0 off
# Ou via ip link
ip link set br0 type bridge stp_state 0

# Option 2 : Activer RSTP (Rapid STP) pour une convergence rapide
brctl stp br0 on
# RSTP est activé par défaut sur les noyaux récents

# Vérification de l'état STP
ip -d link show br0

Cause principale n°3 : Problèmes spécifiques à l’environnement Windows Server

Communication NTLM et Kerberos à travers un bridge

Les protocoles d’authentification Windows utilisent des ports spécifiques. Si des règles iptables filtrent ces ports sur le bridge, les machines Windows ne pourront pas s’authentifier :

# Vérifier si les ports Windows critiques passent à travers le bridge
# Ports essentiels pour Windows/AD :
# 88  (TCP/UDP) : Kerberos
# 135 (TCP)     : RPC Endpoint Mapper
# 389 (TCP/UDP) : LDAP
# 445 (TCP)     : SMB
# 636 (TCP)     : LDAPS
# 3268 (TCP)    : Global Catalog
# 49152-65535   : RPC dynamique

# Capturer le trafic sur le bridge pour diagnostiquer
tcpdump -i br0 -n port 445 or port 88 or port 389 -v

Ajouter des règles iptables pour les flux Windows

# Autoriser le trafic Windows essentiel sur le bridge
iptables -A FORWARD -i br0 -p tcp --dport 88 -j ACCEPT
iptables -A FORWARD -i br0 -p udp --dport 88 -j ACCEPT
iptables -A FORWARD -i br0 -p tcp --dport 445 -j ACCEPT
iptables -A FORWARD -i br0 -p tcp --dport 389 -j ACCEPT
iptables -A FORWARD -i br0 -p tcp --dport 135 -j ACCEPT
iptables -A FORWARD -i br0 -p tcp --dport 3268 -j ACCEPT
iptables -A FORWARD -i br0 -p tcp --dport 49152:65535 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Diagnostic avancé avec tcpdump et Wireshark

# Capturer le trafic sur le bridge et ses interfaces membres
tcpdump -i br0 -w /tmp/bridge_capture.pcap -n &
tcpdump -i eth0 -w /tmp/eth0_capture.pcap -n &
tcpdump -i eth1 -w /tmp/eth1_capture.pcap -n &

# Effectuer un test (ping entre machines Windows via le bridge)
# Puis analyser les captures
pkill tcpdump

# Comparer les captures : les trames arrivent sur eth0 mais pas sur eth1 ?
# C'est le signe d'un filtrage au niveau bridge ou iptables

Configuration complète d’un bridge fonctionnel (exemple)

Voici une configuration de référence pour un bridge Linux qui transmet correctement le trafic vers des systèmes Windows Server :

# /etc/network/interfaces (Debian/Ubuntu)
auto br0
iface br0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.1
    bridge_ports eth0 eth1
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

# /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-arptables = 0

# Script de configuration iptables minimal pour un bridge avec machines Windows
iptables -F FORWARD
iptables -P FORWARD ACCEPT

# Ou si une politique DROP est nécessaire :
iptables -P FORWARD DROP
iptables -A FORWARD -i br0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Vérifications côté Windows Server

Si le problème persiste, vérifiez également côté Windows :

# Tester la connectivité réseau depuis Windows Server
Test-NetConnection -ComputerName "192.168.1.10" -Port 445
Test-NetConnection -ComputerName "192.168.1.10" -Port 80

# Vérifier la configuration réseau
Get-NetIPConfiguration
Get-NetRoute

# Vérifier le pare-feu Windows Server
Get-NetFirewallProfile | Select-Object Name, Enabled

Conclusion

Dans la majorité des cas de bridges Linux qui ne transmettent pas les paquets dans un environnement Windows Server, la cause est l’une des suivantes :

bridge-nf-call-iptables = 1 combiné avec une politique FORWARD DROP dans iptables
STP bloquant les ports du bridge pendant ou après une transition de topologie
Règles iptables spécifiques bloquant les ports de protocoles Windows (SMB, Kerberos, RPC)

Commencez par vérifier iptables -L FORWARD -v -n et cat /proc/sys/net/bridge/bridge-nf-call-iptables. Ces deux vérifications couvrent l’immense majorité des cas rencontrés en pratique.

Pourriez-vous partager la sortie de brctl show, iptables -L -v -n, et sysctl net.bridge sur votre système ? Avec ces informations, je pourrai vous donner un diagnostic précis et une solution adaptée à votre configuration spécifique.