Proxmox: comprendre et bien gérer le réseau

Le réseau est l’une des parties les plus simples à sous-estimer dans une infrastructure Proxmox VE. Une machine virtuelle peut être correctement dimensionnée, sauvegardée et supervisée: si son bridge, son VLAN ou sa route est mal conçu, elle reste inaccessible ou insuffisamment isolée.

Proxmox s’appuie sur la pile réseau Linux. Ce choix laisse beaucoup de liberté, mais demande de comprendre ce que l’on configure. L’interface d’administration facilite les opérations courantes; elle ne remplace pas une architecture réseau documentée.

Les briques réseau essentielles de Proxmox

La configuration est enregistrée principalement dans /etc/network/interfaces. Proxmox permet de la gérer depuis son interface web et s’appuie sur ifupdown2 pour appliquer de nombreuses modifications sans redémarrage complet du nœud.

On retrouve généralement quatre types d’éléments:

• les interfaces physiques, par exemple eno1 ou enp3s0;
• les bridges Linux, souvent nommés vmbr0, vmbr1, etc.;
• les interfaces VLAN;
• les bonds, qui regroupent plusieurs interfaces physiques.

Le point central est le bridge Linux. Il fonctionne comme un commutateur virtuel auquel on raccorde les interfaces des machines virtuelles et des conteneurs. Un bridge peut être relié à une carte physique pour accéder au réseau extérieur, ou rester sans port physique afin de créer un réseau privé entre plusieurs charges.

Bridge, routage ou NAT: choisir le bon modèle

Le bridge pour intégrer les VM au réseau existant

Le mode bridgé est le plus courant. Une interface physique est attachée à vmbr0, puis les interfaces virtuelles des VM sont connectées à ce bridge. Les VM apparaissent alors sur le même domaine réseau que les autres équipements autorisés.

Cette approche est lisible et performante. Elle suppose cependant de disposer des adresses nécessaires et de contrôler ce que le réseau amont accepte: nombre d’adresses MAC, anti-spoofing, VLAN disponibles et règles de filtrage.

Le routage pour garder la maîtrise des flux

Dans une architecture routée, le nœud Proxmox achemine le trafic vers un sous-réseau réservé aux VM. Ce modèle évite d’étendre inutilement un domaine de niveau 2 et permet de placer plus clairement le filtrage aux frontières.

Il faut en contrepartie gérer les routes aller et retour. Une route présente uniquement sur l’hyperviseur ne suffit pas: le routeur amont doit savoir comment joindre le réseau des VM.

Le NAT pour des usages ciblés

Le NAT permet à un réseau privé de sortir en utilisant l’adresse du nœud. Il peut convenir à un laboratoire, un environnement de développement ou des charges qui ne doivent pas être exposées directement.

Pour une production, son usage doit rester explicite. Les règles de publication, les journaux et les dépendances à l’hyperviseur doivent être documentés. Un NAT improvisé devient rapidement difficile à diagnostiquer.

Segmenter avec des VLAN

Les VLAN servent à séparer logiquement plusieurs usages sur une même infrastructure physique. Une plateforme Proxmox peut par exemple distinguer:

• l’administration des hyperviseurs;
• le trafic des machines virtuelles;
• le stockage Ceph ou NFS;
• les migrations;
• les sauvegardes;
• les réseaux publics et privés des applications.

Un bridge VLAN aware peut transporter plusieurs VLAN. Chaque interface virtuelle reçoit alors un tag précis, ou une liste de VLAN lorsqu’elle doit fonctionner comme un trunk.

Cette souplesse implique une cohérence de bout en bout. Le VLAN doit être autorisé sur le switch physique, présent sur le bon bond ou la bonne interface, puis affecté à la VM concernée. Une erreur de tag peut provoquer une coupure; une absence de filtrage peut créer une communication qui n’était pas prévue.

La segmentation ne constitue pas, à elle seule, une politique de sécurité. Elle doit être complétée par des règles de pare-feu, une gestion stricte des accès d’administration et une supervision des flux importants.

Bonding: redondance et débit ne sont pas la même chose

Un bond agrège plusieurs interfaces physiques. Le bon mode dépend de l’objectif et des capacités des commutateurs.

Le mode active-backup privilégie la simplicité: une interface transporte le trafic et une autre prend le relais en cas de panne. Le mode 802.3ad, ou LACP, peut répartir plusieurs flux, mais exige une configuration compatible sur les switches.

LACP n’additionne pas automatiquement les débits pour une connexion unique. Le résultat dépend de la méthode de répartition et du nombre de flux. Il faut donc éviter de le présenter comme un multiplicateur universel de bande passante.

Pour une infrastructure critique, la redondance doit aussi couvrir les commutateurs, les alimentations, les chemins réseau et les erreurs de configuration. Deux câbles branchés sur le même équipement ne protègent pas contre la panne de cet équipement.

Réseau de cluster: protéger Corosync et le quorum

Corosync transporte les échanges indispensables au fonctionnement d’un cluster Proxmox. Il a besoin d’une latence faible et stable. Une saturation ou une perte de paquets peut perturber le quorum et les mécanismes de haute disponibilité.

Il est préférable de prévoir des liens Corosync distincts et indépendants. La documentation Proxmox recommande plusieurs réseaux pour assurer cette redondance plutôt que de dépendre uniquement d’un bond. Le trafic de stockage très consommateur, notamment Ceph, ne doit pas pouvoir saturer sans contrôle le réseau du cluster.

Il n’existe pas de découpage universel. Une petite plateforme et un cluster hyperconvergé n’ont pas les mêmes contraintes. L’important est de mesurer les débits, la latence et les conséquences d’une panne avant de mutualiser plusieurs usages.

Modifier le réseau sans perdre l’accès au nœud

Une erreur sur le bridge d’administration peut rendre un serveur inaccessible alors même qu’il fonctionne encore. Toute modification distante devrait donc prévoir:

• un accès hors bande, IPMI, iDRAC, iLO ou console opérateur;
• une copie de la configuration connue comme fonctionnelle;
• une procédure de retour arrière;
• un créneau adapté et une vérification après changement;
• un second regard sur les changements touchant le cluster ou le stockage.

Avec ifupdown2, le bouton Apply Configuration et la commande ifreload -a permettent d’appliquer de nombreux changements à chaud. Cela réduit les redémarrages, mais ne supprime pas le risque. Les commandes traditionnelles ifup et ifdown, utilisées sans maîtriser leurs effets sur les bridges et les dépendances, peuvent provoquer une interruption.

Dans un cluster, les changements doivent être progressifs: un nœud à la fois, avec contrôle de Corosync, du stockage, des migrations et de la connectivité des VM avant de poursuivre.

Les erreurs que nous rencontrons le plus souvent

Les incidents réseau viennent rarement d’une fonction exotique. Ils proviennent plutôt d’un manque de cohérence entre les couches:

• une adresse de passerelle déclarée sur plusieurs interfaces du même nœud;
• un VLAN configuré dans Proxmox mais absent du trunk physique;
• un MTU jumbo activé seulement sur une partie du chemin;
• le trafic Ceph et Corosync placé sur un lien unique sans contrôle;
• un bond LACP configuré d’un seul côté;
• un réseau d’administration accessible depuis trop de postes;
• une modification appliquée sans console de secours;
• une configuration qui fonctionne, mais n’est ni documentée ni sauvegardée.

Le MTU mérite une attention particulière. Une valeur de 9000 n’apporte un bénéfice que si l’ensemble du chemin la supporte. Une configuration partielle peut produire des pannes intermittentes, plus difficiles à comprendre qu’une coupure franche.

Une configuration fiable reste une configuration maintenue

Le réseau Proxmox n’est pas un réglage effectué une seule fois. Les switches évoluent, de nouveaux VLAN apparaissent, les versions de Proxmox changent et les besoins de stockage augmentent.

Une maintenance rigoureuse comprend au minimum:

• une cartographie à jour des ports, bonds, bridges, VLAN et sous-réseaux;
• une sauvegarde versionnée des configurations;
• la supervision des erreurs, pertes, débits, latences et états de liens;
• des tests réguliers de bascule;
• la mise à jour contrôlée des nœuds et équipements réseau;
• la vérification périodique des règles de pare-feu;
• des tests de restauration et de reprise après incident.

Plus l’infrastructure est disponible, plus les procédures d’exploitation comptent. Le bond, le cluster ou le stockage distribué ne compensent pas l’absence de maintenance.

Quand utiliser le SDN de Proxmox?

Les fonctions SDN de Proxmox deviennent utiles lorsqu’il faut administrer de façon cohérente de nombreux réseaux, zones et nœuds, ou mettre en œuvre des overlays comme VXLAN. Elles évitent certaines répétitions et facilitent les architectures multi-tenants.

Elles ajoutent aussi une couche d’abstraction. Pour une plateforme simple, quelques bridges et VLAN clairement documentés restent souvent plus faciles à exploiter. Le SDN doit répondre à un besoin identifié, pas seulement à la disponibilité de la fonction.

Concevoir avant de configurer

Une bonne architecture réseau Proxmox commence par des questions concrètes: quels flux doivent communiquer, quels usages doivent être isolés, quelle panne doit être tolérée et comment reprendre la main si l’administration devient inaccessible?

La configuration découle ensuite de ces réponses. C’est cette démarche qui permet d’obtenir une plateforme lisible, sécurisée et maintenable, plutôt qu’un empilement de bridges et de VLAN dont personne n’ose plus modifier le fonctionnement.

Nous pouvons vous accompagner pour concevoir une infrastructure Proxmox, auditer une plateforme existante ou en assurer l’infogérance.

Sources officielles

• Proxmox VE: Network Configuration
• Proxmox VE Administration Guide