¿Por qué falla tu VPN invitado detrás del NAT de VirtualBox?

Un navegador dentro de la máquina virtual funciona, y el cliente VPN en el mismo invitado no puede transportar datos. El invitado tiene conectividad, está claro, así que el fallo está en lo que necesita el protocolo exterior de la VPN y en lo que dejará pasar el NAT virtual. Tres condiciones deciden el resultado: qué proceso posee la VPN, cómo se ve el intercambio exterior en el cable y si el modo del adaptador es el que crees. Nombrar la condición que puedes cambiar es toda la decisión.

Localiza el proceso de la VPN antes de culpar a la red

Decide primero si la VPN se ejecuta dentro del invitado o en el anfitrión, porque los dos arreglos fallan de forma distinta. Un cliente dentro del invitado construye su propia conexión exterior a través del adaptador del invitado y de cualquier traducción que haya detrás. Una VPN del anfitrión captura el tráfico del invitado según la política del anfitrión y del hipervisor, que es un punto de captura separado con sus propias reglas. Pueden ejecutarse a la vez y confundir las pruebas, así que identifica la que debe transportar este tráfico antes de tocar cualquiera.

Anota el modo del adaptador del invitado ahora, antes de cambiar nada. Ese único valor explica la mayor parte de lo que sigue, y es lo primero que cualquiera te preguntará más adelante.

El intercambio exterior decide la compatibilidad

La guía de redes de VirtualBox enumera limitaciones del NAT que importan aquí: no dejará pasar protocolos distintos de TCP y UDP, GRE aparece como no admitido y PPTP se da como ejemplo afectado. PPTP usa un intercambio de control TCP y GRE para los datos, así que la conexión de control puede tener éxito mientras la ruta de datos no puede cruzar la misma frontera. Son dos pruebas distintas y solo una trata del transporte de tráfico. Permitir el puerto TCP 47 en una regla de cortafuegos no es lo mismo que permitir el protocolo IP 47, y los dos se confunden constantemente.

Mantén la limitación ligada a este arreglo de NAT y no a cada dispositivo que use la palabra NAT. Un router físico puede dejar pasar GRE sin queja mientras el NAT virtual lo descarta, y otro hipervisor toma su propia decisión sobre qué reenvía. Donde la organización ofrezca un transporte aprobado dentro de TCP o UDP, usa su cliente y perfil admitidos para esa ruta. La compatibilidad es un requisito entre varios y no establece ni la confianza del servidor ni el permiso de la cuenta ni rutas privadas que funcionen.

Qué cambia realmente el puente

Un puente entrega la dirección MAC del invitado al segmento físico en lugar de esconderla tras la traducción. El invitado toma entonces una dirección de cualquier servidor DHCP que sirva a ese segmento, responde ARP para esa dirección y aparece ante el conmutador superior como un puerto más. Eso elimina la ruta de traducción virtual, que es exactamente por lo que una receta antigua lo recomienda, y cambia otras tres cosas en el mismo momento. El direccionamiento ahora viene del segmento local y no del hipervisor, la exposición significa que el invitado es visible para ese segmento, y la admisión depende del puerto del conmutador y de su política. Cada una de ellas puede ser un motivo para rechazar el cambio, y ninguna trata del protocolo VPN.

El puenteo no instala un complemento que falta, no proporciona un agente secreto no disponible ni repara un rechazo de autenticación. Tampoco convierte un protocolo obsoleto en una buena elección, y donde el operador tiene un reemplazo mantenido, la decisión es ese y no cambiar el hipervisor. El reenvío de puertos es un tercer papel del todo: publica un servicio entrante y no hace nada por el protocolo exterior de un cliente saliente.

Dos túneles, dos rastros de pruebas

Una VPN invitado necesita una ruta utilizable desde la interfaz del invitado hasta su par antes de que importe cualquier dirección interna o ruta privada. Donde haya una VPN del anfitrión, puede retransmitir o bloquear ese intercambio exterior según su propia política, y el túnel interno del invitado solo empieza después de que el exterior tenga éxito. La cobertura de ninguna capa puede leerse de un solo icono conectado ni de la dirección pública del navegador del anfitrión.

Quédate con el primer mensaje de error y no con el último, porque el fallo más temprano nombra la capa. Cambia un arreglo de red admitido cada vez, con el mismo perfil de invitado y las mismas credenciales, para que la comparación signifique algo. Decide por el fallo qué etapa se rompió: integración local, transporte, autenticación o acceso a recursos una vez levantado el túnel. Cada una tiene un dueño distinto, y solo una es una cuestión de hipervisor.

Qué condición te bloquea de verdad

A estas alturas la decisión se reduce a tres preguntas con respuestas distintas. Si el protocolo exterior queda fuera de TCP y UDP, el modo NAT es la restricción, y el camino adelante es el puente o un transporte TCP/UDP aprobado. Si el intercambio exterior se completa y la ruta de datos no, la restricción es la misma que se ve en la segunda prueba. Si el túnel se levanta y los recursos no responden, el problema ya ha pasado del hipervisor al enrutamiento o a la política.

Escribe la respuesta con el modo del adaptador al lado, o la siguiente persona repetirá la misma tarde. Prueba la aplicación real y la resolución de nombres dentro del invitado después de cualquier corrección, luego vuelve a conectarte y ejercita la política de fallo. Una página web que funciona a través del túnel solo demuestra que la ruta web funciona, que es una afirmación más pequeña de lo que parece en ese momento.