Ruta rexeitada por bits de host? Atope o prefixo que quería

A súa liña de ruta volve rexeitada, e o consello que atopa di que active o reenvío IP. Esas dúas cousas están en etapas distintas do problema. O reenvío decide se un host pode mover paquetes entre interfaces; non opina sobre se o destino que escribiu é unha rede válida. Corrixa primeiro o prefixo, porque o reenvío non rescatará unha dirección e unha máscara que non concordan.

Do que se queixa realmente o analizador

Un destino escrito como dirección máis máscara debe describir unha rede, e unha rede empeza cos bits de host a cero. Cando a dirección que proporciona aínda leva un valor na parte de host, o par é internamente incoherente: 172.20.130.0 parece ordenado porque remata en cero, pero o cero do cuarto octeto non é o único que importa. O terceiro octeto é o que aquí contén bits soltos.

As ferramentas tratan esa incoherencia de forma distinta. Os analizadores estritos rexeitan a liña e nomean os bits de host. Os analizadores permisivos enmascaran a dirección e instalan algo que vostede non pediu, o cal é peor, porque a configuración agora encamiña un rango que nunca pretendeu. O módulo ipaddress de Python expón a escolla directamente: a análise estrita de rede xera un erro, e strict=False enmascara os bits de host. O seu cliente pode ser estrito, permisivo ou incoherente entre versións, así que lea a mensaxe en lugar de confiar nunha costume.

Traballe o exemplo a man

Tome un túnel que necesita alcanzar 172.20.130.0 cunha máscara /20. Unha /20 toma catro bits do terceiro octeto, así que ese octeto só conta en pasos de 16: 0, 16, 32 e así ata 240. O valor 130 cae entre 128 e 143, o que significa que a rede que o engloba comeza en 172.20.128.0, non en 172.20.130.0 co último octeto a cero.

Escrito, o bloque vai de 172.20.128.0 a 172.20.143.255 e contén 4,096 enderezos. Pasar os mesmos valores a un analizador non estrito mostra a substitución que faría no 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 pretendía realmente

A liña rexeitada adoita ocultar unha de tres intencións, e só vostede pode escoller. Se o túnel necesita todo o bloque, escriba 172.20.128.0/20, a dirección de rede canónica. Se o túnel só necesita o segmento 130, a máscara era incorrecta e 172.20.130.0/24 é a forma honesta. Se o obxectivo é unha soa máquina, unha ruta de host IPv4 é /32 e non intervé ningunha aritmética de máscaras.

Cada unha autoriza unha cantidade distinta de tráfico, e esa é a verdadeira razón para non ampliar a máscara ata que a queixa cese. Unha /16 acepta a liña case en calquera sitio e envía tráfico cara a destinos que nunca quixo encamiñar polo túnel. Escriba o prefixo máis estreito que coincida coa intención e logo confírmeno contra o seguinte salto que espera, non contra o silencio do analizador.

Por que o reenvío nunca foi a solución

Unha ruta rexeitada nunca chega á ruta de reenvío, así que cambiar net.ipv4.ip_forward non pode cambiar o resultado. Ese axuste importa máis adiante, cando o host debe pasar paquetes entre interfaces, e activalo antes de que a táboa sexa correcta só cambia que etapa falla despois.

Outras dúas cousas adoitan ser culpadas no mesmo punto. A ruta pode aceptarse e aínda así perder fronte a unha ruta máis específica, e unha regra de devasado pode descartar tráfico tras unha busca correcta. Manteña as etapas separadas: sintaxe, instalación, selección, filtrado. Traballar na etapa equivocada parece produtivo porque cada cambio reinicia algo.

Comprobe a ruta instalada e o camiño que gaña

Cando o cliente acepte a liña, mire o que instalou e que ruta escolle o núcleo para unha dirección representativa dentro do bloque. Se o prefixo instalado difire do que escribiu, un normalizador actuou no seu nome.

Consulte unha dirección membro e tamén unha fóra do bloque, para que a comparación sexa significativa e non unha soa liña 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 debería caer fóra do túnel se o seu prefixo é correcto, e cando non o fai, a ruta que construíu é máis ampla do que cre. Anote que debía cubrir o prefixo antes de tocar o seguinte axuste, porque unha ruta que se analiza e un camiño que funciona seguen sendo observacións separadas.