Endereço peer PPP ou extremo VPN: qual vai em via

Uma única linha numa interface PPP resolve a maior parte da discussão de roteamento numa caixa VPN: o endereço interno e o peer impresso ao lado. Leia esse par como uma sub-rede minúscula e vai procurar um gateway que não existe. Leia-o como as duas pontas de um único enlace e o próximo salto fica óbvio. A comparação aqui é entre essas duas leituras, porque cada tabela que você construir depois herda a que escolheu. Nada sobre o extremo VPN externo é decidido por nenhuma delas.

Duas leituras de uma mesma linha de interface

Pegue uma sessão em que a interface informe inet 10.64.3.9 peer 10.64.3.1/32. A leitura de sub-rede trata 10.64.3.9 como um host solitário numa ilha /32 e depois procura um roteador para alcançar qualquer coisa além dela. Como o único outro endereço no enlace é o peer, essa leitura acaba propondo 10.64.3.9 como gateway, o que é circular.

A leitura de extremo é a documentada. Numa interface ponto a ponto, peer nomeia a ponta remota desse único enlace, então 10.64.3.1 é o próximo salto utilizável e 10.64.3.9 é sempre apenas um endereço de origem.

Essa diferença governa o que pode aparecer em via. Escrever ali o endereço local produz uma rota que o kernel não consegue resolver para um vizinho, então a entrada falha a validação ou engole tráfego enquanto parece perfeitamente saudável numa listagem. O peer funciona porque é um destino real no enlace. As duas leituras concordam sobre o extremo VPN externo, que é uma identidade totalmente separada: ele é alcançado pelo underlay, não pelo túnel que ele termina.

O que a sessão já instalou

Antes de escrever qualquer tabela própria, imprima o que veio com o enlace. Uma integração PPP suportada costuma instalar uma rota de dispositivo e uma rota de peer durante a montagem da sessão, e essas duas entradas já codificam a leitura correta.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Uma rota de dispositivo como 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 não carrega gateway porque a própria interface é o caminho. Uma rota que nomeia o peer com via é outro objeto com outra vida útil, e desaparece quando a sessão cai. Copiar qualquer uma das duas formas para uma tabela persistente sem verificar como ela é reinstalada é o motivo habitual pelo qual um túnel que funcionava perde a rota após uma reconexão.

Compare as duas listagens em vez de confiar na memória. Se a rota do peer existe em main mas a sua tabela extra está vazia, você aprendeu algo que a linha de endereço nunca lhe disse.

Uma regra e uma tabela são decisões separadas

Selecionar uma tabela e preenchê-la são passos independentes, e a comparação importa aqui porque os dois são frequentemente confundidos ao depurar. Uma regra que envia tráfego marcado para a tabela 100 não faz nada se a tabela 100 não tiver uma rota correspondente, e uma tabela bem povoada é inalcançável se nenhuma regra apontar para ela.

Meia rota padrão não é uma rota padrão. Uma única 0.0.0.0/1 cobre a metade inferior do espaço IPv4, então uma política que pretende capturar tudo precisa também da 128.0.0.0/1 correspondente, ou de uma default genuína. Ler uma configuração que funciona e copiar uma das duas metades é como as pessoas acabam com um laço de roteamento que só quebra em certos destinos.

Deixe exceções deliberadas para os endereços que devem ficar na LAN, e decida o que acontece quando a consulta não encontra nada na tabela selecionada. Uma rota de fallback explícita é mais fácil de raciocinar do que uma tabela vazia, que devolve um resultado inalcançável e faz a aplicação parecer quebrada em vez de mal roteada.

Faça à consulta a pergunta que sua aplicação faz

ip route get resolve um caminho; ip route show lista as entradas armazenadas, e as duas podem discordar sem que nenhuma esteja errada. Inclua o contexto de origem, porque regras baseadas em origem só correspondem quando a consulta carrega uma origem.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

O primeiro comando faz a pergunta a partir do host. O segundo acrescenta uma interface de entrada, que fica mais perto do que o tráfego encaminhado experimenta, e a resposta costuma apontar para outra tabela. Nenhum dos destinos é um serviço de teste ao vivo; 198.51.100.23 é um endereço de documentação, então substitua-o por um host que você tenha permissão de sondar.

Mesmo uma consulta correta prova apenas que um caminho foi escolhido. Ela não diz nada sobre se o outro lado aceita o tráfego ou se a resposta consegue voltar pelo mesmo raciocínio.

Onde a comparação se inverte

O tráfego do host e o tráfego encaminhado não apenas fazem consultas diferentes; eles encontram filtros diferentes na volta. O Linux aplica a validação de caminho reverso usando o mais estrito entre os ajustes de todas as interfaces e da interface receptora, então mudar o valor de uma interface pode não ter efeito visível. O roteamento baseado em marca acrescenta a relação src_valid_mark, em que a marca precisa coincidir para que uma origem seja considerada válida.

Se as respostas desaparecem enquanto o roteamento de saída parece correto, leia os valores efetivos antes de mexer neles, e altere-os apenas com uma razão de política declarada.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Escolha entre os dois desenhos com base em evidência: se a aplicação se liga ao endereço PPP, basta uma regra de origem mais uma tabela que contenha a rota do peer. Se a caixa encaminha para uma LAN atrás dela, você também precisa que o contexto de entrada e o caminho de volta concordem. Quando não concordam, corrija a propriedade da rota em vez de afrouxar a validação para a máquina inteira.