WireGuard i LXC eller en VM på Proxmox: hvor skal det køre?

WireGuard har brug for præcis én kerne, der ejer sit interface, og den kendsgerning afgør det meste af Proxmox-placeringsdebatten, før ydeevnen overhovedet kommer ind i rummet. En LXC-container er en navnerumsvisning af værtens kerne, mens en VM booter sin egen. Så det nyttige spørgsmål er ikke, hvilken mulighed der er lettest, men hvilken kerne du er villig til at ændre, og hvilken gendannelsesvej du kan leve med. Besvar det, og valget mellem vært, container eller VM træffer sig normalt selv.

En LXC-gæst arbejder inde i værtens kerne

At installere wireguard-tools i en container giver dig kontrolprogrammet, ikke en privat kerne. Det wg0-interface, du opretter, registreres i værtens netværksstak og dukker op på værtens modulliste. Det er derfor, en container kan bestå alle pakkekontroller og alligevel fejle på den første wg-kommando, når værtens kerne mangler modulet. Og Proxmox' containerreference dokumenterer den delte kernemodel sammen med de navnerums- og privilegiegrænser, du arbejder inden for.

Autoritet er den anden begrænsning. At rejse et interface og knytte adresser til det kræver netværksadministrationsrettigheder i det navnerum, der ejer det, og en uprivilegeret container mapper de rettigheder gennem sit brugernavnerum i stedet for at holde dem direkte. Grib aldrig efter fuld privilegium som det første svar; se på, hvad containeren faktisk bliver bedt om, og giv så det.

Værtens kerne er også en delt afhængighed. En Proxmox-kernopdatering ændrer WireGuard-implementeringen under hver container på én gang, hvilket er bekvemt, indtil en opdatering og en containers forventninger er uenige.

Vært, container, VM: hvad hver placering egentlig ejer

Placering på værten sætter VPN'en i hypervisorens eget netværk. Ruter, firewallregler og tunnelen bliver en del af værtens gendannelse, og en fejl der kan tage administrationsinterfacet med sig. Det er acceptabelt til infrastrukturrutning på en vært, du kan nå via en konsol, og smertefuldt på en fjern boks uden adgang uden for båndet.

En container holder tjenesten pakket og genstartbar, mens den stadig låner værtens kerne. Den passer til en bevidst delt-kerne-tjeneste og giver dig en lille enhed at genopbygge. Den giver dig ikke en uafhængig kerne, så alt, der kræver et bestemt modulbyggeri, peger væk fra denne mulighed.

En VM koster mere hukommelse og endnu et system at patche, og til gengæld får tunnelen sin egen kerne, sin egen rutetabel og en snapshotgrænse. Når VPN'en er det, du ruller tilbage efter en dårlig ændring, er det snapshot overkørslen værd.

Tre betingelser, der vælger for dig

Hvis tunnelen har brug for en kerneversion eller en WireGuard-funktion, som Proxmox-værten ikke leverer, så stop her og brug en VM. Du kan ikke installere en nyere kerne i en container, og du bør ikke udskifte hypervisorens kerne for at tilfredsstille én gæst.

Hvis tunnelen er stedets gateway for rigtige LAN-præfikser, så spørg, hvem der allerede ejer returruten. En container kan route trafik, men dens interfaces sidder i værtens stak, så værten ender med at bære en del af konfigurationen, uanset om du planlagde det. Placering på værten er ærlig om det; placering i en container er det ofte ikke.

Vej derefter sprængradiusen af en fejl. Genstart af en container er billig, gendannelse af et VM-snapshot er forudsigelig, og reparation af værtens netværk kan kræve fysisk eller konsoladgang. Det rigtige valg er det, hvis værste tilfælde du faktisk kan gendanne i den time, det sker.

Et fjerde spørgsmål er sjældent afgørende, men værd at nævne: skal noget andet på værten kunne se tunnelinterfacet? Hvis ja, holder placering på værten eller i en container den synlighed lokal, mens en VM tvinger dig til at route mellem gæsten og værten.

Bevis placeringen, før du router trafik gennem den

Når det er installeret, bekræft hvilken kerne der faktisk betjener interfacet, og om containeren har fået nok autoritet til at beholde det:

$ 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

Kontroller derefter videresendelsessiden fra værten, for et håndtryk alene beviser kun, at tunnelen er oppe. Brug ip route get til en klientadresse, og bekræft at næste hop og interface matcher designet, og at returvejen findes i den fjerne ende.

Forlad udrulningen med en skrevet ejer: hvilken kerne der bærer implementeringen, hvilket navnerum der holder interfacet, og hvilke præfikser gatewayen må videresende. Den sætning forhindrer flere hændelser end nogen benchmarksammenligning af de tre placeringer.