WireGuard in LXC o in una VM su Proxmox: dove dovrebbe girare?

WireGuard ha bisogno di esattamente un kernel che possieda la sua interfaccia, e questo fatto risolve la maggior parte del dibattito sul posizionamento in Proxmox prima ancora che le prestazioni entrino nella stanza. Un container LXC è una vista di namespace del kernel dell'host, mentre una VM avvia il proprio. Quindi la domanda utile non è quale opzione sia più leggera, ma quale kernel sei disposto a modificare e con quale percorso di ripristino puoi convivere. Rispondi a questo e la scelta tra host, container o VM di solito si fa da sola.

Un guest LXC lavora dentro il kernel dell'host

Installare wireguard-tools dentro un container ti dà il programma di controllo, non un kernel privato. L'interfaccia wg0 che crei viene registrata nello stack di rete dell'host e compare nell'elenco dei moduli dell'host. È per questo che un container può superare ogni controllo dei pacchetti e comunque fallire al primo comando wg quando al kernel dell'host manca il modulo. E la guida ai container di Proxmox documenta quel modello a kernel condiviso insieme ai confini di namespace e privilegi entro cui lavori.

L'autorità è il secondo vincolo. Alzare un'interfaccia e collegarvi indirizzi richiede diritti di amministrazione di rete nello spazio dei nomi che la possiede, e un container non privilegiato mappa quei diritti attraverso il proprio namespace utente invece di tenerli direttamente. Non ricorrere mai al privilegio completo come prima risposta; guarda che cosa viene realmente chiesto al container, poi concedilo.

Anche il kernel dell'host è una dipendenza condivisa. Un aggiornamento del kernel Proxmox cambia l'implementazione di WireGuard sotto ogni container insieme, il che è comodo finché un aggiornamento e le aspettative di un container non vanno d'accordo.

Host, container, VM: cosa possiede davvero ogni posizionamento

Il posizionamento sull'host mette la VPN nella rete propria dell'hypervisor. Le rotte, le regole del firewall e il tunnel diventano parte del ripristino dell'host, e un errore lì può portarsi via l'interfaccia di gestione. È accettabile per il routing di infrastruttura su un host raggiungibile da console, e doloroso su una macchina remota senza accesso fuori banda.

Un container tiene il servizio impacchettato e riavviabile mentre prende ancora in prestito il kernel dell'host. Si adatta a un servizio deliberatamente a kernel condiviso e ti dà una piccola unità da ricostruire. Non ti dà un kernel indipendente, quindi tutto ciò che richiede una compilazione di modulo specifica punta lontano da questa opzione.

Una VM costa più memoria e un altro sistema da correggere, e in cambio il tunnel ottiene il proprio kernel, la propria tabella di routing e un confine di istantanea. Quando la VPN è ciò che riporti indietro dopo una modifica sbagliata, quell'istantanea vale il sovraccarico.

Tre condizioni che scelgono per te

Se il tunnel ha bisogno di una versione del kernel o di una funzione WireGuard che l'host Proxmox non fornisce, fermati qui e usa una VM. Non puoi installare un kernel più recente in un container, e non dovresti sostituire il kernel dell'hypervisor per soddisfare un solo guest.

Se il tunnel è il gateway del sito per prefissi LAN reali, chiedi chi possiede già la rotta di ritorno. Un container può instradare il traffico, ma le sue interfacce stanno nello stack dell'host, quindi l'host finisce per portare parte della configurazione, che tu l'abbia pianificato o no. Il posizionamento sull'host è onesto al riguardo; quello in container spesso no.

Poi valuta il raggio d'azione di un errore. Riavviare un container costa poco, ripristinare un'istantanea di VM è prevedibile, e riparare la rete dell'host può richiedere accesso fisico o da console. La scelta giusta è quella di cui riesci davvero a recuperare il caso peggiore nell'ora in cui accade.

Una quarta domanda è raramente decisiva ma vale la pena dirla: qualcos'altro sull'host deve vedere l'interfaccia del tunnel? Se sì, il posizionamento sull'host o in container mantiene quella visibilità locale, mentre una VM ti costringe a instradare tra guest e host.

Dimostra il posizionamento prima di instradarvi il traffico

Una volta installato, conferma quale kernel serve davvero l'interfaccia e se al container è stata data autorità sufficiente a mantenerla:

$ 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

Poi controlla il lato dell'inoltro dall'host, perché una stretta di mano da sola dimostra solo che il tunnel è attivo. Usa ip route get per un indirizzo client e conferma che il salto successivo e l'interfaccia corrispondano al progetto, e che il percorso di ritorno esista dall'altra parte.

Lascia il deployment con un proprietario scritto: quale kernel porta l'implementazione, quale namespace tiene l'interfaccia e quali prefissi il gateway può inoltrare. Quella frase previene più incidenti di qualsiasi confronto prestazionale dei tre posizionamenti.