Por que a sua VPN convidada falha atrás do NAT do VirtualBox?

Um navegador dentro da máquina virtual funciona, e o cliente VPN no mesmo convidado não consegue transportar dados. O convidado tem claramente conectividade, portanto a falha está no que o protocolo externo da VPN exige e no que o NAT virtual deixará passar. Três condições decidem o resultado: que processo possui a VPN, como a troca externa se parece no cabo e se o modo do adaptador é o que pensa. Nomear a condição que pode mudar é toda a decisão.

Localize o processo da VPN antes de culpar a rede

Decida primeiro se a VPN corre dentro do convidado ou no anfitrião, porque os dois arranjos falham de forma diferente. Um cliente dentro do convidado constrói a sua própria ligação externa através do adaptador do convidado e de qualquer tradução que esteja por trás. Uma VPN do anfitrião captura o tráfego do convidado segundo a política do anfitrião e do hipervisor, que é um ponto de captura separado com as suas próprias regras. Podem correr ao mesmo tempo e confundir as provas, por isso identifique qual deve transportar este tráfego antes de tocar em qualquer uma.

Anote o modo do adaptador do convidado agora, antes de mudar qualquer coisa. Esse único valor explica a maior parte do que se segue, e é a primeira coisa que alguém lhe perguntará mais tarde.

A troca externa decide a compatibilidade

O guia de redes do VirtualBox enumera limitações do NAT que importam aqui: não deixa passar protocolos além de TCP e UDP, o GRE é indicado como não suportado e o PPTP é dado como exemplo afetado. O PPTP usa uma troca de controlo TCP e GRE para os dados, pelo que a ligação de controlo pode ter êxito enquanto o caminho de dados não consegue atravessar a mesma fronteira. São duas provas diferentes, e apenas uma delas diz respeito ao transporte de tráfego. Permitir a porta TCP 47 numa regra de firewall não é o mesmo que permitir o protocolo IP 47, e os dois são constantemente confundidos.

Mantenha a limitação ligada a este arranjo NAT e não a cada dispositivo que usa a palavra NAT. Um router físico pode deixar passar GRE sem queixa enquanto o NAT virtual o descarta, e outro hipervisor faz a sua própria escolha sobre o que reencaminha. Onde a organização oferece um transporte aprovado dentro de TCP ou UDP, use o cliente e o perfil suportados para esse caminho. A compatibilidade é um requisito entre vários, e não estabelece nem a confiança no servidor, nem a permissão da conta, nem rotas privadas que funcionem.

O que a ponte muda realmente

Uma ponte entrega o endereço MAC do convidado ao segmento físico em vez de o esconder atrás da tradução. O convidado recebe então um endereço de qualquer servidor DHCP que sirva esse segmento, responde a ARP para esse endereço e aparece ao comutador a montante como mais uma porta. Isso remove o caminho de tradução virtual, que é exatamente a razão pela qual uma receita antiga o recomenda, e altera outras três coisas no mesmo momento. O endereçamento vem agora do segmento local e não do hipervisor, a exposição significa que o convidado é visível para esse segmento, e a admissão depende da porta do comutador e da sua política. Cada uma delas pode ser um motivo para recusar a mudança, e nenhuma diz respeito ao protocolo VPN.

O empentelhamento não instala um plugin em falta, não fornece um agente secreto indisponível e não repara uma rejeição de autenticação. Também não torna um protocolo obsoleto numa boa escolha, e onde o operador tem um substituto mantido, a decisão é esse e não a mudança do hipervisor. O reencaminhamento de portas é um terceiro papel completamente diferente: publica um serviço de entrada e não faz nada pelo protocolo externo de um cliente de saída.

Dois túneis, dois rastos de provas

Uma VPN convidada precisa de um caminho utilizável da interface do convidado até ao seu par antes de qualquer endereço interno ou rota privada importar. Onde existe uma VPN do anfitrião, pode reencaminhar ou bloquear essa troca externa segundo a sua própria política, e o túnel interno do convidado só começa depois de o externo ter êxito. A cobertura de nenhuma camada pode ser lida a partir de um único ícone ligado ou do endereço público do navegador do anfitrião.

Guarde a primeira mensagem de erro e não a última, porque a falha mais precoce nomeia a camada. Mude um arranjo de rede suportado de cada vez, com o mesmo perfil de convidado e as mesmas credenciais, para que a comparação signifique algo. Decida pela falha qual etapa se rompeu: integração local, transporte, autenticação ou acesso a recursos depois de o túnel estar levantado. Cada uma tem um dono diferente, e apenas uma é uma questão de hipervisor.

Que condição o bloqueia realmente

A esta altura a decisão reduz-se a três perguntas com respostas diferentes. Se o protocolo externo estiver fora de TCP e UDP, o modo NAT é a restrição, e o caminho em frente é a ponte ou um transporte TCP/UDP aprovado. Se a troca externa se completar e o caminho de dados não, a restrição é a mesma que se vê na segunda prova. Se o túnel levantar e os recursos não responderem, o problema já passou do hipervisor para o encaminhamento ou a política.

Escreva a resposta com o modo do adaptador ao lado, ou a pessoa seguinte repetirá a mesma tarde. Teste a aplicação real e a resolução de nomes dentro do convidado depois de qualquer correção, e depois volte a ligar-se e exercite a política de falha. Uma página web que funciona pelo túnel prova apenas que o caminho web funciona, o que é uma afirmação menor do que parece naquele momento.