A VM de Vagrant desaparece ao conectar a VPN: de quen é a ruta rota

A máquina respondía hai un minuto, a VPN conectouse e agora a mesma dirección esgota o tempo. Tres fallos producen ese síntoma e viven en máquinas distintas. O anfitrión pode perder a ruta cara á rede privada, o rango NAT do convidado pode chocar cun rango que o túnel agora anuncia, ou un túnel completo pode apropiarse de todas as rutas do anfitrión. Aventure cal ocorreu antes de cambiar calquera configuración, porque cada arranxo vive noutro lugar.

Mire a ruta, non a máquina

Observe a decisión de encamiñamento do anfitrión para o enderezo do convidado mentres o túnel está activo. Unha ruta que aínda apunta ao adaptador só de anfitrión non é o problema. Unha ruta que agora apunta ao adaptador da VPN si é o problema, e cambiouna o cliente, non vostede. Que o adaptador conserve o seu enderezo di que a interface sobreviviu, un feito distinto de que o camiño sobreviva.

Unha sesión SSH que cae xusto no momento de conectar é un comportamento esperado. O cliente recicla adaptadores e instala rutas, así que a conexión morre durante uns segundos. A falla é a conexión que nunca volve, non a que parpadeou.

Capture a táboa antes do túnel e outra vez despois, e despois compare esas dúas saídas. A diferenza é o diagnóstico, e ademais resulta ser a evidencia que pedirá o responsable da rede.

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

Lea a táboa do anfitrión antes e despois

En Linux a preferencia entre rutas superpostas vén da lonxitude do prefixo e da métrica, así que unha ruta VPN máis específica gaña aínda que sexa incorrecta. En Windows a métrica da interface decide o empate, e o adaptador do túnel adoita chegar cunha métrica máis baixa que o virtual. En ambos os casos o síntoma visible é idéntico: os paquetes saen polo adaptador do túnel e desaparecen.

Imprima os adaptadores e as súas métricas xunto á ruta do prefixo do convidado. Ese par de saídas responde a pregunta da propiedade dunha ollada.

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

Se a ruta cambiou pero a métrica do adaptador non, o cliente instalou unha ruta competidora. Se a métrica cambiou, o cliente reordenou os adaptadores. Ambas son reparables, e repáranse en sitios distintos.

Cando o rango NAT do convidado é a colisión

VirtualBox NAT usa 10.0.2.0/24 por defecto, e un túnel que empurra o mesmo rango fai que o convidado envíe ese tráfico á súa pasarela NAT no canto do destino real. O paquete nunca sae do anfitrión, así que ningún rexistro de devasas do outro lado o mostrará. Docker Machine ten a mesma clase de conflito no seu plan só de anfitrión, e cambiar ese plan pode esixir recrear a máquina xunto cos seus certificados.

Escolla o substituto enumerando o que o túnel xa anuncia, despois o que usa a rede da oficina e despois o que reclamou cada adaptador virtual deste anfitrión. A superposición é o que rompe o encamiñamento, e o parecido é irrelevante. Un rango pode estar enteiro dentro doutro mentres a primeira vista non se parece en nada.

Fixe o novo rango ao crear a máquina, ou cámbieo e recargue, e despois probe de novo a conexión que falla desde o convidado. A táboa do propio convidado é a 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 o camiño sen pelexar co cliente

Cada plataforma ofrece un xeito de volver poñer diante o prefixo só de anfitrión. En macOS unha ruta estática cara á interface só de anfitrión funciona ata a seguinte conexión. En Windows unha métrica de interface máis baixa no adaptador virtual manteno preferido. En Linux unha operación de substitución cobre un só prefixo. As tres son solucións temporais, porque un cliente que reafirma as súas rutas desfaránas.

Programe a comprobación en lugar dunha reconexión cega ao arrincar. Un script pequeno que imprime a ruta do prefixo do convidado tras cada conexión converte un misterio nunha liña dun rexistro.

Se o perfil é un túnel completo, pida ao responsable da rede un túnel dividido ou unha excepción documentada. Engadir en silencio rutas que eluden unha política de seguridade non é un arranxo, é un segundo problema que chega máis tarde cun auditor detrás.

Comprobe o arranxo nos dous lados

Verifique tres camiños tras o cambio: anfitrión ao convidado, convidado ao anfitrión corporativo e convidado a internet. Un arranxo que restaura un e rompe outro é un cambio de configuración disfrazado de reparación. Capture as mesmas saídas que recolleu antes do cambio para que a comparación sexa entre iguais.

Anote a interface, a métrica e a ruta que cambiaron, xunto coa hora, para que a próxima vez sexa unha consulta e non unha reconstrución. Esa nota vale máis que un fío longo 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

Cando o anfitrión volve alcanzar o convidado e o convidado alcanza a LAN, restaurou o camiño co que comezou. Cando só un dos dous funciona, a falla restante está no territorio do outro propietario, e a diferenza dille cal é ese territorio.