WireGuard i LXC eller en VM på Proxmox: hvor bør det kjøre?

WireGuard trenger nøyaktig én kjerne som eier grensesnittet sitt, og det faktumet avgjør mesteparten av Proxmox-plasseringsdebatten før ytelsen i det hele tatt kommer inn i rommet. En LXC-container er en navneromsvisning av vertskjernen, mens en VM starter sin egen. Så det nyttige spørsmålet er ikke hvilket alternativ som er lettest, men hvilken kjerne du er villig til å endre og hvilken gjenopprettingsvei du kan leve med. Svar på det, og valget mellom vert, container eller VM tar seg vanligvis selv.

En LXC-gjest arbeider inne i vertskjernen

Å installere wireguard-tools i en container gir deg kontrollprogrammet, ikke en privat kjerne. Grensesnittet wg0 du oppretter, registreres i værtens nettverksstakk og dukker opp i værtens modulliste. Det er derfor en container kan bestå alle pakkekontroller og likevel feile på den første wg-kommandoen når vertskjernen mangler modulen. Og Proxmox-containerreferansen dokumenterer den delte kjernemodellen sammen med navneroms- og privilegiegrensene du arbeider innenfor.

Autoritet er den andre begrensningen. Å heise et grensesnitt og knytte adresser til det krever nettverksadministrasjonsrettigheter i navnerommet som eier det, og en upriv ilegert container mapper disse rettighetene gjennom brukernavnerommet sitt i stedet for å holde dem direkte. Grip aldri etter fullt privilegium som første svar; se på hva containeren faktisk blir bedt om, og gi så det.

Vertskjernen er også en delt avhengighet. En Proxmox-kjerneoppdatering endrer WireGuard-implementasjonen under hver container på én gang, noe som er praktisk helt til en oppdatering og en containers forventninger er uenige.

Vert, container, VM: hva hver plassering egentlig eier

Plassering på verten setter VPN-en i hypervisorens eget nettverk. Ruter, brannmurregler og tunnelen blir en del av vertens gjenoppretting, og en feil der kan ta med seg administrasjonsgrensesnittet. Det er akseptabelt for infrastrukturruting på en vert du når via en konsoll, og smertefullt på en ekstern boks uten tilgang utenfor båndet.

En container holder tjenesten pakket og omstartbar mens den fortsatt låner vertskjernen. Den passer for en bevisst delt-kjerne-tjeneste og gir deg en liten enhet å bygge på nytt. Den gir deg ikke en uavhengig kjerne, så alt som trenger et bestemt modulbygg, peker bort fra dette alternativet.

En VM koster mer minne og enda et system å patche, og til gjengjeld får tunnelen sin egen kjerne, sin egen rutetabell og en snapshot-grense. Når VPN-en er det du ruller tilbake etter en dårlig endring, er det snapshotet verdt overheaden.

Tre betingelser som velger for deg

Hvis tunnelen trenger en kjerneversjon eller en WireGuard-funksjon som Proxmox-verten ikke leverer, stopp her og bruk en VM. Du kan ikke installere en nyere kjerne i en container, og du bør ikke bytte ut hypervisor-kjernen for å tilfredsstille én gjest.

Hvis tunnelen er stedets gateway for ekte LAN-prefikser, spør hvem som allerede eier returruten. En container kan rute trafikk, men grensesnittene dens sitter i værtens stakk, så verten ender med å bære en del av konfigurasjonen, enten du planla det eller ikke. Plassering på verten er ærlig om dette; plassering i en container er det ofte ikke.

Vei deretter sprengradiusen til en feil. Å starte en container på nytt er billig, å gjenopprette et VM-snapshot er forutsigbart, og å reparere vertens nettverk kan kreve fysisk eller konsolltilgang. Det riktige valget er det hvis verste tilfelle du faktisk kan gjenopprette i timen det skjer.

Et fjerde spørsmål er sjelden avgjørende, men verdt å nevne: må noe annet på verten se tunnelgrensesnittet? Hvis ja, holder plassering på verten eller i en container den synligheten lokal, mens en VM tvinger deg til å rute mellom gjesten og verten.

Bevis plasseringen før du ruter trafikk gjennom den

Etter installasjonen, bekreft hvilken kjerne som faktisk betjener grensesnittet og om containeren har fått nok autoritet til å 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

Sjekk deretter videresendingssiden fra verten, for et håndtrykk alene beviser bare at tunnelen er oppe. Bruk ip route get for en klientadresse og bekreft at neste hopp og grensesnitt stemmer med designet, og at returveien finnes i den andre enden.

Forlat utrullingen med en skriftlig eier: hvilken kjerne som bærer implementasjonen, hvilket navnerom som holder grensesnittet, og hvilke prefikser gatewayen har lov til å videresende. Den setningen forhindrer flere hendelser enn noen benchmark-sammenligning av de tre plasseringene.