A VM do Vagrant desaparece quando a VPN se liga: de quem é a rota quebrada

A máquina respondia há um minuto, a VPN ligou-se e agora o mesmo endereço esgota o tempo. Três falhas produzem esse sintoma, e vivem em máquinas diferentes. O anfitrião pode perder a rota para a rede privada, o intervalo NAT do convidado pode colidir com um intervalo que o túnel agora anuncia, ou um túnel completo pode assumir a propriedade de todas as rotas do anfitrião. Descubra qual aconteceu antes de mudar qualquer configuração, porque cada correção vive noutro lugar.

Olhe para a rota, não para a máquina

Veja a decisão de encaminhamento do anfitrião para o endereço do convidado enquanto o túnel está ativo. Uma rota que ainda aponta para o adaptador só de anfitrião não é o problema. Uma rota que agora aponta para o adaptador da VPN é o problema, e foi o cliente que a mudou, não você. O adaptador manter o endereço diz que a interface sobreviveu, um facto diferente de o caminho sobreviver.

Uma sessão SSH que cai exatamente no momento da ligação é comportamento esperado. O cliente recicla adaptadores e instala rotas, por isso a ligação morre durante alguns segundos. A falha é a ligação que nunca regressa, não a que apenas piscou.

Capture a tabela antes do túnel e outra vez depois, e depois compare essas duas saídas. A diferença é o diagnóstico, e é também a prova que o responsável da rede vai pedir.

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

Leia a tabela do anfitrião antes e depois

No Linux a preferência entre rotas sobrepostas vem do comprimento do prefixo e da métrica, por isso uma rota VPN mais específica ganha mesmo quando está errada. No Windows a métrica da interface decide o empate, e o adaptador do túnel chega normalmente com uma métrica mais baixa do que o virtual. Em ambos os casos o sintoma visível é idêntico: os pacotes saem pelo adaptador do túnel e desaparecem.

Imprima os adaptadores e as suas métricas ao lado da rota do prefixo do convidado. Esse par de saídas responde à pergunta da propriedade num só olhar.

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 rota mudou mas a métrica do adaptador não, o cliente instalou uma rota concorrente. Se a métrica mudou, o cliente reordenou os adaptadores. As duas são reparáveis, e são reparadas em sítios diferentes.

Quando o intervalo NAT do convidado é a colisão

O VirtualBox NAT usa 10.0.2.0/24 por defeito, e um túnel que empurra o mesmo intervalo faz o convidado enviar esse tráfego para a sua gateway NAT em vez do destino real. O pacote nunca sai do anfitrião, por isso nenhum registo de firewall do outro lado o vai mostrar. O Docker Machine tem a mesma classe de conflito no seu plano só de anfitrião, e mudar esse plano pode exigir recriar a máquina com os seus certificados.

Escolha a substituição listando o que o túnel já anuncia, depois o que a rede do escritório usa, e depois o que cada adaptador virtual deste anfitrião reivindicou. É a sobreposição que quebra o encaminhamento, e a semelhança é irrelevante. Um intervalo pode estar inteiro dentro de outro enquanto à primeira vista não se parece nada.

Defina o novo intervalo na criação da máquina, ou altere-o e recarregue, e depois teste novamente a ligação que falha a partir do convidado. A tabela do próprio 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 caminho sem lutar com o cliente

Cada plataforma oferece uma forma de voltar a pôr o prefixo só de anfitrião à frente. No macOS uma rota estática para a interface só de anfitrião funciona até à ligação seguinte. No Windows uma métrica de interface mais baixa no adaptador virtual mantém-no preferido. No Linux uma operação de substituição cobre um único prefixo. As três são paliativos, porque um cliente que reafirma as suas rotas vai desfazê-las.

Programe a verificação em vez de uma religação cega no arranque. Um pequeno script que imprime a rota do prefixo do convidado após cada ligação transforma um mistério numa linha de registo.

Se o perfil é um túnel completo, peça ao responsável da rede um túnel dividido ou uma exceção documentada. Acrescentar rotas em silêncio que contornam uma política de segurança não é uma correção, é um segundo problema que chega mais tarde com um auditor atrás.

Verifique a correção dos dois lados

Verifique três caminhos depois da alteração: anfitrião para convidado, convidado para o anfitrião corporativo e convidado para a internet. Uma correção que restaura um e quebra outro é uma alteração de configuração disfarçada de reparação. Capture as mesmas saídas que recolheu antes da alteração para que a comparação seja entre iguais.

Anote a interface, a métrica e a rota que mudaram, junto com a hora, para que a próxima ocorrência seja uma consulta e não uma reconstrução. Essa nota vale mais do que uma longa linha 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

Quando o anfitrião volta a alcançar o convidado e o convidado alcança a LAN, restaurou o caminho com que começou. Quando só um dos dois funciona, a falha restante está no território do outro proprietário, e a diferença diz-lhe qual é esse território.