La VM de Vagrant desaparece al conectar la VPN: de quién es la ruta rota

La máquina respondía hace un minuto, la VPN se conectó y ahora la misma dirección agota el tiempo. Tres fallos producen ese síntoma y viven en máquinas distintas. El equipo anfitrión puede perder la ruta hacia la red privada, el rango NAT del invitado puede chocar con un rango que el túnel ahora anuncia, o un túnel completo puede apropiarse de todas las rutas del anfitrión. Averigüe cuál ocurrió antes de cambiar cualquier configuración, porque cada arreglo vive en otro lugar.

Mire la ruta, no la máquina

Observe la decisión de enrutamiento del anfitrión para la dirección del invitado mientras el túnel está activo. Una ruta que sigue apuntando al adaptador solo de anfitrión no es el problema. Una ruta que ahora apunta al adaptador de la VPN sí es el problema, y la cambió el cliente, no usted. Que el adaptador conserve su dirección dice que la interfaz sobrevivió, un hecho distinto de que el camino sobreviva.

Una sesión SSH que cae justo en el momento de conectar es un comportamiento esperado. El cliente recicla adaptadores e instala rutas, así que la conexión muere durante unos segundos. La falla es la conexión que nunca vuelve, no la que parpadeó.

Capture la tabla antes del túnel y otra vez después, y luego compare esas dos salidas. La diferencia es el diagnóstico, y además resulta ser la evidencia que pedirá el responsable de la red.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Lea la tabla del anfitrión antes y después

En Linux la preferencia entre rutas superpuestas viene de la longitud del prefijo y de la métrica, así que una ruta VPN más específica gana aunque sea incorrecta. En Windows la métrica de la interfaz decide el empate, y el adaptador del túnel suele llegar con una métrica más baja que el virtual. En ambos casos el síntoma visible es idéntico: los paquetes salen por el adaptador del túnel y desaparecen.

Imprima los adaptadores y sus métricas junto a la ruta del prefijo del invitado. Ese par de salidas responde la pregunta de la propiedad de un vistazo.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Si la ruta cambió pero la métrica del adaptador no, el cliente instaló una ruta competidora. Si la métrica cambió, el cliente reordenó los adaptadores. Ambas son reparables, y se reparan en sitios distintos.

Cuando el rango NAT del invitado es la colisión

VirtualBox NAT usa 10.0.2.0/24 por defecto, y un túnel que empuja el mismo rango hace que el invitado envíe ese tráfico a su puerta de enlace NAT en lugar del destino real. El paquete nunca sale del anfitrión, así que ningún registro de cortafuegos del otro lado lo mostrará. Docker Machine tiene la misma clase de conflicto en su plan solo de anfitrión, y cambiar ese plan puede exigir recrear la máquina junto con sus certificados.

Elija el reemplazo enumerando lo que el túnel ya anuncia, luego lo que usa la red de la oficina y luego lo que ha reclamado cada adaptador virtual de este anfitrión. La superposición es lo que rompe el enrutamiento, y el parecido es irrelevante. Un rango puede estar entero dentro de otro mientras a primera vista no se parece en nada.

Fije el nuevo rango al crear la máquina, o cámbielo y recargue, y luego pruebe de nuevo la conexión que falla desde el invitado. La tabla del propio invitado es la vista que importa.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Restaure el camino sin pelear con el cliente

Cada plataforma ofrece una forma de volver a poner delante el prefijo solo de anfitrión. En macOS una ruta estática a la interfaz solo de anfitrión funciona hasta la siguiente conexión. En Windows una métrica de interfaz más baja en el adaptador virtual lo mantiene preferido. En Linux una operación de reemplazo cubre un solo prefijo. Las tres son soluciones provisionales, porque un cliente que reafirma sus rutas las deshará.

Programe la comprobación en lugar de una reconexión ciega al arrancar. Un script pequeño que imprime la ruta del prefijo del invitado tras cada conexión convierte un misterio en una línea de un registro.

Si el perfil es un túnel completo, pida al responsable de la red un túnel dividido o una excepción documentada. Añadir en silencio rutas que eluden una política de seguridad no es un arreglo, es un segundo problema que llega más tarde con un auditor detrás.

Compruebe el arreglo en ambos lados

Verifique tres caminos tras el cambio: anfitrión al invitado, invitado al anfitrión corporativo e invitado a internet. Un arreglo que restaura uno y rompe otro es un cambio de configuración disfrazado de reparación. Capture las mismas salidas que recogió antes del cambio para que la comparación sea entre iguales.

Anote la interfaz, la métrica y la ruta que cambiaron, junto con la hora, para que la próxima vez sea una consulta y no una reconstrucción. Esa nota vale más que un hilo largo de tickets.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Cuando el anfitrión vuelve a alcanzar al invitado y el invitado alcanza la LAN, ha restaurado el camino con el que empezó. Cuando solo uno de los dos funciona, la falla restante está en el territorio del otro propietario, y la diferencia le dice cuál es ese territorio.