WireGuard in LXC of een VM op Proxmox: waar moet het draaien?

WireGuard heeft precies één kernel nodig die zijn interface bezit, en dat feit beslecht het grootste deel van de Proxmox-plaatsingsdiscussie voordat prestaties überhaupt ter sprake komen. Een LXC-container is een naamsruimtebeeld van de hostkernel, terwijl een VM zijn eigen kernel boot. De nuttige vraag is dus niet welke optie lichter is, maar welke kernel je bereid bent te wijzigen en met welk herstelpad je kunt leven. Beantwoord dat, en de keuze tussen host, container of VM maakt zich meestal vanzelf.

Een LXC-gast werkt binnen de hostkernel

Door wireguard-tools in een container te installeren krijg je het besturingsprogramma, geen eigen kernel. De interface wg0 die je aanmaakt, wordt in de netwerkstack van de host geregistreerd en verschijnt in de modulelijst van de host. Daarom kan een container elke pakketcontrole doorstaan en toch bij het eerste wg-commando falen wanneer de hostkernel de module mist. En de Proxmox-containerreferentie documenteert dat gedeelde-kernelsmodel samen met de naamsruimte- en bevoegdheidsgrenzen waarbinnen je werkt.

Bevoegdheid is de tweede beperking. Een interface opheffen en er adressen aan koppelen vereist netwerkbeheerrechten binnen de naamsruimte die hem bezit, en een niet-geprivilegieerde container beeldt die rechten af via zijn gebruikersnaamsruimte in plaats van ze rechtstreeks te houden. Grijp nooit naar volledige bevoegdheid als eerste antwoord; kijk wat er feitelijk van de container wordt gevraagd en geef dat dan.

De hostkernel is ook een gedeelde afhankelijkheid. Een Proxmox-kernelupdate verandert de WireGuard-implementatie onder elke container tegelijk, wat handig is tot een update en de verwachtingen van een container niet meer overeenkomen.

Host, container, VM: wat elke plaatsing werkelijk bezit

Plaatsing op de host zet de VPN in het eigen netwerk van de hypervisor. Routes, firewallregels en de tunnel worden onderdeel van hostherstel, en een fout daar kan de beheerinterface meenemen. Dat is aanvaardbaar voor infrastructuurroutering op een host die je via een console bereikt, en pijnlijk op een externe machine zonder toegang buiten de band.

Een container houdt de dienst verpakt en herstartbaar terwijl hij nog steeds de hostkernel leent. Hij past bij een bewust gedeelde-kerneldienst en geeft je een kleine eenheid om opnieuw op te bouwen. Hij geeft je geen onafhankelijke kernel, dus alles wat een specifieke modulebuild nodig heeft, wijst weg van deze optie.

Een VM kost meer geheugen en nog een systeem om te patchen, en in ruil krijgt de tunnel zijn eigen kernel, zijn eigen routingtabel en een snapshotgrens. Wanneer de VPN het ding is dat je na een slechte wijziging terugdraait, is die snapshot de overhead waard.

Drie voorwaarden die voor jou kiezen

Als de tunnel een kernelversie of WireGuard-functie nodig heeft die de Proxmox-host niet levert, stop hier en gebruik een VM. Je kunt geen nieuwere kernel in een container installeren, en je zou de hypervisorkernel niet moeten vervangen om één gast tevreden te stellen.

Als de tunnel de gateway van de site is voor echte LAN-prefixen, vraag dan wie de retourroute al bezit. Een container kan verkeer routeren, maar zijn interfaces zitten in de stack van de host, dus de host draagt uiteindelijk een deel van de configuratie, of je dat nu had gepland of niet. Plaatsing op de host is daar eerlijk over; plaatsing in een container vaak niet.

Weeg dan de impactradius van een fout. Een container herstarten is goedkoop, een VM-snapshot terugzetten is voorspelbaar, en het repareren van hostnetwerken kan fysieke of consoletoegang vereisen. De juiste keuze is degene waarvan je het slechtste geval echt kunt herstellen op het uur dat het gebeurt.

Een vierde vraag is zelden beslissend maar wel het vermelden waard: moet iets anders op de host de tunnelinterface kunnen zien? Zo ja, dan houdt plaatsing op de host of in een container die zichtbaarheid lokaal, terwijl een VM je dwingt tussen gast en host te routeren.

Bewijs de plaatsing voordat je er verkeer doorheen stuurt

Controleer na installatie welke kernel de interface daadwerkelijk bedient en of de container genoeg bevoegdheid heeft gekregen om hem te behouden:

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

Controleer daarna de doorstuurzijde vanaf de host, want een handshake alleen bewijst enkel dat de tunnel staat. Gebruik ip route get voor een clientadres en bevestig dat de volgende hop en de interface bij het ontwerp passen, en dat het retourpad aan de andere kant bestaat.

Laat de uitrol achter met een schriftelijke eigenaar: welke kernel de implementatie draagt, welke naamsruimte de interface houdt en welke prefixen de gateway mag doorsturen. Die zin voorkomt meer incidenten dan welke benchmarkvergelijking van de drie plaatsingen dan ook.