Condividere la sessione VPN dell’host con un guest VMware

La macchina virtuale non raggiunge un sistema interno che funziona perfettamente sull’host, e l’host è connesso tramite un client che possiede la tabella di routing. Collegare con un bridge l’adattatore virtuale al tunnel sembra ovvio e fallisce per due motivi distinti. Ciò che funziona è la traduzione su un segmento che entrambe le macchine possiedono. Il costo è reale: ogni guest smette di avere un’identità propria sulla rete aziendale.

Due motivi per cui il bridge non può funzionare

L’adattatore del client porta di solito un solo indirizzo, spesso un /32, e il client riscrive le rotte dell’host perché il traffico in uscita ordinario preferisca il tunnel. Le applicazioni sull’host obbediscono a quella tabella e raggiungono il sistema privato. Un guest in bridge non legge mai la tabella, perché i suoi frame escono da uno switch sotto il livello IP.

Mettere l’adattatore del tunnel in un bridge risolverebbe il percorso in teoria, e il driver non lo accetterà. Windows 10 consente inoltre un solo dispositivo bridge e nega il ruolo di routing che lascerebbe a una workstation inoltrare tra due subnet. Ciò che resta è la traduzione di sorgente. Fate apparire il traffico del guest come proveniente dall’host, e le decisioni dell’host stesso lo portano nel tunnel senza che il guest abbia bisogno di una rotta che non può avere.

Create un segmento che l’host possiede

Nell’editor di rete virtuale, aggiungete una rete solo host come VMnet3 su un prefisso che non instradate altrove, per esempio 172.28.90.0/24. L’host prende 172.28.90.1 su quell’adattatore e il guest si collega allo stesso switch. Disattivate il DHCP dell’hypervisor su quel segmento perché lo possieda un solo servizio di indirizzi.

Verificate che Windows veda l’interfaccia prima di costruirci sopra qualcosa, perché l’intero progetto dipende dal fatto che quell’adattatore sia ordinario:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

Un adattatore solo host appare lì come qualsiasi adattatore fisico. È esattamente la differenza con l’adattatore del tunnel, che non può essere collegato a nulla.

Traducete il prefisso del guest

Aprite una sessione elevata e traducete il prefisso. Controllate prima ciò che esiste già, perché i runtime dei container e gli hypervisor installano le proprie traduzioni e cancellare quella sbagliata rompe un altro prodotto.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Poi configurate il guest con un indirizzo statico in quel prefisso, 172.28.90.1 come gateway e gli indirizzi del resolver che il tunnel dà all’host. La traduzione inoltra i pacchetti e non insegna nulla al guest sul DNS, quindi un guest lasciato sul router locale risolve i nomi pubblici e fallisce su ogni nome interno.

Controllate il primo hop, poi il costo

Provate il confine più vicino prima di provare un’applicazione. Un tracciato che si ferma al gateway dell’host significa che la traduzione non avviene, mentre uno che si ferma oltre l’host significa che il tunnel è giù o che il lato remoto ha rifiutato l’indirizzo tradotto.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Confrontate con l’accesso proprio dell’host alla stessa destinazione mentre il tunnel è attivo. Se l’host riesce e il guest no, il difetto sta nella traduzione o nell’impostazione del gateway del guest, non nella connessione.

Poi accettate lo scambio. I sistemi aziendali ora vedono un solo indirizzo per ogni guest, quindi i certificati dei dispositivi e i controlli di postura per dispositivo non possono distinguerli, e alcune policy lo vietano del tutto. Decidete anche il comportamento di scarto, poiché il traffico tradotto può ricadere sul percorso internet ordinario quando il tunnel fallisce, a meno che non blocchiate quel prefisso sul firewall dell’host.