O túnel segue en pé, a ruta desapareceu: separar dúas avarías de VPN

Un servidor deixa de ser accesible mentres a interface do túnel segue informando de que está establecida, e as dúas observacións non se contradín. Algo eliminou o camiño que usaba o tráfico: un veciño retirou o seu prefixo, retirouse unha ruta estática seguida ou outra ruta pasou a ser preferida. A asociación de seguridade pode permanecer perfectamente sa e nos tres casos. Separar os sucesos significa preguntar que capa cambiou primeiro, non se a VPN fallou.

Tres etapas que parecen un só suceso

Unha decisión de enrutamento ten tres etapas. O prefixo recíbese, selecciónase como o mellor e instálase na táboa de reenvío. Cada etapa pode fallar por si soa, e a avaría vese idéntica desde o lado da aplicación. Un prefixo que se aprendeu pero perdeu a selección é indistinguible dun que nunca chegou cando a única proba que se mira é a táboa de reenvío.

Por iso a primeira pregunta é que etapa se rompeu, non que protocolo ten a culpa. A resposta decide quen é dono do incidente e que ferramenta usa a seguinte comprobación.

Lea primeiro a ruta instalada

Pregúntelle ao núcleo a onde vai realmente o tráfico cara ao destino que falla. ip route get imprime o seguinte salto, a interface e o enderezo de orixe que usaría o núcleo, e responde para un destino en lugar de para toda a táboa. Se a resposta nomea o túnel, a táboa de reenvío segue crendo que o camiño existe e o problema está por riba.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Unha resposta «unreachable» significa que non hai ningunha ruta instalada, o que apunta a unha retirada ou a unha instalación que falta. Unha resposta que nomea unha interface física significa que o tráfico saíu do túnel sen que ninguén o decidise, e a seguinte comprobación é a preferencia que gañou. Unha resposta que nomea o túnel mentres os paquetes seguen desaparecendo apunta máis abaixo no camiño, ao filtrado ou ao lado remoto.

Despois mire a visión do propio protocolo

Un daemon de enrutamento mantén máis dunha táboa, e a comparación interesante é entre elas. En BGP, o estado da sesión veciña, o anuncio recibido e a ruta instalada son tres probas separadas. Un prefixo pode quedar na táboa recibida e non chegar nunca ao núcleo porque gaña unha ruta cunha distancia administrativa máis curta. Comprobe as tres antes de concluír que o outro lado deixou de anunciar.

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

O resumo dille se a sesión está establecida, a vista por prefixo dille se o prefixo se aceptou, e a consulta ao núcleo dille se se instalou. Leelas nesa orde evita que un parpadeo de sesión se confunda cunha retirada, e unha retirada cun rexeitamento por política.

Cando os reloxos non coinciden

Pon o rexistro do túnel, o rexistro de enrutamento e o primeiro fallo da aplicación nunha soa liña de tempo usando os seus fusos horarios reais. Se a perda do veciño chega primeiro, o túnel derrubou a ruta con el. Se a retirada chega primeiro, o enrutamento cambiou e o túnel reaccionou despois. Son incidentes distintos con donos distintos, e a orde é todo o achado.

Un minuto de desviación do reloxo abonda para inverter esa conclusión, así que confirme o fuso horario e o desprazamento antes de fiarse da secuencia. Os dispositivos que rexistran en hora local sen desprazamento son a fonte habitual dunha liña de tempo segura pero errónea.

Recuperación sen bucle

Tras unha retirada poden ser elixibles dous camiños: o que selecciona o protocolo e o que se fixa a man. Só o primeiro é unha decisión que a rede segue tomando por vostede, por iso unha ruta manual é unha solución provisional e non un plan de recuperación. Un anuncio alternativo tampouco conserva o estado da devasa nin do NAT para unha sesión xa establecida, así que os fluxos novos poden funcionar mentres o orixinal segue roto. Confirme que copia de seguridade debe activarse e se o sitio remoto aceptará un camiño de volta a través dela.

Non instale unha substitución estática permanente antes de entender por que se produciu a retirada. Ese atallo pode fixar o tráfico nun camiño fallido ou saltar en silencio unha política de enrutamento deliberada, e enterra a causa orixinal baixo unha configuración nova. Volva probar a aplicación cando a ruta estea restaurada, e confirme que o prefixo elixido ten un camiño de datos funcional e non só unha entrada nunha táboa.