El túnel continua obert, la ruta ha desaparegut: separar dues fallades de VPN

Un amfitrió es torna inabastable mentre la interfície del túnel encara es declara establerta, i les dues observacions no es contradiuen. Alguna cosa va eliminar el camí que feia servir el trànsit: un veí va retirar el seu prefix, una ruta estàtica seguida es va treure, o una altra ruta va esdevenir preferida. L’associació de seguretat pot romandre perfectament sana en els tres casos. Separar els esdeveniments vol dir preguntar quina capa va canviar primer, no si la VPN ha fallat.

Tres etapes que semblen un sol esdeveniment

Una decisió d’encaminament té tres etapes. El prefix es rep, es selecciona com a millor i s’instal·la a la taula d’encaminament. Cada etapa pot fallar per si sola, i la fallada sembla idèntica des del costat de l’aplicació. Un prefix après però que va perdre la selecció és indistingible d’un que mai no va arribar quan l’única evidència que mireu és la taula d’encaminament.

Per això la primera pregunta és quina etapa s’ha trencat, no quin protocol té la culpa. La resposta decideix qui és el propietari de l’incident i quina eina fa servir la comprovació següent.

Llegiu primer la ruta instal·lada

Pregunteu al nucli on va realment el trànsit cap a la destinació que falla. ip route get imprimeix el salt següent, la interfície i l’adreça d’origen que faria servir el nucli, i respon per a una destinació, no per a tota la taula. Si la resposta anomena el túnel, la taula d’encaminament encara creu que el camí existeix i el problema és per sobre.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Una resposta «unreachable» vol dir que no hi ha cap ruta instal·lada, cosa que apunta a una retirada o a una instal·lació que falta. Una resposta que anomena una interfície física vol dir que el trànsit va sortir del túnel sense que ningú ho decidís, i la comprovació següent és la preferència que va guanyar. Una resposta que anomena el túnel mentre els paquets segueixen desapareixent apunta més avall del camí, al filtratge o a l’altre costat.

Després mireu la visió pròpia del protocol

Un dimoni d’encaminament manté més d’una taula, i la comparació interessant és entre elles. Per a BGP, l’estat de la sessió veïna, l’anunci rebut i la ruta instal·lada són tres proves separades. Un prefix pot seure a la taula rebuda i no arribar mai al nucli perquè guanya una ruta amb una distància administrativa més curta. Comproveu les tres coses abans de concloure que l’altre costat ha deixat d’anunciar.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

El resum us diu si la sessió està establerta, la vista per prefix us diu si el prefix ha estat acceptat, i la consulta al nucli us diu si s’ha instal·lat. Llegir-les en aquest ordre evita que un parpelleig de sessió es confongui amb una retirada, i una retirada amb un rebuig per política.

Quan els rellotges no coincideixen

Poseu el registre del túnel, el registre d’encaminament i la primera fallada de l’aplicació en una sola línia temporal amb els seus fusos horaris reals. Si la pèrdua del veí arriba primer, el túnel va fer caure la ruta amb ell. Si la retirada arriba primer, l’encaminament va canviar i el túnel va reaccionar després. Són incidents diferents amb propietaris diferents, i l’ordre és tota la troballa.

Un minut de desviació del rellotge n’hi ha prou per invertir aquesta conclusió, així que confirmeu el fus horari i la desviació abans de confiar en la seqüència. Els dispositius que registren en hora local sense desviació són la font habitual d’una línia temporal segura però equivocada.

Recuperació sense bucle

Després d’una retirada, dos camins poden ser elegibles: el que selecciona el protocol i el que fixeu a mà. Només el primer és una decisió que la xarxa continua prenent per vosaltres, i per això una ruta manual és una solució provisional i no un pla de recuperació. Un anunci alternatiu tampoc no conserva l’estat del tallafoc ni del NAT per a una sessió ja establerta, així que els fluxos nous poden funcionar mentre l’original continua trencat. Confirmeu quina còpia de seguretat hauria d’esdevenir activa i si el lloc remot acceptarà un camí de retorn a través seu.

No instal·leu una substitució estàtica permanent abans d’entendre per què s’ha produït la retirada. Aquest atall pot fixar el trànsit en un camí fallit o saltar-se en silenci una política d’encaminament deliberada, i enterra la causa original sota una configuració nova. Torneu a provar l’aplicació quan la ruta estigui restaurada, i confirmeu que el prefix triat té un camí de dades funcional i no només una entrada en una taula.