Rede local inacessível com a VPN ligada? Quatro verificações

O túnel sobe, a intranet aparece e a impressora para de responder. Nada na LAN falhou; o cliente mudou o caminho que usa para endereços que já não trata como locais. Percorra as quatro verificações abaixo por ordem e pare quando uma delas mostrar uma discrepância concreta, porque o mesmo sintoma tem quatro causas comuns e só uma delas se corrige editando a VPN.

Primeiro, veja a tabela de rotas que o cliente instalou

Abra a tabela de rotas do cliente enquanto a VPN está ligada. No Linux use ip route, no Windows use route print ou Get-NetRoute, e no macOS use netstat -rn. Você procura uma rota predefinida pelo túnel e o que aconteceu à rota predefinida física.

Um cliente de túnel completo costuma acrescentar duas rotas meio-predefinidas, 0.0.0.0/1 e 128.0.0.0/1, em vez de substituir 0.0.0.0/0. A predefinida original continua visível mas perde todas as consultas, e é por isso que a tabela pode parecer intacta enquanto todo o tráfego fora da sub-rede se desloca. Se o cliente de VPN oferece uma opção de túnel dividido e a política o permite, essa é a reparação mais limpa.

Se o túnel tiver de continuar a ser a predefinida, fixe antes a sub-rede local. No Linux a rota nomeia a interface física e o gateway; no Windows acrescente -p para a tornar persistente e leia o número da interface em route print em vez de o adivinhar:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Uma rota fixa só se mantém enquanto o endereço que nomeia não mudar. Um portátil que recebe um número novo para o adaptador Wi-Fi a cada ligação volta a quebrar a regra, por isso verifique o endereço da interface antes de concluir que a correção falhou.

Segundo, confirme que o endereço era local desde o início

Se o destino está dentro da sub-rede ligada, a predefinida do túnel nunca se aplica e a VPN não é a causa. Uma impressora em 192.168.1.40 num cliente com 192.168.1.0/24 usa a rota ligada; se esse endereço falha, olhe para o dispositivo, o switch ou a firewall do cliente em vez da VPN.

O caso que engana as pessoas é um endereço público para um servidor local. De dentro da LAN, chegar ao endereço WAN do roteador e voltar exige hairpin NAT, e muitos roteadores simplesmente não o implementam para encaminhamento de portas. Teste o endereço privado ao lado do público. Se o privado funciona e o público não, a VPN apenas expôs uma limitação de NAT que já existia.

Um nome de anfitrião piora isto. Se o nome local agora resolve para o endereço público, o cliente vai continuar a tentar o caminho que não pode voltar. Use o endereço privado para o teste e depois corrija o nome em vez de acrescentar outro encaminhamento de portas.

Terceiro, veja quem responde aos nomes agora

Um resolvedor empresarial conhece a intranet e normalmente nada sabe sobre o nome de anfitrião de um NAS, o nome Bonjour de uma impressora ou o alias local de um roteador. Quando a VPN empurra os seus servidores DNS, esses nomes deixam de resolver ainda que os endereços continuem alcançáveis. Consulte o nome diretamente e compare a resposta com o endereço que sabe que o dispositivo tem.

No Linux, resolvectl query nas.local mostra qual resolvedor respondeu. No Windows, nslookup nas.local nomeia o servidor, e ipconfig /all mostra a ordem dos resolvedores. Se o sufixo local passou a ser tratado pelo resolvedor empresarial, encaminhe esse sufixo de volta para o resolvedor local ou use o endereço IP para o dispositivo.

A descoberta é uma camada separada. mDNS e broadcast não atravessam um túnel encaminhado, por isso um dispositivo pode ser alcançável por endereço enquanto o nome fica invisível. Um refletor ou uma entrada DNS local resolvem isso; uma rota não.

Quarto, verifique se a outra máquina também está numa VPN

Quando a máquina que quer alcançar também corre um cliente de VPN, a sua sessão pode chegar enquanto a resposta sai pelo outro túnel. Isso produz uma ligação que se estabelece e depois encrava, ou uma tentativa de RDP e SSH que expira sem erro do seu lado. Verifique a tabela de rotas e o caminho predefinido do outro anfitrião antes de culpar o seu cliente.

Verifique também o endereço em que o serviço escuta. Um listener ligado apenas ao endereço do túnel aceita ligações da VPN e recusa-as da LAN, mesmo quando o encaminhamento é perfeito. Isso é configuração do serviço, não caminho de rede, e é comum em interfaces de gestão fechadas ao endereço da VPN.

Mantenha um caminho de gestão que não dependa do túnel: uma rota estática que nomeie a sua rede de origem, outra interface ligada à LAN, ou uma consola que contorne o túnel por completo. Desenhar esse caminho depois de a sessão cair é muito mais difícil do que acrescentá-lo antes da ligação seguinte.

Aplique a correção que corresponde à verificação que falhou

Se a tabela de rotas mostrou uma captura meio-predefinida, escolha túnel dividido quando a política o permite e uma rota local fixa quando não permite. Se o endereço se revelou público, mude o teste e o nome para o endereço privado. Se o resolvedor mudou de mãos, limite ao sufixo local ou use o endereço. Se o outro anfitrião está em túnel, corrija o caminho de retorno ou a ligação do listener.

Mude uma coisa e repita a mesma verificação. Uma rota acrescentada para a sub-rede errada, um sufixo de resolvedor com um erro de escrita e uma rota fixa numa interface que recebe números novos parecem todos a falha original. A repetição é o que separa uma correção de uma coincidência.

Anote a rota, o endereço e o resolvedor que funcionaram com a VPN ligada. A próxima religação muda pelo menos um deles, e a nota transforma a próxima falha numa comparação curta em vez de uma nova investigação.