WireGuard i LXC eller ein VM på Proxmox: kvar bør det køyre?

WireGuard treng nøyaktig éin kjerne som eig grensesnittet sitt, og det faktumet avgjer mestedelen av Proxmox-plasseringsdebatten før ytinga i det heile kjem inn i rommet. Ein LXC-container er ei namneromsvising av vertskjerna, medan ein VM startar si eiga. Så det nyttige spørsmålet er ikkje kva alternativ som er lettast, men kva kjerne du er villig til å endre og kva gjenopprettingsveg du kan leve med. Svar på det, og valet mellom vert, container eller VM gjer seg vanlegvis sjølv.

Ein LXC-gjest arbeider inne i vertskjerna

Å installere wireguard-tools i ein container gir deg kontrollprogrammet, ikkje ei privat kjerne. Grensesnittet wg0 du lagar, blir registrert i nettverksstakken til verten og dukkar opp i modullista hans. Derfor kan ein container greie alle pakkekontrollar og likevel feile på den første wg-kommandoen når vertskjerna manglar modulen. Og Proxmox-containerreferansen dokumenterer den delte kjernemodellen saman med namneroms- og privilegieavgrensingane du arbeider innanfor.

Autoritet er den andre avgrensinga. Å heise eit grensesnitt og knyte adresser til det krev nettverksadministrasjonsrettar i namnerommet som eig det, og ein uprivilegert container kartlegg desse rettane gjennom brukarnamnerommet sitt i staden for å halde dei direkte. Grip aldri etter fullt privilegium som første svar; sjå på kva containeren faktisk blir beden om, og gje så det.

Vertskjerna er òg ein delt avhengnad. Ei Proxmox-kjerneoppdatering endrar WireGuard-implementasjonen under kvar container på éin gong, noko som er praktisk heilt til ei oppdatering og forventningane til ein container er usamde.

Vert, container, VM: kva kvar plassering eig i røynda

Plassering på verten set VPN-en i hypervisoren sitt eige nettverk. Ruter, brannmurreglar og tunnelen blir del av gjenopprettinga til verten, og ein feil der kan ta med seg administrasjonsgrensesnittet. Det er akseptabelt for infrastrukturrutting på ein vert du når via ein konsoll, og smertefullt på ein ekstern boks utan tilgang utanfor bandet.

Ein container held tenesta pakka og omstartbar medan han framleis låner vertskjerna. Han passar for ei medvite delt-kjerne-teneste og gir deg ei lita eining å byggje på nytt. Han gir deg ikkje ei uavhengig kjerne, så alt som treng eit bestemt modulbygg, peikar bort frå dette alternativet.

Ein VM kostar meir minne og endå eit system å patche, og til gjengjeld får tunnelen si eiga kjerne, si eiga rutetabell og ei snapshot-grense. Når VPN-en er det du rullar tilbake etter ei dårleg endring, er det snapshotet verdt overheaden.

Tre vilkår som vel for deg

Viss tunnelen treng ein kjerneversjon eller ein WireGuard-funksjon som Proxmox-verten ikkje leverer, stopp her og bruk ein VM. Du kan ikkje installere ei nyare kjerne i ein container, og du bør ikkje bytte ut hypervisor-kjerna for å tilfredsstille éin gjest.

Viss tunnelen er gatewayen til nettstaden for ekte LAN-prefiks, spør kven som alt eig returruta. Ein container kan rute trafikk, men grensesnitta hans sit i stakken til verten, så verten endar med å bere ein del av konfigurasjonen, anten du planla det eller ikkje. Plassering på verten er ærleg om dette; plassering i ein container er det ofte ikkje.

Vei deretter sprengradiusen til ein feil. Å starte ein container på nytt er billeg, å gjenopprette eit VM-snapshot er føreseieleg, og å reparere nettverket til verten kan krevje fysisk eller konsolltilgang. Det rette valet er det der du faktisk kan gjenopprette det verste tilfellet i timen det skjer.

Eit fjerde spørsmål er sjeldan avgjerande, men verdt å nemne: må noko anna på verten sjå tunnelgrensesnittet? Viss ja, held plassering på verten eller i ein container den synlegheita lokal, medan ein VM tvingar deg til å rute mellom gjesten og verten.

Prov plasseringa før du rutar trafikk gjennom henne

Etter installasjonen, stadfest kva kjerne som faktisk tener grensesnittet og om containeren har fått nok autoritet til å halde på 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 videresendingssida frå verten, for eit handtrykk åleine beviser berre at tunnelen er oppe. Bruk ip route get for ei klientadresse og stadfest at neste hopp og grensesnittet stemmer med designet, og at returvegen finst i den andre enden.

Forlat utrullinga med ein skriftleg eigar: kva kjerne som ber implementasjonen, kva namnerom som held grensesnittet, og kva prefiks gatewayen har lov til å videresende. Den setninga hindrar fleire hendingar enn nokon benchmark-samanlikning av dei tre plasseringane.