Verificação de rota VPN no macOS: route get sem alterar nada
Uma captura da rota padrão pode perder um caminho mais específico. Consulte o destino que falha com route get, leia a interface e o gateway e não altere nada.
Um usuário chega à intranet na rede do escritório e não pelo túnel, enquanto os Ajustes ainda mostram a VPN como conectada. Editar a tabela de rotas nesse momento corre o risco de cortar a sessão remota que você usa para diagnosticar. Pergunte ao kernel qual caminho ele escolheria para o host que falha. O utilitário route do macOS tem uma operação get que responde exatamente a isso, para um destino, sem alterar nada.
Consulte o host que falha, não a rota padrão
Uma captura da rota padrão diz muito pouco num Mac moderno, porque um destino mais específico ou uma política restrita podem sobrepor o que a rota padrão parece dizer. O túnel pode estar ativo, a rota padrão pode parecer correta e, mesmo assim, o único host de que você precisa pode estar roteado para outro lugar. Consulte o endereço que falha e deixe o kernel nomear o caminho escolhido.
A forma é route -n get seguida do endereço: route -n get 203.0.113.10, em que o endereço de documentação representa o seu alvo. Use o destino autorizado e a família de endereços correspondente, porque uma resposta IPv4 não diz nada sobre um recurso apenas IPv6. A documentação do utilitário route descreve a operação get e os campos que ela imprime.
Leia a interface e o gateway como evidência
Execute a consulta antes de conectar a VPN e depois novamente, e compare as linhas de interface e de gateway. A diferença entre essas duas respostas é o que o túnel realmente mudou, e é muito mais útil do que despejar a tabela inteira. Se a interface for idêntica nas duas execuções, a rota nunca foi o problema e você pode parar de olhar o roteamento.
Anote o destino, a interface, o gateway e a hora da consulta antes de tirar uma conclusão. A saída é evidência, não diagnóstico: a mesma interface pode estar correta para um host e errada para outro quando há tunelamento dividido envolvido.
Uma rota correta não é uma requisição que funciona
Uma rota informa qual interface o kernel usaria, nada mais. O DNS, um firewall do host e a autorização da aplicação ficam todos acima dessa decisão, e a requisição pode falhar depois que o roteamento dá certo. Preserve o sintoma exato antes de seguir, porque "não consegue conectar" e "conecta mas devolve um erro" são investigações diferentes com próximos passos diferentes. A visão do resolvedor e a visão da interface complementam a consulta de destino em vez de substituí-la.
Uma listagem da tabela de roteamento ainda tem o seu lugar: é assim que você percebe uma rota padrão inesperada. Uma rota padrão comum que resta não prova que a VPN não é usada, porque entradas mais específicas vencem sobre ela.
Mantenha o endpoint e o recurso separados
Há duas consultas envolvidas e elas respondem a perguntas diferentes. Alcançar o endpoint é uma viagem externa pela rede física. Alcançar a aplicação acontece dentro do túnel, num endereço que só existe do lado privado. Confundir os dois produz o clássico laço falso, em que o endpoint parece roteado pelo túnel que ele encerra. Consulte os dois endereços separadamente, rotule cada resultado, e a confusão desaparece.
A sobreposição de prefixos é o outro caso que vale a pena conhecer. Quando as faixas local e remota se sobrepõem, decide a correspondência do prefixo mais longo, então uma sub-rede local sobreposta pode ofuscar o endereço remoto que você esperava. O destino privado então parece idêntico a um local, e a correção pertence ao plano de endereçamento e não à tabela de rotas. A consulta get mostra qual interface venceu, e esse é o fato de que você precisa antes de alterar qualquer coisa.
Primeiro leia, depois altere
Mantenha route add e route delete fora da primeira passagem. Num Mac que você administra remotamente, uma edição descuidada da tabela pode levar embora justamente o caminho de volta para a máquina e não deixar ninguém capaz de concluir o diagnóstico. Decida qual é a rota correta, anote como desfazer a alteração e só então execute. A inspeção não tem esse rabo.
O mesmo cuidado vale para limpar caches e reiniciar serviços de rede como primeiro movimento, porque ambos destroem a evidência que você estava prestes a ler. As verificações somente leitura são baratas, repetíveis e seguras em qualquer ordem. Faça delas o passo padrão, e recorra a uma alteração só quando a evidência apontar para ela.