Le SDN Proxmox VE : réseau logiciel sur serveur dédié
Sur un serveur dédié sous Proxmox VE, toutes les machines virtuelles et tous les conteneurs LXC partagent par défaut le même pont réseau Linux (vmbr0). Chaque machine virtuelle voit le trafic des autres sur le réseau local, et une erreur de configuration réseau sur une VM peut affecter l'ensemble de l'hôte. Le SDN (Software-Defined Networking) de Proxmox VE résout ce problème en ajoutant une couche de gestion réseau au niveau du datacenter : les administrateurs créent des zones, des VNets (réseaux virtuels) et des sous-réseaux depuis l'interface web, puis assignent chaque VM ou conteneur LXC au VNet qui lui correspond.
Proxmox VE repose sur Debian, ce qui signifie que la pile réseau sous-jacente (ponts Linux, ifupdown2, iptables/nftables) bénéficie de la stabilité et de la documentation de l'écosystème Debian. Le SDN est intégré nativement depuis la version 8.1. La gestion des VNets et des zones est pleinement supportée. Les fonctions avancées (IPAM avec DHCP via dnsmasq, contrôleurs FRRouting) restent en aperçu technique. Ce guide couvre les configurations des zones Simple, VLAN et VXLAN, la création de VNets et de sous-réseaux, et les cas d'usage concrets sur un serveur dédié chez un hébergeur comme ElypseCloud.
Prérequis
- Un serveur dédié sous Proxmox VE 8.1 ou supérieur (la version 9.x est recommandée). L'hôte doit disposer d'au moins 16 Go de RAM pour faire tourner plusieurs machines virtuelles et conteneurs LXC dans des VNets séparés ;
- Un accès root à l'interface web Proxmox VE (port 8006) et une connexion SSH pour vérifier la configuration réseau en ligne de commande ;
- Pour les zones VLAN : un switch physique ou virtuel configuré pour le trunking 802.1Q sur la carte réseau du serveur ;
- Pour les zones VXLAN : au moins deux hôtes Proxmox VE avec une connectivité IP entre eux (protocole UDP, port 4789) ;
- Le serveur dédié mis à jour avec les derniers correctifs de sécurité et les paquets
libpve-network-perletifupdown2installés.
Architecture SDN : zones, VNets et sous-réseaux
Le SDN Proxmox repose sur trois niveaux hiérarchiques qui segmentent le réseau local de votre serveur dédié :
- Zone : définit la technologie de transport réseau et les protocoles utilisés (Simple, VLAN, VXLAN, EVPN, QinQ). Chaque zone détermine comment le trafic circule entre les hôtes du cluster Proxmox VE. Contrairement à un réseau physique où chaque segment nécessite un câble et un périphérique réseau dédié, la zone SDN virtualise la segmentation sur la même carte réseau physique.
- VNet (Virtual Network) : un réseau virtuel rattaché à une zone. Sur chaque hôte concerné, le VNet se matérialise sous forme d'un pont Linux auquel vous connectez vos machines virtuelles et conteneurs LXC. Chaque VNet est isolé des autres au niveau Ethernet : les connexions entre VNets différents sont bloquées par défaut.
- Sous-réseau (Subnet) : une plage IP en notation CIDR associée à un VNet. Le sous-réseau définit la passerelle, les options de NAT (SNAT pour l'accès à Internet sortant) et la plage DHCP éventuelle. Vous pouvez aussi y configurer un préfixe DNS pour la résolution de noms sur ce segment.
Cette architecture permet de segmenter le réseau d'un serveur dédié sans toucher à la configuration physique. Les administrateurs créent autant de VNets que nécessaire pour séparer leurs environnements : production, développement, DMZ, réseau d'administration distant, serveurs de jeu isolés entre eux.
Toute la configuration SDN se fait depuis l'onglet Datacenter, SDN de l'interface web Proxmox VE. Les modifications ne sont pas appliquées immédiatement : elles sont enregistrées comme pending (en attente) dans /etc/pve/sdn/, puis appliquées en lot depuis le panneau SDN principal en cliquant sur Apply. Ce mécanisme évite les coupures réseau pendant la configuration.
Créer une zone Simple
La zone Simple crée un pont réseau isolé localement sur chaque hôte. Elle convient aux serveurs dédiés mono-noeud qui ont besoin de séparer des groupes de machines virtuelles sans dépendre d'un switch VLAN ou d'un tunnel entre noeuds. Les VMs connectées au même VNet dans une zone Simple communiquent entre elles sur le réseau local virtuel, mais pas avec les VMs des autres VNets.
Créez la zone depuis l'interface web :
- Allez dans Datacenter, SDN, Zones ;
- Cliquez sur Add, puis sélectionnez Simple ;
- Renseignez l'identifiant de la zone (ex.
simple1) ; - Validez, puis cliquez sur Apply dans le panneau SDN principal.
Créez ensuite un VNet dans cette zone :
- Dans Datacenter, SDN, VNets, cliquez sur Create ;
- Choisissez un identifiant (ex.
vnet-dev, 8 caractères maximum) et sélectionnez la zonesimple1; - Validez, puis cliquez sur Apply.
Ajoutez un sous-réseau au VNet pour définir la plage IP et la passerelle :
- Sélectionnez le VNet dans la liste, puis cliquez sur Subnet, Create ;
- Renseignez le CIDR (ex.
10.10.10.0/24) et la passerelle (ex.10.10.10.1) ; - Cochez SNAT si les VMs de ce VNet doivent accéder à Internet via l'hôte du serveur dédié ;
- Validez et appliquez.
Chaque machine virtuelle ou conteneur LXC connecté à ce VNet recevra une interface sur le pont vnet-dev. Configurez l'adresse IP statiquement dans la VM (ex. 10.10.10.2/24, passerelle 10.10.10.1). Sur une VM Ubuntu ou Debian, éditez le fichier /etc/network/interfaces ou utilisez Netplan.
Créer une zone VLAN
La zone VLAN utilise le marquage 802.1Q pour isoler les segments réseau sur un même lien physique. C'est la solution la plus courante pour les serveurs dédiés connectés à un switch compatible VLAN, comme ceux que vous trouvez en housing en datacenter. Le tag VLAN est défini au niveau du VNet, ce qui permet de créer plusieurs VNets dans la même zone VLAN avec des tags différents. Chaque tag VLAN isole le trafic au niveau de la carte réseau physique du serveur, comme si chaque segment disposait de son propre câble Ethernet.
Configuration depuis l'interface web :
- Dans Datacenter, SDN, Zones, ajoutez une zone de type VLAN ;
- Renseignez l'identifiant (ex.
vlanzone) et le pont physique (vmbr0) ; - Validez et appliquez ;
- Créez un VNet (ex.
vnet-prod) dans cette zone, avec le tag VLAN souhaité (ex.100) ; - Ajoutez un sous-réseau au VNet (ex.
192.168.100.0/24, passerelle192.168.100.1) ; - Appliquez la configuration.
Répétez l'opération pour chaque segment réseau : un VNet avec le tag 200 pour le réseau de développement, un VNet avec le tag 300 pour la DMZ. Chaque VNet est totalement isolé au niveau Ethernet, comme s'il s'agissait de câbles physiques séparés vers des périphériques réseau distincts.
Pour approfondir l'isolation réseau avec un pare-feu dédié devant vos VLANs, consultez notre guide installer pfSense dans une VM Proxmox ou installer OPNsense dans Proxmox.
Créer une zone VXLAN
La zone VXLAN (Virtual Extensible LAN) encapsule les trames Ethernet de couche 2 dans des datagrammes UDP sur le port 4789 (protocole TCP/IP standard). Cette technologie permet d'étendre un réseau virtuel sur plusieurs hôtes Proxmox VE sans configuration VLAN côté switch. Chaque VNet VXLAN est identifié par un VNI (VXLAN Network Identifier) numérique, défini comme tag au niveau du VNet. La zone VXLAN supporte environ 16 millions de VNI, bien au-delà des 4 094 tags disponibles en VLAN 802.1Q.
L'encapsulation VXLAN ajoute 50 octets d'en-tête à chaque paquet, ce qui réduit la bande passante utile. Si le MTU physique du réseau est de 1 500, configurez le MTU de la zone VXLAN à 1 450 pour éviter la fragmentation des paquets.
Configuration :
- Dans Datacenter, SDN, Zones, ajoutez une zone de type VXLAN ;
- Renseignez l'identifiant (ex.
vxlanzone) ; - Dans Peers Address List, listez les adresses IP de chaque hôte du cluster (séparées par des virgules) ;
- Définissez le MTU à
1450; - Validez et appliquez ;
- Créez un VNet (ex.
vnet-jeux) avec un tag VNI unique (ex.10000) ; - Ajoutez un sous-réseau et appliquez.
Les machines virtuelles assignées au VNet vnet-jeux communiquent entre elles quel que soit l'hôte physique sur lequel elles s'exécutent. La migration à chaud des VMs entre noeuds conserve la connectivité réseau sans reconfiguration, ce qui simplifie la gestion pour les administrateurs de clusters.
Connecter les VMs et conteneurs LXC aux VNets
Une fois les VNets créés et la configuration appliquée, chaque VNet apparaît comme un pont Linux dans la liste des interfaces réseau disponibles lors de la création ou modification d'une machine virtuelle ou d'un conteneur LXC.
Pour une VM (KVM/QEMU) :
- Éditez la VM, onglet Hardware, puis Network Device ;
- Dans le champ Bridge, sélectionnez le VNet souhaité (ex.
vnet-prod) ; - Le modèle de carte réseau virtuelle par défaut est VirtIO (recommandé pour les meilleures performances) ;
- Configurez l'adresse IP à l'intérieur de la VM (statique ou DHCP si dnsmasq est configuré sur l'hôte).
Pour un conteneur LXC :
- Éditez le conteneur, onglet Network ;
- Sélectionnez le VNet comme pont dans le champ Bridge ;
- Renseignez l'adresse IP statique directement dans la configuration du conteneur LXC.
Chaque machine virtuelle ou conteneur ne voit que le trafic de son propre VNet. Pour permettre la communication entre deux VNets différents, vous devez configurer un routeur virtuel (une VM pfSense, OPNsense ou un routeur logiciel sous Debian) connecté aux deux VNets. Cette séparation par défaut est le principe fondamental de l'isolation SDN.
Firewall et SDN : filtrer le trafic par VNet
Le SDN de Proxmox VE s'intègre avec le firewall intégré de l'hyperviseur. Lorsque vous créez des VNets et des sous-réseaux, Proxmox génère automatiquement des IPSets correspondant aux plages IP de chaque VNet. Ces IPSets sont utilisables dans les règles firewall au niveau du datacenter, de l'hôte ou de la machine virtuelle.
Configurations typiques du firewall avec le SDN :
- Bloquer le trafic inter-VNets : par défaut, les VNets sont isolés. Le firewall renforce cette isolation en filtrant les connexions au niveau TCP/IP, même si un routeur logiciel est présent entre les VNets ;
- Autoriser des protocoles spécifiques : ouvrir uniquement les ports nécessaires (SSH sur le port 22, HTTP/HTTPS sur les ports 80 et 443, DNS sur le port 53, protocoles de jeu sur leurs ports dédiés) ;
- Limiter l'accès à Internet : autoriser le SNAT sortant uniquement pour les VNets qui en ont besoin, bloquer les connexions sortantes sur les VNets de production internes ;
- Protéger l'accès d'administration : restreindre les connexions SSH et l'accès à l'interface web (port 8006) à un VNet d'administration dédié, avec authentification par clé SSH et certificat TLS.
Les règles firewall se configurent dans Datacenter, Firewall pour les règles globales, ou au niveau de chaque machine virtuelle pour des règles spécifiques. Combiner le firewall Proxmox avec le SDN offre une défense en profondeur sans installer de pare-feu supplémentaire dans chaque VM.
Cas d'usage : séparer prod, dev, DMZ et serveurs de jeu
Sur un serveur dédié dimensionné pour la virtualisation, le SDN permet de reproduire une architecture réseau d'entreprise avec un seul serveur physique, sans ordinateurs ni périphériques réseau supplémentaires.
Séparer production, développement et DMZ
Créez trois VNets dans une zone VLAN ou Simple :
| VNet | Tag VLAN | Sous-réseau | Usage |
|---|---|---|---|
vnet-prod | 100 | 192.168.100.0/24 | Applications en production, bases de données |
vnet-dev | 200 | 192.168.200.0/24 | Environnement de test et développement |
vnet-dmz | 300 | 10.10.30.0/24 | Serveur web (Apache, Nginx), reverse proxy, FTP |
Un pare-feu virtuel (pfSense ou OPNsense) connecté aux trois VNets filtre le trafic inter-zones : la DMZ accède à Internet pour servir les requêtes web et les noms de domaine, le réseau de production n'est joignable que depuis la DMZ sur les ports nécessaires, et le réseau de développement reste totalement isolé. Un serveur DNS interne dans le VNet de production résout les noms des machines virtuelles sans exposer le DNS sur Internet.
Isoler des serveurs de jeu entre eux
Si vous hébergez plusieurs serveurs de jeu sur le même serveur dédié (FiveM, Minecraft, Rust), le SDN empêche un serveur compromis ou mal configuré d'interférer avec les autres :
- Un VNet par serveur de jeu ou par client locataire ;
- Chaque VNet a son propre sous-réseau avec SNAT activé pour l'accès sortant (mises à jour, connexions aux API) ;
- Les ports de jeu sont redirigés individuellement depuis l'IP publique du serveur dédié via des règles NAT ;
- Aucune communication directe entre les VNets : un joueur malveillant sur un serveur ne peut pas scanner les autres.
Réseau d'administration et backup isolé
Créez un VNet dédié à l'administration et aux sauvegardes. Les connexions SSH des administrateurs passent par ce VNet, isolé du trafic de production. Ce réseau transporte aussi les flux de backup entre les machines virtuelles et le serveur de sauvegarde, sans consommer la bande passante du réseau de production. Configurez l'authentification SSH par clé publique et désactivez le mot de passe root pour sécuriser l'accès distant à chaque VM via ce réseau d'administration.
VPN site-à-site entre serveurs dédiés
Combinez le SDN avec un tunnel VPN (WireGuard ou IPsec) pour relier les réseaux virtuels de deux serveurs dédiés distants. Le VPN chiffre les connexions entre les hôtes, et le SDN isole les flux métier de chaque côté. Cette architecture convient aux infrastructures réparties sur plusieurs datacenters.
Tableau comparatif des types de zones SDN
| Type de zone | Portée | Prérequis réseau | Cas d'usage principal |
|---|---|---|---|
| Simple | Locale (un seul hôte) | Aucun | Isolation rapide sur un serveur dédié mono-noeud |
| VLAN | Tous les hôtes du cluster | Switch 802.1Q, trunk configuré sur la carte réseau | Segmentation classique, compatible infrastructure existante |
| QinQ | Tous les hôtes du cluster | Switch compatible 802.1ad | Fournisseur de services, VLAN empilés client par client |
| VXLAN | Tous les hôtes avec connectivité IP | Connectivité IP entre noeuds, MTU 1 450 | Overlay multi-noeuds sans configuration switch |
| EVPN | Multi-clusters | FRRouting, BGP | Routage L3 entre sites, architecture avancée |
Pour un serveur dédié mono-noeud, la zone Simple couvre la majorité des besoins d'isolation. La zone VLAN s'impose dès que le serveur est connecté à un switch géré en datacenter. La zone VXLAN est le choix naturel pour les clusters multi-noeuds sans infrastructure VLAN partagée.
SDN Proxmox vs VMware vSwitch et Hyper-V
Les administrateurs qui migrent depuis VMware ESXi ou Microsoft Hyper-V retrouvent des concepts similaires dans le SDN Proxmox, mais avec une implémentation open source basée sur Debian :
| Fonctionnalité | Proxmox VE SDN | VMware vDS (ESXi) | Hyper-V Virtual Switch |
|---|---|---|---|
| Type de switch virtuel | Pont Linux / OVS | vSwitch / vDS | Extensible Virtual Switch |
| Isolation VLAN | Zone VLAN (802.1Q) | Port Group + VLAN ID | VLAN ID par port |
| Overlay réseau | VXLAN natif | NSX-T (licence séparée) | NVGRE / VXLAN (SDN v2) |
| Firewall intégré | nftables + IPSets SDN | DFW (NSX-T requis) | Windows Firewall / NPS |
| Licence | Open source (AGPL v3) | Payante (vSphere + NSX) | Incluse avec Windows Server |
| Système hôte | Debian Linux | ESXi (propriétaire) | Windows Server |
Le SDN de Proxmox VE offre une segmentation réseau comparable à VMware NSX ou Hyper-V SDN, sans coût de licence supplémentaire. Les administrateurs familiers avec la ligne de commande Linux (SSH, apt, ip) retrouveront un environnement familier sous Debian.
Appliquer et vérifier la configuration SDN
Après chaque modification dans l'interface SDN, les changements restent en attente (pending) jusqu'à ce que vous cliquiez sur Apply dans Datacenter, SDN. Cette étape écrit les configurations dans /etc/pve/sdn/ et génère les ponts Linux correspondants sur chaque hôte concerné.
Vérifiez que les ponts ont été créés correctement. Connectez-vous en SSH à l'hôte Proxmox en tant que root :
ip link show type bridgeChaque VNet apparaît comme un pont (ex. vnet-prod). Testez la connectivité entre deux machines virtuelles du même VNet avec ping :
ping -c 4 10.10.10.2Vérifiez ensuite qu'une VM d'un VNet ne peut pas joindre une machine virtuelle d'un autre VNet. Si la connexion aboutit alors qu'elle ne devrait pas, vérifiez que les VNets sont bien dans des zones séparées ou que le firewall bloque les connexions inter-VNets.
Pour surveiller la bande passante et les connexions réseau par VNet, consultez notre guide Grafana et Prometheus sur Linux. Pour maintenir votre installation Proxmox VE à jour et sécurisée, suivez notre guide sécuriser un serveur dédié : premiers réglages. Pour automatiser le déploiement de services dans vos VMs et conteneurs, consultez les Proxmox VE Helper Scripts.
Conclusion
Le SDN de Proxmox VE transforme un serveur dédié en une infrastructure réseau segmentée sans matériel supplémentaire ni routeurs physiques. Les zones Simple, VLAN et VXLAN couvrent les besoins d'isolation de la plupart des architectures, du serveur mono-noeud au cluster multi-sites. En séparant vos environnements de production, de développement, vos serveurs de jeu et votre réseau de backup dans des VNets distincts, vous limitez la surface d'attaque et simplifiez la gestion réseau depuis l'interface web Proxmox VE.
Pour choisir la bonne plateforme de virtualisation selon votre usage, consultez notre comparatif Proxmox VE vs OpenStack.
FiveM
Minecraft
Rust
RedM
Hytale