Una VM Hyper-V usa la VPN dell'host? Dipende dallo switch

Installate un client VPN sull'host Hyper-V, aprite lì un browser e l'indirizzo di uscita cambia; aprite la stessa pagina dentro la macchina virtuale e potrebbe mostrare l'indirizzo vecchio, o niente affatto. La conclusione abituale è che la macchina virtuale è guasta, o che va attivato il tunnel diviso. Nessuna delle due consegue. Un client VPN non è una proprietà della macchina; è un insieme di rotte, un adattatore virtuale e spesso un filtro legato a interfacce precise. Che il traffico dei guest incontri mai questo meccanismo dipende dallo switch virtuale usato dal guest.

Il mito, detto chiaramente

La convinzione è che una VPN installata sull'host protegga l'intera macchina, macchine virtuali comprese, perché una macchina virtuale è solo un processo in esecuzione su quella macchina. È una convinzione comoda, perché l'antivirus e i firewall dell'host di solito si comportano così. I percorsi di rete no.

Il frame di un guest è toccato dallo stack VPN dell'host solo se l'host lo instrada o lo filtra. Copiate quella frase su un foglietto adesivo, perché ogni caso qui sotto ne è una variante.

Tre tipi di switch, tre percorsi

Uno switch esterno lega un adattatore virtuale a una scheda di rete fisica, e il guest invia frame attraverso quel legame con il proprio indirizzo MAC. Il guest diventa un pari sulla rete fisica, con il proprio lease DHCP, il gateway e i server DNS. La rotta predefinita della VPN dell'host vive nello stack dell'host e non sposta quei frame, perché sono pontati anziché instradati attraverso l'host. Per questo anche uno switch esterno su un adattatore Wi-Fi è una cattiva idea: la maggior parte dei driver wireless non trasporta frame per un secondo indirizzo MAC.

Uno switch interno collega i guest a un adattatore virtuale dell'host. Da solo non offre alcuna uscita internet; un oggetto NAT sull'host fornisce la traduzione, come descritto nella guida NAT di Hyper-V. Ora i pacchetti del guest entrano davvero nell'instradamento e nel percorso NAT dell'host, quindi le rotte e i filtri del client VPN tornano a contare. Questa è la disposizione in cui la macchina virtuale segue davvero la VPN dell'host, e in cui un kill switch può tagliare fuori del tutto il guest.

Uno switch privato non ha adattatore host né collegamento verso l'alto. I guest parlano tra loro e con nient'altro, quindi se una macchina virtuale su uno switch privato non ha internet, il router mancante è la causa e la VPN è irrilevante.

Lo switch predefinito è una disposizione a sé

Windows fornisce uno switch predefinito che combina uno switch interno con NAT e un proxy DNS. La sua sottorete è scelta dall'host, può cambiare dopo i riavvii e non è lo stesso oggetto di una rete NAT che create voi. Ricostruirlo come se fosse una rete di laboratorio è il modo in cui la gente finisce con due NAT e un guest ancora senza rotta.

Se la macchina virtuale è sullo switch predefinito, leggete l'indirizzo ricevuto dal guest e confrontatelo con la tabella NAT dell'host prima di toccare il client VPN. Una discordanza tra il gateway del guest e il prefisso NAT spiega più guasti di qualsiasi impostazione del client.

Quattro fatti che risolvono la domanda

Raccogliete questi prima di cambiare qualcosa: il tipo di switch e il suo collegamento verso l'alto, l'adattatore collegato alla macchina virtuale, l'indirizzo, il gateway e il DNS del guest stesso, e lo stato di NAT e della rotta predefinita dell'host. I comandi di sola lettura sono Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, e Get-NetRoute -DestinationPrefix 0.0.0.0/0; e dentro il guest ipconfig /all fornisce il resto.

Poi decidete che cosa deve fare il guest. Se deve restare fuori dalla VPN, ottenete l'eccezione supportata dal fornitore per quel percorso esatto, perché escludere un eseguibile dell'host non esenta il traffico inoltrato della macchina virtuale. Se deve usare la VPN, confermate la gestione documentata del traffico delle macchine virtuali da parte del client invece di supporre che un test nel browser dell'host la copra.

Un test dentro il guest è l'unica prova che conta. Controllate l'indirizzo di uscita dal guest, risolvete un nome interno, riconnettete la VPN e ripetete. Il risultato del browser dell'host non sostituisce nulla di tutto ciò.

Quanto costa il mito

Le persone disattivano il kill switch, aggiungono rotte statiche o eliminano e ricreano switch solo per far passare un test. Ogni scorciatoia cambia il modo di guasto: il guest può raggiungere internet per un percorso che nessuno intendeva, oppure l'host può perdere la connettività quando uno switch esterno ricollega la sua scheda fisica.

Ricollegare uno switch esterno interrompe l'accesso dell'host stesso, quindi tenete aperto un percorso fuori banda ed evitate di eliminare switch mentre state ancora diagnosticando. Il risultato corretto è il percorso voluto del guest, compreso come si riconnette e come fallisce, non un segno di spunta verde da un caricamento di pagina.

La risposta duratura è una riga per macchina virtuale nell'inventario: quale switch usa e quale componente fornisce il suo gateway. Con questo scritto, il prossimo cambio di VPN è una consultazione invece di un pomeriggio di congetture.