Por que sua VPN do Windows mata a impressora local e como impedir

Conecte a VPN e a impressora desaparece, o compartilhamento NAS para de abrir, e uma sessão de Área de Trabalho Remota para a máquina ao lado estoura o tempo limite. Nada quebrou. O cliente adicionou uma rota padrão e agora possui todos os destinos que o notebook consegue nomear, incluindo os que estão a três metros. Esse é o mecanismo inteiro, e chamar isso de falha da VPN é o que transforma um conserto de uma linha em um caso de suporte.

Leia primeiro a tabela de rotas

Antes de mudar qualquer coisa, capture a tabela IPv4 com route print -4 e guarde a saída. Conecte, capture de novo e compare as linhas 0.0.0.0: a rota padrão ativa nomeia uma interface, e se essa interface for o túnel, a impressão e a navegação locais vão primeiro para o escritório.

O número da interface na segunda coluna é o que uma rota persistente terá de referenciar mais tarde, então anote-o enquanto o túnel está ativo. É também o valor que muda quando o adaptador é recriado, e por isso rotas fixadas nele podem sobreviver em silêncio à sua utilidade.

Remova a rota padrão, de três maneiras

Num perfil integrado do Windows o controle é uma caixa de seleção. Abra as propriedades da conexão, IPv4, depois Avançado, e desmarque Use default gateway on remote network; o aplicativo Configurações mais novo esconde a mesma caixa de diálogo um nível mais fundo. Num prompt elevado a mesma mudança é um cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Um perfil OpenVPN funciona de forma diferente, e por isso o comportamento confunde quem espera uma caixa de seleção. A diretiva redirect-gateway def1 não substitui a rota padrão de jeito nenhum; ela instala duas rotas de meio intervalo, 0.0.0.0/1 e 128.0.0.0/1, que juntas vencem a padrão sem apagá-la. Como a padrão original sobrevive, acrescentar um prefixo apontado para net_gateway devolve só esse prefixo ao roteador local. Esse detalhe explica por que o conserto para um perfil def1 é uma rota de prefixo e não uma caixa de seleção que ninguém acha.

Acrescente de volta apenas o que pertence ao trabalho

Sem a rota padrão o túnel não carrega nada, então os prefixos de trabalho precisam ser nomeados explicitamente. O cmdlet que amarra um prefixo à conexão é mais seguro que uma rota persistente, porque só é instalado enquanto aquela conexão está ativa e não depende de um número de interface:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

A abordagem mais antiga ainda funciona e ainda está em toda lista de verificação: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, com o índice de interface e o endereço de gateway do próprio túnel. Persiste entre reinicializações, o que é o propósito e também o perigo, já que o índice pode pertencer a outra coisa no próximo boot.

O resto quem decide são as métricas. Se tanto o adaptador físico quanto o do túnel reivindicam uma rota para o mesmo prefixo, vence a métrica mais baixa, e aumentar a métrica do túnel é um controle legítimo do lado do cliente e não um truque.

Quando o servidor decide por você

Um cliente que ignora sua caixa de seleção normalmente está obedecendo a uma política. Os perfis Cisco carregam um ajuste Allow Local LAN Access, e um headend pode empurrar uma política tunnel-all que anula o que o cliente preferiria; numa implantação de túnel obrigatório não há nenhum interruptor local para virar. Leia o log do cliente em busca das rotas e linhas de política empurradas em vez de reconferir a mesma caixa de diálogo.

Depois olhe a resolução de nomes, que é um interruptor separado do roteamento. Um túnel dividido ainda pode receber um resolver interno e um sufixo de busca, então um dispositivo local é alcançável por endereço e impossível de achar por nome até o lado DNS também ser corrigido.

Sobreposições são outro problema

Se a LAN de casa e a LAN do escritório compartilham um prefixo como 192.168.0.0/24, nenhuma rota consegue distingui-las. Cada pacote dessa faixa tem um único resultado de busca, e o conserto é renumerar um lado ou chegar ao escritório por um endereço traduzido do pool. Acrescentar rotas mais específicas só desloca qual metade da rede quebra.

Termine com uma verificação em vez de cinco: conecte e depois execute tracert contra um host interno e um público. O primeiro salto deveria diferir, e se não diferir, a divisão não está em vigor, diga o que disser o cliente. Depois reconecte uma vez e repita, porque as rotas empurradas voltam a cada sessão.