Próximo salto numa rota VPN: porque o gateway tem de ser alcançável localmente

Uma rota para uma rede VPN transporta dois endereços fáceis de confundir: o prefixo de destino que o pacote tenta alcançar e o próximo salto que o moverá um passo mais perto. Num anfitrião de LAN, esse próximo salto tem de ser um encaminhador que consiga realmente alcançar na mesma ligação. O endereço VPN remoto não é um próximo salto, por muito bem que se ajuste ao destino que tem em mente.

Este manual cobre o caso habitual: um portátil em 192.168.20.0/24, um gateway VPN com endereço LAN 192.168.20.5 e uma rede remota 10.70.0.0/24 atrás desse gateway. Todos os comandos abaixo assumem que está no portátil, salvo indicação em contrário.

Dois endereços, uma rota

A entrada pretendida é 10.70.0.0/24 via 192.168.20.5. O prefixo diz para onde vai o pacote; o endereço via diz quem o transporta até lá. O núcleo recusa instalar uma rota cujo gateway não consegue alcançar através da interface que indica, e essa recusa é todo o ponto: um próximo salto que precisa do túnel para ser alcançável não pode ser o próximo salto que constrói o túnel.

Assim, a primeira verificação não é «o gateway está a funcionar» mas «o gateway está nesta ligação». A sub-rede do próprio portátil, a sua entrada ARP ou de vizinho e a interface na rota têm todas de concordar. Um endereço que só existe dentro de 10.70.0.0/24 pode ser o destino de uma segunda rota, mas nunca o via da primeira.

A que obriga o próximo salto o gateway

Instalar a rota no portátil decide apenas a primeira entrega. Depois o gateway precisa do seu próprio caminho: reencaminhamento ativo, uma rota de túnel para 10.70.0.0/24 e qualquer política de acesso que determine quem a pode usar. No Linux isso é net.ipv4.ip_forward=1 mais uma rota de túnel; uma firewall à frente precisa de uma regra que permita o fluxo reencaminhado.

O sentido de regresso é a parte que as pessoas esquecem. O lado remoto tem de ter uma rota de regresso para 192.168.20.0/24, ou o desenho tem de traduzir a origem do portátil em algo que o lado remoto conheça. Um ping que funciona a partir do gateway prova que o gateway alcança a rede remota; não diz nada sobre se os pacotes do portátil sobrevivem à viagem de regresso.

Verifique a pesquisa a partir do anfitrião que envia

Pergunte ao núcleo qual o próximo salto que escolheria e leia a interface na resposta:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Se a pesquisa indicar o gateway e a interface LAN, o primeiro troço está configurado como pretendido. Se indicar o dispositivo de túnel, algo mais acima na tabela é mais específico e está a ganhar. Se a rota não instalar de todo, o núcleo está a dizer-lhe que o gateway não é alcançável, e essa mensagem é mais útil do que qualquer captura de pacotes.

Depois repita o teste a partir do local certo. Um pedido criado no gateway usa o endereço de origem do próprio gateway, o que pode esconder uma rota de regresso em falta ou uma política que só permite certas origens. O manual do ip-route separa o destino, o gateway e a substituição onlink, e vale a pena compreender a substituição antes de a usar.

Não use onlink para fingir alcançabilidade

onlink diz ao núcleo para ignorar a verificação de alcançabilidade de um gateway e enviar para lá mesmo assim. Não cria um caminho, não resolve ARP para um endereço que não existe nem faz um encaminhador remoto responder no seu segmento Ethernet. É legítimo para gateways que respondem mas não estão numa sub-rede ligada, e é uma armadilha quando serve para silenciar um erro que não explicou.

Se a rota só instala com onlink, a pergunta seguinte é porque é que o gateway não está onde pensa. Uma VLAN errada, um segundo endereço na interface errada ou um erro de escrita no último octeto produzem isto, e cada um deles também quebra o caminho de regresso assim que o tráfego começa a fluir.

Os túneis ponto a ponto não são Ethernet

Um dispositivo de túnel não faz ARP e muitas vezes não tem uma sub-rede de vizinhos com sentido. As suas rotas parecem-se frequentemente com 10.70.0.0/24 dev tun0, sem qualquer via, porque o par é o único outro extremo. Copiar um via ao estilo LAN para essa tabela produz uma rota que o núcleo pode rejeitar ou, pior, uma que aponta para um endereço a que o par nunca responde.

Mantenha os dois modelos separados no manual: uma rota LAN tem um gateway alcançável, uma rota de túnel tem uma interface e um par. O WireGuard, o OpenVPN e o IPsec expõem formas ligeiramente diferentes, por isso registe a forma que realmente usou em vez de generalizar a partir de um só anfitrião.

Acrescente, confirme, reverta

Toda a alteração são três comandos e uma verificação, e deve ser escrita nessa ordem:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confirme o caminho, confirme um destino e depois mantenha a linha de eliminação pronta caso a alteração torne o anfitrião inalcançável de uma forma que não previu. Se a rota tiver de sobreviver a um reinício, coloque-a na configuração de rede do anfitrião e não num perfil da shell, e teste o reinício antes de contar com ela. Uma rota que só existe na shell que a acrescentou é uma rota que vai depurar duas vezes.