NAT o rete VM in bridge: quale trasporta il traffico VPN?

Bridge e NAT non sono due modi di collegare lo stesso ospite alla tua VPN; decidono a chi appartengono i pacchetti dell'ospite prima che entri in gioco un tunnel. In modalità NAT l'hypervisor riscrive il traffico dell'ospite e lo emette da codice lato host, così l'ospite percorre qualunque rotta l'host assegni a quel codice. In modalità bridge l'ospite ottiene una propria identità di livello collegamento sul segmento fisico e sceglie il proprio gateway predefinito, il che rende il tunnel dell'host irrilevante per lui, a meno che sia il router della LAN a fare tunneling. Ho smesso di considerare la VM come "sulla VPN" e ho iniziato a trattarla come una domanda su dove punti la rotta predefinita di quell'ospite. Il test qui sotto richiede qualche minuto per modalità e risolve la questione senza congetture.

NAT tiene l'ospite dietro il codice dell'hypervisor, dove valgono le rotte dell'host

In VirtualBox un ospite NAT si trova su 10.0.2.0/24 con un gateway virtuale a 10.0.2.2, un proxy DNS a 10.0.2.3 e nessuna rotta propria verso la rete fisica. I pacchetti in uscita vengono presi dal motore NAT, riscritti in modo che la sorgente sia l'host e passati allo stack IP dell'host. Da lì il traffico dell'ospite è un flusso dell'host, e la ricerca della rotta avviene per destinazione: un client in tunnel completo che installa 0.0.0.0/1 e 128.0.0.0/1 sull'host lo cattura senza mai sapere che esiste una VM. Il capitolo di Oracle sul networking di VirtualBox elenca questi valori predefiniti se vuoi confermare gli indirizzi nella tua installazione.

La rete predefinita di libvirt arriva nello stesso punto da 192.168.122.0/24, dove dnsmasq distribuisce i lease e l'host fa masquerade della sottorete, così i pacchetti dell'ospite tornano alla decisione di routing dell'host. L'eccezione è un client che sceglie il traffico per processo invece che per rotta. Se la lista dello split tunneling contiene solo il tuo browser e nient'altro, il motore NAT non è su quella lista, e l'ospite esce dalla macchina senza tunnel mentre il browser dell'host sembra ancora coperto. Stessa sottorete, risultato opposto.

Il bridge dà all'ospite un proprio posto sulla LAN fisica

A un ospite in bridge viene data una NIC virtuale collegata a un adattatore reale, riceve un proprio indirizzo MAC e prende un lease DHCP dalla rete fisica. Il suo gateway predefinito è il router della LAN, non l'hypervisor, e le sue trame escono sul cavo attraverso quell'adattatore. Le rotte del tunnel dell'host vivono nella tabella dell'host e non vengono mai consultate, perché le trame dell'ospite non entrano mai nello stack IP dell'host.

Questo taglia in entrambe le direzioni. mDNS e la navigazione SMB iniziano a funzionare perché l'ospite vede il traffico broadcast della LAN, e l'ospite diventa raggiungibile da altre macchine dello stesso segmento senza un firewall dell'host in mezzo. Il bridge non è nemmeno un modo per spingere un ospite attraverso un tunnel esistente: collegare una VM all'interfaccia WireGuard o OpenVPN dell'host non è qualcosa che VirtualBox o libvirt facciano per te. Se un ospite in bridge deve passare da un tunnel, il tunnel deve terminare da qualche parte su quella LAN.

Il test che chiude la discussione

Esegui gli stessi controlli in entrambe le modalità e annota le risposte:

• Sull'host, curl -s https://ifconfig.me restituisce l'indirizzo v4 pubblico.
• Nell'ospite, lo stesso comando, più ip route su Linux o Get-NetRoute -DestinationPrefix 0.0.0.0/0 su Windows per il gateway predefinito.
• Identità del resolver: resolvectl status o cat /etc/resolv.conf nell'ospite, per vedere se punta a 10.0.2.3 o a un server della LAN.
• Famiglia di indirizzi: ip -6 addr show scope global e una richiesta v6, perché un tunnel v4 non dice nulla su un indirizzo v6 globale che l'ospite potrebbe avere.

Indirizzi pubblici coincidenti significano che l'ospite è sul percorso dell'host. Un indirizzo dell'ospite che coincide con l'uscita ordinaria della LAN significa che non lo è. Il passo che le persone saltano è il controllo: abbassa il tunnel dell'host e ripeti la richiesta dall'ospite. Se l'ospite continua a navigare, non ha mai dipeso dal tunnel dell'host, qualunque cosa suggerisca il nome della modalità. In modalità NAT l'ospite dovrebbe perdere internet con il tunnel dell'host abbassato, a meno che il client sia configurato per consentire traffico senza tunnel, il che vale la pena sapere di per sé.

Due segnali mentono. Un ping riuscito dimostra la raggiungibilità, non il percorso di uscita. E il DNS può essere risolto dal proxy 10.0.2.3 attraverso il resolver dell'host mentre TCP prende un'altra rotta, ed è così che si ottiene una pagina che carica e un accesso che non si completa mai.

Quale modalità si adatta al lavoro

La modalità è una decisione di routing, quindi sceglila dal requisito e non dall'abitudine:

La prima riga è dove la gente rimane impigliata: NAT più un client host in tunnel completo copre davvero un ospite, ma solo finché il client tunnella per rotta e l'uplink dell'host è quel tunnel. Sposta il client su una lista di autorizzati solo per il browser e la copertura sparisce senza alcun errore da nessuna parte. La quarta riga è l'errore inverso: un ospite messo in bridge per comodità che inizia silenziosamente a rispondere in SMB o SSH sulla LAN dell'ufficio.

Guasti che vengono attribuiti alla VPN

Su Windows la traduzione NAT gira dentro il processo della VM di VirtualBox, quindi un client per applicazione ha bisogno di esattamente quell'immagine nella sua lista invece di una regola generale per le macchine virtuali. Quando un aggiornamento del client ricostruisce la lista dei processi, gli ospiti NAT perdono la copertura per primi, e il rapporto suona come una VM che raggiunge la LAN ma non internet mentre l'host sta bene.

Il bridge su Wi-Fi è l'altro classico. Gli access point raramente inoltrano trame con un MAC sorgente estraneo, quindi un bridge su wlan0 o fallisce del tutto o funziona finché l'isolamento dei client sull'AP inizia a scartarlo. VirtualBox offrirà comunque l'adattatore wireless nella sua lista. Se l'host è su Wi-Fi e l'ospite deve essere in bridge, pianifica di testarlo invece di darlo per scontato.

L'MTU è il terzo. Un ospite in bridge mantiene l'MTU di 1500 byte della LAN, e se esegue un proprio client WireGuard a 1420, le grandi strette di mano TLS si bloccano mentre le richieste piccole passano. Sotto NAT l'MTU del tunnel dell'host è un problema dell'host, ma l'ospite crede ancora in 1500, e UDP con il bit don't-fragment impostato sparisce allo stesso modo.

Annota la modalità e ricontrolla dopo ogni cambio di adattatore

Annota la modalità, l'interfaccia dell'host usata dal bridge, il gateway predefinito dell'ospite, il suo resolver e i suoi indirizzi di uscita v4 e v6. È quella registrazione che rende economico il guasto successivo: quando un portatile passa dalla dock al Wi-Fi, un ospite in bridge segue il bridge su un altro adattatore fisico e può riprendere un lease in un'altra sottorete, mentre un ospite NAT mantiene il suo indirizzo 10.0.2.x e eredita silenziosamente un altro uplink.

Prima di chiudere il ticket, conferma ciascuno di questi punti:

• L'indirizzo di uscita dell'ospite differisce da quello dell'host, quindi non è sul tunnel dell'host.
• Il resolver è il proxy 10.0.2.3 o un server della LAN, e sai quale ha risposto.
• Non esiste alcun indirizzo v6 globale nell'ospite se il progetto del tunnel è solo v4.
• Con il tunnel dell'host abbassato, l'ospite smette di navigare, oppure ora sai che non ne ha mai dipeso.
• L'ospite non vede traffico broadcast della LAN che non lo riguarda.