La tua VM usa la VPN dell'host? Provalo dall'interno del guest

Controlli l'IP pubblico dell'host, vedi la VPN e concludi che la VM è coperta. Questa conclusione non è supportata dal test. Un guest ha la propria tabella di routing, il proprio resolver e le proprie interfacce, e l'indirizzo di uscita dell'host non dice nulla su di esse.

Il test deve essere eseguito dentro il guest e deve indicare che cosa ha misurato.

Parti dall'interno del guest, non dal browser dell'host

Registra prima la modalità di rete dell'hypervisor: NAT, bridged, host-only o macvtap. In modalità NAT l'host instrada il traffico del guest, quindi il tunnel dell'host può valere o meno a seconda di come il client installa le rotte. In modalità bridged il guest è un peer sulla LAN fisica e il tunnel dell'host è irrilevante. Queste due modalità danno risposte opposte con la stessa configurazione dell'host.

Annota la modalità prima di cambiare qualsiasi cosa, perché è lei a determinare che cosa può significare il risultato.

Fai una richiesta di cui conosci la destinazione

Usa una richiesta innocua verso un servizio che riporta l'indirizzo di origine che ha visto. Poi controlla la decisione di routing del guest per quella destinazione: ip route get 203.0.113.5 stampa l'interfaccia e il gateway che il guest userà.

Se l'interfaccia è la normale NIC del guest, il traffico non passa attraverso un tunnel dentro il guest.

Un secondo adattatore, un'impostazione proxy o un client VPN sul guest possono cambiare la risposta per un'applicazione e non per un'altra. Prova l'applicazione che ti interessa davvero, non una richiesta generica da una shell.

Controlla il resolver separatamente

Un indirizzo di uscita cambiato non ti dice quale resolver ha gestito il nome host. Interroga il nome in modo esplicito con lo strumento adatto alla piattaforma e annota quale server ha risposto. Split DNS significa che la domanda sul resolver e quella sul routing hanno risposte diverse.

Le due possono divergere in entrambe le direzioni, e la divergenza è spesso il bug vero.

Su un host systemd, resolvectl query indica l'interfaccia e il server DNS dietro la risposta. Le configurazioni più vecchie mostrano il server nell'output di dig. In ogni caso il punto è vedere quale server ha risposto, non solo se è arrivata una risposta.

Prova la politica di guasto, non solo il successo

Se il requisito è che nessun traffico esca fuori dal tunnel, una richiesta riuscita non dimostra nulla. Usa il test di guasto controllato supportato dal client: ferma il tunnel nel modo supportato e verifica se una nuova richiesta del guest viene bloccata. Non dare per scontato che il kill switch del client host copra ogni soluzione di inoltro virtuale. Il suo ambito documentato è l'unica cosa su cui puoi contare.

Un guest che ricade sulla NIC fisica quando il tunnel cade fa esattamente ciò che la modalità NAT consente.

Registra la modalità e l'ambito

Annota la modalità dell'hypervisor, l'interfaccia e la rotta del guest, il resolver e l'applicazione che hai testato. Aggiungi la data, perché un ripristino di snapshot o un aggiornamento dell'hypervisor possono cambiare tutte e quattro le cose.

Se IPv4 ha seguito il tunnel, dillo. Non estendere l'affermazione a IPv6, a un altro namespace o a un'altra VM su una rete diversa.