¿Ruta rechazada por bits de host? Encuentre el prefijo que quería

Su línea de ruta vuelve rechazada, y el consejo que encuentra dice que active el reenvío IP. Esas dos cosas están en etapas distintas del problema. El reenvío decide si un host puede mover paquetes entre interfaces; no opina sobre si el destino que escribió es una red válida. Corrija primero el prefijo, porque el reenvío no rescatará una dirección y una máscara que no concuerdan.

De qué se queja realmente el analizador

Un destino escrito como dirección más máscara debe describir una red, y una red empieza con los bits de host a cero. Cuando la dirección que proporciona aún lleva un valor en la parte de host, el par es internamente incoherente: 172.20.130.0 parece ordenado porque termina en cero, pero el cero del cuarto octeto no es lo único que importa. El tercer octeto es el que aquí contiene bits sueltos.

Las herramientas tratan esa incoherencia de forma distinta. Los analizadores estrictos rechazan la línea y nombran los bits de host. Los analizadores permisivos enmascaran la dirección e instalan algo que usted no pidió, lo cual es peor, porque la configuración ahora enruta un rango que nunca pretendió. El módulo ipaddress de Python expone la elección directamente: el análisis estricto de red genera un error, y strict=False enmascara los bits de host. Su cliente puede ser estricto, permisivo o incoherente entre versiones, así que lea el mensaje en lugar de confiar en una costumbre.

Trabaje el ejemplo a mano

Tome un túnel que necesita alcanzar 172.20.130.0 con una máscara /20. Una /20 toma cuatro bits del tercer octeto, así que ese octeto solo cuenta en pasos de 16: 0, 16, 32 y así hasta 240. El valor 130 cae entre 128 y 143, lo que significa que la red que lo engloba empieza en 172.20.128.0, no en 172.20.130.0 con el último octeto a cero.

Escrito, el bloque va de 172.20.128.0 a 172.20.143.255 y contiene 4,096 direcciones. Pasar los mismos valores a un analizador no estricto muestra la sustitución que habría hecho en su nombre:

$ 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 qué destino pretendía realmente

La línea rechazada suele ocultar una de tres intenciones, y solo usted puede elegir. Si el túnel necesita todo el bloque, escriba 172.20.128.0/20, la dirección de red canónica. Si el túnel solo necesita el segmento 130, la máscara era incorrecta y 172.20.130.0/24 es la forma honesta. Si el objetivo es una sola máquina, una ruta de host IPv4 es /32 y no interviene ninguna aritmética de máscaras.

Cada una autoriza una cantidad distinta de tráfico, y esa es la verdadera razón para no ampliar la máscara hasta que la queja cese. Una /16 acepta la línea casi en cualquier sitio y envía tráfico hacia destinos que nunca quiso enrutar por el túnel. Escriba el prefijo más estrecho que coincida con la intención y luego confírmelo contra el siguiente salto que espera, no contra el silencio del analizador.

Por qué el reenvío nunca fue la solución

Una ruta rechazada nunca llega a la ruta de reenvío, así que cambiar net.ipv4.ip_forward no puede cambiar el resultado. Ese ajuste importa más adelante, cuando el host debe pasar paquetes entre interfaces, y activarlo antes de que la tabla sea correcta solo cambia qué etapa falla después.

Otras dos cosas suelen ser culpadas en el mismo punto. La ruta puede aceptarse y aun así perder frente a una ruta más específica, y una regla de cortafuegos puede descartar tráfico tras una búsqueda correcta. Mantenga las etapas separadas: sintaxis, instalación, selección, filtrado. Trabajar en la etapa equivocada parece productivo porque cada cambio reinicia algo.

Compruebe la ruta instalada y el camino que gana

Cuando el cliente acepte la línea, mire lo que instaló y qué ruta elige el núcleo para una dirección representativa dentro del bloque. Si el prefijo instalado difiere del que escribió, un normalizador actuó en su nombre.

Consulte una dirección miembro y también una fuera del bloque, para que la comparación sea significativa y no una sola línea 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

La tercera consulta debería caer fuera del túnel si su prefijo es correcto, y cuando no lo hace, la ruta que construyó es más amplia de lo que cree. Anote qué debía cubrir el prefijo antes de tocar el siguiente ajuste, porque una ruta que se analiza y un camino que funciona siguen siendo observaciones separadas.