Dépannage des ponts réseau Proxmox VE pour machines virtuelles : guide d'implémentation pratique

Introduction

Proxmox VE connecte les machines virtuelles au réseau physique via des ponts Linux (généralement vmbr0). Lorsqu'une VM n'a pas d'Internet ou ne peut pas atteindre les services locaux, la cause se trouve habituellement dans un ensemble restreint d'éléments : le pont hôte, les VLAN et ports de commutateur, l'adressage IP et les passerelles, le DHCP, ou les pare-feu locaux. Ce guide propose une liste de contrôle pratique et ordonnée pour localiser et corriger la panne rapidement.

Public visé : développeurs, consultants DevOps et équipes techniques de startups qui ont besoin d'une connectivité VM fiable sans tâtonnements.

Ce que vous allez accomplir :

Vérifier que vmbr0 et la carte physique sont correctement câblés
Détecter les erreurs courantes de VLAN et de passerelle
Diagnostiquer les échecs DHCP et les IP statiques mal configurées
Confirmer le routage et le DNS à l'intérieur de l'invité
Valider les réglages NAT, pare-feu et MTU

Aperçu du flux de travail

Procédez de l'extérieur vers l'intérieur, puis de l'intérieur vers l'extérieur :

Cartographier la topologie

Identifier les interfaces de l'hôte Proxmox (ex. enp3s0), le pont (vmbr0), le port commutateur amont et le(s) VLAN cible(s)
Noter si les VM utilisent le DHCP ou des IP statiques, et quelle doit être la passerelle par défaut

Valider le lien hôte et le pont

Confirmer que le lien physique est actif et que vmbr0 asservit la bonne carte
S'assurer que l'IP de gestion de l'hôte et sa passerelle (si présentes) sont correctes et n'entrent pas en conflit avec le plan d'adressage des invités

Vérifier la carte NIC de l'invité et son IP

Confirmer que la carte VM est attachée à vmbr0 et que le modèle est approprié (VirtIO recommandé pour Linux)
Contrôler la configuration IP, la route par défaut et le DNS à l'intérieur de l'invité

Contrôler les VLAN

Aligner les étiquettes VLAN des VM, la sensibilité VLAN du pont et le mode du port commutateur (accès vs trunk)

Corriger la configuration DHCP ou statique

Tracer les requêtes et réponses DHCP ou valider l'IP statique, le masque, la passerelle et le DNS

Confirmer le routage et le DNS

Pinger la passerelle, une IP externe et tester la résolution DNS

Revoir le NAT et le pare-feu

Si le NAT est utilisé, vérifier le transfert et le MASQUERADE. Contrôler les règles qui bloqueraient DHCP/DNS

Tester le MTU et les performances

Valider le MTU du chemin et désactiver les offloads pendant le diagnostic si nécessaire

Vérifications hôte et pont

Sur l'hôte Proxmox, confirmer l'état du lien et du pont.

Afficher les liens et adresses :

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

Confirmer quels ports appartiennent au pont :

bridge link
bridge vlan show

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

ethtool enp3s0
dmesg -T | grep -i link

Examiner /etc/network/interfaces (pont L2 typique avec gestion hôte 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

Exemple de pont VLAN-aware (filtrage par port ; autoriser VLAN 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 l'IP de l'hôte sur vmbr0
Si l'hôte n'a pas d'IP sur vmbr0 (usage L2 pur), prévoir un autre chemin pour la gestion (ex. carte de gestion dédiée ou interface out-of-band)
Après modification d'interfaces, planifier l'application pendant une fenêtre de maintenance ou utiliser la console pour éviter le verrouillage

Vérifications NIC et IP de l'invité

Valider la configuration VM dans Proxmox et à l'intérieur de l'OS invité.

Dans la vue matériel de la VM :

Pont : vmbr0
Étiquette VLAN : vide si accès non étiqueté, ou définie sur le bon ID VLAN si étiqueté (ex. 10 pour VLAN 10)
Modèle : VirtIO (paravirtualisé) recommandé pour les invités Linux

À l'intérieur d'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

À l'intérieur d'un invité Windows :

ipconfig /all
route print
nslookup example.com

Problèmes courants :

Mauvais masque ou passerelle (ex. /24 vs /23)
Route par défaut manquante
Serveur DNS inaccessible ou mal configuré

Dépannage VLAN

Décider si l'étiquetage se fait sur la carte VM ou sur le port commutateur.

Si la carte VM a une étiquette VLAN définie dans Proxmox :

Le port commutateur amont doit être un trunk transportant ce VLAN
Avec un pont VLAN-aware, s'assurer que le VLAN est autorisé pour le port VM (bridge-vids ou liste d'autorisation de l'interface)

Si la carte VM n'est pas étiquetée :

Le port commutateur doit être un port d'accès dans le VLAN cible

Inspecter le trafic pour les étiquettes VLAN depuis l'hôte :

tcpdump -ni vmbr0 -e vlan

Vérifier les VLAN autorisés sur le pont et l'appartenance :

bridge vlan show

S'assurer qu'un seul endroit applique l'étiquette. Le double étiquetage ou le mélange de cartes VM non étiquetées avec des ports trunk uniquement cassera la connectivité L2. Par exemple, si la carte VM est étiquetée 10 dans Proxmox et que le port commutateur est un port d'accès dans le VLAN 10, la trame arrive double-étiquetée et est rejetée.

Problèmes DHCP

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

Confirmer que le serveur DHCP est sur le bon VLAN et accessible depuis vmbr0
Observer l'échange DHCP côté invité et côté hôte :

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

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

Si du filtrage est activé, autoriser le DHCP :
UDP 67 (serveur) et UDP 68 (client) doivent passer entre VM et serveur
Si une VM est configurée statiquement par cloud-init ou le gestionnaire de réseau de l'OS, s'assurer que le DHCP n'est pas désactivé inopinément, ou que les réglages statiques sont corrects

Routage et DNS

Une fois que la VM a une IP, confirmer la couche 3 et la résolution de noms.

Vérifier la route par défaut et l'accessibilité de la passerelle :

ip route
ping -c 3 <ip-passerelle>

Tester l'accessibilité externe par IP, puis 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, corriger /etc/resolv.conf ou les paramètres de résolution de l'OS pour pointer vers des serveurs DNS accessibles (ex. 1.1.1.1, 8.8.8.8, ou votre résolveur interne).

Sur l'hôte, s'assurer que le routeur amont connaît le sous-réseau VM si vous faites du routage (le routeur a une route de retour vers le réseau VM via l'IP de l'hôte Proxmox).

NAT et pare-feu

Si les VM doivent atteindre Internet via NAT sur l'hôte Proxmox :

Activer le transfert 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), exemple iptables :

sudo iptables -t nat -S | grep MASQUERADE
# Exemple de règle si manquante (remplacer 10.10.10.0/24 par votre sous-réseau VM) :
sudo iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o enp3s0 -j MASQUERADE

Si utilisation de nftables :

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

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

MTU et performances

Les incompatibilités de MTU de chemin peuvent causer des blocages ou une connectivité partielle (ex. SSH connecte mais les gros transferts plantent).

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

ip link show vmbr0
ip link show enp3s0

Tester le MTU de chemin vers Internet :

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

Si utilisation de VLAN ou tunnels, réduire le MTU en conséquence (ex. 1500 -> 1496 pour 802.1Q) ou ajuster l'amont pour correspondre.

Pendant le diagnostic, on peut désactiver temporairement les offloads pour écarter les problèmes de pilote :

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

Liste de contrôle diagnostic rapide

Lien hôte actif et bonne carte asservie à vmbr0
Configuration du pont alignée avec la topologie visée
Carte VM attachée à vmbr0, bon modèle, étiquette VLAN conforme au design
Invité avec IP, masque, route par défaut et DNS corrects
Trunk/accès VLAN correspond au choix d'étiquetage VM ; pas de double étiquetage
Requêtes et réponses DHCP observées ; baux obtenus
Passerelle accessible ; IP externe accessible ; DNS résout
Règles NAT et pare-feu autorisent le trafic attendu
MTU cohérent de bout en bout

Plan pilote local

Commencer petit et prouver chaque couche avant déploiement large.

Construire un laboratoire minimal :

Une carte hôte Proxmox vers un port commutateur connu bon
vmbr0 pontant cette carte
Une VM test avec une seule carte sur vmbr0

Choisir un seul VLAN et une méthode d'adressage :

Accès non étiqueté avec DHCP, ou
VLAN étiqueté avec IP statique et passerelle connue

Définir 4 sondes de succès et sorties attendues :

Liaison/L2 : l'invité reçoit une réponse ARP de la passerelle (arping <ip-gw> montre une réponse)
L3 : ping passerelle réussit avec <20 ms sur LAN
Hors sous-réseau : ping une IP externe connue (ex. 1.1.1.1) réussit
DNS : résoudre example.com en IP et ping par nom

Capturer avant/après :

Sauvegarder les sorties de ip addr, ip route, bridge link, bridge vlan show, extraits tcpdump

Étendre progressivement :

Ajouter une deuxième VM, puis un deuxième VLAN
Ne changer qu'une variable à la fois (ex. ajouter VLAN 20 après vérification VLAN 10)

Conclusion

Un processus fiable bat les conjectures. Valider d'abord l'hôte Proxmox et vmbr0, puis confirmer la carte NIC, l'IP et la passerelle de l'invité, aligner l'étiquetage VLAN avec la configuration commutateur, et tracer le DHCP et le DNS. Revoir les règles NAT et pare-feu quand la sortie nécessite du masquerade, et vérifier le MTU pour les pertes subtiles. Utiliser le plan pilote local pour prouver liaison, ARP, routage et DNS sur une seule VM avant d'étendre.

Vérifications finales :

vmbr0 asservit la carte voulue et correspond au mode port commutateur
L'invité a une unique route par défaut correcte et un DNS accessible
Les poignées de main DHCP traversent le VLAN prévu
NAT, pare-feu et MTU ne bloquent ni ne fragmentent le trafic de façon inattendue