La detecció de parell mort a IKEv2 no prova la vostra aplicació

La comprovació de vivacitat a IKEv2 fa una pregunta: l'altre parell encara respon a la relació de control protegida. No mesura si una aplicació interna és sana, si hi ha una ruta darrere la passarel·la o si navegar sembla ràpid. La comprovació pot passar mentre tot el que és útil darrere el túnel falla.

Llegiu les dues classes d'evidència per separat abans de canviar un temporitzador.

Què pregunta realment la comprovació de vivacitat

Un intercanvi de vivacitat s'envia dins de l'associació de seguretat IKE establerta i espera una resposta dins d'una finestra configurada. Èxit vol dir que la implementació IKE del parell encara hi és i encara té ganes de parlar. No diu res sobre les associacions de seguretat filles que porten trànsit, res sobre l'encaminament més enllà de la passarel·la i res sobre el servei pel qual vau obrir el túnel. Són tres preguntes separades amb tres modes de fallada separats.

Aquesta distinció decideix on mirar quan una sessió calla. Un parell que continua responent mentre un camí de dades està trencat apunta a política, encaminament o un servei posterior. Un parell que deixa de respondre apunta a accessibilitat o a l'estat propi de l'extrem llunyà.

Llegiu les associacions de seguretat abans del navegador

L'estat de control i l'estat de dades es llisten per separat quan pregunteu al dimoni, i els comptadors diuen si s'ha intentat alguna cosa. Una associació filla que mai es va instal·lar no s'assembla gens a una que es va instal·lar i després va deixar de passar paquets, tot i que totes dues produeixen la mateixa queixa de l'usuari.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Anoteu els noms d'estat textualment al tiquet, juntament amb els comptadors en el moment de la queixa. Una descripció com túnel caigut amaga quina de les dues associacions va acabar, i normalment aquest és l'únic fet que val la pena tenir.

Una fallada de ruta sembla exactament un parell mort

La passarel·la pot respondre als intercanvis de control mentre un servidor privat està fora de línia, falta una ruta reenviada o la resolució de noms interna falla del tot. Des del client, tot això es presenta com una sessió activa i una destinació que no ho és. Comproveu el camí de tornada amb la mateixa cura que el d'anada, perquè l'encaminament asimètric a l'extrem llunyà produeix silenci només en una direcció.

Proveu l'aplicació prevista directament i anomeneu l'adreça que ha provat, en lloc de provar si el túnel està aixecat. Un ping a la passarel·la demostra que la passarel·la respon; mai no ha demostrat que l'aplicació ho fes. Registreu l'adreça exacta que l'aplicació ha provat. Aquesta cadena estreny la cerca més endavant i és l'únic fet que el tiquet sol ometre.

Manteniu els temporitzadors fora del diagnòstic

Escurçar un interval de detecció no és un canvi de rendiment i no afegeix capacitat. Amb pèrdua de paquets canvia com de ràpid es reconeix una fallada, cosa que pot fer que un símptoma sembli diferent sense millorar res. Registreu primer l'hora real de la fallada i després decidiu si la tolerància és incorrecta per a l'enllaç que realment teniu.

Les actualitzacions de mapatge NAT pertanyen a la mateixa categoria. Mantenen utilitzable un camí traduït i no són evidència que l'aplicació remota funcioni.

Una política de recuperació completa diu què ha de fer el client quan es declara mort un parell: reiniciar, tancar o esperar, i què pot fer el trànsit restant mentre passa. Sense això, el mateix incident es torna a diagnosticar des de zero cada trimestre.