Proxmox VE-netwerken uitgelegd: bridges, bonds en VLAN's

Eerst het antwoord: het ene mentale model

Proxmox VE-netwerken is Linux-netwerken, opgebouwd rond één idee: virtuele machines en containers koppelen hun virtuele NIC's aan softwareswitches die Linux-bridges heten. De standaardbridge, vmbr0, wordt bij de installatie aangemaakt met je fysieke NIC eraan gekoppeld; dat is de enige reden waarom je eerste VM het internet kon bereiken.

Elke praktijkopstelling is een variatie op waar die bridges op aansluiten:

• Bridged: de VM zit rechtstreeks op het fysieke netwerk met een eigen publiek IP en MAC. Het eenvoudigst, maar bij een hostingprovider zijn hiervoor door de provider goedgekeurde extra IP's/MAC's nodig.
• Routed: de host bezit de publieke adressen en routeert verkeer naar VM's. Werkt overal, geen MAC-beperkingen, iets meer configuratie.
• NAT / privé: VM's leven op een privébridge en delen uitgaand het IP van de host. Geschikt voor VM's die niet publiek bereikbaar hoeven te zijn.

De configuratie staat in één leesbaar bestand, /etc/network/interfaces, en omdat Proxmox ifupdown2 gebruikt, worden wijzigingen live toegepast met ifreload -a (of de "Apply Configuration"-knop in de GUI), zonder herstarten. Dit artikel gaat uit van een werkende installatie; ben je daar nog niet, begin dan met onze Proxmox VE-installatiegids, die kort vmbr0 introduceert; dit is de beloofde verdieping. De adressen hieronder zijn documentatiebereiken (203.0.113.0/24, 10.0.0.0/24); vervang ze door je eigen adressen.

Anatomie van vmbr0

Bij een verse installatie ziet /etc/network/interfaces er in de kern zo uit:

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Lees het van onder naar boven en het model valt op zijn plek: de fysieke NIC (enp1s0) draagt zelf geen IP; het is puur een bridgepoort. De bridge bezit het IP-adres van de host en de uplink. VM's koppelen hun virtuele NIC's (tap-apparaten) aan diezelfde bridge, waardoor die een unmanaged switch wordt met de fysieke NIC als uplinkpoort. Al het andere in dit artikel komt neer op meer bridges toevoegen, er verkeer op taggen, of veranderen wat ze voedt.

De drie patronen op een gehoste server

Op je eigen switch thuis werkt bridged networking gewoon. Op een dedicated server bij een provider is er een beperking waarmee je rekening moet houden: datacenter-accessswitches passen doorgaans MAC-filtering toe; verkeer van MAC-adressen die de provider niet op jouw poort verwacht, wordt gedropt. Dat ene gegeven bepaalt welk patroon past:

Bridged: VM's met een eigen publiek IP

Elke VM krijgt een publiek IP en de virtuele MAC ervan verschijnt op de switch van de provider. Dit vereist extra IP's die door de provider aan je server zijn toegewezen, waarbij de MAC van de VM wordt geregistreerd waar de provider dat vereist (sommige providers wijzen een MAC per IP toe, andere accepteren elke MAC op je poort voor routed subnets). Waar dit wordt ondersteund (zoals op ons netwerk, waar extra IP-ruimte standaard bij de server komt), is dit de schoonste opzet: de VM-configuratie is simpelweg "koppel aan vmbr0, stel het toegewezen IP in en dezelfde gateway als de host".

Routed: werkt onder elk MAC-beleid

Alleen het MAC-adres van de host verschijnt ooit op de lijn; de host routeert voor zijn VM's. Schets. Publiek subnet 203.0.113.64/26 gerouteerd naar je server:

auto vmbr1
iface vmbr1 inet static
    address 203.0.113.65/26
    bridge-ports none
    bridge-stp off
    bridge-fd 0

bridge-ports none is de truc die het waard is om je eigen te maken: een bridge zonder fysieke poort is een puur interne switch. VM's op vmbr1 gebruiken 203.0.113.65 als gateway; de host forwardt tussen vmbr1 en de uplink (schakel net.ipv4.ip_forward in via /etc/sysctl.d/). De switch van de provider ziet nooit meer dan de host.

NAT: privé-VM's die naar buiten kunnen

Dezelfde poortloze bridge met een privébereik (10.0.0.1/24 op de bridge), plus een masquerade-regel zodat VM's het publieke IP van de host delen voor uitgaand verkeer. Geschikt voor build-VM's, databases die alleen andere VM's bedienen, en labgasten. Inkomende toegang, waar nodig, is port forwarding (DNAT) op de host; forward je veel, overweeg dan of de VM niet gewoon een routed publiek IP wil.

Vrij te combineren: een typische host draait vmbr0 (publiek, bridged) plus een privébridge voor backendverkeer tussen guests.

VLAN's: één bridge, veel netwerken

Het moderne patroon is de VLAN-aware bridge, één vlag op vmbr0:

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Nu laat de bridge getagd verkeer door, en stel je de VLAN Tag per virtuele NIC in bij de hardware-opties van de VM; de bridge regelt het taggen/untaggen, guests merken er niets van. Vergeleken met de oudere stijl met één bridge per VLAN (vmbr0v40 en soortgenoten) is dit één bridge in plaats van een stuk of tien, en geen hostconfiguratie-wijziging nodig wanneer je een nieuwe VLAN introduceert: wijs een nieuwe tag toe en klaar. Guests die trunks nodig hebben (een firewall-VM, bijvoorbeeld) kunnen ook rechtstreeks getagd verkeer ontvangen.

Waar VLAN's een hostingprovider raken: ze segmenteren verkeer alleen waar de infrastructuur de tags doorgeeft. Binnen je eigen host altijd; tussen je servers alleen wanneer het privénetwerk van de provider ze behoudt (bij ons is dat zo; VLAN's over het privé-LAN zijn hoe klanten multi-host gesegmenteerde netwerken bouwen; het is ook het mechanisme achter DMZ's van klanten).

Bonding: twee NIC's, één logische uplink

Bonds bundelen fysieke NIC's voor redundantie (en soms bandbreedte). De bond wordt de poort van de bridge:

auto bond0
iface bond0 inet manual
    bond-slaves enp1s0 enp2s0
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports bond0
    ...

De modekeuze is eenvoudiger dan de zeven opties doen vermoeden, en de officiële documentatie is duidelijk: gebruik 802.3ad (LACP) als je switch dat ondersteunt; gebruik anders active-backup. LACP vereist bijpassende configuratie op de switch van de provider (bij een dedicated server betekent dat: iets om met je host te regelen, niet iets wat je lokaal even aanzet); active-backup werkt met elke switch en levert puur failover. Merk op dat een enkele TCP-flow onder LACP nooit sneller gaat dan één fysieke link; bonding vermenigvuldigt de totale bandbreedte, niet die per flow. En cluster je later: corosync heeft een hekel aan sommige bondmodi; geef clusterverkeer een eigen ongebonden NIC of active-backup.

Waar de SDN-laag past

Alles hierboven configureert één host. De SDN-functie van Proxmox (volledig ondersteunde kernfunctie sinds 8.1, te configureren onder Datacenter → SDN) past netwerkdefinities clusterbreed toe: definieer een zone en de bijbehorende VNets eenmalig, en elke node biedt ze consistent aan. Zonetypes lopen op in ambitie:

• Simple: geïsoleerde bridges per node met optionele, door het cluster beheerde IPAM/DHCP; de beheerde versie van bridge-ports none.
• VLAN: de VLAN-opzet hierboven, eenmalig gedefinieerd voor het hele cluster.
• QinQ: gestapelde VLAN-tags, voor wanneer je VLAN's aan tenants uitgeeft.
• VXLAN: laag-2-netwerken getunneld over willekeurige laag-3-connectiviteit tussen nodes; het standaardantwoord op "één privénetwerk dat servers overspant die geen switch delen". Let op de MTU: VXLAN kost 50 bytes overhead, dus verhoog de MTU van de underlay of verlaag die van het VNet.
• EVPN: VXLAN plus een op BGP gebaseerd control plane en distributed routing; het domein van datacenter-fabrics.

Vuistregel: één host of een handvol statische bridges → gewoon /etc/network/interfaces, dit artikel. Cluster met meer dan een paar gedeelde netwerken, of enige vorm van tenancy → definieer ze eenmalig in SDN. (PVE 9 voegde "fabrics" toe, automatisch geconfigureerde routed underlays, een teken van waar deze laag naartoe gaat.)

Jezelf niet buitensluiten

Elk horrorverhaal over Proxmox-netwerken is hetzelfde verhaal: een bridgewijziging toegepast op de interface die de SSH-sessie draagt. De discipline zit hem in:

• Live en atomair toepassen. Bewerk /etc/network/interfaces, dan ifreload -a (ifupdown2 past het verschil live toe). De pending-changes-plus-"Apply Configuration"-flow van de GUI doet hetzelfde, met een controlestap erbij.
• Zorg dat je de console hebt vóór je hem nodig hebt. IPMI/KVM-over-IP-toegang (inbegrepen bij onze servers) maakt van "ik heb mijn uplink weg-bridged" een storing van twee minuten aan de console in plaats van een uitval. Controleer je toegang voordat je gaat bewerken.
• Verander één laag tegelijk. Eerst de bond, controleren; dan de bridge op de bond; dan de VLAN's. Samengestelde wijzigingen leveren samengestelde faalpatronen op.
• Firewall de host niet per ongeluk dicht. Proxmox heeft een eigen firewall (niveaus datacenter → node → VM). Wanneer je die inschakelt, controleer dan eerst de beheerregels (SSH, 8006) voordat je toepast op nodeniveau. Dezelfde lockout-logica als in onze gids voor firewall-basisregels, een laag hoger.

Veelgestelde vragen

Moet ik Linux-bridges of Open vSwitch gebruiken?

Linux-bridges, tenzij je met een specifieke OVS-eis binnenkomt. Het is Proxmox' standaardpad en het best gedocumenteerd, de VLAN-aware-vlag dekt de segmentatiegevallen waarvoor vroeger OVS werd gebruikt, en de hele SDN-laag is gebouwd op Linux-bridges met ifupdown2. OVS blijft ondersteund voor wie de extra's nodig heeft, maar voor een typische dedicated-server-inzet voegt het complexiteit toe zonder functionaliteit die je daadwerkelijk zult gebruiken.

Hoe geef ik een VM zijn eigen publieke IP?

Twee manieren. Bridged: koppel de VM aan vmbr0 en configureer een extra IP dat je provider aan je server heeft toegewezen (met inachtneming van hun MAC-beleid; op ons netwerk komen extra IP's standaard bij de server en is dit de gangbare opzet). Routed: houd het MAC-adres richting de provider dat van de host zelf, plaats VM's achter een interne bridge en route het subnet naar hen. Werkt onder elk switchbeleid, ten koste van het feit dat de host het forwarden voor zijn rekening neemt.

Waarom viel het netwerk van mijn VM uit toen ik VLAN-tagging inschakelde?

Bijna altijd een van drie oorzaken: de bridge is niet VLAN-aware (bridge-vlan-aware yes ontbreekt), het fysieke pad draagt de tag niet (de switch van de provider of het privénetwerk moet die VLAN doorlaten), of een MTU-mismatch bij tunneling (de 50 bytes overhead van VXLAN). Debug in die volgorde: eerst de bridge-vlaggen, dan end-to-end tagtransport met tcpdump -e vlan, dan de MTU met een do-not-fragment-ping ter grootte van de limiet.

Is hier een cluster voor nodig?

Nee. Alles tot aan de SDN-sectie is single-host. SDN werkt op zichzelf ook op één node (Simple-zones met beheerde DHCP zijn ook solo echt nuttig), maar de waarde ervan stapelt op met het aantal nodes. Staat clustering op je roadmap, dan is de netwerkbeslissing die je vroeg wilt nemen het reserveren van een NIC (of op zijn minst een VLAN) voor clusterverkeer: corosync wil lage latency en heeft een hekel aan concurrentie met bulkverkeer van VM's; details in onze gids voor cluster en HA.

Uitrollen op Serverside

De patronen in deze gids sluiten rechtstreeks aan op wat een Proxmox dedicated server van ons je biedt: extra publieke IP-ruimte voor bridged VM's, privénetwerken tussen je servers die je VLAN's dragen (de multi-host-segmentatie- en DMZ-patronen hierboven), KVM-over-IP voor angstvrije netwerkwijzigingen, en altijd-actieve DDoS-mitigatie boven op alles, geprovisioned met Proxmox VE vooraf geïnstalleerd in minder dan een minuut op ASN 55285.

Vervolg de serie met hoe je je eerste VM's en containers opzet, LXC vs KVM: wanneer gebruik je wat, en back-upstrategieën met vzdump en PBS.