Partilhar a sessão VPN do anfitrião com um convidado VMware

A sua máquina virtual não alcança um sistema interno que funciona perfeitamente no anfitrião, e o anfitrião está ligado através de um cliente que possui a tabela de encaminhamento. Ligar o adaptador virtual ao túnel por ponte parece óbvio e falha por duas razões separadas. O que funciona é a tradução num segmento que ambas as máquinas possuem. O custo é real: cada convidado deixa de ter identidade própria na rede corporativa.

Duas razões pelas quais a ponte não pode funcionar

O adaptador do cliente transporta normalmente um único endereço, muitas vezes um /32, e o cliente reescreve as rotas do anfitrião para que o tráfego de saída comum prefira o túnel. As aplicações no anfitrião obedecem a essa tabela e chegam ao sistema privado. Um convidado ligado por ponte nunca lê a tabela, porque as suas tramas saem por um comutador abaixo da camada IP.

Colocar o adaptador do túnel dentro de uma ponte resolveria o caminho em teoria, e o controlador não o aceitará. O Windows 10 também só permite um dispositivo de ponte e retém a função de encaminhamento que deixaria uma estação de trabalho reencaminhar entre duas sub-redes. O que resta é a tradução de origem. Faça com que o tráfego do convidado pareça vir do anfitrião, e as decisões do próprio anfitrião levam-no para o túnel sem que o convidado precise de uma rota que não pode ter.

Crie um segmento que o anfitrião possua

No editor de rede virtual, adicione uma rede só de anfitrião como VMnet3 num prefixo que não encaminhe em mais lado nenhum, por exemplo 172.28.90.0/24. O anfitrião fica com 172.28.90.1 nesse adaptador e o convidado liga-se ao mesmo comutador. Desative o DHCP do hipervisor nesse segmento para que um único serviço de endereços o possua.

Confirme que o Windows vê a interface antes de construir algo por cima, porque todo o desenho depende de esse adaptador ser comum:

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

Um adaptador só de anfitrião aparece ali como qualquer um físico. É exatamente essa a diferença em relação ao adaptador do túnel, que não pode ser ligado a nada.

Traduza o prefixo do convidado

Abra uma sessão elevada e traduza o prefixo. Verifique primeiro o que já existe, porque os ambientes de execução de contentores e os hipervisores instalam as suas próprias traduções e apagar a errada quebra outro produto.

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

Depois configure o convidado com um endereço estático nesse prefixo, 172.28.90.1 como a sua porta de ligação e os endereços de resolução que o túnel dá ao anfitrião. A tradução reencaminha pacotes e não ensina nada ao convidado sobre DNS, por isso um convidado deixado no router local resolve nomes públicos e falha em todos os internos.

Verifique o primeiro salto, depois o custo

Teste a fronteira mais próxima antes de testar uma aplicação. Um traçado que para na porta de ligação do anfitrião significa que a tradução não está a acontecer, enquanto um que para para lá do anfitrião significa que o túnel está em baixo ou que o lado remoto recusou o endereço traduzido.

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

Compare com o acesso próprio do anfitrião ao mesmo destino enquanto o túnel está ativo. Se o anfitrião consegue e o convidado não, a falha está na tradução ou na configuração da porta de ligação do convidado, não na ligação.

Depois aceite a troca. Os sistemas corporativos veem agora um único endereço para cada convidado, por isso os certificados de dispositivo e as verificações de postura por dispositivo não os conseguem distinguir, e algumas políticas proíbem-no por completo. Decida também o comportamento de descarte, já que o tráfego traduzido pode cair no caminho normal da internet quando o túnel falha, a menos que bloqueie esse prefixo na firewall do anfitrião.