Por que falla a túa VPN convidada detrás do NAT de VirtualBox?

Un navegador dentro da máquina virtual funciona, e o cliente VPN no mesmo convidado non pode transportar datos. O convidado ten conectividade, está claro, así que o fallo está no que necesita o protocolo exterior da VPN e no que deixará pasar o NAT virtual. Tres condicións deciden o resultado: que proceso posúe a VPN, como se ve o intercambio exterior no cable e se o modo do adaptador é o que cres. Nomear a condición que podes cambiar é toda a decisión.

Localiza o proceso da VPN antes de culpar á rede

Decide primeiro se a VPN se executa dentro do convidado ou no anfitrión, porque os dous arranxos fallan de forma distinta. Un cliente dentro do convidado constrúe a súa propia conexión exterior a través do adaptador do convidado e de calquera tradución que haxa detrás. Unha VPN do anfitrión captura o tráfico do convidado segundo a política do anfitrión e do hipervisor, que é un punto de captura separado coas súas propias regras. Poden executarse á vez e confundir as probas, así que identifica a que debe transportar este tráfico antes de tocar calquera.

Anota o modo do adaptador do convidado agora, antes de cambiar nada. Ese único valor explica a maior parte do que segue, e é o primeiro que calquera che preguntará máis adiante.

O intercambio exterior decide a compatibilidade

A guía de redes de VirtualBox enumera limitacións do NAT que importan aquí: non deixará pasar protocolos distintos de TCP e UDP, GRE aparece como non admitido e PPTP dáse como exemplo afectado. PPTP usa un intercambio de control TCP e GRE para os datos, así que a conexión de control pode ter éxito mentres a ruta de datos non pode cruzar a mesma fronteira. Son dúas probas distintas e só unha trata do transporte de tráfico. Permitir o porto TCP 47 nunha regra de cortafuegos non é o mesmo que permitir o protocolo IP 47, e os dous confúndense constantemente.

Mantén a limitación ligada a este arranxo de NAT e non a cada dispositivo que use a palabra NAT. Un router físico pode deixar pasar GRE sen queixa mentres o NAT virtual o descarta, e outro hipervisor toma a súa propia decisión sobre que reenvía. Onde a organización ofreza un transporte aprobado dentro de TCP ou UDP, usa o seu cliente e perfil admitidos para esa ruta. A compatibilidade é un requisito entre varios e non establece nin a confianza do servidor nin o permiso da conta nin rutas privadas que funcionen.

Que cambia de verdade a ponte

Unha ponte entrega o enderezo MAC do convidado ao segmento físico en lugar de escondelo tras a tradución. O convidado toma entón un enderezo de calquera servidor DHCP que sirva ese segmento, responde ARP para ese enderezo e aparece ante o conmutador superior como un porto máis. Iso elimina a ruta de tradución virtual, que é exactamente por que unha receita antiga o recomenda, e cambia outras tres cousas no mesmo momento. O direccionamento agora vén do segmento local e non do hipervisor, a exposición significa que o convidado é visible para ese segmento, e a admisión depende do porto do conmutador e da súa política. Cada unha delas pode ser un motivo para rexeitar o cambio, e ningunha trata do protocolo VPN.

A ponte non instala un complemento que falta, non fornece un axente secreto non dispoñible nin repara un rexeitamento de autenticación. Tampouco converte un protocolo obsoleto nunha boa elección, e onde o operador ten un substituto mantido, a decisión é ese e non cambiar o hipervisor. O reenvío de portos é un terceiro papel do todo: publica un servizo entrante e non fai nada polo protocolo exterior dun cliente saínte.

Dous túneles, dúas pistas de probas

Unha VPN convidada necesita unha ruta utilizábel desde a interface do convidado ata o seu par antes de que importe calquera enderezo interno ou ruta privada. Onde haxa unha VPN do anfitrión, pode retransmitir ou bloquear ese intercambio exterior segundo a súa propia política, e o túnel interno do convidado só comeza despois de que o exterior teña éxito. A cobertura de ningunha capa pode lerse dun só icona conectado nin do enderezo público do navegador do anfitrión.

Queda coa primeira mensaxe de erro e non coa última, porque o fallo máis temperán nomea a capa. Cambia un arranxo de rede admitido cada vez, co mesmo perfil de convidado e as mesmas credenciais, para que a comparación signifique algo. Decide polo fallo que etapa se rompeu: integración local, transporte, autenticación ou acceso a recursos unha vez levantado o túnel. Cada unha ten un dono distinto, e só unha é unha cuestión de hipervisor.

Que condición te bloquea realmente

A estas alturas a decisión redúcese a tres preguntas con respostas distintas. Se o protocolo exterior queda fóra de TCP e UDP, o modo NAT é a restrición, e o camiño adiante é a ponte ou un transporte TCP/UDP aprobado. Se o intercambio exterior se completa e a ruta de datos non, a restrición é a mesma que se ve na segunda proba. Se o túnel se levanta e os recursos non responden, o problema xa pasou do hipervisor ao encamiñamento ou á política.

Escribe a resposta co modo do adaptador ao lado, ou a seguinte persoa repetirá a mesma tarde. Proba a aplicación real e a resolución de nomes dentro do convidado despois de calquera corrección, logo volve conectarte e exercita a política de fallo. Unha páxina web que funciona a través do túnel só demostra que a ruta web funciona, que é unha afirmación máis pequena do que parece nese momento.