2. VLAN et NAT : segmenter et faire sortir
Un bridge par réseau physique ne suffit vite plus : on veut séparer plusieurs réseaux sur le même câble, et faire sortir sur Internet des machines placées sur un réseau privé. Ce sont les deux outils de cette section : le VLAN et le NAT.
2.1 VLAN — segmenter sans multiplier les câbles
Un VLAN permet de segmenter un réseau physique en plusieurs réseaux logiques. Chaque VLAN est identifié par un ID numérique, de 1 à 4094. Deux notions structurent tout le sujet :
Le VLAN natif (non tagué) correspond au trafic envoyé sans balise 802.1Q — c'est souvent le VLAN par défaut d'un port. Le VLAN tagué encapsule le trafic avec un identifiant VLAN explicite ; cela nécessite que le switch et l'OS le prennent en charge.
Prenons un exemple concret avec un switch configuré ainsi :
| Port | Type de VLAN | ID VLAN | Utilisation |
|---|---|---|---|
| 1 | Natif (untagged) | 1 | Administration |
| 2 | Tagged | 10, 20 | VM réseau privé, stockage |
Le port 1 reçoit du trafic non tagué (VLAN 1). Le port 2 transporte plusieurs VLANs identifiés par des balises (10, 20) — la machine connectée doit donc gérer le trunk 802.1Q.
Chaque bridge de Proxmox peut transporter un ou plusieurs VLANs, et les VMs peuvent être attachées à un bridge avec un VLAN ID explicite. La configuration côté hyperviseur doit toujours correspondre à celle du switch physique.
Pourquoi éviter le VLAN 1 comme VLAN natif : le VLAN 1 est activé par défaut sur presque tous les switchs. Il sert à la gestion, aux protocoles de découverte et à tout trafic non tagué.
Le laisser actif peut entraîner des fuites réseau involontaires ou un accès non souhaité. Choisir un VLAN natif explicite (par exemple VLAN 10 ou 100) rend l'architecture plus claire et plus sécurisée.
Pour que Proxmox comprenne ces tags, le bridge doit être déclaré VLAN-aware.
Via l'interface graphique :
Nœud → Network → vmbr0 → Edit → cocher VLAN aware → OK → Apply Configuration
Une fois le bridge VLAN-aware, assigner un VLAN à une VM ou un conteneur est immédiat : VM → Hardware → Network Device → Edit → VLAN Tag = 10 (remplacer 10 par l'ID voulu).
En CLI, c'est l'option bridge-vlan-aware yes accompagnée de bridge-vids 2-4094 qui autorise tous les tags VLAN possibles dans /etc/network/interfaces :
# Bridge vmbr0 rendu VLAN-aware (modif dans /etc/network/interfaces)
auto vmbr0
iface vmbr0 inet static
address <ip-de-votre-noeud>/24
gateway <ip-de-la-passerelle>
bridge-ports ens18
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes # Active la compréhension des tags VLAN
bridge-vids 2-4094 # Autorise tous les VLANs de 2 à 4094
Revenons à la définition de base : un réseau local est l'ensemble des machines qui reçoivent les diffusions (broadcast) les unes des autres. Un VLAN découpe un même réseau physique en plusieurs de ces réseaux.
| Terme | Ce que c'est | Dans le laboratoire |
|---|---|---|
| VLAN | Un réseau logique, isolé des autres sur le même câble | L'exemple du cours : VLAN 10 |
| ID de VLAN | Un numéro de 1 à 4094 | 10 |
| Étiquette 802.1Q (tag) | Quatre octets ajoutés à la trame, qui portent l'ID | Invisible pour la VM |
| Trunk (port tagué) | Un lien qui transporte plusieurs VLAN, étiquetés | Le port du switch physique relié au nœud |
| Port access | Un port d'un seul VLAN : l'étiquette est retirée avant la livraison | La carte d'une VM avec VLAN Tag = 10 |
| VLAN natif | Le trafic non étiqueté d'un port | VLAN 1 par défaut sur la plupart des switchs |
Pont vlan-aware |
Un pont qui pose, lit et retire les étiquettes | vmbr0 après VLAN aware coché |
Un même lien trunk transporte tous les VLAN, et chaque invité ne reçoit que le trafic de son VLAN. La VM ne voit jamais l'étiquette : le pont la pose en sortie et la retire en entrée (§2.2).
Où voir un VLAN sur un nœud :
| Notion | Où la voir |
|---|---|
Le pont vlan-aware |
Nœud → System → Network → vmbr0 → Edit : case VLAN aware ; dans /etc/network/interfaces : bridge-vlan-aware yes et bridge-vids 2-4094 |
| Le VLAN d'une VM | La VM → Hardware → Network Device : champ VLAN Tag ; dans sa configuration : net0: virtio=…,bridge=vmbr0,tag=10 |
| Les VLAN autorisés sur chaque port du pont | bridge vlan show dans le Shell du nœud |
2.2 Comprendre le flux d'une trame taguée
Un bridge Linux configuré vlan-aware fonctionne comme un switch manageable. Il comprend les VLANs tagués et peut filtrer par VLAN. Il peut aussi tagger ou détagger les paquets selon les paramètres du port.
Flux entrant — du physique vers la VM. Un paquet arrive sur l'interface physique (ens18).
Si le bridge est configuré pour accepter le VLAN correspondant (VLAN 10 par exemple), il laisse passer ce paquet. Le bridge examine ensuite le port virtuel associé à la VM (tapX).
Si ce port est en mode access pour le VLAN 10, le bridge détague le paquet et le livre nu à la VM. S'il est en mode trunk, le tag est conservé et le paquet est remis à la VM avec son tag.
Flux sortant — de la VM vers l'extérieur. Quand une VM envoie un paquet, le bridge le reçoit via son interface tapX.
Si le port est en mode access avec PVID (Port VLAN ID, le VLAN par défaut du port) 10, l'interface tague elle-même le paquet en VLAN 10. C'est la configuration matérielle de la VM dans Proxmox. Le paquet part ensuite vers l'interface physique avec ce tag.
Si le port est en trunk, le bridge n'ajoute aucun tag — il attend que la VM ait déjà tagué le paquet elle-même.
Les trois trajets d'une trame du VLAN 10. En entrée, le pont retire l'étiquette avant de livrer la VM ; en sortie, le port de la VM (« VLAN Tag = 10 ») l'ajoute. La VM ne voit donc jamais l'étiquette.
Le troisième trajet, en trunk, montre le cas rare où la VM tague elle-même. Cliquez sur un trajet pour le détail.
En pratique : il est très rare de configurer un port de VM en mode trunk pour un seul VLAN. On préfère gérer le tag directement via les paramètres réseau de la VM (VLAN Tag = 10) — c'est la méthode utilisée dans ce chapitre et dans les ateliers.
2.3 NAT — faire sortir un réseau privé sur Internet
Le NAT (Network Address Translation) permet de faire transiter des paquets IP d'un réseau privé vers un réseau public en modifiant l'adresse IP source ou destination. C'est ce qui permet à plusieurs machines privées (192.168.x.x) d'accéder à Internet avec une seule adresse IP publique. Trois variantes structurent le sujet :
Le Source NAT (SNAT : Source Network Address Translation) modifie l'adresse IP source des paquets sortants — c'est ce qui fait sortir un réseau privé sur Internet avec une IP publique unique. Exemple : 192.168.1.100 devient 203.0.113.1 pour Internet.
Le Destination NAT (DNAT : Destination Network Address Translation) modifie l'adresse IP de destination des paquets entrants. Il sert à rediriger des ports vers des machines internes, par exemple pour un hébergement web en DMZ (Demilitarized Zone, réseau exposé isolé du réseau interne). Exemple : 203.0.113.1:80 redirige vers 192.168.1.10:80.
Le PAT (Port Address Translation), aussi appelé NAT overload, est une extension de SNAT ou DNAT qui ajoute la modification des ports pour permettre plusieurs connexions sur une même IP. En sortie, le PAT est généralement transparent : c'est le mécanisme qui permet au firewall d'ouvrir un port dynamique pour savoir vers qui rediriger une réponse — donc du SNAT + PAT.
En entrée, on ouvre un port fixe et non utilisé pour exposer un service en continu (SSH, reverse proxy sur 443) — donc du DNAT + PAT.
| Terme | Traduit | Fonction principale |
|---|---|---|
| NAT | Traduction d'adresse | Concept global de substitution IP |
| SNAT | Source NAT | Modifier l'IP source en sortie |
| DNAT | Destination NAT | Modifier l'IP de destination en entrée |
| PAT | Traduction de ports | Multiplexer plusieurs machines via une IP |
2.4 Mettre en place le NAT pour des VMs isolées
Un cas pratique fréquent : un bridge interne sans accès direct à Internet (vmbr9, sans interface physique attachée). Ses VMs doivent malgré tout pouvoir sortir vers Internet pour leurs mises à jour. Le bridge devient alors la passerelle de ce réseau interne, et l'hôte fait le NAT vers l'extérieur.
La méthode que recommande Proxmox attache le routage et la règle NAT au pont lui-même, dans /etc/network/interfaces. Ils naissent quand le pont monte et disparaissent quand il descend, sans service supplémentaire à installer.
# /etc/network/interfaces — pont interne 10.0.0.0/24, NATé derrière vmbr0
auto vmbr9
iface vmbr9 inet static
address 10.0.0.1/24 # le nœud est la passerelle de ce réseau
bridge-ports none # aucune carte physique : réseau interne
bridge-stp off
bridge-fd 0
# Routage activé, puis traduction d'adresse des paquets qui sortent par vmbr0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE
Dans le Shell du nœud (interface web → votre nœud → Shell) :
# Appliquer sans redémarrer, puis vérifier que la règle est posée
ifreload -a
iptables -t nat -S POSTROUTING # la règle MASQUERADE doit apparaître
La règle se lit de gauche à droite. Table nat, chaîne POSTROUTING : juste avant que le paquet quitte le nœud.
Tout paquet venant de 10.0.0.0/24 (-s) et sortant par vmbr0 (-o) prend l'adresse de vmbr0 (MASQUERADE). Le -s compte : sans lui, la règle traduirait aussi le trafic du nœud lui-même.
Le trajet d'un paquet qui quitte une VM du pont interne vmbr9. La VM l'envoie à sa passerelle (le nœud, 10.0.0.1), et le nœud le route.
Puis la règle MASQUERADE remplace l'adresse source par celle de vmbr0, juste avant la sortie. Cliquez sur une étape pour la commande qui la met en place.
Deux méthodes répandues à éviter sur Proxmox. Écrire net.ipv4.ip_forward=1 dans /etc/sysctl.conf ne tient plus sur Debian 13 : ce fichier n'est plus relu au démarrage, il faut un fichier dans /etc/sysctl.d/ — d'où l'intérêt de la ligne post-up. Et le paquet iptables-persistent recharge au démarrage un jeu de règles figé, qui entre en concurrence avec celles que le pare-feu Proxmox (pve-firewall) réécrit lui-même : les deux se marchent dessus.
Résultat attendu de iptables -t nat -S POSTROUTING : une ligne -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE. Le test se fait ensuite depuis une VM branchée sur vmbr9, d'adresse 10.0.0.x/24 et de passerelle 10.0.0.1 : elle doit joindre une machine extérieure au pont.
Le NAT MASQUERADE traduit silencieusement l'adresse interne de la VM en adresse de l'hôte au moment où le paquet sort par vmbr0. La VM n'a aucune adresse routable, et pourtant elle atteint internet — c'est tout l'objet de la manœuvre.
Sur le lab, ce test dépend du routage en place autour de vous. Le mécanisme décrit ici est celui du NAT, et il fonctionne : la VM sort bien par vmbr0 avec l'adresse de l'hôte. Mais si le réseau de la salle ne route pas lui-même vers internet, le ping échouera un cran plus loin, sans que la configuration soit en cause.
Pour vérifier que le NAT fait son travail, visez une machine du réseau de la salle plutôt qu'une adresse publique. Observez iptables -t nat -L POSTROUTING -v : le compteur de la règle MASQUERADE s'incrémente à chaque paquet traduit.
- 📖 Documentation Proxmox — Network Configuration
- 📖 Configuration réseau avancée sous Proxmox — Documentation Resinfo
À retenir : un VLAN découpe un même réseau physique en réseaux logiques par une étiquette 802.1Q ; un pont vlan-aware pose ou retire l'étiquette selon le tag de chaque carte. Le NAT (SNAT / masquerade) fait sortir un réseau privé sous l'adresse du nœud ; sur Proxmox, on l'attache au pont dans /etc/network/interfaces (post-up).
▶ À pratiquer maintenant — Atelier 2
Le pont vmbr9 de l'atelier 1 au travail : VLAN-aware, il sépare deux conteneurs selon leur VLAN ; passerelle NATée, il fait sortir un réseau privé sous l'adresse du nœud. Sans jamais toucher à vmbr0.
Proxmox VE — TSSR