Por que uma rota VPN não mostra gateway na saída do ip route

As tabelas de roteamento são lidas como quebradas sempre que a coluna do gateway fica vazia, quando a linha normalmente já é completa por si mesma. O campo via aparece apenas quando o kernel entrega o pacote a um endereço de próximo salto; uma rota ligada a uma interface alcança os seus destinos através de resolução na camada de ligação ou através de um par ponto a ponto. Ler as colunas da esquerda para a direita diz em qual caso você está, e essa leitura deve acontecer antes de alguém editar uma rota padrão. A maioria dos chamados sobre um gateway ausente termina nessa distinção.

Leia uma linha de rota coluna por coluna

Cada entrada começa com o destino e o comprimento do seu prefixo e depois acrescenta modificadores num vocabulário fixo: via, dev, proto, scope, src e metric. Uma linha como 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 é densa, mas está completamente especificada. Não lhe falta nada e nenhum endereço de roteador está implícito.

A ausência de via é a parte interessante. Sem um próximo salto, o kernel resolve o destino diretamente na interface indicada, o que, para um túnel, significa entregar o quadro ao dispositivo de túnel e deixar a encapsulação encarregar-se a partir daí. proto kernel registra que a entrada foi instalada automaticamente quando um endereço foi atribuído, e não digitada por um administrador. scope link diz que o destino é alcançável nessa ligação sem passar por um roteador, e src nomeia o endereço que o kernel preferirá como origem para o tráfego correspondente.

Agora leia uma rota padrão da mesma forma: default via 192.0.2.254 dev eth0 proto static metric 100. Aqui via está presente porque o pacote realmente precisa de um próximo salto, e esse salto tem de ser alcançável ele próprio em eth0. As duas linhas não são variantes uma da outra; respondem a perguntas diferentes sobre para onde o tráfego vai.

Duas formas de rota que se confundem entre si

Uma rota de sub-rede de túnel e uma rota padrão parecem-se numa captura de ecrã e comportam-se de forma totalmente diferente. Use a tabela abaixo como ajuda de leitura dos campos e depois confirme os números reais na máquina que está a depurar, em vez de confiar numa amostra de um guia.

O que a tabela não pode dizer é a intenção. Uma rota direta para um intervalo privado através de um túnel é um desenho deliberado de túnel dividido; a mesma forma num anfitrião que deveria enviar tudo pela VPN é um sintoma. A intenção vive na configuração que produziu a entrada, por isso olhe para a ferramenta que a instalou antes de concluir que o kernel errou.

Da mesma forma, um gateway em falta não é permissão para inventar um. Se uma rota precisa mesmo de um próximo salto, esse salto tem de ser alcançável na interface que o transporta, e para um túnel ponto a ponto o endereço do par não é o mesmo objeto que o endereço local. Tratar o endereço local do túnel como um router Ethernet é uma forma comum de produzir uma rota que parece correta e não encaminha nada.

Pergunte ao kernel qual linha vai realmente usar

Ler a tabela não é o mesmo que efetuar a consulta, porque o kernel consulta regras de política, várias tabelas e entradas em cache antes de responder. O verbo que efetua a consulta real é ip route get, e imprime a rota que um pacote com essas propriedades seguiria.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Substitua pelo destino que realmente lhe importa e depois acrescente from ou iif quando o tráfego é selecionado pela origem ou encaminhado, porque uma consulta local comum pode escolher um caminho diferente do de um cliente encaminhado. A resposta nomeia a interface, o endereço de origem escolhido e qualquer próximo salto, que é a mesma informação com que um pacote seria encaminhado naquele momento.

Se a resposta o surpreender, imprima as regras antes de mudar o que quer que seja: ip -4 rule show lista-as por ordem de prioridade, e um cliente VPN que instala a sua própria tabela ou uma regra para pacotes marcados não aparecerá de todo na tabela principal. Listar todas as tabelas fecha essa lacuna.

ip -4 route show table all | grep -E 'tun|default'

Verifique a camada subjacente antes de substituir a rota padrão

Os próprios pacotes do túnel têm de chegar ao ponto final remoto, e fazem-no pela interface física usando a rota que existia antes de a VPN subir. Substituir toda a rota padrão sem fixar esse ponto final envia os pacotes encapsulados para o túnel que deveriam construir, e a ligação colapsa. Confirme primeiro o caminho até ao ponto final com uma consulta apenas do endereço do ponto final.

Mantenha três coisas separadas quando fizer a alteração: a rota do ponto final que tem de ficar na interface física, os intervalos privados que deveriam entrar no túnel e a rota padrão que decide todo o resto. Separe-as nessa ordem, aplique uma de cada vez e volte a executar a consulta depois de cada passo. Um ping falhado depois disso prova muito pouco por si só, já que permissões, encaminhamento de respostas, DNS e o próprio serviço ficam todos a jusante de uma rota correta.

Anote os quatro valores que a linha lhe deu antes da edição: destino, próximo salto ou a sua ausência, dispositivo e origem escolhida. Se uma alteração posterior mover qualquer um deles, sabe qual decisão foi realmente alterada, e pode restaurar uma entrada em vez de adivinhar a tabela inteira.