<p>Bonjour,</p>
<p>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.</p>
<h2><a name="p-34552-comprendre-le-fonctionnement-du-pontage-linux-1" class="anchor" href="#p-34552-comprendre-le-fonctionnement-du-pontage-linux-1" aria-label="Heading link"></a>Comprendre le fonctionnement du pontage Linux</h2>
<p>Un <strong>bridge Linux</strong> (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.</p>
<p>Cependant, <strong>plusieurs mécanismes Linux peuvent bloquer cette transmission</strong>, notamment :</p>
<ul>
<li><strong>iptables / nftables</strong> appliqués aux paquets pontés</li>
<li><strong>ebtables</strong> (filtrage de trames Ethernet)</li>
<li>Le paramètre noyau <strong><code>net.bridge.bridge-nf-call-iptables</code></strong></li>
<li><strong>STP (Spanning Tree Protocol)</strong> activé sur le bridge</li>
<li>Problèmes de <strong>forwarding IP</strong></li>
</ul>
<h2><a name="p-34552-diagnostic-initial-2" class="anchor" href="#p-34552-diagnostic-initial-2" aria-label="Heading link"></a>Diagnostic initial</h2>
<h3><a name="p-34552-vrifier-ltat-du-bridge-3" class="anchor" href="#p-34552-vrifier-ltat-du-bridge-3" aria-label="Heading link"></a>Vérifier l’état du bridge</h3>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h3><a name="p-34552-vrifier-le-forwarding-ip-4" class="anchor" href="#p-34552-vrifier-le-forwarding-ip-4" aria-label="Heading link"></a>Vérifier le forwarding IP</h3>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h3><a name="p-34552-vrifier-les-paramtres-bridge-nf-source-principale-du-problme-5" class="anchor" href="#p-34552-vrifier-les-paramtres-bridge-nf-source-principale-du-problme-5" aria-label="Heading link"></a>Vérifier les paramètres bridge-nf (source principale du problème)</h3>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h2><a name="p-34552-cause-principale-n1-iptables-bloque-le-trafic-pont-6" class="anchor" href="#p-34552-cause-principale-n1-iptables-bloque-le-trafic-pont-6" aria-label="Heading link"></a>Cause principale n°1 : iptables bloque le trafic ponté</h2>
<h3><a name="p-34552-le-problme-bridge-nf-call-iptables-7" class="anchor" href="#p-34552-le-problme-bridge-nf-call-iptables-7" aria-label="Heading link"></a>Le problème bridge-nf-call-iptables</h3>
<p>Lorsque <code>bridge-nf-call-iptables = 1</code>, <strong>tout le trafic transitant par le bridge passe par les chaînes iptables</strong> (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.</p>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h3><a name="p-34552-solution-autoriser-le-trafic-forward-pour-le-bridge-8" class="anchor" href="#p-34552-solution-autoriser-le-trafic-forward-pour-le-bridge-8" aria-label="Heading link"></a>Solution : autoriser le trafic FORWARD pour le bridge</h3>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<blockquote>
<p><strong>Note</strong> : Sur les systèmes récents (nftables), le module <code>br_netfilter</code> doit être chargé pour que ces paramètres prennent effet.</p>
</blockquote>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h2><a name="p-34552-cause-principale-n2-spanning-tree-protocol-bloque-les-ports-9" class="anchor" href="#p-34552-cause-principale-n2-spanning-tree-protocol-bloque-les-ports-9" aria-label="Heading link"></a>Cause principale n°2 : Spanning Tree Protocol bloque les ports</h2>
<p>Le <strong>STP</strong> peut mettre les ports du bridge en état <strong>Listening</strong> ou <strong>Blocking</strong> pendant 30 à 50 secondes lors d’un changement de topologie. Dans certains cas, un port peut rester bloqué indéfiniment.</p>
<pre data-code-wrap="bash"><code class="lang-bash"># 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é
</code></pre>
<h3><a name="p-34552-solutions-pour-le-stp-10" class="anchor" href="#p-34552-solutions-pour-le-stp-10" aria-label="Heading link"></a>Solutions pour le STP</h3>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h2><a name="p-34552-cause-principale-n3-problmes-spcifiques-lenvironnement-windows-server-11" class="anchor" href="#p-34552-cause-principale-n3-problmes-spcifiques-lenvironnement-windows-server-11" aria-label="Heading link"></a>Cause principale n°3 : Problèmes spécifiques à l’environnement Windows Server</h2>
<h3><a name="p-34552-communication-ntlm-et-kerberos-travers-un-bridge-12" class="anchor" href="#p-34552-communication-ntlm-et-kerberos-travers-un-bridge-12" aria-label="Heading link"></a>Communication NTLM et Kerberos à travers un bridge</h3>
<p>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 :</p>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h3><a name="p-34552-ajouter-des-rgles-iptables-pour-les-flux-windows-13" class="anchor" href="#p-34552-ajouter-des-rgles-iptables-pour-les-flux-windows-13" aria-label="Heading link"></a>Ajouter des règles iptables pour les flux Windows</h3>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h2><a name="p-34552-diagnostic-avanc-avec-tcpdump-et-wireshark-14" class="anchor" href="#p-34552-diagnostic-avanc-avec-tcpdump-et-wireshark-14" aria-label="Heading link"></a>Diagnostic avancé avec tcpdump et Wireshark</h2>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h2><a name="p-34552-configuration-complte-dun-bridge-fonctionnel-exemple-15" class="anchor" href="#p-34552-configuration-complte-dun-bridge-fonctionnel-exemple-15" aria-label="Heading link"></a>Configuration complète d’un bridge fonctionnel (exemple)</h2>
<p>Voici une configuration de référence pour un bridge Linux qui transmet correctement le trafic vers des systèmes Windows Server :</p>
<pre data-code-wrap="bash"><code class="lang-bash"># /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
</code></pre>
<pre data-code-wrap="bash"><code class="lang-bash"># 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
</code></pre>
<h2><a name="p-34552-vrifications-ct-windows-server-16" class="anchor" href="#p-34552-vrifications-ct-windows-server-16" aria-label="Heading link"></a>Vérifications côté Windows Server</h2>
<p>Si le problème persiste, vérifiez également côté Windows :</p>
<pre data-code-wrap="powershell"><code class="lang-powershell"># 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
</code></pre>
<h2><a name="p-34552-conclusion-17" class="anchor" href="#p-34552-conclusion-17" aria-label="Heading link"></a>Conclusion</h2>
<p>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 :</p>
<ol>
<li><strong><code>bridge-nf-call-iptables = 1</code></strong> combiné avec une politique FORWARD DROP dans iptables</li>
<li><strong>STP bloquant les ports</strong> du bridge pendant ou après une transition de topologie</li>
<li><strong>Règles iptables spécifiques</strong> bloquant les ports de protocoles Windows (SMB, Kerberos, RPC)</li>
</ol>
<p>Commencez par vérifier <code>iptables -L FORWARD -v -n</code> et <code>cat /proc/sys/net/bridge/bridge-nf-call-iptables</code>. Ces deux vérifications couvrent l’immense majorité des cas rencontrés en pratique.</p>
<p>Pourriez-vous partager la sortie de <code>brctl show</code>, <code>iptables -L -v -n</code>, et <code>sysctl net.bridge</code> sur votre système ? Avec ces informations, je pourrai vous donner un diagnostic précis et une solution adaptée à votre configuration spécifique.</p>
