Impressora offline quando a VPN conecta? Verifique a tabela de rotas

O seu portátil entra na VPN corporativa e a impressora a dois metros deixa de responder. Nada mudou na impressora, e a rede local não caiu. O que mudou foi a tabela de rotas: o adaptador do túnel passa a ter um caminho que cobre o endereço da impressora, por isso esses pacotes saem pela VPN e chegam a um gateway que não faz ideia de onde está a sua rede plana. Percorra as quatro verificações abaixo por ordem e pare na primeira que falhar.

Passo um: prove que a impressora continua acessível na LAN

Antes de mexer no encaminhamento, confirme que o dispositivo está vivo para algo que não usa a VPN. Peça a um telefone na mesma Wi-Fi para abrir a página web da impressora, ou faça ping ao endereço a partir de outra máquina na rede plana. Se a impressora também não responder aí, a VPN é coincidência e a falha está na impressora, na associação Wi-Fi dela ou no isolamento de clientes no ponto de acesso.

Se responder em todo o lado exceto neste portátil, tem um problema de encaminhamento ou de resolução de nomes que vive no portátil, e o passo seguinte diz-lhe qual dos dois é.

Passo dois: encontre a rota que o Windows escolhe realmente

Não leia a tabela de cima para baixo nem adivinhe. Pergunte ao Windows que entrada escolhe para o endereço exato que lhe interessa, e obtenha o índice da interface ao mesmo tempo.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute imprime a rota vencedora e a respetiva interface, e esses são os dois factos de que tudo o resto depende. route print -4 mostra as entradas em volta, incluindo as duas meias rotas predefinidas que os clientes de túnel completo instalam: 0.0.0.0/1 e 128.0.0.0/1, que juntas cobrem todo o espaço IPv4 sem nunca substituir 0.0.0.0/0. Uma /1 é mais longa do que uma /0, mas a sua 192.168.1.0/24 é ainda mais longa, e é por isso que uma rota LAN ausente importa mais do que a própria pretensão do túnel.

Duas regras decidem a resposta. O prefixo correspondente mais longo ganha primeiro, e entre entradas com o mesmo prefixo ganha a métrica total mais baixa, onde o total combina a métrica da rota e a métrica da interface. Se a interface selecionada for o túnel, continue. Se for o adaptador físico e o tráfego continuar a falhar, pare aqui: o seu problema é a resolução de nomes ou a lista de acesso da própria impressora, não a rota da VPN.

Passo três: adicione a rota mais estreita que nomeia gateway e interface

A reparação é uma entrada que aponta o endereço da impressora para o router local no adaptador local. Execute-a num prompt elevado e substitua os valores que acabou de ler.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

O valor de if é o índice da interface do adaptador físico. Omiti-lo é o motivo mais comum para o comando parecer ter êxito e não mudar nada, porque com dois adaptadores capazes de alcançar o mesmo salto seguinte o Windows fica livre de escolher o que não queria. O sinalizador -p torna a entrada persistente, para que sobreviva a um reinício em vez de morrer com a sessão.

Prefira uma rota de host para o dispositivo único a uma rota para toda a 192.168.1.0/24. Uma rota de sub-rede é mais ampla do que a tarefa precisa e colide no momento em que o lado corporativo também usa esse prefixo: um prefixo passa a ter dois donos, e a entrada que ganhar decide a que rede consegue realmente chegar.

No sentido inverso, se apagou a opção de gateway predefinido na ligação VPN para proteger a LAN, os prefixos privados remotos também deixam de ser resolvidos. Adicione rotas para eles através da interface VPN da mesma forma, ou o túnel passa a ser uma ligação que não transporta nada.

Passo quatro: faça com que a exceção sobreviva à próxima ligação

Muitos clientes corporativos reinstalam todo o seu conjunto de rotas a cada ligação e recalculam as métricas das interfaces ao fazê-lo, por isso uma rota que funcionava ontem pode ser ultrapassada hoje. Depois de reconectar, repita Find-NetRoute para a impressora e verifique se a interface continua a corresponder ao adaptador físico. Se a entrada desapareceu, algo a está a apagar; uma rota persistente não o protege de um agente que varre a tabela. As tarefas agendadas que voltam a adicionar a rota depois de a VPN ligar são a solução habitual, e são também a solução que se rompe quando o índice do adaptador muda após uma dock ou uma atualização de controlador.

Vigie o IPv6 em separado. Um cliente que só reclama o padrão IPv4 pode deixar a rota padrão IPv6 no adaptador físico, por isso uma impressora acessível por IPv6 continua a funcionar enquanto o IPv4 falha, ou o contrário. Teste com ping -4 e ping -6 antes de decidir que a tabela de rotas é inocente.

O que o atalho local lhe custa

Qualquer rota que contorne o túnel é um buraco na promessa do túnel. O tráfego para esse endereço deixa de passar pelo gateway corporativo, o que significa sem inspeção, sem registo e sem aplicação de políticas. Num dispositivo gerido isso pode ser um problema de conformidade e não uma preferência, por isso pergunte se existe uma exceção oficial de túnel dividido antes de acrescentar uma à mão. Mantenha a sua tão estreita como a tarefa e tão breve como a situação permitir.

Se a impressora responder após a alteração, repita as quatro verificações depois da sua próxima reconexão em vez de assumir que a correção se manteve. Se não responder, capture a saída de Find-NetRoute antes e depois da ligação; a diferença diz-lhe se o cliente apagou a entrada ou apenas a reordenou.