Eseguire la VPN sull’host o dentro la VM? Guida alla decisione

Costruire il tunnel dentro il guest e costruirlo sull’host cambiano entrambi l’indirizzo che un browser riporta, e lì finisce la somiglianza. Un tunnel di proprietà del guest tiene le sue chiavi, la sua rotta predefinita e il suo resolver nel kernel del guest, mentre l’host inoltra pacchetti cifrati verso un solo indirizzo remoto. Un tunnel di proprietà dell’host è l’immagine speculare: il client dell’host tiene la sessione e applica rotte e criteri, e il guest prende in prestito ciò che esce. Scegliete il proprietario sbagliato e ogni sintomo successivo vi manda alla macchina sbagliata. Due comandi risolvono la questione in circa un minuto, e il resto di questa guida è cosa fare con la risposta.

Decidete il proprietario prima di toccare il client

La regola riguarda dove viene prodotto il testo cifrato, non quale macchina mostra un’icona VPN. Se lo produce il guest, il guest ha bisogno di una rotta funzionante verso il server VPN e di nient’altro dall’host. Se lo produce l’host, il guest ha bisogno che il percorso attraverso l’host sopravviva a qualsiasi criterio che il client dell’host impone al traffico locale.

Tre domande di solito scelgono la collocazione per voi. Il traffico del guest deve sopravvivere a un client aziendale sull’host? Allora il tunnel è nel guest. Diversi guest hanno bisogno di un’unica credenziale e di un unico indirizzo di uscita? Allora è sull’host, con l’inoltro configurato di proposito. Il traffico del guest deve restare del tutto fuori dalla VPN dell’host? Allora un tunnel nel guest è l’unica disposizione che ve lo dà per costruzione.

Annotate la risposta su una riga accanto al nome della VM: guest-owned o host-owned. In un laboratorio di sei macchine quella nota fa risparmiare più tempo di qualsiasi passo sotto, perché vi impedisce di diagnosticare un tunnel che non era mai nella macchina a cui avete effettuato l’accesso.

WSL1 e WSL2 sono casi opposti

WSL1 non è una macchina virtuale, quindi la questione della collocazione per lo più svanisce. I suoi binari Linux girano contro lo stack di rete di Windows attraverso uno strato di traduzione, e un client VPN Linux non ha interfacce indipendenti da configurare. La disposizione che funziona è un tunnel sul lato Windows, con la distribuzione che usa il risultato senza possedere nulla.

WSL2 è l’opposto. Esegue un kernel vero in una VM di servizio leggera dietro uno switch virtuale Hyper-V, e il suo spazio di indirizzi viene tradotto in NAT tramite un adattatore lato host. Perciò un client Linux dentro la distribuzione si comporta come su una macchina Linux fisica: crea tun0 o wg0, installa le proprie rotte e funziona. Il guasto vive sul lato host. Quando un client VPN di Windows si connette con un criterio che blocca il traffico sulle reti locali, tratta la sottorete WSL2 come rete locale non affidabile e taglia il percorso NAT. La distribuzione perde allora DNS e accesso in uscita mentre il suo tunnel è ancora sano: wg show segnala un handshake, ip route sembra corretto, e curl si blocca.

Quale correzione potete usare dipende dalla build di Windows. La più vecchia è un’eccezione nel client dell’host per la sottorete WSL, aggiunta nelle impostazioni di rete locale o di tunnel diviso del client. La più recente, sulle build di Windows 11 che la supportano, è la rete a specchio: mettete networkingMode=mirrored nella sezione [wsl2] di %UserProfile%\.wslconfig, eseguite wsl --shutdown, e la distribuzione condivide le interfacce dell’host invece di una sottorete NAT privata. La modalità a specchio cambia anche il comportamento di localhost e delle porte in entrata, quindi trattatela come una migrazione e non come un interruttore.

NAT, bridge e cosa può vedere l’host

Sotto NAT, i pacchetti del tunnel del guest sono indirizzati all’indirizzo pubblico del server VPN ed escono dall’adattatore dell’host come UDP o TCP cifrato. L’host vede un solo flusso e il suo conteggio di byte, nulla sulle destinazioni al suo interno. Sotto un adattatore in bridge il guest ha la propria identità di livello 2 sulla LAN fisica, prende il proprio lease DHCP e appare a qualsiasi criterio basato su MAC come un secondo dispositivo. Nessuna delle due modalità lascia che l’host legga il carico del tunnel; il guest in bridge è semplicemente molto più visibile alla rete che lo circonda.

Anche l’isolamento ha un pavimento. Un guest non può nascondersi alla macchina che possiede la sua memoria, e chi controlla l’host può leggere chiavi dalla RAM del guest. Ciò che un tunnel nel guest vi dà è un confine di instradamento e un confine contro il malware, non una protezione dalla persona che tiene il portatile. Vale la pena tenere aperti i modi adattatore documentati mentre scegliete, perché il modo cambia sia ciò che vede l’host sia ciò che vede la LAN.

Guida: collocare, configurare, dimostrare

Eseguite questi quattro controlli in ordine in una shell del guest nuova, e fermatevi al primo che non concorda con il proprietario che avete annotato.

1. ip route get 1.1.1.1 che restituisce tun0 o wg0 significa proprietà del guest, e eth0 con un prossimo salto privato significa proprietà dell’host.
2. resolvectl query example.com, oppure leggete /etc/resolv.conf dove il guest non esegue alcun servizio resolver. Un tunnel che trasporta traffico ma non DNS è lo stato a metà configurazione più comune.
3. Confrontate le uscite: curl -4 -s https://ifconfig.me nel guest contro curl.exe -4 -s https://ifconfig.me sull’host. Indirizzi diversi significano che il guest possiede il tunnel, e un host sulla VPN con un guest che mostra il provider di casa è il caso in cui non si è ereditato nulla.
4. Ripetete entrambi con -6. Un tunnel solo v4 perde v6 a meno che il client non lo blocchi o lo instradi, e molti client lasciano v6 sull’interfaccia fisica per impostazione predefinita.

Per un progetto a gateway sull’host, dove diversi guest condividono un tunnel, l’host deve inoltrare e tradurre. Su un host Linux sono tre pezzi, e il guest ricade silenziosamente sulla sua rotta semplice quando ne manca uno:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Lato WireGuard, l’AllowedIPs del peer host deve includere la sottorete dei guest, per esempio 192.168.122.0/24, altrimenti i pacchetti di ritorno non arrivano mai e la configurazione sembra un problema di firewall. Un host Windows ottiene lo stesso risultato con Condivisione connessione Internet o una regola NAT sullo switch Hyper-V, e ha bisogno dello stesso controllo del percorso di ritorno.

Quando la disposizione è ancora aperta, questa tabella copre gli arrangiamenti più frequenti:

Due tunnel, due guest e i conflitti tra loro

Quando servono due uscite insieme, il modello che regge è un tunnel per guest. Ogni VM mantiene la propria rotta predefinita e il proprio resolver, l’host resta sulla rete ordinaria, e i due tunnel non litigano mai sulla stessa tabella di routing. Mettere in bridge due guest non unisce nemmeno le loro rotte: la rete virtuale fornisce un percorso, e a ogni client va ancora detto che questo traffico locale può aggirare il tunnel.

Eseguire un tunnel dell’host e un tunnel del guest insieme è legittimo, e l’annidamento deliberato a volte è esattamente ciò che volete, con il guest che esce dal proprio tunnel e quel tunnel che esce da quello dell’host. Ciò che lo trasforma in un’interruzione è che nessuno ha annotato quale endpoint va raggiunto attraverso quale strato. Tenete un elenco a due colonne con destinazione e proprietario, e un conflitto di rotte diventa una ricerca invece di un pomeriggio di scoperte.

Verificate, poi lasciate il ripristino al proprietario

Provate dall’interno del guest con un nuovo processo applicativo: traffico, risoluzione dei nomi, entrambe le famiglie di indirizzi e cosa succede quando il tunnel cade. L’icona VPN dell’host non dice nulla sulla copertura del guest, e questa è la conferma falsa più comune in tutto questo ambito.

Anche il ripristino appartiene al proprietario. Un tunnel di proprietà del guest viene ripristinato dal client proprio del guest e dalle rotte che ha scritto. Un progetto di proprietà dell’host viene ripristinato dalla sequenza di avvio dell’host, e le regole di inoltro non sopravvivono a un riavvio se un’unità o un’attività di avvio non le riapplica. Un’istantanea ripristinata è un rilascio, non un annullamento, perché riporta vecchie credenziali e vecchie rotte insieme al disco. Prima di dichiarare il lavoro finito, confermate che il proprietario corrisponda ancora alla riga che avete annotato, che DNS ed entrambe le famiglie di indirizzi si risolvano dentro il guest, che un tunnel morto lasci una rete utilizzabile invece di un buco nero, e che un riavvio o un ripristino di istantanea riproduca lo stesso stato.