A VPN bloqueia a LAN local no Windows: rota ou política do cliente?

Uma impressora, um NAS ou uma máquina de desenvolvimento na sua própria secretária param de responder no momento em que a VPN do trabalho se liga. Às vezes um comando de rota resolve em segundos; às vezes a mesma rota está correta e os pacotes desaparecem mesmo assim, o que significa que está a ver outro problema com um sintoma semelhante. A decisão resume-se a três perguntas, e fazê-las na ordem errada é a razão pela qual as pessoas passam uma noite inteira a apagar e a voltar a adicionar rotas.

Três perguntas antes de qualquer comando

Primeiro: existe uma entrada para o prefixo local, e aponta para o adaptador físico? Segundo: o cliente recebe do gateway uma permissão ou uma recusa de rede local ao ligar-se? Terceiro: só precisa de acesso de saída à LAN, ou algo na internet também tem de chegar a um serviço que corre na sua máquina?

A primeira pergunta separa uma falha de encaminhamento de uma falha de filtragem. A segunda diz se uma correção de rota pode sequer funcionar. A terceira muda a reparação: uma rota corrige o tráfego de saída, enquanto um serviço de entrada inalcançável é normalmente um problema de ligação do ouvinte e de caminho de regresso que uma rota agrava.

Pergunta um: rota, filtro ou nome

Leia a tabela antes de lhe acrescentar algo. O índice da interface importa, porque cada comando de rota abaixo está ancorado nele:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Uma sub-rede ligada diretamente costuma manter uma rota on-link mesmo com o túnel ativo, pelo que a entrada pode existir e o tráfego falhar na mesma. Essa combinação é a assinatura de um filtro que corre depois do encaminhamento, e é o caso em que uma segunda rota mais específica não muda absolutamente nada.

Teste em separado por endereço e por nome. Se ping 192.168.1.50 responder e net view 192.168.1.50 não, a tabela de encaminhamento nunca foi o problema: o túnel mudou o resolvedor e o nome local já não resolve. Acrescentar uma rota por causa disso é trabalho perdido.

Pergunta dois: o gateway permite o acesso à LAN local?

Um cliente comercial instala mais do que rotas. Recebe uma política ao ligar-se, e essa política pode incluir uma permissão explícita de rede local. Em instalações Cisco IPsec a política de grupo leva a definição de tunelamento dividido e um indicador separado de acesso à LAN local; a caixa de verificação no cliente é um pedido que o gateway pode recusar. No AnyConnect o perfil controla as listas de inclusão e exclusão do split e a mesma permissão. No Windows RRAS os equivalentes são a opção de gateway predefinido no perfil mais as rotas estáticas que o servidor atribui.

Quando o indicador está desligado, o comportamento documentado é que o cliente bloqueia o tráfego para a sub-rede ligada diretamente, mesmo existindo uma rota válida e mais específica. É também por isso que rotas que o cliente não possui podem desaparecer segundos depois de as acrescentar: o cliente está a reconstruir o estado que lhe foi dito para construir, não está a lutar contra si.

O registo do cliente anota a decisão ao ligar-se, e lê-lo é mais rápido do que qualquer experiência na máquina. Se o registo disser que o acesso local está bloqueado, pare: nenhuma correção de linha de comandos sobrevive a isso, e os únicos caminhos que restam são uma mudança de política, chegar ao recurso pelo túnel, ou encerrar o cliente numa máquina virtual e deixar o anfitrião na rede local.

Pergunta três: de que direção precisa?

O tráfego de saída para um dispositivo próximo é uma questão de encaminhamento. Aponte o prefixo da LAN para o gateway local com uma métrica suficientemente baixa para vencer a rota predefinida do túnel:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

A segunda forma fixa um único dispositivo, que é o que quer quando um endereço é todo o requisito. O equivalente netsh regista a mesma decisão por nome de interface em vez de índice:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Os comandos de rota falham com O parâmetro não está correto quando o endereço e a máscara não coincidem, por exemplo um endereço de anfitrião com máscara /24. Use o endereço de rede para uma rota de sub-rede e uma máscara de anfitrião para um único anfitrião.

O tráfego de entrada é diferente. Um servidor VNC ou SSH na mesma máquina torna-se inalcançável quando as respostas a uma ligação de entrada saem pelo gateway da VPN e nunca regressam. Verifique em que escuta o serviço antes de tocar nas rotas:

netstat -ano | findstr :5900

Um ouvinte ligado a um endereço específico não responderá na outra interface. Ligá-lo a todas as interfaces é uma decisão deliberada, tomada em conjunto com uma regra de firewall limitada à rede em que confia. Só depois disso a reparação da rota restaura o caminho de regresso.

Aplique a mudança mais pequena que corresponda

A outra jogada comum é desmarcar «Utilizar gateway predefinido na rede remota» nas propriedades avançadas de IPv4. Mantém o tráfego de internet local, mas faz duas coisas ao mesmo tempo: a VPN deixa de ser o caminho predefinido, e o cliente deixa de receber rotas para a rede remota, incluindo multicast. Desmarque-o e a LAN remota desaparece, a menos que o servidor empurre os prefixos remotos específicos de que cada cliente precisa.

Essa assimetria decide a ordem do trabalho. Se o lado remoto tem de permanecer totalmente alcançável, empurre as sub-redes remotas a partir do servidor e deixe a predefinida local em paz. Se não pode mudar o servidor, acrescente uma rota persistente para o prefixo remoto através do endereço que o túnel atribuiu, e verifique com route print que o prefixo aponta para a interface da VPN enquanto a predefinida continua a apontar para o gateway físico.

Depois confirme que a reparação sobrevive a uma reconexão, porque as rotas não persistentes morrem com o adaptador e um script que corra após cada ligação é o lugar honesto para elas. Teste um dispositivo local e um recurso remoto na mesma sessão, desligue, volte a ligar e teste outra vez. Se o dispositivo local continuar a falhar enquanto a rota parece correta, volte à pergunta dois: o cliente está a filtrar, e a resposta é uma mudança de política e não uma segunda rota concorrente.