Les VMs Proxmox n’ont pas Internet : erreurs du pont vmbr0 et corrections rapides

Procédure de diagnostic rapide

Si vous êtes d’astreinte, vous ne voulez pas un cours de réseau. Vous voulez un ordre de triage qui localise rapidement le goulot d’étranglement. Voici le chemin que j’utilise : invité → bridge → uplink → passerelle → DNS. Ne devinez pas. Mesurez.

Première étape : confirmer le domaine de défaillance (invité seulement, hôte seulement ou amont)

• Depuis l’hôte : peut-il atteindre la passerelle et Internet ? Si oui, l’amont est probablement OK.
• Depuis une VM : peut-elle atteindre sa passerelle par défaut ? Si non, le problème est à l’intérieur de l’invité, de la vNIC, du bridge, du marquage VLAN ou du firewall entre l’invité et la passerelle.
• Depuis une VM : peut-elle atteindre une IP sur Internet (par ex., un résolveur connu) mais pas les noms DNS ? Si oui, c’est DNS ou interception DNS.

Deuxième étape : vérifier que vmbr0 transporte les bons trames

• Est-ce que vmbr0 a la bonne configuration IP (si c’est l’interface L3 de l’hôte) et les bons ports (NIC physique ou bond en tant que port du bridge) ?
• Les VLANs sont-ils tagués là où vous le pensez ? Les bridges VLAN-aware de Proxmox ne corrigent pas magiquement les erreurs de trunk.
• Le firewall Proxmox est-il activé au niveau Datacenter / Node / VM avec un DROP par défaut que vous avez oublié ?

Troisième étape : valider le comportement de la passerelle et le MTU

• Vérifiez les tables ARP et neighbor : si ARP échoue, vous n’êtes même pas au niveau 2.
• Vérifiez les mismatches MTU : classique quand l’hôte fonctionne (paquets plus petits) et que le trafic des invités cale (PMTUD bloqué).
• Vérifiez les offloads et les réglages bridge netfilter : ils peuvent produire des symptômes « ça ping mais TCP est mort ».

Cessez de faire ceci : redémarrer au hasard le réseau en espérant qu’il « réapprenne ». Les bridges n’ « apprennent » pas ; ils transfèrent. Votre problème est déterministe, même s’il est irritant.

Comment vmbr0 fonctionne réellement (et pourquoi ça lâche)

vmbr0 sur Proxmox est généralement un bridge Linux. Pensez-le comme un switch virtuel dans le noyau. Vos VMs s’y attachent via des interfaces tap (par ex., tap100i0) et le bridge transfère les trames entre ces taps et un uplink physique (par ex., eno1) ou un bond (bond0).

Le bridge est de niveau 2. Le routage est de niveau 3. Les problèmes réseau Proxmox surviennent quand on brouille cette ligne. Un bridge peut transporter du traffic taggué VLAN, mais il ne « route pas les VLANs ». Si votre VM est sur le VLAN 30 et que le port du switch en amont n’est pas en trunk pour le VLAN 30, votre VM n’est pas « mal configurée ». Elle est isolée par conception.

Topologies typiques de bridge Proxmox

• Uplink en bridging simple : vmbr0 avec bridge-ports eno1. L’IP de l’hôte est sur vmbr0. Les VMs partagent le même domaine L2.
• Bridge VLAN-aware : vmbr0 avec bridge-vlan-aware yes, et chaque NIC de VM spécifie un tag VLAN.
• Réseau routé ou NAT : un bridge séparé (ex. vmbr1) est interne ; l’hôte fait du NAT via vmbr0. Bien pour les labos, pas mon premier choix en production sauf si vous voulez une isolation volontaire.
• Uplink bondé : bond0 est un port de vmbr0. Mal configurer le mode de bonding vs la config du switch est un générateur classique d’incident.

Les modes de panne sont pour la plupart ennuyeux

Quand les VMs n’ont pas Internet, le problème est généralement l’un de ceux-ci :

• Mauvaise passerelle par défaut (invité) ou mauvaise route par défaut (hôte) si vous faites du NAT/routage.
• Mismatch VLAN (tag VM vs bridge vs trunk switch).
• Règle de firewall qui droppe le forwarding.
• Bridge connecté au mauvais NIC physique (oui, vraiment).
• Filtrage MAC / sécurité de port en amont refusant plusieurs MACs sur un port.
• Mismatch MTU ou PMTUD bloqué.
• nftables/iptables ou bridge-nf-call-iptables qui font un filtrage surprise.

Blague n°1 : Un bridge Linux, c’est comme un tableau blanc de salle de réunion — tout le monde suppose qu’il est correct jusqu’à ce qu’on lise ce qui est écrit dessus.

Faits intéressants et contexte historique (utile, pas trivia)

1. Le bridging Linux existe dans le noyau depuis des décennies, et les conceptions initiales supposaient un « simple transfert L2 ». Les setups modernes empilent VLANs, hooks firewall et offloads dessus.
2. Le réseau Proxmox hérite des conventions Debian : ce que vous configurez dans /etc/network/interfaces reste encore la source de vérité pour de nombreuses installations, même avec des outils plus récents disponibles.
3. Les tags VLAN ne sont pas des « métadonnées », ils font partie de la trame Ethernet. Si un port de switch est en access-only, les trames taggées sont généralement rejetées sans cérémonie.
4. Les modes de bonding ne sont pas interchangeables. 802.3ad (LACP) exige une config LACP correspondante sur le switch ; active-backup non. Les mélanger peut ressembler à un « internet instable » plutôt qu’à une panne nette.
5. Les paramètres STP du bridge comptent. Activer STP peut prévenir les boucles, mais peut aussi introduire un délai de forwarding qui ressemble à des échecs DHCP aléatoires juste après un changement de lien.
6. « L’hôte a internet » prouve moins que vous ne le pensez. L’hôte peut être routé différemment (VLAN différent, interface différente, politique firewall différente) que les invités.
7. La sécurité de port est courante dans les réseaux d’entreprise. Les switches peuvent limiter le nombre d’adresses MAC apprises sur un port. La virtualisation viole par conception cette hypothèse.
8. Les mismatches MTU sont tolérables pour l’ICMP, mortels pour le TCP quand PMTUD est bloqué. Les gens interprètent cela comme « DNS cassé » parce que les requêtes web se figent.
9. Les hooks bridge netfilter étaient controversés car ils brouillent les frontières L2/L3. Ils sont puissants, mais rendent le flux de paquets non évident à moins de savoir où se trouvent les hooks.

Tâches pratiques : commandes, ce que la sortie signifie, et ce que vous décidez

Voici des tâches réelles que vous pouvez exécuter sur un nœud Proxmox. Chacune donne un signal. L’astuce est de traiter les sorties comme des points de décision, pas comme de l’« information ».

Task 1: Check host routes (prove the host has a sane default route)

cr0x@server:~$ ip route
default via 192.0.2.1 dev vmbr0 proto static
192.0.2.0/24 dev vmbr0 proto kernel scope link src 192.0.2.10

Ce que ça signifie : la route par défaut de l’hôte passe par vmbr0 vers 192.0.2.1. Si la route par défaut pointe ailleurs (mauvaise interface, manquante), votre hôte peut encore avoir une certaine connectivité via du policy routing, mais votre chemin « normal » est cassé.

Décision : si la route par défaut est absente ou erronée, corrigez d’abord le réseau de l’hôte. Ne touchez pas encore aux VMs.

Task 2: Inspect bridge membership (is the uplink actually in vmbr0?)

cr0x@server:~$ bridge link
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
5: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Ce que ça signifie : eno1 est esclave de vmbr0. Si vous ne voyez pas votre NIC physique/bond avec master vmbr0, vos VMs sont pontées vers nulle part.

Décision : si l’uplink n’est pas un port du bridge, corrigez /etc/network/interfaces (ou la config réseau du nœud) et rechargez le réseau avec précaution.

Task 3: Confirm vmbr0 configuration and VLAN awareness

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0
  bridge-vlan-aware yes
  bridge-vids 2-4094

Ce que ça signifie : l’IP est sur vmbr0, pas sur eno1. VLAN-aware est activé, permettant au trafic taggé de traverser.

Décision : si VLAN-aware est désactivé mais que vous tagguez les NICs de VM, soit activez-le soit retirez les tags et utilisez un VLAN d’accès sur le switch. Choisissez une stratégie. Mélanger crée des pannes.

Task 4: Verify the VM NIC is attached to vmbr0 and has a VLAN tag (Proxmox view)

cr0x@server:~$ qm config 100 | sed -n 's/^net0:/net0:/p'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=30,firewall=1

Ce que ça signifie : la VM 100 utilise vmbr0, tag VLAN 30, et le firewall Proxmox est activé pour cette NIC.

Décision : si le bridge est mauvais, corrigez-le ici. Si firewall=1, vous devez considérer la politique firewall comme un suspect de première classe.

Task 5: Confirm the VM sees a link and has an IP (inside the guest)

cr0x@server:~$ qm guest exec 100 -- ip -br addr
1: lo               UNKNOWN        127.0.0.1/8 ::1/128
2: ens18            UP             192.0.2.50/24 fe80::dcad:beff:feef:1000/64

Ce que ça signifie : l’interface ens18 est UP avec l’IPv4 192.0.2.50/24.

Décision : s’il n’y a pas d’IP, arrêtez de blâmer vmbr0 et corrigez la configuration DHCP/static dans l’invité (ou cloud-init).

Task 6: Check the guest’s default route (the most common “no internet” cause)

cr0x@server:~$ qm guest exec 100 -- ip route
default via 192.0.2.1 dev ens18
192.0.2.0/24 dev ens18 proto kernel scope link src 192.0.2.50

Ce que ça signifie : la route par défaut pointe vers 192.0.2.1.

Décision : si la passerelle par défaut est erronée (ou manquante), corrigez la config réseau de l’invité ou la portée DHCP. Ne touchez pas encore au bridge.

Task 7: Quick reachability ladder: ARP → gateway ping → external IP ping → DNS

cr0x@server:~$ qm guest exec 100 -- bash -lc 'ip neigh; ping -c2 -W1 192.0.2.1; ping -c2 -W1 1.1.1.1; getent hosts example.com'
192.0.2.1 dev ens18 lladdr aa:bb:cc:dd:ee:ff REACHABLE
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.421 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.389 ms

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=3.12 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=3.08 ms

93.184.216.34  example.com

Ce que ça signifie : la VM a la résolution de voisin L2, le L3 vers la passerelle, le L3 vers Internet, et la résolution DNS fonctionne.

Décision : si une étape échoue, vous savez maintenant quel niveau investiguer. Ne sautez pas d’étapes, parce que « DNS cassé » est souvent juste « pas de route ».

Task 8: Inspect ARP and forwarding database on the host (who learned whose MAC)

cr0x@server:~$ ip neigh show dev vmbr0 | head
192.0.2.1 lladdr aa:bb:cc:dd:ee:ff REACHABLE
192.0.2.50 lladdr de:ad:be:ef:10:00 STALE

cr0x@server:~$ bridge fdb show br vmbr0 | head
aa:bb:cc:dd:ee:ff dev eno1 master vmbr0
de:ad:be:ef:10:00 dev tap100i0 master vmbr0

Ce que ça signifie : le bridge a appris la MAC de la VM sur tap100i0 et la MAC de la passerelle sur eno1. Si vous voyez la MAC de la passerelle apprise sur un tap (ou pas du tout), vous avez une boucle, un câblage erroné, ou un mismatch VLAN.

Décision : si l’apprentissage FDB est incorrect, concentrez-vous sur le marquage VLAN, les ports du bridge, et la configuration du port physique du switch.

Task 9: Check whether Proxmox firewall is enabled and dropping forwarding

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "vmbr0" oifname "vmbr0" accept
  }
}

Ce que ça signifie : la politique forward est DROP par défaut (courant), avec un accept explicite pour le trafic intra-bridge. Si vous faites du NAT (vmbr1 → vmbr0), vous avez besoin de forwards explicites.

Décision : si le ruleset droppe le forwarding, soit ajustez les règles PVE firewall soit désactivez temporairement le firewall pour confirmer la cause (puis réactivez avec la bonne politique).

Task 10: Validate bridge netfilter sysctls (the “why is my bridge being firewalled?” trap)

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 0

Ce que ça signifie : les trames bridgées IPv4/IPv6 sont passées aux hooks iptables/nftables. Cela peut être voulu, ou bien un destructeur de paquets accidentel si vous pensiez « bridge = switch = pas de firewall ».

Décision : si vous ne filtrez pas intentionnellement le trafic bridgé, envisagez de désactiver ces hooks. Si vous filtrez, auditez les règles soigneusement et documentez-les.

Task 11: Check MTU end-to-end (VM, bridge, uplink)

cr0x@server:~$ ip -br link show vmbr0 eno1
vmbr0            UP             00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eno1             UP             00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

cr0x@server:~$ qm guest exec 100 -- ip -br link show ens18
ens18            UP             de:ad:be:ef:10:00 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Ce que ça signifie : le MTU correspond à 1500. Si le MTU de la VM est 1500 mais que l’uplink est 9000 (ou inversement), vous pouvez obtenir une connectivité partielle étrange selon le type de trafic.

Décision : choisissez une stratégie MTU et appliquez-la de manière cohérente : 1500 partout, ou jumbo frames partout incluant les ports switch en amont. Le demi-jumbo est une excellente façon de perdre un après-midi.

Task 12: Detect “it pings but TCP dies” with a DF ping

cr0x@server:~$ qm guest exec 100 -- ping -c2 -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=3.24 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=3.18 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Ce que ça signifie : le PMTU est au moins 1500. Si vous obtenez « Frag needed and DF set », vous avez un mismatch MTU ou un tunnel dans le chemin.

Décision : si le ping DF échoue, corrigez le MTU ou autorisez PMTUD (ICMP too-big) à travers les firewalls. Ne « corrigez » pas en réduisant MSS aveuglément à moins de maîtriser l’environnement et documenter le hack.

Task 13: Check for MAC address limits / port security symptoms (from host perspective)

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'mac|flood|storm|blocked|bond|link' | tail -n 20
Dec 26 09:21:07 server kernel: vmbr0: port 2(eno1) entered blocking state
Dec 26 09:21:07 server kernel: vmbr0: port 2(eno1) entered forwarding state

Ce que ça signifie : les logs du noyau ne vont pas directement dire « votre switch applique la sécurité de port », mais des changements fréquents d’état de port ou des flaps de lien apparaîtront.

Décision : si vous suspectez la sécurité de port, parlez à l’équipe réseau. Votre hôte Proxmox n’est pas un point MAC unique ; c’est une usine à MACs. Configurez le switch en conséquence.

Task 14: Packet capture on vmbr0 and on the tap (prove VLAN tagging and DHCP)

cr0x@server:~$ tcpdump -eni vmbr0 -c 10 '(arp or (udp port 67 or 68) or icmp)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:15:11.120001 de:ad:be:ef:10:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
08:15:11.220112 aa:bb:cc:dd:ee:ff > de:ad:be:ef:10:00, ethertype IPv4 (0x0800), length 342: 192.0.2.1.67 > 192.0.2.50.68: BOOTP/DHCP, Reply

Ce que ça signifie : vous voyez la requête et la réponse DHCP. Si les requêtes DHCP quittent la VM mais qu’aucune réponse ne revient, le VLAN amont, le relay ou le firewall est erroné. Si vous voyez des trames taggées alors que vous attendiez de l’unta gged (ou l’inverse), vous avez trouvé votre mismatch.

Décision : les captures de paquets mettent fin aux arguments. Utilisez-les tôt quand l’équipe reste bloquée sur « ça devrait marcher ».

Task 15: Validate NAT configuration (if you built a private vmbr1)

cr0x@server:~$ ip -br addr show vmbr1
vmbr1            UP             10.10.10.1/24

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ nft list ruleset | sed -n '1,200p' | egrep -n 'nat|masquerade|postrouting|forward' | head -n 20
42: table ip nat {
55:   chain postrouting {
58:     oifname "vmbr0" ip saddr 10.10.10.0/24 masquerade

Ce que ça signifie : vmbr1 existe, le forwarding est activé, et il y a une règle de masquerade pour NATer le trafic sortant via vmbr0.

Décision : si les invités sur vmbr1 n’ont pas Internet, le NAT est un suspect de premier plan. Corrigez-le ou évitez le NAT et utilisez des VLANs/routage appropriés comme un réseau adulte.

Task 16: Check Proxmox-specific network device naming and bonds

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
Slave Interface: eno1
MII Status: up
Slave Interface: eno2
MII Status: up

Ce que ça signifie : le bond est en LACP (802.3ad) et les deux esclaves sont up. Si le bond montre « Number of ports: 1 » de façon inattendue, ou si les esclaves flapent, la config LACP du switch n’est probablement pas d’accord avec vous.

Décision : si le mode de bonding et la config du switch ne sont pas alignés, ne « tunez » pas. Alignez-les. En production, faites du LACP correctement des deux côtés ou restez en active-backup pour la simplicité.

Erreurs courantes : symptôme → cause racine → correctif

Ceci est la partie que vous transférez à votre futur vous.

1) Symptom: Host has internet, VMs can’t reach gateway

Cause racine : VM attachée au mauvais bridge, ou le bridge n’a pas de port uplink physique, ou mismatch de tag VLAN qui bloque l’adjacence L2.

Correctif : vérifiez que qm config NIC utilise bridge=vmbr0 ; vérifiez que bridge link montre le NIC physique comme master vmbr0 ; vérifiez la configuration VLAN de bout en bout (tag VM, bridge VLAN-aware, trunk/access sur le switch).

2) Symptom: VM can ping gateway, can’t ping external IP

Cause racine : route manquante au-delà de la passerelle (mauvaise passerelle invité), ACL amont, ou NAT/routage mal configuré si la VM est sur un bridge privé.

Correctif : vérifiez la route par défaut de l’invité ; si design NAT, vérifiez ip_forward et la masquerade ; confirmez que la passerelle amont route de retour vers le sous-réseau de la VM (si routé).

3) Symptom: VM can ping 1.1.1.1 but DNS fails

Cause racine : serveurs DNS inaccessibles, mauvais resolv.conf, systemd-resolved mal orienté, ou interception DNS d’entreprise + règles firewall.

Correctif : vérifiez getent hosts, contrôlez /etc/resolv.conf dans l’invité, assurez-vous que UDP/TCP 53 est autorisé, et que DHCP fournit les bons résolveurs pour ce VLAN.

4) Symptom: DHCP times out in VM, static IP works

Cause racine : trunk VLAN manquant pour ce VLAN, délai STP au lien up, problème DHCP snooping/relay, ou firewall qui bloque les broadcasts DHCP.

Correctif : tcpdump sur vmbr0 pour DHCP ; activez bridge-fd 0 sauf si vous avez besoin de STP ; coordonnez-vous avec l’équipe réseau sur le snooping/relay ; assurez-vous que le firewall de la VM ne bloque pas DHCP.

5) Symptom: Some VMs work, others don’t, on same host

Cause racine : tags VLAN différents par VM ; firewall différent par VM ; conflit MAC ; IP dupliquée ; ou une VM sur un bridge différent.

Correctif : comparez les qm config entre VMs ; vérifiez les IP dupliquées avec arping ou la table neighbor ; auditez les réglages firewall par VM.

6) Symptom: Works for small pings, HTTPS hangs or is slow

Cause racine : mismatch MTU ou PMTUD bloqué ; parfois des bizarreries d’offload checksum avec certains drivers/firmware NIC.

Correctif : test DF ping ; alignez le MTU ; autorisez ICMP too-big ; si toujours étrange, testez la désactivation de GRO/LRO/TSO sur le NIC hôte comme diagnostic.

7) Symptom: Connectivity dies after enabling Proxmox Firewall

Cause racine : politique par défaut DROP dans la chaîne forward, règles allow manquantes, ou hooks bridge netfilter activés avec des règles inattendues.

Correctif : relisez les règles nftables ; ajustez les règles PVE firewall ; conservez une baseline minimale « allow established + allow vmbrX forwarding » et construisez dessus.

8) Symptom: VMs lose connectivity when another host connects, or during migration

Cause racine : sécurité de port en amont limitant le nombre de MAC, ou switch non préparé à plusieurs MACs derrière un seul port, ou hash LACP produisant des flux asymétriques.

Correctif : configurez le port du switch pour la virtualisation (autoriser plusieurs MACs, désactiver la sécurité stricte ou augmenter les limites), vérifiez LACP des deux côtés, envisagez active-backup si l’équipe réseau ne veut pas supporter correctement LACP.

Trois mini-histoires d’entreprise (anonymisées, plausibles, techniquement exactes)

Mini-histoire 1 : La panne causée par une mauvaise hypothèse

L’équipe a récupéré un petit cluster Proxmox d’un projet qui « n’est jamais allé en production ». Ils l’ont déplacé dans une baie de production, ont branché deux ports 10GbE sur une paire de switches top-of-rack, et ont configuré bond0 en 802.3ad parce que « c’est la manière professionnelle ». Les switches avaient des ports configurés en access indépendants sur un VLAN standard. Personne n’a prévenu l’équipe virtualisation. Personne n’a non plus prévenu l’équipe réseau, car tout le monde supposait que c’était évident.

L’hôte lui-même avait une connectivité intermittente. Les VMs étaient pires : parfois elles pouvaient résoudre le DNS mais pas récupérer des paquets ; parfois le ping vers la passerelle fonctionnait ; parfois ARP semblait stale. Ça sentait la liaison ISP flaky, ce qui est toujours un mensonge tentant parce que ça vous permet d’arrêter de réfléchir.

Le tournant a été une capture de paquets sur l’uplink montrant des rafales de retransmissions puis le silence, corrélées à des messages de négociation LACP qui ne se stabilisaient jamais. Sur l’hôte, /proc/net/bonding/bond0 montrait une interface « up » avec un esclave actif, puis ça basculait. L’hypothèse erronée était que LACP est inoffensif si le switch ne le supporte pas. Ce n’est pas inoffensif ; c’est un protocole de négociation qui attend un partenaire.

Ils ont corrigé le problème en passant le bond en active-backup temporairement, restaurant la stabilité en quelques minutes, puis ont planifié un changement avec l’équipe réseau pour déployer un channel LACP correct. Le post-mortem a été court et un peu douloureux : le système s’est comporté exactement comme configuré. Les humains ont été la partie imprévisible.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Un ingénieur axé performance a remarqué une hausse de l’utilisation CPU sur les nœuds Proxmox pendant les heures de pointe. Les interruptions réseau montaient. Il y avait aussi des pics de latence sur une VM API chargée. Il a décidé « d’optimiser le réseau » en activant les jumbo frames sur l’uplink hyperviseur et sur vmbr0. Le réseau de stockage utilisait déjà les jumbo frames, donc ça semblait cohérent.

Il a changé le MTU à 9000 sur vmbr0 et les NICs physiques. L’hôte semblait aller bien. Les VMs ont commencé à rapporter des comportements bizarres : les pings ICMP fonctionnaient, mais les handshakes TLS s’arrêtaient. Les tableaux de bord de monitoring étaient une œuvre d’art moderne de pannes partielles. L’ingénieur a supposé que le changement MTU ne pouvait pas être responsable parce que « des paquets plus gros réduisent l’overhead ». C’est vrai seulement si tout le chemin est d’accord.

Le switch en amont restait à 1500. Pire, le firewall réseau sur le chemin était configuré pour dropper les messages ICMP fragmentation-needed. PMTUD ne pouvait pas faire son travail, donc les sessions TCP se bloquaient quand elles essayaient d’envoyer de plus grands segments. Le DNS a paru flaky parce que les retries clients étaient retardés et les timeouts mal attribués.

La correction n’a pas été héroïque : remettre le MTU à 1500 sur vmbr0 et les vNICs des VMs, puis planifier les jumbo frames correctement avec validation bout à bout et politique ICMP alignée. La leçon est ancienne : optimiser sans mesurer, c’est simplement changer. Parfois un changement coûteux.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation exploitait des nœuds Proxmox sur plusieurs sites, chacun avec des vendors de switch et des layouts VLAN légèrement différents. Ils avaient une règle simple : chaque nœud Proxmox doit avoir un réseau de management « known good » untagged sur vmbr0, et chaque réseau VM doit être taggué avec des VLANs explicites sur un bridge VLAN-aware. Pas d’exception, pas de ports d’accès « temporaires ».

Ça semble pointilleux. Ça a surtout fait que quand un site a rapporté « les VMs n’ont pas Internet », l’équipe a vérifié immédiatement les trunks et les tags VLAN au lieu de réécrire les configs réseau. L’IP de management de l’hôte est restée joignable, parce qu’elle ne reposait pas sur le même bazar taggé que les réseaux tenants.

Pendant un remplacement de switch, un trunk a été accidentellement configuré en access VLAN 10 au lieu de trunk. Le symptôme est apparu instantanément : toutes les VMs sur VLAN 30 sur ce nœud ont perdu la connectivité, mais le nœud restait accessible sur le management. La capture montrait des trames taggées quittant vmbr0 et disparaissant dans le port access. Le diagnostic a pris des minutes, pas des heures.

La pratique ennuyeuse était la séparation des responsabilités : connectivité management stable, VLANs explicites pour les invités, et une checklist standard après les changements réseau. Ce n’est pas glamour. C’est comment éviter de réveiller toute l’équipe parce que quelqu’un a mal appliqué un template de switch.

Blague n°2 : La seule chose plus persistante qu’un VLAN mal taggé, c’est une invitation de réunion à propos du VLAN mal taggé.

Listes de contrôle / plan pas à pas

Pas à pas : corriger « VM n’a pas Internet » sans aggraver la situation

1. Choisissez une VM affectée et utilisez-la comme canari. Ne modifiez pas d’un coup les paramètres sur tous les invités.
2. Dans la VM : vérifiez IP, sous-réseau, passerelle, DNS. Confirmez ip route et getent hosts.
3. Depuis la VM : pinguez la passerelle, pinguez une IP externe, résolvez un nom DNS. Notez exactement ce qui échoue.
4. Sur l’hôte : confirmez que vmbr0 a le port uplink et les bons réglages VLAN.
5. Vérifiez l’état du firewall : statut Proxmox firewall, flag firewall NIC VM, politique nftables forward.
6. Confirmez l’adjacence L2 : table neighbor hôte et entrées FDB du bridge pour la MAC de la VM et la MAC de la passerelle.
7. Faites une capture ciblée : tcpdump sur vmbr0 pour voir ARP/DHCP/ICMP ; confirmez les tags si pertinent.
8. Vérifiez le MTU : assurez-vous d’un MTU cohérent ; exécutez un DF ping vers Internet.
9. Ensuite seulement changez la configuration, une dimension à la fois : VLAN, règle firewall, route, NAT, MTU.
10. Validez et documentez l’état final fonctionnel : config du bridge, attentes sur le port switch, et politique de tagging des VMs.

Schémas « known good » minimaux pour vmbr0

Schéma A : réseau d’accès non taggé simple pour hôte et VMs (bon pour petits labos ; limité pour multi-tenant) :

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0

Schéma B : bridge VLAN-aware avec réseaux invités taggés (ce que je recommande en production) :

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0
  bridge-vlan-aware yes
  bridge-vids 2-4094

Schéma C : réseau privé VM avec NAT (à utiliser avec parcimonie, documenter fortement) :

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
  address 192.0.2.10/24
  gateway 192.0.2.1
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0

auto vmbr1
iface vmbr1 inet static
  address 10.10.10.1/24
  bridge-ports none
  bridge-stp off
  bridge-fd 0

Pour le Schéma C, vous avez toujours besoin du forwarding et des règles NAT. Si vous ne pouvez pas les expliquer à l’ingénieur d’astreinte suivant en moins d’une minute, vous construisez une panne, pas un réseau.

Checklist opérationnelle après modifications (celle que les gens sautent)

• L’hôte peut-il atteindre la passerelle, résoudre le DNS, et récupérer des paquets ?
• Une VM sur chaque VLAN peut-elle atteindre sa passerelle, une IP externe, et résoudre DNS ?
• Les entrées ARP sont-elles stables (pas constamment incomplètes) ?
• Un DF ping à 1472 octets fonctionne-t-il vers une IP externe ?
• La politique firewall Proxmox est-elle documentée (ce qui est autorisé, ce qui est en DROP par défaut) ?
• La configuration du port switch est-elle consignée (access vs trunk, VLANs autorisés, limites MAC, LACP) ?

Une citation fiabilité (idée paraphrasée)

Idée paraphrasée, attribuée à W. Edwards Deming : « On ne peut pas améliorer ce qu’on ne mesure pas. »

FAQ

1) Pourquoi l’hôte a Internet mais pas les VMs ?

Parce que l’hôte et les VMs ne partagent pas nécessairement le même chemin réseau. L’hôte peut être non taggé sur vmbr0 tandis que les VMs sont taggées, ou les règles firewall peuvent traiter le trafic forwardé différemment du trafic local de l’hôte.

2) L’IP de l’hôte doit-elle être sur eno1 ou sur vmbr0 ?

Sur vmbr0, dans la conception bridgée commune. Mettez eno1 en mode manual et faites-en un port du bridge. Attribuer une IP à eno1 tout en le bridgant est un classique « ça marche plus ou moins jusqu’à ce que ça casse ».

3) Ai-je besoin de « bridge-vlan-aware yes » si je n’utilise pas de tags VLAN ?

Non. Si tout est non taggé et que le port switch est en access VLAN, gardez la simplicité. Activez la VLAN awareness seulement quand vous taggez réellement les NICs invités ou avez besoin de trunks.

4) Ma VM a une IP mais n’arrive pas à sortir. Quel est le contrôle le plus rapide ?

Vérifiez la route par défaut de la VM : ip route. Si la passerelle par défaut est erronée ou manquante, rien d’autre n’a d’importance tant que ce n’est pas réglé.

5) Le Firewall Proxmox est-il sûr à activer ?

Oui, si vous comprenez ses politiques par défaut et où il s’applique (Datacenter, Node, VM/NIC). Il devient dangereux quand quelqu’un l’active avec un DROP par défaut et aucune autorisation de forwarding, puis part pour le week-end.

6) Quand devrais-je utiliser le NAT pour l’accès Internet des VMs ?

Quand vous voulez délibérément un réseau VM privé non routable et acceptez que l’hôte Proxmox devienne un routeur/firewall. Pour des environnements multi-VM en production, les VLANs et un routage approprié sont généralement plus clairs et plus faciles à dépanner.

7) Pourquoi je vois des requêtes DHCP dans tcpdump mais pas de réponses ?

Souvent un problème de trunk VLAN (mauvais VLAN autorisé), DHCP snooping/relay mal configuré, ou règles firewall bloquant les broadcasts/UDP. Si la requête quitte la VM et apparaît sur vmbr0, le côté invité fonctionne.

8) Un mismatch MTU peut-il vraiment provoquer « pas d’internet » ?

Oui, de manière trompeuse. Les petits trafics (pings, certains DNS) peuvent fonctionner tandis que TCP se bloque. Utilisez les DF pings et alignez le MTU bout à bout, ou autorisez les messages ICMP liés à PMTUD.

9) Dois-je désactiver les offloads (GRO/LRO/TSO) sur le NIC ?

Pas par défaut. Mais en tant que diagnostic, cela peut isoler des interactions étranges driver/firmware. Si la désactivation des offloads « corrige » le problème, considérez cela comme un indice : mettez à jour firmware/drivers et validez les fonctionnalités du switch plutôt que de rester avec un contournement permanent.

10) Quelle est la manière la plus propre de gérer plusieurs réseaux sur Proxmox ?

Un réseau management stable (souvent non taggé), plus des bridges VLAN-aware pour les réseaux invités avec tags explicites par NIC de VM. Documentez la configuration des ports switch et gardez-la cohérente entre les nœuds.

Conclusion : prochaines étapes pour éviter les répétitions

Quand les VMs Proxmox n’ont pas Internet, ce n’est presque jamais de la « virtualisation mystérieuse ». C’est un décalage prévisible entre ce que la VM envoie, ce que vmbr0 transfère, et ce que le réseau amont accepte. Le chemin le plus rapide vers la résolution est d’arrêter de traiter ça comme de la magie et de commencer à le traiter comme un pipeline.

Faites ceci ensuite :

• Standardisez votre pattern de bridge : choisissez non-taggué ou VLAN-aware+taggé. Ne faites pas les deux par accident.
• Notez les attentes du switch : trunk/access, VLANs autorisés, limites MAC, mode LACP. Si ce n’est pas écrit, c’est de la tradition orale.
• Gardez une VM canari avec une config réseau connue bonne et un script de test simple (ping passerelle, ping IP externe, résolution DNS, DF ping).
• Auditez la posture firewall : sachez où le DROP par défaut existe, et assurez-vous que les règles de forwarding correspondent à votre design (bridgé, routé, ou NAT).
• Faites du MTU une décision de politique, pas un bouton. 1500 partout fonctionne. Jumbo frames partout fonctionne. « Quelque part au milieu » est là où vivent les incidents.

Si vous voulez une seule action pratique : capturez des paquets plus tôt. Rien ne met fin à un débat comme voir les trames sortir et ne pas revenir.