Per què el teu túnel IPsec funciona fins al primer canvi de clau de CHILD SA

El túnel es va aixecar, el ping va respondre i tothom va donar el vistiplau. Quatre hores més tard la sessió cau, els parells registren una errada de proposta o d’intercanvi de claus, i la primera suposició és que alguna cosa de la xarxa ha canviat. No ha canviat res. Un túnel que transporta trànsit ha demostrat que els dos parells coincideixen en com autenticar-se i com protegir la primera associació filla, i no ha demostrat res sobre l’intercanvi de claus que exigiran en la renovació. El desajust és al buit entre aquests dos esdeveniments.

Estar connectat no vol dir que la configuració de PFS coincideixi

Amb IKEv2, la primera associació filla es crea durant l’intercanvi d’autenticació, i les seves claus deriven de material que l’associació IKE ja ha produït. Per a aquesta filla no es fa cap intercanvi Diffie-Hellman separat, de manera que una política que n’exigeixi un en la renovació no es prova en l’aixecament.

La renovació és un intercanvi diferent. Quan es canvia la clau d’una associació filla, els parells poden fer un intercanvi de claus nou amb el grup que anomenen les seves propostes, i aquest és el primer moment en què es comparen els paràmetres del grup. Per tant, dos parells que no coincideixen poden autenticar-se, instal·lar una associació filla i passar trànsit, i després fallar en el canvi de clau.

On s’amaga el desajust a la cadena de la proposta

A strongSwan el grup s’afegeix a la proposta filla, i per això una cadena com aes256gcm16-prfsha256-ecp256 sembla una tria de xifratge però també arrossega un requisit d’intercanvi de claus. Un parell que només ofereix aes256gcm16-prfsha256 no té aquest requisit, i les dues llistes coincideixen en xifratge però discrepen en l’intercanvi.

Llegeix la proposta filla i la proposta IKE com a llistes separades. Un grup que apareix a la llista IKE no diu res sobre la llista filla, i editar-ne una mentre es llegeix l’altra és la manera habitual de passar-ho per alt.

Llegeix la fallada, no el fitxer que has editat

Troba el notify que va tancar l’intercanvi. Un canvi de clau de filla que retorna «cap proposta acceptable» apunta a les llistes de propostes; una petició de canvi de clau que no rep mai resposta apunta al camí o a un parell que ha deixat d’escoltar. Aquests dos casos demanen correccions diferents, i la redacció de la línia de registre els separa.

Confirma la configuració en execució, no la del disc. Un fitxer desat però no carregat, o una connexió rellegida des d’un include diferent, produiran un desajust que cap quantitat d’edició del fitxer visible no pot arreglar.

Tres esdeveniments que tots anomenem canvi de clau

El canvi de clau de l’associació IKE, la reautenticació IKE i el canvi de clau de l’associació filla són operacions separades amb regles de proposta separades. Una fallada informada en una d’elles no diu res directament de les altres, i un registre que les barreja es llegeix com una única avaria recurrent quan en són tres.

Fixa’t en quin esdeveniment anomena el parell i després revisa les propostes només per a aquest esdeveniment. Canvia una llista, recarrega i força el mateix esdeveniment una altra vegada. Si el registre anomena una reautenticació, la proposta IKE és la que cal llegir. Si anomena un canvi de clau de filla, la proposta filla porta el grup que importa.

Desactivar la renovació no és una solució

Posar el temps de canvi de clau a zero suprimeix l’intercanvi que falla, i el túnel sobreviu fins que es desmunta o el parell es reinicia. El que has comprat és una clau més duradora i un desajust que et tornarà a trobar durant una migració, una auditoria o una actualització del proveïdor. El mateix val per a durades estirades molt més enllà de la política que espera l’altra banda.

Alinea les propostes. Tria un grup que tots dos parells implementin, posa’l a la proposta filla dels dos extrems i mantén la política de renovació dins del rang que l’organització realment requereix.

Demostra-ho amb l’intercanvi que va fallar

Escurça el temps de canvi de clau de filla en una finestra de manteniment perquè l’esdeveniment arribi en minuts i no en hores, o desencadena un canvi manual. Després vigila una renovació correcta i confirma que el trànsit hi continua passant, perquè un nou handshake que instal·la una associació filla però deixa caure el flux de l’aplicació és un defecte diferent.

Després restaura la durada normal i conserva tots dos registres dels esdeveniments, el fallit i el correcte. La prova que vols és que la connexió sobrevisqui el seu propi cicle de vida, no que hagi sobreviscut a un ping.