IKE-SA establerta, CHILD-SA absent: on s’aturen les dades
Una IKE-SA establerta no vol dir que hi hagi dades en moviment. Llegeix les entrades CHILD, comprova els selectors i els comptadors, i anomena la capa que realment ha fallat.
El client diu que s’ha autenticat, l’estat d’IKE sembla sa, i els comptadors de paquets continuen a zero. Aquesta combinació no és cap contradicció: IKEv2 manté separades la relació de control i la relació de dades, i la primera pot reeixir mentre la segona no s’aixeca mai. El pare porta la negociació; el fill porta el trànsit. Llegeix les dues capes per separat abans de declarar el túnel caigut.
Què fan les dues SA
La IKE-SA és la relació de control: autentica els parells i transporta els intercanvis que negocien, substitueixen i eliminen la protecció. No transporta mai els paquets de les teves aplicacions. Per tant, un pare sa només demostra que els dos extrems poden acordar una política de seguretat, i res més.
Una CHILD-SA és la relació de dades, creada sota el pare, amb selectors de trànsit i material de clau per a un conjunt protegit. És direccional, així que la sortida d’estat llista una associació d’entrada i una de sortida amb identificadors separats, i normalment comptadors separats per a cada direcció. Aquest emparellament explica per què una direcció pot funcionar mentre l’altra cau, i per què la frase el túnel està aixecat no diu res sobre el trànsit. Un pare també pot tenir diversos fills, i així una sola etiqueta de connexió amaga la que necessites.
Llegeix les entrades filles, no l’etiqueta de connexió
Obre l’estat del pare i la llista de fills alhora, i troba el fill els selectors del qual coincideixen amb el flux que proves. Anota’n els selectors de trànsit, els algorismes negociats, la seva vida útil i els comptadors en totes dues direccions. Si hi ha diversos fills, compara pels selectors i no per la posició, perquè la posició canvia després d’una renovació de claus. Escriu els identificadors abans de canviar res.
Si el pare llista un conjunt de trànsit diferent del que proves, estàs llegint el fill equivocat. Això és un problema de selectors, no un túnel trencat.
Anota també les marques de temps. La renovació de claus pot substituir una capa mentre l’altra continua establerta, i un fill que sembla nou pot ser el substitut del que estaves vigilant. Compara els identificadors abans de concloure que un fill ha desaparegut.
Quan no existeix cap fill
L’autenticació pot reeixir mentre la proposta de dades o els selectors fallen, i el pare es queda sense cap fill. La causa habitual és una discrepància d’algorisme o de selectors de trànsit, i tots dos parells registren la proposta rebutjada. Llegeix els dos extrems, perquè el costat al qual arribes pot mostrar només el rebuig. Corregeix la discrepància en lloc de reiniciar el pare, que repeteix la mateixa negociació fallida i afegeix una interrupció a les proves.
Un pare que es torna a establir una vegada i una altra és una fallada diferent d’un pare que es manté aixecat sense fill. En el segon cas els registres anomenen la proposta rebutjada, així que recull aquesta proposta dels dos extrems abans d’editar una política.
Quan el fill existeix però els comptadors continuen a zero
Envia una petició nova que coincideixi amb els selectors del fill. Una petició a una destinació fora d’aquesta política no mourà els seus comptadors, per bé que sembli reeixida.
Comprova la ruta que ha d’empènyer el flux cap al túnel, perquè un fill sense trànsit sovint és un fill cap on no s’encamina res. Els comptadors que només es mouen en una direcció assenyalen una discrepància de selectors o de política al camí de tornada. Mira els selectors de tornada del parell remot abans de tocar el costat local. Una petició nova també et dona una marca de temps per correlacionar amb la sortida d’estat dels dos extrems.
Anomena la capa a l’informe
Informa de la fallada com a tres camps i no com a veredicte: la capa que ha fallat, l’intercanvi o fill que has inspeccionat, i les proves que tens. La capa és una de tres: el pare no es va establir mai, la negociació del fill va ser rebutjada, o hi ha un fill i el trànsit no hi arriba. La prova és l’identificador del fill amb els seus selectors i comptadors, o la proposta rebutjada citada dels dos registres. Qui ho llegeixi pot anar directament a l’intercanvi que importa en lloc de preguntar a quin VPN et refereixes.
La documentació d’IKEv2 de strongSwan mostra com apareixen aquestes capes a la sortida d’estat. Adjunta la sortida del fill que has provat, no només el resum del pare.