WireGuard i LXC eller en VM på Proxmox: var bör det köra?

WireGuard behöver exakt en kärna som äger sitt gränssnitt, och det faktumet avgör det mesta av Proxmox-placeringsdebatten innan prestanda ens kommer in i rummet. En LXC-container är en namnrymdsvy av värdens kärna, medan en VM startar sin egen. Så den användbara frågan är inte vilket alternativ som är lättast, utan vilken kärna du är villig att ändra och vilken återställningsväg du kan leva med. Svara på det, och valet mellan värd, container eller VM gör sig oftast självt.

En LXC-gäst arbetar inne i värdens kärna

Att installera wireguard-tools i en container ger dig kontrollprogrammet, inte en privat kärna. Gränssnittet wg0 som du skapar registreras i värdens nätverksstack och dyker upp i värdens modullista. Det är därför en container kan klara alla paketkontroller och ändå misslyckas på det första wg-kommandot när värdens kärna saknar modulen. Och Proxmox containerreferens dokumenterar den delade kärnmodellen tillsammans med de namnrymds- och behörighetsgränser du arbetar inom.

Behörighet är den andra begränsningen. Att resa ett gränssnitt och koppla adresser till det kräver nätverksadministrationsrättigheter i den namnrymd som äger det, och en oprivilegierad container mappar dessa rättigheter genom sin användarnamnrymd i stället för att hålla dem direkt. Ta aldrig till full behörighet som första svar; titta på vad containern faktiskt ombeds göra och ge sedan det.

Värdens kärna är också ett delat beroende. En Proxmox-kärnuppdatering ändrar WireGuard-implementeringen under varje container på en gång, vilket är praktiskt tills en uppdatering och en containers förväntningar inte längre stämmer.

Värd, container, VM: vad varje placering egentligen äger

Placering på värden sätter VPN i hypervisorns eget nätverk. Rutter, brandväggsregler och tunneln blir en del av värdens återställning, och ett misstag där kan ta med sig hanteringsgränssnittet. Det är acceptabelt för infrastrukturrouting på en värd du når via en konsol, och smärtsamt på en fjärrmaskin utan åtkomst utanför bandet.

En container håller tjänsten paketerad och omstartbar medan den fortfarande lånar värdens kärna. Den passar för en medvetet delad kärntjänst och ger dig en liten enhet att bygga om. Den ger dig ingen oberoende kärna, så allt som kräver en viss modulbyggnad pekar bort från det här alternativet.

En VM kostar mer minne och ännu ett system att patcha, och i gengäld får tunneln sin egen kärna, sin egen routingtabell och en snapshotgräns. När VPN:en är det du rullar tillbaka efter en dålig ändring är den snapshoten värd överkostnaden.

Tre villkor som väljer åt dig

Om tunneln behöver en kärnversion eller en WireGuard-funktion som Proxmox-värden inte levererar, stanna här och använd en VM. Du kan inte installera en nyare kärna i en container, och du bör inte byta ut hypervisorns kärna för att tillfredsställa en enda gäst.

Om tunneln är platsens gateway för riktiga LAN-prefix, fråga vem som redan äger returrutten. En container kan routa trafik, men dess gränssnitt sitter i värdens stack, så värden bär till slut en del av konfigurationen, oavsett om du planerade det eller inte. Placering på värden är ärlig om detta; placering i en container är det ofta inte.

Väg sedan in sprängradien för ett misstag. Att starta om en container är billigt, att återställa en VM-snapshot är förutsägbart, och att reparera värdens nätverk kan kräva fysisk eller konsolåtkomst. Rätt val är det där du verkligen kan återställa värsta fallet i den timme det inträffar.

En fjärde fråga är sällan avgörande men värd att nämna: behöver något annat på värden se tunnelgränssnittet? Om ja håller placering på värden eller i en container den synligheten lokal, medan en VM tvingar dig att routa mellan gästen och värden.

Bevisa placeringen innan du routar trafik genom den

Efter installationen, bekräfta vilken kärna som faktiskt betjänar gränssnittet och om containern har fått tillräcklig behörighet att behålla 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

Kontrollera sedan vidarebefordringssidan från värden, för en handskakning ensam bevisar bara att tunneln är uppe. Använd ip route get för en klientadress och bekräfta att nästa hopp och gränssnittet stämmer med designen, och att returvägen finns i den andra änden.

Lämna driftsättningen med en skriftlig ägare: vilken kärna som bär implementeringen, vilken namnrymd som håller gränssnittet och vilka prefix gatewayen får vidarebefordra. Den meningen förhindrar fler incidenter än någon benchmarkjämförelse av de tre placeringarna.