Supervisar una interfície de túnel IPsec: què cal llegir

Un disseny IPsec basat en rutes instal·la una interfície virtual, i aquesta interfície dona a la supervisió un objecte concret: alguna cosa amb un nom, comptadors i una ruta que hi va lligada. No és, per si sol, un senyal de salut. La interfície pot existir mentre no hi ha cap associació utilitzable instal·lada, i una associació pot estar sana mentre cap ruta no hi envia el trànsit interessant. És llegir quatre estats alhora el que converteix un recompte de paquets en un diagnòstic.

Recorre’ls en ordre i atura’t en el primer que falli.

Què aporta la interfície al panorama

Amb un disseny basat en polítiques, la selecció viu a la taula de polítiques IPsec i el nucli decideix què queda protegit a partir dels selectors de trànsit. Un disseny basat en rutes afegeix una interfície i una ruta, de manera que tcpdump i els comptadors de la interfície veuen una sola frontera en lloc d’un conjunt de selectors. És un guany real per al diagnòstic i per als protocols d’encaminament que necessiten una interfície per establir-hi peering.

El guany és administratiu, no criptogràfic. La interfície informa del trànsit que transporta i no diu res sobre si la protecció del peer és utilitzable en aquest moment.

Llegir els quatre estats abans de culpar el túnel

Comença per la interfície i la ruta, després per l’associació i després per l’aplicació. Cadascuna té la seva pròpia comanda i la seva pròpia signatura de fallada. Un resultat net en una capa no és un resultat net a la següent. Executa les quatre abans de treure cap conclusió. Una línia verda poques vegades resol res.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Una interfície amb un comptador que puja però sense cap entrada d’estat corresponent descriu trànsit que entra en un camí on res no el protegeix, cosa que és pitjor que un túnel simplement aturat. Una entrada d’estat sense cap ruta que seleccioni la interfície significa que la criptografia està a punt i sense fer servir.

La prova de l’aplicació arriba al final i a propòsit: un ping correcte a l’altre costat del túnel no demostra que el servei que hi ha darrere accepti connexions.

Comparar els comptadors interns amb els externs

Els comptadors de la interfície de túnel mesuren el trànsit intern; els comptadors i les captures de la interfície física mostren l’intercanvi encapsulat. Els dos no coincidiran u a u, perquè l’encapsulació afegeix capçaleres, les retransmissions dupliquen alguns paquets i la comptabilitat de la implementació segueix regles pròpies. Espera una proporció, no una igualtat.

La ubicació de la captura també decideix quines dades privades reculls, així que fes servir filtres estrets i una adreça de prova innòcua en lloc d’una captura completa del trànsit de producció.

Si els recomptes interns pugen i els externs no, el pas que falta sol ser la ruta o la política que envia els paquets al túnel, no el túnel mateix.

Observar-ho durant la renegociació i el failover

Observa una renegociació de claus, un esdeveniment de detecció de peer mort i un failover d’enllaç mentre vigiles els mateixos quatre estats. Una interfície pot romandre present durant una renegociació que no s’acaba mai, i un failover pot deixar una entrada d’estat apuntant a una adreça de peer que ja no és abastable.

Alerta sobre el camí de servei del qual depens realment, amb l’estat de l’associació com a context, en lloc d’un simple indicador amunt o avall. Mantén el nom de la interfície, l’adreça del peer i la ruta a la càrrega de l’alerta, perquè qui respongui no els hagi de reconstruir.

strongSwan documenta el seu propi model d’interfície XFRM, i altres plataformes anomenen i implementen l’objecte equivalent de manera diferent. Llegeix la comparació basada en rutes del dispositiu que tens al davant abans de traslladar-hi supòsits d’una altra implementació. Una plantilla de supervisió que encaixa amb els comptadors d’un fabricant enganyarà en silenci amb un altre.