Dépanner le réseau Proxmox avec des exemples pratiques : guide d'implémentation

Introduction

Quand quelque chose déraille dans le réseau Proxmox, de petits détails sur le DNS, le routage ou le pare-feu peuvent provoquer des effets en chaîne : un nœud disparaît du cluster, une VM perd sa route par défaut, l'accès web devient instable, ou une migration à chaud se fige. Ce guide fournit une approche pratique, pas à pas, pour isoler la panne en toute sécurité et corriger avec confiance.

Vous allez dresser un inventaire clair des versions et de la topologie, valider les hypothèses de base (adressage IP, bridges, bonds, VLAN et DNS), vérifier que les bons ports sont joignables, lancer des tests de connectivité ciblés, puis choisir des voies de retour sûres si un changement n'a pas l'effet attendu. Tous les exemples sont des scénarios construits, adaptables à votre environnement. Pour faciliter la recherche, nous mentionnons ponctuellement les termes d'usage comme réseau Proxmox (Proxmox networking), DNS Proxmox (Proxmox DNS), ports Proxmox (Proxmox ports), connectivité Proxmox (Proxmox connectivity) et dépannage réseau Proxmox (Proxmox network troubleshooting).

Inventaire des versions et de l'environnement

Avant tout changement, capturez une image minimale mais complète de ce que vous dépannez. Un inventaire court évite les hypothèses non alignées entre membres de l'équipe et rend le diagnostic reproductible.

Prérequis

• Accès console à chaque nœud (local ou hors bande) en cas de perte réseau
• Accès shell root sur les nœuds Proxmox
• Fenêtre de changement ou labo pour les tests
• Un emplacement pour consigner les sorties (ticket ou notes)

Consignez les versions et l'identité des nœuds. Exécutez sur chaque nœud :

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

• Confirmez que le FQDN correspond à la configuration du nœud et résout vers l'IP de management.
• Relevez la version du kernel et de Proxmox pour le contexte (comportement des pilotes et backends de pare-feu selon les releases).

Inventoriez bridges, bonds, VLAN et routes :

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

• Identifiez quelles NIC physiques alimentent quels bridges (par ex. enp3s0 -> vmbr0), les interfaces VLAN (vmbr0.100) et les bonds (bond0).
• Capturez la route par défaut et d'éventuelles passerelles par VLAN.

Inventaire 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 management et que /etc/hosts contient une correspondance cohérente.

Inventaire 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 datacenter ou nœud.
• Listez les sockets à l'écoute pour recouper avec les services attendus.

Chemin de configuration sécurisé

Les changements réseau peuvent déconnecter un nœud ou partitionner un cluster. Conduisez un pilote étroit, mesurable, et appliquez les changements de manière réversible.

Principes pour des changements sûrs

• Ne modifiez qu'un paramètre à la fois et mesurez son effet (ex. restaurer la résolution DNS, puis re-tester la santé du cluster).
• Gardez une console root ouverte pendant les changements réseau afin de pouvoir revenir en arrière si SSH coupe.
• Préférez les rechargements ifupdown2 aux redémarrages complets si possible.
• Documentez précisément les diffs sous /etc/network/interfaces ainsi que tout sysctl ou changement de pare-feu.

Exemple construit : bridge statique minimal

Si votre IP de management doit résider sur un bridge Linux utilisé par les VMs :

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 sécurité avec ifupdown2 (recommandé sur Proxmox) :

ifreload -a

Vérification juste après :

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 VLAN, affectez l'IP à la sous-interface VLAN, pas au bridge brut. Exemple (VLAN de management 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

De nouveau, appliquez via :

ifreload -a

Hygiène DNS

• Assurez-vous que /etc/hosts inclut le court nom et le FQDN mappés vers la bonne IP de management.
• Vérifiez que les résolveurs dans /etc/resolv.conf (ou systemd-resolved) sont joignables depuis le nœud.
• Maintenez l'alignement hostname/FQDN attendu par Proxmox : court nom et FQDN doivent tous deux résoudre vers l'IP de management.

Vérifications et diagnostics

Utilisez des tests ciblés qui confirment ou infirment des hypothèses précises. Commencez localement, puis élargissez.

Repères rapides

• Accès web local OK ? Depuis le nœud : curl -k https://127.0.0.1:8006/ et cherchez du HTML.
• Route par défaut correcte ? ip route get 8.8.8.8 doit montrer la passerelle et l'interface prévues.
• Le nœud résout son propre FQDN ? getent hosts $(hostname -f) doit renvoyer l'IP de management.

Connectivité du local au local

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

# Ports de console (spot-check)
ss -lnt | egrep ':8006|:22|:3128|:59'

# Vérif UDP Corosync (présence uniquement)
ss -lun | grep 5405 || true

Du nœud vers la passerelle et le DNS

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

ARP et cohérence couche 2

arp -an | head -n 10
ethtool -S $(basename $(readlink -f /sys/class/net/vmbr0/brif/* 2>/dev/null | head -n1)) 2>/dev/null | sed -n '1,80p'

Routage et chemins asymétriques

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

# Route choisie vers un pair
ip route get <PEER_IP>

Vérifications du 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 <OTHER_NODE_IP> 8006

Visibilité du cluster

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

Vérifications de la dataplane VM

• Confirmez que la NIC de la VM est attachée au bridge et VLAN attendus :

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

• Si un tag VLAN est attendu sur la VM, assurez-vous que le trunk du bridge l'autorise et que la NIC VM inclut le tag, par ex. net0: virtio=...,bridge=vmbr0, tag=100.

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

ping -c 3 -I vmbr0.100 10.10.100.1

• Depuis la VM (via console), validez IP, route, DNS :

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

Résultats attendus et interprétation

• curl -kI https://127.0.0.1:8006/ doit retourner HTTP/1.1 200 ou 302 avec des en-têtes Proxmox.
• ip route get 8.8.8.8 doit montrer un next hop sur l'interface prévue (ex. via 192.168.10.1 dev vmbr0 src 192.168.10.20).
• getent hosts $(hostname -f) doit mapper vers l'IP de management du nœud.
• nc -vz <OTHER_NODE_IP> 8006 doit annoncer succeeded pour la connectivité TCP entre nœuds sur le port web si votre modèle de sécurité le permet.

Symptômes courants et premiers contrôles

| Nœud hors du cluster | Port Corosync bloqué ou mauvais NIC/VLAN | ss -lun | grep 5405; pvecm status; journalctl -u corosync | | VM avec IP mais sans Internet | Route par défaut manquante ou mauvais tag VLAN | ip route get 8.8.8.8 dans la VM; qm config <VMID> pour tag= | | Résolution DNS en échec | resolv.conf erroné ou DNS injoignable | cat /etc/resolv.conf; ping IP DNS; getent hosts nom | | Migration figée | TCP inter-nœuds bloqué sur des ports service | nc -vz autre nœud 8006 et ports de migration pertinents |

Ports réseau Proxmox courants (défaut)

Interpréter les échecs

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

Modes de panne et remédiation

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 passerelle invalide.
• Remédiation :

1. Basculez sur la console ouverte ou la gestion hors bande.
2. Restaurez le dernier changement (gardez une sauvegarde, ex. /root/interfaces.bak).
3. Appliquez avec ifreload -a. Si indisponible, ifdown <iface>; ifup <iface> uniquement sur les interfaces affectées.
4. Validez avec ip -br a, ip route, et ping vers la passerelle.

Nœud partitionné du cluster

• Cause probable : Corosync sur le mauvais réseau, UDP 5405 bloqué, ou MTU incohérente.
• Remédiation :

1. Confirmez le lien et la L2 entre nœuds sur le NIC/VLAN visé : arp -an, ping -c 3 <peer>.
2. Autorisez temporairement l'UDP Corosync entre nœuds au périmètre ou pare-feu nœud pour tester.
3. Si vous avez déplacé le trafic cluster, mettez à jour bindnet de Corosync selon les procédures documentées puis redémarrez Corosync en fenêtre de maintenance.
4. Validez avec pvecm status et les journaux Corosync.

UI web inaccessible mais SSH OK

• Cause probable : pveproxy non à l'écoute, règle pare-feu sur 8006, ou souci de certificat derrière un proxy.
• Remédiation :

1. Vérifiez systemctl status pveproxy et journalctl -u pveproxy --since "-10m".
2. Confirmez l'écoute : ss -lnt | grep ':8006'.
3. Test local : curl -kI https://127.0.0.1:8006/.
4. Si local OK mais distant KO, inspectez les règles de pare-feu et tout load balancer en frontal.

VM sans réseau après passage en VLAN taggé

• Cause probable : VLAN non trunké sur l'uplink hôte ou tag erroné sur la VM.
• Remédiation :

1. Sur le nœud, vérifiez que l'uplink du bridge est en trunk et que la sous-interface existe (ex. vmbr0.100 avec IP ou trunk pur).
2. Dans la config VM, confirmez tag=100 sur la NIC si la VM doit émettre en taggé.
3. Côté switch, validez l'appartenance du port hôte aux bons VLANs.

DNS en panne après changement de résolveurs

• Cause probable : nouveau résolveur injoignable ou bloqué.
• Remédiation :

1. Revenez à un résolveur connu dans /etc/resolv.conf.
2. Testez avec getent hosts deb.debian.org et dig @<resolver> example.com +time=1 +tries=1 (si dig est installé).
3. Si vous utilisez systemd-resolved, vérifiez resolvectl status et définissez des DNS par lien au besoin.

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 uniquement après avoir rétabli les fichiers de config vers la dernière bonne version. Le redémarrage est un ultime recours quand la config statique est correcte.

Liste de contrôle d'exploitation

1. Établir la base

• pveversion, uname -r consignés
• hostname -f et getent hosts correspondent à l'IP de management
• ip -br a et ip route sauvegardés

1. Contrôles de service locaux

• curl -kI https://127.0.0.1:8006/ retourne des en-têtes
• ss -lnt montre 8006, 22 en écoute
• ss -lun montre l'UDP 5405 si cluster

1. Sanité DNS

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

1. Routage et passerelle

• ip route get <internet IP> montre le bon next hop et l'interface
• ping passerelle OK

1. Inter-nœuds et ports

• nc -vz <autre nœud> 8006 réussit si autorisé
• pvecm status sain, pas d'erreurs Corosync dans le journal

1. Dataplane VM

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

1. Appliquer en sécurité

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

1. En cas d'échec

• Revenez au dernier changement depuis la sauvegarde
• Re-testez la base ci-dessus
• Ne progressez que quand la base est verte

Conclusion

Un dépannage réseau Proxmox réussi suit un chemin simple : capturer une base claire des versions et de la topologie ; valider DNS, IP, routes et bridges ; confirmer que les ports requis sont à l'écoute et joignables ; et exécuter des tests précis, par couches, du nœud vers l'extérieur et des VMs vers l'intérieur. Appliquez des changements mesurés, avec une console ouverte, et gardez toujours une option de retour. Avec les inventaires, commandes et vérifications de ce guide, vous pouvez isoler l'immense majorité des problèmes de connectivité en minutes, pas en heures.