Dépannage du bridge réseau Proxmox VE pour machines virtuelles : guide pratique

Introduction

Proxmox VE relie vos machines virtuelles (VM) au réseau physique via des Linux bridges, le plus souvent vmbr0. Quand une VM n'a plus d'internet ou ne parvient pas à joindre des services locaux, la cause se situe généralement dans un périmètre restreint : le Proxmox VE network bridge, les VLANs et les ports de switch, l'adressage IP et la passerelle, le DHCP, ou le pare-feu local. Ce guide propose une checklist ordonnée et concrète pour résoudre rapidement un cas « Proxmox VM no internet », sans supposition hasardeuse.

Public cible : développeurs, consultants DevOps et équipes techniques de startups recherchant une connectivité VM fiable, sans guesswork.

Objectifs :

• Vérifier que vmbr0 et la NIC physique sont correctement câblés.
• Éviter les erreurs courantes de VLAN et de passerelle.
• Diagnostiquer les pannes DHCP et les IP statiques mal configurées.
• Confirmer le routage et le DNS dans l'invité.
• Valider NAT, pare-feu et MTU.

Vue d'ensemble du flux

Travaillez de l'extérieur vers l'intérieur, puis dans l'autre sens :

1. Cartographier la topologie

• Identifiez les interfaces de l'hôte Proxmox (ex. enp3s0), le bridge (vmbr0), le port de switch amont, et le(s) VLAN(s) cible(s).
• Notez si les VMs utilisent DHCP ou IP statique, et quelle est la passerelle par défaut attendue.

1. Valider le lien hôte et le bridge

• Confirmez que le lien physique est UP et que vmbr0 asservit la bonne NIC.
• Vérifiez l'IP et la passerelle de gestion de l'hôte (si présentes) et évitez tout conflit avec le plan d'adressage des invités.

1. Vérifier la NIC invité et l'IP

• Confirmez que la NIC de la VM est attachée à vmbr0 et que le modèle est approprié (VirtIO recommandé pour Linux).
• Vérifiez l'IP, la route par défaut et le DNS dans l'OS invité.

1. Contrôler les VLAN

• Alignez le tag VLAN de la VM, la conscience VLAN du bridge, et le mode du port de switch (access vs trunk).

1. Corriger DHCP ou la configuration statique

• Tracez les requêtes/offres DHCP, ou validez IP/mask/gateway/DNS statiques.

1. Confirmer routage et DNS

• Ping de la passerelle, test d'une IP externe, puis résolution DNS.

1. Revoir NAT et pare-feu

• Si NAT, vérifiez forwarding et MASQUERADE. Contrôlez les règles bloquantes (DHCP/DNS).

1. Tester MTU et performance

• Validez la path MTU et, si besoin, désactivez provisoirement les offloads pour diagnostiquer.

Vérifications hôte et bridge

Sur l'hôte Proxmox, confirmez l'état du lien et du bridge.

• Afficher les liens et adresses :

ip -br link
ip -br addr
ip addr show vmbr0
ip link show vmbr0

• Confirmer quels ports sont dans le bridge :

bridge link
bridge vlan show

• Vérifier la NIC physique et l'état du lien :

ethtool enp3s0
dmesg -T | grep -i link

• Exemple /etc/network/interfaces (bridge L2 typique avec gestion sur vmbr0) :

auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0

• Bridge conscient des VLANs (autoriser VLANs 10 et 20) :

auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp3s0
    bridge-vlan-aware yes
    bridge-vids 10 20

Notes :

• La passerelle de l'hôte doit être dans le même sous-réseau que son IP sur vmbr0.
• Si l'hôte n'a pas d'IP sur vmbr0 (L2 pur), prévoyez un autre accès de gestion.
• Appliquez les changements en fenêtre de maintenance ou via console pour éviter une perte d'accès.

NIC invité et IP

Validez la configuration de la VM dans Proxmox et dans l'OS invité.

• Dans le matériel de la VM :
• Bridge : vmbr0
• VLAN tag : vide si accès non tagué, sinon l'ID correct
• Modèle : VirtIO recommandé pour Linux

• Dans un invité Linux :

ip -br addr
ip route
resolvectl status 2>/dev/null || cat /etc/resolv.conf
ping -c 3 <ip-passerelle>
ping -c 3 8.8.8.8
getent hosts example.com || nslookup example.com || dig +short example.com

• Dans un invité Windows :

ipconfig /all
route print
nslookup example.com

Problèmes courants :

• Mauvais masque (/24 vs /23), ou passerelle erronée.
• Route par défaut manquante.
• DNS injoignable ou mal configuré.

Dépannage VLAN

Décidez si le tagging se fait sur la NIC de la VM ou sur le port de switch.

• Si la NIC de VM est taguée dans Proxmox :
• Le port de switch amont doit être en trunk transportant ce VLAN.
• Avec un bridge VLAN-aware, vérifiez que le VLAN est autorisé pour le port de la VM (bridge-vids ou liste dans l'UI).

• Si la NIC de VM est non taguée :
• Le port de switch doit être en access dans le VLAN cible.

• Inspecter les trames VLAN depuis l'hôte :

tcpdump -ni vmbr0 -e vlan

• Vérifier les VLAN autorisés et l'appartenance :

bridge vlan show

• Évitez d'appliquer le tag à deux endroits. Le double-tagging ou mélanger une VM non taguée sur un port trunk-only casse la L2.

Problèmes DHCP

Quand une VM n'obtient pas d'adresse via DHCP :

• Confirmez que le serveur DHCP est sur le bon VLAN et joignable depuis vmbr0.
• Observez l'échange côté invité et côté hôte :

# Dans l'invité (Linux)
dhclient -v -r && dhclient -v <nic>

# Sur l'hôte, à l'écoute sur vmbr0
sudo tcpdump -ni vmbr0 port 67 or port 68

• Si un filtrage existe, autorisez DHCP :
• UDP 67 (serveur) et UDP 68 (client) doivent passer entre la VM et le serveur.

• Si la VM est en statique via cloud-init ou un gestionnaire réseau, vérifiez que DHCP n'a pas été désactivé par inadvertance, et que l'IP, le masque, la passerelle et le DNS sont corrects.

Routage et DNS

Une fois l'IP présente, confirmez la L3 et la résolution.

• Vérifier la route par défaut et la passerelle :

ip route
ping -c 3 <ip-passerelle>

• Tester l'externe par IP puis le DNS :

ping -c 3 1.1.1.1
getent hosts example.com || nslookup example.com || dig +short example.com

• Si l'IP fonctionne mais pas les noms, corrigez resolv.conf ou la configuration du résolveur.
• Sur l'hôte, en topologie routée, assurez-vous que le routeur amont connaît le sous-réseau des VMs.

NAT et pare-feu

Si les VMs doivent sortir via NAT sur l'hôte Proxmox :

• Activer le forwarding IPv4 :

sysctl net.ipv4.ip_forward
# Si 0, l'activer
sudo sysctl -w net.ipv4.ip_forward=1

• Vérifier le NAT (iptables ou nftables), ex. iptables :

sudo iptables -t nat -S | grep MASQUERADE
# Règle d'exemple si manquante :
sudo iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o enp3s0 -j MASQUERADE

• Avec nftables :

sudo nft list ruleset | sed -n '/nat/,/}/p'

• Confirmez qu'aucune règle ne bloque DHCP (UDP 67-68) ou DNS (UDP/TCP 53).

MTU et performance

Des incohérences de MTU provoquent gels ou connectivité partielle.

• Vérifier les MTU sur l'hôte, le bridge et l'invité :

ip link show vmbr0
ip link show enp3s0

• Tester la path MTU vers internet :

ping -M do -s 1472 8.8.8.8   # 1472 + 28 = 1500

• En présence de VLANs ou tunnels, réduisez l'MTU en conséquence (ex. 1500 → 1496 pour 802.1Q) ou alignez l'amont.

• En diagnostic, désactivez temporairement les offloads pour écarter un problème de pilote :

sudo ethtool -K enp3s0 tso off gso off gro off tx off rx off

Checklist rapide

• Lien hôte UP et bonne NIC asservie à vmbr0.
• Configuration du bridge en phase avec la topologie.
• NIC VM attachée à vmbr0, modèle correct, tag VLAN cohérent.
• IP, masque, route par défaut et DNS corrects côté invité.
• Trunk/access aligné avec le choix de tagging ; pas de double-tagging.
• Requêtes/réponses DHCP observées ; bail obtenu.
• Passerelle joignable ; IP externe accessible ; DNS résout.
• Règles NAT/pare-feu conformes au trafic attendu.
• MTU homogène de bout en bout.

Plan pilote local

Démarrez petit et validez chaque couche avant d'étendre :

• Labo minimal :
• Un hôte Proxmox relié à un port de switch valide.
• vmbr0 bridgé sur cette NIC.
• Une VM de test avec une seule NIC sur vmbr0.

• Un seul VLAN et une seule méthode d'adressage :
• Accès non tagué avec DHCP, ou
• VLAN tagué avec IP statique et passerelle connue.

• Quatre sondes de succès et résultats attendus :

1. L2 : la VM reçoit une réponse ARP de la passerelle (arping <ip-gw> renvoie une réponse).
2. L3 : ping de la passerelle < 20 ms sur le LAN.
3. Hors sous-réseau : ping d'une IP externe (ex. 1.1.1.1) réussi.
4. DNS : résolution de example.com et ping par nom.

• Capture avant/après :
• ip addr, ip route, bridge link, bridge vlan show, extraits tcpdump.

• Expansion graduelle :
• Ajoutez une seconde VM, puis un second VLAN.
• Ne changez qu'une variable à la fois (ex. ajouter VLAN 20 après validation de VLAN 10).

Conclusion

Un processus reproductible surpasse le hasard. Commencez par valider l'hôte Proxmox et vmbr0, puis la NIC invitée, l'IP et la passerelle. Alignez le tagging VLAN avec la configuration du switch, suivez les échanges DHCP et vérifiez le DNS. Examinez NAT et pare-feu quand une sortie vers internet requiert du MASQUERADE, et contrôlez l'MTU pour déceler les pertes subtiles. En synthèse :

• vmbr0 asservit la NIC prévue et correspond au mode du port de switch ;
• l'invité dispose d'une route par défaut unique et d'un DNS joignable ;
• les handshakes DHCP traversent le VLAN attendu ;
• NAT, pare-feu et MTU n'entravent ni ne fragmentent le trafic à contretemps.

Mots-clés utiles pour la recherche et les tickets : vmbr0 troubleshooting, Linux bridge VLAN Proxmox, Proxmox VE network bridge, Proxmox VM no internet.