Dê aos hosts da LAN uma rota de retorno VPN com a opção 121 do DHCP

Os clientes VPN remotos se conectam, o servidor da LAN responde, e a resposta sai pelo roteador de internet comum e morre ali. Um servidor pode ser corrigido com uma rota estática, mas uma sub-rede inteira deles é melhor tratada onde eles já recebem a configuração de rede. A opção 121 do DHCPv4 distribui exatamente esse tipo de rota de destino, e é a parte que as pessoas costumam errar no momento em que esquecem a padrão. O sintoma é tráfego em um só sentido: as requisições chegam e as respostas desaparecem.

Nomeie primeiro os três endereços

Pegue uma LAN concreta: 192.168.50.0/24 com o roteador padrão habitual em 192.168.50.1 e um gateway VPN separado em 192.168.50.2. Os clientes remotos autenticados ocupam 10.90.0.0/24.

A rota de que cada host participante precisa é 10.90.0.0/24 via 192.168.50.2. O destino é o pool de clientes, e o próximo salto é o endereço LAN do gateway, não o endereço de túnel dele.

Codifique-a como rota estática sem classe

A opção 121 carrega pares de prefixo e próximo salto, e RFC 3442 define tanto a codificação quanto o comportamento do cliente que se segue. Para uma instância dnsmasq existente que atende apenas esta LAN ilustrativa, a forma da configuração é:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Isso é um fragmento, não um serviço DHCP novo. Num servidor que atende vários segmentos, limite a opção com as tags ou a política de rede que você já usa. Mantenha a configuração anterior à mão, porque reverter isso significa outra renovação de concessão, não um reinício.

Não perca a rota padrão

Esta é a armadilha. Um cliente que recebe a opção 121 deve ignorar a opção Router comum, então anunciar apenas a rota do pool VPN pode deixar aquele host sem nenhuma rota padrão. A máquina ainda parece configurada e perde a internet em silêncio. Os usuários descrevem isso como rede fora do ar enquanto todas as interfaces estão ativas.

Inclua a rota padrão pretendida na mesma lista, como faz o fragmento acima. Mantenha também a opção Router comum para clientes que não implementam rotas sem classe; o tratamento de opções do próprio servidor decide o que é enviado a quem.

Verifique o que o cliente vai aceitar

Um host com endereço manual nunca capta isso, porque não pede uma concessão. O suporte dos clientes também varia, então teste no sistema operacional que você realmente executa em vez de supor que cada dispositivo respeita a opção 121. Confirme com quem é dono desses servidores quais têm endereço estático. Esses hosts precisam das próprias entradas de rota ou simplesmente não participarão.

Os serviços DHCP gerenciados são outro limite. Algumas redes de nuvem não permitem que administradores publiquem opções arbitrárias, e um servidor DHCP concorrente no mesmo segmento é pior do que nenhuma opção.

Verifique a concessão, depois a consulta

Peça ao dono do DHCP para aplicar a mudança e então renove a concessão num cliente. As concessões existentes mantêm a configuração antiga até serem renovadas, então resultados imediatos não são garantidos.

Num cliente Linux, leia as rotas reais e confirme as duas entradas:

ip -4 route
ip -4 route get 10.90.0.23

A consulta contextual deve mostrar a rota do pool por 192.168.50.2 e a padrão por 192.168.50.1. Se a padrão faltar, você reproduziu a armadilha acima.

Depois teste a troca real

A distribuição de rotas não é o caminho inteiro. O gateway separado ainda precisa de encaminhamento, propriedade dos pares remotos e uma política de acesso que permita o servidor, e o DHCP não autentica ninguém.

Por fim, mantenha um plano de remoção. Uma rota estática aprendida não se retira sozinha quando a VPN cai, então um próximo salto obsoleto pode transformar esse prefixo num buraco negro muito depois de o túnel ter sumido.