Rota rejeitada por bits de host? Encontre o prefixo pretendido

A sua linha de rota volta rejeitada, e o conselho que encontra diz para ativar o encaminhamento IP. Estas duas coisas estão em fases diferentes do problema. O encaminhamento decide se um host pode mover pacotes entre interfaces; não tem opinião sobre se o destino que escreveu é uma rede válida. Corrija primeiro o prefixo, porque o encaminhamento não salva um endereço e uma máscara que discordam.

Do que o analisador se queixa realmente

Um destino escrito como endereço mais máscara tem de descrever uma rede, e uma rede começa com bits de host a zero. Quando o endereço fornecido ainda transporta um valor na parte de host, o par é internamente incoerente: 172.20.130.0 parece arrumado porque termina em zero, mas o zero no quarto octeto não é a única coisa que importa. O terceiro octeto é o que aqui contém bits perdidos.

As ferramentas tratam essa incoerência de formas diferentes. Analisadores estritos rejeitam a linha e nomeiam os bits de host. Analisadores permissivos mascaram o endereço e instalam algo que não pediu, o que é pior, porque a configuração passa a encaminhar um intervalo que nunca pretendeu. O módulo ipaddress do Python expõe a escolha diretamente: a análise estrita da rede gera um erro, e strict=False mascara os bits de host. O seu cliente pode ser estrito, permissivo ou incoerente entre versões, por isso leia a mensagem em vez de confiar num hábito.

Faça o exemplo à mão

Considere um túnel que tem de alcançar 172.20.130.0 com uma máscara /20. Uma /20 pede emprestados quatro bits ao terceiro octeto, portanto esse octeto só conta em passos de 16: 0, 16, 32 e assim por diante até 240. O valor 130 fica entre 128 e 143, o que significa que a rede que o envolve começa em 172.20.128.0, não em 172.20.130.0 com o último octeto a zero.

Escrito, o bloco vai de 172.20.128.0 a 172.20.143.255 e contém 4,096 endereços. Passar os mesmos valores a um analisador não estrito mostra a substituição que faria em seu nome:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

Decida que destino pretendia realmente

A linha rejeitada costuma esconder uma de três intenções, e só você pode escolher. Se o túnel precisa do bloco inteiro, escreva 172.20.128.0/20, o endereço de rede canónico. Se o túnel só precisa do segmento 130, a máscara estava errada e 172.20.130.0/24 é a forma honesta. Se o alvo é uma única máquina, uma rota de host IPv4 é /32 e não está envolvida qualquer aritmética de máscaras.

Cada uma autoriza uma quantidade diferente de tráfego, e é essa a verdadeira razão para não alargar a máscara até a queixa parar. Uma /16 aceita a linha quase em qualquer lugar e envia tráfego para destinos que nunca quis encaminhar pelo túnel. Escreva o prefixo mais estreito que corresponde à intenção e depois confirme-o contra o próximo salto que espera, não contra o silêncio do analisador.

Porque o encaminhamento nunca foi a solução

Uma rota rejeitada nunca chega à via de encaminhamento, por isso alternar net.ipv4.ip_forward não pode mudar o resultado. Essa definição importa mais tarde, quando o host tem de passar pacotes entre interfaces, e ativá-la antes de a tabela estar correta só muda qual etapa falha a seguir.

Outras duas coisas são frequentemente culpadas no mesmo ponto. A rota pode ser aceite e ainda assim perder para uma rota mais específica, e uma regra de firewall pode descartar tráfego após uma pesquisa correta. Mantenha as fases separadas: sintaxe, instalação, seleção, filtragem. Trabalhar na fase errada parece produtivo porque cada alteração reinicia algo.

Verifique a rota instalada e o caminho que ela ganha

Assim que o cliente aceitar a linha, veja o que instalou e que rota o núcleo escolhe para um endereço representativo dentro do bloco. Se o prefixo instalado diferir do que escreveu, um normalizador agiu em seu nome.

Pergunte por um endereço membro e também por um fora do bloco, para que a comparação seja significativa e não apenas uma linha tranquilizadora:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

A terceira consulta deve cair fora do túnel se o prefixo estiver correto, e quando não cai, a rota que construiu é mais ampla do que pensa. Anote o que o prefixo devia cobrir antes de tocar na definição seguinte, porque uma rota que se analisa e um caminho que funciona continuam a ser observações separadas.