Compartir a sesión VPN do anfitrión cun convidado de VMware

A súa máquina virtual non chega a un sistema interno que funciona perfectamente no anfitrión, e o anfitrión está conectado mediante un cliente que posúe a táboa de encamiñamento. Pontear o adaptador virtual ao túnel parece obvio e falla por dúas razóns separadas. O que funciona é a tradución nun segmento que ambas as máquinas posúen. O custo é real: cada convidado deixa de ter identidade propia na rede corporativa.

Dúas razóns polas que a ponte non pode funcionar

O adaptador do cliente adoita levar unha soa dirección, a miúdo /32, e o cliente reescribe as rutas do anfitrión para que o tráfico saínte ordinario prefira o túnel. As aplicacións do anfitrión obedecem esa táboa e chegan ao sistema privado. Un convidado ponteado nunca le a táboa, porque as súas tramas saen por un conmutador por baixo da capa IP.

Pór o adaptador de túnel dentro dunha ponte resolvería o camiño en teoría, e o controlador non o aceptará. Windows 10 tamén permite un só dispositivo de ponte e retén o rol de encamiñamento que deixaría a unha estación de traballo reenviar entre dúas subredes. O que queda é a tradución de orixe. Faga que o tráfico do convidado pareza vir do anfitrión, e as decisións do propio anfitrión lévao ao túnel sen que o convidado necesite unha ruta que non pode ter.

Cree un segmento que posúa o anfitrión

No editor de rede virtual, engada unha rede só de anfitrión como VMnet3 nun prefixo que non encamiñe en ningún outro sitio, por exemplo 172.28.90.0/24. O anfitrión toma 172.28.90.1 nese adaptador e o convidado conéctase ao mesmo conmutador. Desactive o DHCP do hipervisor nese segmento para que o posúa un só servizo de direccións.

Confirme que Windows ve a interface antes de construír nada enriba, porque todo o deseño depende de que ese adaptador sexa ordinario:

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

Un adaptador só de anfitrión aparece alí como calquera físico. Esa é precisamente a diferenza co adaptador de túnel, que non se pode conectar a nada.

Traduza o prefixo do convidado

Abra unha sesión elevada e traduza o prefixo. Comprobe primeiro que existe xa, porque os contornos de execución de contedores e os hipervisores instalan as súas propias traducións e borrar a incorrecta rompe outro produto.

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

Despois configure o convidado cunha dirección estática nese prefixo, 172.28.90.1 como a súa pasarela e as direccións de resolución que o túnel entrega ao anfitrión. A tradución reenvía paquetes e non lle ensina nada ao convidado sobre DNS, así que un convidado deixado no router local resolve nomes públicos e falla en todos os internos.

Comprobe o primeiro salto, despois o custo

Probe a fronteira máis próxima antes de probar unha aplicación. Un trazado que se detén na pasarela do anfitrión significa que a tradución non ocorre, mentres que un que se detén máis alá do anfitrión significa que o túnel está caído ou que o lado remoto rexeitou a dirección traducida.

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

Compáreo co acceso propio do anfitrión ao mesmo destino mentres o túnel está activo. Se o anfitrión o consegue e o convidado non, a falla está na tradución ou na configuración de pasarela do convidado, non na conexión.

Despois acepte o intercambio. Os sistemas corporativos agora ven unha dirección para cada convidado, así que os certificados de dispositivo e as comprobacións de estado por dispositivo non os poden distinguir, e algunhas políticas próhibeno de plano. Decida tamén o comportamento de descarte, xa que o tráfico traducido pode caer na ruta ordinaria de internet cando o túnel falla, salvo que bloquee ese prefixo na devasa do anfitrión.