Ruta rebutjada per bits d’amfitrió? Trobeu el prefix volgut

La vostra línia de ruta torna rebutjada, i el consell que trobeu diu que activeu el reenviament IP. Aquestes dues coses són en etapes diferents del problema. El reenviament decideix si un amfitrió pot moure paquets entre interfícies; no té opinió sobre si la destinació que heu escrit és una xarxa vàlida. Arregleu primer el prefix, perquè el reenviament no salvarà una adreça i una màscara que no concorden.

De què es queixa realment l’analitzador

Una destinació escrita com a adreça més màscara ha de descriure una xarxa, i una xarxa comença amb els bits d’amfitrió a zero. Quan l’adreça que proporcioneu encara porta un valor a la part d’amfitrió, la parella és internament inconsistent: 172.20.130.0 sembla ordenat perquè acaba en zero, però el zero del quart octet no és l’únic que importa. El tercer octet és el que aquí conté bits sobrants.

Les eines tracten aquesta inconsistència de maneres diferents. Els analitzadors estrictes rebutgen la línia i anomenen els bits d’amfitrió. Els analitzadors permisius emmascaren l’adreça i instal·len una cosa que no heu demanat, que és pitjor, perquè la configuració ara encamina un rang que no volíeu. El mòdul ipaddress de Python exposa l’opció directament: l’anàlisi estricta de xarxa genera un error, i strict=False emmascara els bits d’amfitrió. El vostre client pot ser estricte, permissiu o inconsistent entre versions, així que llegiu el missatge en lloc de confiar en un hàbit.

Feu l’exemple a mà

Agafeu un túnel que ha d’arribar a 172.20.130.0 amb una màscara /20. Una /20 manlleva quatre bits del tercer octet, així que aquest octet només compta en passos de 16: 0, 16, 32 i així fins a 240. El valor 130 cau entre 128 i 143, cosa que significa que la xarxa que l’engloba comença a 172.20.128.0, no a 172.20.130.0 amb l’últim octet a zero.

Escrit, el bloc va de 172.20.128.0 a 172.20.143.255 i conté 4,096 adreces. Passar els mateixos valors a un analitzador no estricte mostra la substitució que hauria fet en nom vostre:

$ 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

Decidiu quina destinació volíeu realment

La línia rebutjada sol amagar una de tres intencions, i només vosaltres podeu triar. Si el túnel necessita tot el bloc, escriviu 172.20.128.0/20, l’adreça de xarxa canònica. Si el túnel només necessita el segment 130, la màscara era incorrecta i 172.20.130.0/24 és la forma honesta. Si l’objectiu és una sola màquina, una ruta d’amfitrió IPv4 és /32 i no hi intervé cap aritmètica de màscares.

Cadascuna autoritza una quantitat diferent de trànsit, i aquesta és la raó real per no ampliar la màscara fins que la queixa s’aturi. Una /16 accepta la línia gairebé a qualsevol lloc i envia trànsit cap a destinacions que mai no volíeu encaminar pel túnel. Escriviu el prefix més estret que coincideixi amb la intenció, i després confirmeu-lo contra el següent salt que espereu, no contra el silenci de l’analitzador.

Per què el reenviament no va ser mai la solució

Una ruta rebutjada no arriba mai al camí de reenviament, així que canviar net.ipv4.ip_forward no pot canviar el resultat. Aquest paràmetre importa més endavant, quan l’amfitrió ha de passar paquets entre interfícies, i activar-lo abans que la taula sigui correcta només canvia quina etapa fallarà després.

Dues altres coses sovint es culpen en el mateix punt. La ruta pot ser acceptada i tot i així perdre contra una ruta més específica, i una regla de tallafocs pot descartar trànsit després d’una cerca correcta. Manteniu les etapes separades: sintaxi, instal·lació, selecció, filtratge. Treballar en l’etapa equivocada sembla productiu perquè cada canvi reinicia alguna cosa.

Comproveu la ruta instal·lada i el camí que guanya

Quan el client accepti la línia, mireu què ha instal·lat i quina ruta tria el nucli per a una adreça representativa dins del bloc. Si el prefix instal·lat difereix del que heu escrit, un normalitzador ha actuat en nom vostre.

Consulteu una adreça membre i també una de fora del bloc, perquè la comparació sigui significativa i no una sola línia tranquil·litzadora:

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 ha de caure fora del túnel si el prefix és correcte, i quan no ho fa, la ruta que heu construït és més àmplia del que penseu. Anoteu què havia de cobrir el prefix abans de tocar el paràmetre següent, perquè una ruta que s’analitza i un camí que funciona continuen sent observacions separades.