Compartir la sessió VPN de l’amfitrió amb un convidat VMware

La vostra màquina virtual no pot arribar a un sistema intern que funciona perfectament a l’amfitrió, i l’amfitrió està connectat mitjançant un client que posseeix la taula d’encaminament. Pontar l’adaptador virtual al túnel sembla obvi i falla per dues raons separades. El que funciona és la traducció en un segment que ambdues màquines posseeixen. El cost és real: cada convidat deixa de tenir identitat pròpia a la xarxa corporativa.

Dues raons per les quals el pont no pot funcionar

L’adaptador del client sol portar una sola adreça, sovint /32, i el client reescriu les rutes de l’amfitrió perquè el trànsit sortint ordinari prefereixi el túnel. Les aplicacions de l’amfitrió obeeixen aquesta taula i arriben al sistema privat. Un convidat pontat no llegeix mai la taula, perquè les seves trames surten per un commutador per sota de la capa IP.

Posar l’adaptador de túnel dins d’un pont resoldria el camí en teoria, i el controlador no ho acceptarà. Windows 10 també permet un sol dispositiu de pont i reté el rol d’encaminament que deixaria una estació de treball reenviar entre dues subxarxes. El que queda és la traducció d’origen. Feu que el trànsit del convidat sembli venir de l’amfitrió, i les decisions de l’amfitrió el porten al túnel sense que el convidat necessiti una ruta que no pot tenir.

Creeu un segment que posseeixi l’amfitrió

A l’editor de xarxa virtual, afegiu una xarxa només d’amfitrió com VMnet3 en un prefix que no encamineu enlloc més, per exemple 172.28.90.0/24. L’amfitrió pren 172.28.90.1 en aquest adaptador i el convidat s’uneix al mateix commutador. Desactiveu el DHCP de l’hipervisor en aquest segment perquè el posseeixi un sol servei d’adreces.

Confirmeu que Windows veu la interfície abans de construir-hi res a sobre, perquè tot el disseny depèn que aquest adaptador sigui ordinari:

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

Un adaptador només d’amfitrió hi apareix com qualsevol de físic. Aquesta és precisament la diferència amb l’adaptador de túnel, que no es pot connectar a res.

Traduïu el prefix del convidat

Obriu una sessió elevada i traduïu el prefix. Comproveu primer què ja existeix, perquè els entorns d’execució de contenidors i els hipervisors instal·len les seves pròpies traduccions i esborrar la incorrecta trenca un altre producte.

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

Després configureu el convidat amb una adreça estàtica en aquest prefix, 172.28.90.1 com a passarel·la i les adreces de resolució que el túnel dona a l’amfitrió. La traducció reenvia paquets i no ensenya res al convidat sobre DNS, així que un convidat deixat al router local resol noms públics i falla en tots els interns.

Comproveu el primer salt, després el cost

Proveu la frontera més propera abans de provar una aplicació. Un traçat que s’atura a la passarel·la de l’amfitrió vol dir que la traducció no passa, mentre que un que s’atura més enllà de l’amfitrió vol dir que el túnel està caigut o que el costat remot ha refusat l’adreça traduïda.

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

Compareu-ho amb l’accés propi de l’amfitrió a la mateixa destinació mentre el túnel està actiu. Si l’amfitrió ho aconsegueix i el convidat no, la falla és a la traducció o a la configuració de passarel·la del convidat, no a la connexió.

Després accepteu l’intercanvi. Els sistemes corporatius ara veuen una adreça per a cada convidat, així que els certificats de dispositiu i les comprovacions d’estat per dispositiu no els poden distingir, i algunes polítiques ho prohibeixen del tot. Decidiu també el comportament de descart, ja que el trànsit traduït pot caure al camí ordinari d’Internet quan el túnel falla, tret que bloquegeu aquest prefix al tallafoc de l’amfitrió.