Dépannage réseau Proxmox : guide pratique étape par étape

Introduction

Lorsque le réseau Proxmox se comporte mal, de petites négligences dans le DNS, le routage ou les règles de pare-feu peuvent se transformer en problèmes difficiles à diagnostiquer : un nœud quitte le cluster, une machine virtuelle perd sa route par défaut, l'accès web devient instable ou la migration à chaud bloque. Ce guide propose une approche pratique, étape par étape, pour isoler la panne en toute sécurité et la corriger avec confiance.

Vous allez établir un inventaire clair de vos versions et de votre topologie, valider les hypothèses de base (adressage IP, bridges, bonds, VLANs et DNS), vérifier que les ports nécessaires sont accessibles, exécuter des tests de connectivité ciblés et choisir des chemins de récupération sûrs si un changement ne fonctionne pas. Tous les exemples sont des scénarios construits que vous pouvez adapter à votre environnement.

Inventaire des versions et de l'environnement

Avant de modifier quoi que ce soit, capturez une image minimale mais complète de ce que vous dépannez. Un court inventaire évite les suppositions mal alignées dans l'équipe et rend le dépannage reproductible.

Prérequis

Accès console à chaque nœud (local ou out-of-band) en cas de perte réseau
Accès shell en root sur les nœuds Proxmox
Fenêtre de changement ou environnement de labo pour les tests
Un endroit pour enregistrer les sorties (ticket ou notes)

Enregistrer les versions et l'identité du nœud

Exécutez sur chaque nœud :

pveversion
uname -r
hostname -f
hostname -I
ip -br a
ip -br link

Confirmez que le nom de domaine complet (FQDN) correspond à la configuration du nœud et se résout vers l'IP de gestion.
Notez les versions du noyau et de Proxmox pour le contexte (le comportement des pilotes et les backends de pare-feu peuvent varier selon les versions).

Inventorier les bridges, bonds, VLANs et routes

ip -d link show
ip -br a
ip route show
grep -v '^#' /etc/network/interfaces

Identifiez quelles cartes physiques correspondent à quels bridges (par exemple, enp3s0 -> vmbr0), les interfaces VLAN (vmbr0.100) et les périphériques bond (bond0).
Capturez la route par défaut et les passerelles spécifiques aux VLANs.

Inventorier le DNS

hostname -f
getent hosts $(hostname -f)
cat /etc/hosts
cat /etc/resolv.conf || true
command -v resolvectl >/dev/null && resolvectl status || true

Vérifiez que le FQDN du nœud se résout vers la bonne IP de gestion et que /etc/hosts contient un mappage cohérent.

Inventorier l'état du pare-feu

pve-firewall status || true
command -v nft >/dev/null && nft list ruleset | sed -n '1,120p' || iptables -L -n -v
ss -tulpn | sed -n '1,120p'

Notez si le pare-feu Proxmox est activé au niveau du datacenter ou du nœud.
Listez les sockets en écoute pour vérifier les services attendus.

Chemin de configuration sécurisé

Les changements réseau peuvent déconnecter un nœud ou partitionner un cluster. Utilisez un pilote étroit et mesurable et appliquez les modifications de façon à pouvoir revenir en arrière rapidement.

Principes pour des changements sûrs

Faites un changement à la fois et mesurez son effet (par exemple, restaurez la résolution DNS, puis re-testez la santé du cluster).
Gardez une console root ouverte pendant l'application des changements réseau pour pouvoir annuler si SSH coupe.
Privilégiez les rechargements ifupdown2 plutôt que les redémarrages complets quand c'est possible.
Documentez les diffs exacts appliqués sous /etc/network/interfaces et tout changement sysctl ou pare-feu.

Exemple construit : bridge statique minimal

Si votre IP de gestion doit résider sur un bridge Linux qui supporte le trafic des VM :

auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

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

Appliquez en toute sécurité avec ifupdown2 (recommandé sur Proxmox) :

ifreload -a

Vérification immédiate après rechargement :

ip -br a show dev vmbr0
ip route get 192.168.10.1
ping -c 3 192.168.10.1
ping -c 3 8.8.8.8
getent hosts $(hostname -f)

Si vous utilisez des VLANs, attribuez l'IP à la sous-interface VLAN, pas au bridge brut. Exemple construit pour un VLAN de gestion 100 :

auto vmbr0
iface vmbr0 inet manual
 bridge-ports enp3s0
 bridge-stp off
 bridge-fd 0

auto vmbr0.100
iface vmbr0.100 inet static
 address 10.10.100.20/24
 gateway 10.10.100.1

Encore une fois, appliquez via :

ifreload -a

Hygiène DNS

Assurez-vous que /etc/hosts inclut le nom court et le FQDN de votre nœud mappés vers la bonne IP de gestion.
Assurez-vous que les résolveurs dans /etc/resolv.conf (ou la configuration systemd-resolved) sont accessibles depuis le nœud.
Maintenez le nom d'hôte du nœud aligné avec les attentes de Proxmox : le nom court et le FQDN doivent tous deux se résoudre vers l'IP de gestion.

Vérification et diagnostics

Utilisez des tests ciblés qui confirment ou infirment des hypothèses précises. Commencez au niveau du nœud local, puis élargissez.

Ancres de santé rapides

Pouvez-vous atteindre l'interface web localement ? Essayez depuis le nœud : curl -k https://127.0.0.1:8006/ et cherchez du HTML.
La route par défaut est-elle correcte ? ip route get 8.8.8.8 doit afficher la passerelle et l'interface de sortie attendues.
Le nœud résout-il son propre FQDN ? getent hosts $(hostname -f) doit retourner l'IP de gestion.

Connectivité du local au local

# Proxy web (attend des en-têtes HTTP)
curl -kI https://127.0.0.1:8006/

# Ports console (vérification ponctuelle)
ss -lnt | egrep ':8006|:22|:3128|:59'

# Vérification du port UDP Corosync (présence seulement)
ss -lun | grep 5405 || true

Connectivité du nœud vers la passerelle et le DNS

ping -c 3 $(ip r | awk '/default/ {print $3; exit}')
# Si les IPs DNS sont listées dans resolv.conf
awk '/^nameserver/ {print $2}' /etc/resolv.conf | while read s; do ping -c 3 "$s\); done

ARP et santé de la couche 2

arp -an | head -n 10
# Obtenir le premier port du bridge et afficher ses stats ethtool
phy=$(basename $(readlink -f /sys/class/net/vmbr0/brif/* 2>/dev/null | head -n1))
if [ -n "$phy" ]; then ethtool -S "$phy" 2>/dev/null | sed -n '1,80p'; fi

Routage et chemins asymétriques

# Tracer la route par défaut
traceroute -n 8.8.8.8 2>/dev/null || mtr -n --report 8.8.8.8

# Route choisie pour un pair distant
ip route get <IP_PAIR>

Vérifications pare-feu

pve-firewall status || true
command -v nft >/dev/null && nft list ruleset | sed -n '1,120p' || iptables -L -n -v

# Test ponctuel d'un port TCP vers un autre nœud
nc -vz <IP_AUTRE_NŒUD> 8006

Visibilité du cluster

pvecm status
journalctl -u corosync --since "-10m" | tail -n 80

Vérifications du plan de données des VM

Confirmez que la carte réseau de la VM est attachée au bridge et au VLAN attendus :

qm list
qm config <VMID> | egrep '^net|^name:'

Si un tag VLAN est attendu sur le port de la VM, assurez-vous que le trunk du bridge est configuré pour l'autoriser, et que la carte de la VM inclut le tag, par exemple net0: virtio=...,bridge=vmbr0,tag=100.

Depuis le nœud, vérifiez la sortie vers la passerelle du sous-réseau VM via la sous-interface du bridge (exemple construit) :

ping -c 3 -I vmbr0.100 10.10.100.1

Depuis l'intérieur de la VM (avec accès console), validez IP, route, DNS :

ip -br a
ip route get 8.8.8.8
getent hosts $(hostname -f)

Résultats attendus et comment les lire

curl -kI https://127.0.0.1:8006/ doit retourner HTTP/1.1 200 ou 302 avec les en-têtes Proxmox.
ip route get 8.8.8.8 doit afficher un next hop sur l'interface prévue (par exemple, via 192.168.10.1 dev vmbr0 src 192.168.10.20).
getent hosts $(hostname -f) doit correspondre à l'IP de gestion du nœud.
nc -vz <IP_AUTRE_NŒUD> 8006 doit rapporter « succeeded » pour la connectivité TCP entre nœuds sur le port web si autorisé par votre modèle de sécurité.

Symptômes courants mappés aux vérifications

Interface web inaccessible depuis le LAN — Cause probable : mauvaise IP/passerelle sur vmbr, pare-feu bloquant le port 8006. Première vérification : ip -br a; ip route get passerelle_LAN; nc -vz nœud 8006
Nœud quitte le cluster — Cause probable : port Corosync bloqué ou mauvaise carte/VLAN. Première vérification : ss -lun | grep 5405; pvecm status; journalctl -u corosync
VM a une IP mais pas d'internet — Cause probable : route par défaut manquante ou mauvais tag VLAN. Première vérification : ip route get 8.8.8.8 dans la VM ; qm config <VMID> pour tag=
Échec de la résolution DNS — Cause probable : resolv.conf incorrect ou DNS inaccessible. Première vérification : cat /etc/resolv.conf; ping IP_DNS; getent hosts nom
Migration bloquée — Cause probable : TCP nœud-à-nœud bloqué sur les ports de service. Première vérification : nc -vz autre-nœud 8006 et ports de migration pertinents

Ports réseau courants liés à Proxmox (par défaut)

8006 (TCP) — Interface web (pveproxy) — Admins sur le LAN de gestion
22 (TCP) — SSH vers le nœud — Admins sur le LAN de gestion
5405 (UDP) — Trafic cluster (corosync) — Entre nœuds du cluster
5900-5999 (TCP) — Console VNC vers les invités — Admins via nœud/proxy
3128 (TCP) — Proxy SPICE — Admins via nœud/proxy

Interpréter les échecs

Si le ping vers la passerelle échoue mais que le lien est up, vérifiez le câblage, le VLAN du port switch et le mapping bridge-ports.
Si les requêtes DNS vers un nameserver listé expirent, soit le nameserver est erroné, soit il est bloqué ; essayez un autre résolveur dans le même sous-réseau.
Si nc vers le port 8006 échoue entre nœuds mais que l'interface web fonctionne depuis votre poste, un pare-feu inter-nœuds ou une ACL peut bloquer le trafic nœud-à-nœud.

Modes de défaillance et récupération

La récupération réseau consiste à préserver un chemin de retour. Voici les modes de défaillance courants et les retours en arrière pragmatiques.

Défaillance : Perte de SSH après édition de /etc/network/interfaces

Cause probable : IP du bridge déplacée sur la mauvaise interface, mauvais VLAN ou mauvaise passerelle.
Récupération :

Basculez vers la session console ouverte ou la gestion out-of-band.
Annulez le dernier changement (gardez une copie de sauvegarde, par exemple /root/interfaces.bak).
Appliquez les changements avec ifreload -a. Si ifreload n'est pas disponible, essayez ifdown <iface>; ifup <iface> uniquement sur les interfaces affectées.
Validez avec ip -br a, ip route et ping passerelle.

Défaillance : Nœud partitionné du cluster

Cause probable : Corosync sur le mauvais réseau, UDP 5405 bloqué ou MTU mal assorti.
Récupération :

Confirmez la liaison et l'accessibilité L2 entre nœuds sur la carte/VLAN prévu : arp -an, ping -c 3.
Autorisez temporairement l'UDP corosync entre nœuds au niveau de votre périmètre ou pare-feu nœud pour le test.
Si vous avez déplacé le trafic cluster vers une nouvelle interface, mettez à jour les paramètres bindnet de corosync selon la procédure documentée, puis redémarrez corosync pendant une fenêtre de maintenance.
Validez avec pvecm status et les logs corosync.

Défaillance : Interface web inaccessible mais SSH fonctionne

Cause probable : pveproxy n'écoute pas, règle pare-feu sur le port 8006, ou incompatibilité de certificat derrière un proxy.
Récupération :

Vérifiez systemctl status pveproxy et journalctl -u pveproxy --since "-10m".
Confirmez l'écouteur : ss -lnt | grep ':8006'.
Testez localement : curl -kI https://127.0.0.1:8006/.
Si le local fonctionne mais le distant échoue, inspectez les règles pare-feu et tout load balancer devant.

Défaillance : VM sans réseau après déplacement vers un VLAN tagué

Cause probable : VLAN non trunké sur l'uplink hôte ou mauvais tag sur la VM.
Récupération :

Sur le nœud, assurez-vous que l'uplink du bridge est sur un port trunk et que la sous-interface du bridge existe (par exemple, vmbr0.100 avec une IP ou comme trunk pur).
Dans la config de la VM, confirmez tag=100 sur la carte si vous attendez que la VM envoie des trames taguées.
Validez côté switch que le port hôte est dans les bons VLANs.

Défaillance : DNS cassé après changement de résolveurs

Cause probable : Nouveau résolveur inaccessible ou bloqué.
Récupération :

Revenez à un resolv.conf avec un résolveur connu bon.
Testez avec getent hosts deb.debian.org et dig @<résolveur> example.com +time=1 +tries=1 (si dig est installé).
Si vous utilisez systemd-resolved, vérifiez resolvectl status, et définissez le DNS par lien si nécessaire.

Récupération de dernier recours

Si les changements s'enchaînent et que vous ne pouvez pas restaurer la connectivité, planifiez un court redémarrage pour réinitialiser les états transitoires L2/L3 seulement après avoir remis les fichiers de config aux dernières versions connues bonnes. Les redémarrages doivent être un dernier recours après confirmation que la config statique est correcte.

Check-list opérationnelle

Utilisez cette check-list reproductible pour trier et corriger le réseau dans Proxmox.

Établir la ligne de base

pveversion, uname -r enregistrés
hostname -f et getent hosts correspondent à l'IP de gestion
ip -br a et ip route sauvegardés pour référence

Vérifications des services locaux

curl -kI https://127.0.0.1:8006/ retourne des en-têtes
ss -lnt montre 8006, 22 en écoute
ss -lun montre UDP 5405 utilisé pour le clustering si applicable

Santé DNS

/etc/hosts mappe le nom court et le FQDN vers l'IP de gestion
resolv.conf ou systemd-resolved pointe vers des résolveurs accessibles
getent hosts example.com réussit

Routage et passerelle

ip route get <IP_internet> montre le bon next hop et la bonne interface
ping passerelle réussit

Vérifications inter-nœuds et ports

nc -vz <autre nœud> 8006 réussit là où autorisé
pvecm status sain, pas d'erreurs corosync dans le journal

Plan de données des VM

qm config <VMID> montre le bon bridge et le bon tag VLAN
Depuis la VM, ip -br a et ip route corrects ; ping passerelle fonctionne

Appliquer les changements en sécurité

Éditez /etc/network/interfaces avec une console ouverte
Utilisez ifreload -a ; vérifiez avant de fermer la console
Un changement à la fois ; re-testez après chacun

Si quelque chose échoue

Annulez le dernier changement depuis la sauvegarde
Re-testez les étapes de la ligne de base ci-dessus
Ne continuez que lorsque la ligne de base est verte

Conclusion

Le dépannage réseau Proxmox réussi suit un chemin simple : capturer une ligne de base claire des versions et de la topologie ; valider le DNS, les IP, les routes et les bridges ; confirmer que les ports requis écoutent et sont accessibles ; et exécuter des tests précis, en couches, depuis le nœud vers l'extérieur et depuis les VM vers l'intérieur. Appliquez les changements de façon étroite et mesurable avec une console ouverte, et gardez toujours un retour en arrière clair.

Avec les inventaires, commandes et étapes de vérification de ce guide, vous pouvez isoler la plupart des problèmes de connectivité en minutes, pas en heures. Commencez par un petit pilote local sur un nœud, confirmez la section des résultats attendus section par section, puis étendez-vous au reste de votre environnement avec confiance.