De ce tunelul tău IPsec funcționează până la prima reînnoire a cheii CHILD SA

Tunelul a urcat, pingul a răspuns și toți au semnat. Patru ore mai târziu sesiunea cade, părțile înregistrează o eroare de propunere sau de schimb de chei, iar prima presupunere este că ceva s-a schimbat în rețea. Nimic nu s-a schimbat. Un tunel care transportă trafic a dovedit că cele două părți sunt de acord cum să se autentifice și cum să protejeze prima asociere derivată, și nu a dovedit nimic despre schimbul de chei pe care îl vor cere la reînnoire. Nepotrivirea stă în golul dintre cele două evenimente.

Conectat nu înseamnă că setările PFS sunt aceleași

Cu IKEv2, prima asociere derivată este creată în timpul schimbului de autentificare, iar cheile ei derivă din materialul pe care asocierea IKE l-a produs deja. Pentru acea asociere derivată nu are loc un schimb Diffie-Hellman separat, așa că o politică ce îl cere la reînnoire nu este testată la ridicare.

Reînnoirea este un alt schimb. Când cheia unei asocieri derivate este reînnoită, părțile pot face un schimb de chei nou cu grupul numit în propunerile lor, iar acesta este primul moment în care setările grupului sunt comparate. De aceea două părți care nu sunt de acord pot autentifica, instala o asociere derivată și lăsa traficul să treacă, apoi pot eșua la reînnoire.

Unde se ascunde nepotrivirea în șirul propunerii

În strongSwan grupul este adăugat la propunerea derivată, de aceea un șir precum aes256gcm16-prfsha256-ecp256 pare o alegere de criptare, dar poartă și o cerință de schimb de chei. O parte care oferă doar aes256gcm16-prfsha256 nu are o asemenea cerință, iar cele două liste se intersectează la criptare dar diferă la schimb.

Citește propunerea derivată și propunerea IKE ca liste separate. Un grup care apare în lista IKE nu spune nimic despre lista derivată, iar editarea uneia în timp ce o citești pe cealaltă este felul obișnuit în care acest lucru este ratat.

Citește eșecul, nu fișierul pe care l-ai editat

Găsește notify-ul care a încheiat schimbul. O reînnoire de cheie derivată care întoarce „nicio propunere acceptabilă” indică listele de propuneri; o cerere de reînnoire care nu primește niciodată răspuns indică traseul sau o parte care a încetat să asculte. Acestea două cer corecturi diferite, iar formularea liniei de jurnal le separă.

Confirmă configurația care rulează, nu pe cea de pe disc. Un fișier salvat dar neîncărcat, sau o conexiune recitită dintr-un alt include, vor produce o nepotrivire pe care nicio editare a fișierului vizibil nu o poate repara.

Trei evenimente pe care toți le numesc reînnoire de cheie

Reînnoirea cheii asocierii IKE, reautentificarea IKE și reînnoirea cheii asocierii derivate sunt operațiuni separate cu reguli de propunere separate. Un eșec raportat la una dintre ele nu spune nimic direct despre celelalte, iar un jurnal care le amestecă se citește ca un singur defect recurent, deși sunt trei.

Observă pe care eveniment îl numește partea, apoi verifică propunerile doar pentru acel eveniment. Schimbă o listă, reîncarcă și forțează din nou același eveniment. Dacă jurnalul numește o reautentificare, propunerea IKE este cea care trebuie citită. Dacă numește o reînnoire de cheie derivată, propunerea derivată poartă grupul care contează.

Oprirea reînnoirii nu este o soluție

Setarea timpului de reînnoire a cheii la zero suprimă schimbul care eșuează, iar tunelul supraviețuiește apoi până este demontat sau partea repornește. Ce ai cumpărat este o cheie cu viață mai lungă și o nepotrivire care te va întâlni din nou în timpul unei migrări, al unui audit sau al unei actualizări de la furnizor. Același lucru este valabil pentru duratele de viață întinse mult peste politica pe care o așteaptă cealaltă parte.

Aliniază în schimb propunerile. Alege un grup pe care ambele părți îl implementează, pune-l în propunerea derivată la ambele capete și ține politica de reînnoire în intervalul pe care organizația îl cere cu adevărat.

Dovedește-o cu schimbul care a eșuat

Scurtează timpul de reînnoire a cheii derivate într-o fereastră de mentenanță ca evenimentul să vină în minute, nu în ore, sau declanșează o reînnoire manuală. Apoi urmărește o reînnoire reușită și confirmă că traficul continuă prin ea, pentru că un handshake nou care instalează o asociere derivată dar lasă să cadă fluxul aplicației este un alt defect.

După aceea restaurează durata normală și păstrează ambele înregistrări ale evenimentelor, cea eșuată și cea reușită. Dovada pe care o vrei este că conexiunea supraviețuiește propriului ciclu de viață, nu că a supraviețuit unui ping.