Por que uma VPN de túnel completo esconde suas VLANs locais roteadas

O botão “permitir rede local” de um cliente VPN soa como se cobrisse tudo no prédio. Na prática, ele costuma adicionar algumas exceções de endereços privados à rota padrão do túnel e parar por aí. Sua VLAN de armazenamento continua alcançável apenas se uma rota para esse prefixo específico sobreviver à chegada do túnel, e em muitos clientes ela não sobrevive.

Isso é uma questão de roteamento e não uma configuração de VPN, o que é boa notícia: existe uma resposta concreta.

O que permitir rede local realmente cobre

Os clientes implementam essa opção de formas diferentes. Alguns adicionam rotas para a sub-rede à qual a máquina está conectada, outros adicionam as faixas RFC 1918, e poucos apenas excluem o gateway padrão. Nenhum deles sabe que o roteador do escritório também atende uma VLAN de armazenamento, um segmento de laboratório ou uma sub-rede de impressoras, porque esses prefixos não estão na rede que o cliente consegue ver. Leia a documentação do próprio cliente para saber o comportamento exato, em vez de supor que o rótulo descreve sua topologia.

A diferença importa mais em um projeto de túnel completo, em que o cliente substitui deliberadamente a rota padrão para que todo o tráfego passe pela VPN. Esse é o objetivo do projeto e é também o que faz as redes locais roteadas desaparecerem. Elas nunca foram cobertas por uma rota própria; estavam pegando carona na rota padrão que acabou de ser substituída. Um cliente não consegue rotear o que não sabe que existe, e só aprende os prefixos ligados à sua própria interface. Todo o resto precisa ser descrito por alguém que conhece a topologia.

Rotas conectadas param no primeiro roteador

Uma estação de trabalho em 192.168.10.20/24 com gateway 192.168.10.1 recebe automaticamente uma rota conectada para 192.168.10.0/24. A VLAN de armazenamento em 192.168.20.0/24 é outro prefixo, alcançável apenas por esse gateway, e a estação não tem rota para ela além da padrão. Antes de o túnel subir, a rota padrão comum envia o tráfego de armazenamento para 192.168.10.1 e tudo funciona.

Quando a VPN instala um padrão de túnel completo, os pacotes para 192.168.20.1 seguem o novo padrão para dentro do túnel. O gateway remoto não faz ideia de onde esse prefixo mora, então os descarta ou os encaminha para um lugar inútil. Nada estava mal configurado na VLAN de armazenamento; o caminho dela era emprestado, e o empréstimo foi cobrado.

A tentação é recorrer a uma exceção ampla, como um par de rotas /1 ou um segundo padrão. Resista. Quanto mais estreita a exceção, mais fácil explicá-la, auditá-la e removê-la quando a rede mudar.

Coloque a exceção na tabela que vence

Dentro de uma tabela de roteamento, um /24 vence um /0 ou /1 pela correspondência de prefixo mais longo, então uma rota específica para a VLAN de armazenamento pelo gateway local basta, desde que a tabela seja consultada. No Linux, a forma comum é curta:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

O roteamento por políticas complica essa garantia. Uma regra anterior pode enviar o tráfego para uma tabela cuja própria rota padrão aponta para dentro do túnel, e a tabela principal que contém seu /24 nunca é alcançada. Verifique as regras antes de supor que a rota é autoritativa, porque uma entrada de aparência correta na tabela errada explica uma falha que parece uma rota quebrada.

Depois, torne a entrada persistente pelo mecanismo suportado pelo cliente ou pelo gerenciador de rede que controla a interface. Uma rota digitada no prompt desaparece na próxima reconexão, e uma rota amarrada a um gateway Wi-Fi não é portátil para a próxima rede que o notebook visitar.

Nomes e políticas não seguem rotas

Corrigir a rota restaura pacotes, não nomes. Se os dispositivos locais são resolvidos por um resolver empurrado que nada sabe sobre eles, a montagem ainda falha mesmo com o endereço alcançável. Nomes locais precisam de um arranjo de DNS local ou dividido, e essa é uma decisão separada da exceção de rota.

Política é outra coisa separada. O filtro de acesso local de um cliente VPN pode proibir deliberadamente o tráfego para faixas privadas, e uma rota não sobrepõe essa regra. Em uma rede não confiável, um endereço privado também não é prova de que o destino é o seu servidor de armazenamento, então a exceção deve ser tão específica quanto a rota.

Um contrato que você pode entregar

O projeto finalizado deve ser lido como uma lista curta: o tráfego geral de internet segue o túnel, e esses prefixos locais nomeados mantêm o caminho pelo roteador local. Anote os prefixos, o próximo salto e o sufixo DNS que os acompanha, e mantenha a lista curta o bastante para alguém verificá-la sem ler uma tabela de roteamento.

Fique atento à sobreposição entre faixas locais e remotas. Uma VLAN de armazenamento que compartilha um prefixo com algo atrás da VPN será resolvida para a rota mais específica, e o comportamento resultante é confuso de um jeito que parece intermitente. Renumerar um dos lados costuma ser mais barato do que depurar essa ambiguidade para sempre.

Teste o contrato duas vezes: uma com o túnel ativo e outra com ele desligado. Se o caminho local só funciona em um desses estados, a exceção ainda não é um contrato.