SA IKEv2 este activă, dar nu există nicio SA copil: citiți schimbul

IKE spune că tunelul este activ, SA copil lipsește, iar ambele afirmații pot fi adevărate în același timp. O relație de control stabilită nu este o asociere de date, iar cele două obiecte au durate de viață, negocieri și moduri de eșec separate. Raportarea primeia ca conectivitate este calea prin care un tichet ajunge să susțină că tunelul este activ în timp ce nimic nu funcționează. Citiți lista de asocieri, nu eticheta de rezumat a conexiunii, pentru că acea listă este singurul loc unde obiectul lipsă este vizibil. Urmează ordinea în care lista are sens.

Două asocieri, două sarcini

O SA IKE transportă canalul de control: identități, chei și propunerile pentru schimbul de control propriu-zis. O SA copil transportă protecția ESP, cu algoritmii ei și selectorii ei de trafic. Autentificarea și crearea SA copil merg de obicei împreună, pentru că prima SA copil este negociată în interiorul IKE_AUTH, iar exact această îmbinare surprinde oamenii în privința separării.

Aceasta explică și cele două forme de eșec pe care le veți întâlni. O SA copil respinsă în timpul schimbului inițial coboară de obicei și SA IKE, așa că nu vedeți niciun canal de control stabilit. O SA IKE singură înseamnă mai des că prima SA copil a reușit și că o încercare ulterioară de a crea o SA copil a eșuat, de exemplu în timpul unei reînnoiri de chei. Marcajele de timp separă acele cazuri mai repede decât orice revizuire a configurației.

Ce strat a refuzat

Când o SA copil este respinsă, notificarea numește stratul. O respingere a propunerii înseamnă că părțile nu au putut conveni asupra algoritmilor, adesea pentru că una cere un alt grup de secret perfect înainte sau un cifru pe care cealaltă nu îl va accepta. O respingere a selectorului înseamnă că setul de trafic a fost refuzat direct, iar acesta este un argument de acoperire, nu unul criptografic.

Uneori absența SA copil este chiar proiectul. O SA IKE fără SA copil este o extensie definită folosită acolo unde asocierea de date trebuie creată la cerere, așa că absența este corectă și SA copil apare când sosește trafic potrivit. Notele strongSwan despre IKEv2 acoperă atât stilul la cerere, cât și setările propunerii care decid primul caz.

Verificați dacă există o configurație la cerere sau o capcană înainte de a diagnostica o defecțiune. Dacă SA copil sunt create leneș, absența SA copil în repaus este starea așteptată, iar testul real este dacă traficul ridică una. Acest test separă și un proiect leneș de o defecțiune silențioasă, pentru că o creare eșuată lasă declanșatorul fără răspuns, nu doar în repaus.

Apoi întrebați despre calea datelor

Odată ce există o SA copil, contoarele răspund la următoarea întrebare. ip -s xfrm state raportează numărul de pachete și octeți pe asociere, iar o SA copil care nu transportă nimic în timp ce generați trafic indică potrivire sau rutare, nu către o asociere lipsă. swanctl --list-sas tipărește selectorii SA copil lângă acele contoare, și exact asta confirmă că pachetul se află în setul acceptat.

Țineți separat în raport autentificarea reușită și schimbul eșuat al SA copil. Un raport care spune că autentificarea a eșuat trimite următorul inginer la depozitul de certificate, iar propoziția exactă este mult mai scurtă: SA IKE a urcat, iar SA copil pentru acest flux nu a fost niciodată acceptată.

Corelați cele două capete

Pentru un server pe care îl administrați singur, luați jurnalele clientului și ale porții pentru același schimb în loc să comparați două încercări de reconectare la o oră distanță. Notificările ar trebui să corespundă pe ambele părți, iar acolo unde nu corespund ați găsit partea configurată greșit.

Corectați negocierea SA copil, apoi retestați cu trafic în interiorul selectorului dorit. Acesta este singurul test care dovedește că obiectul lipsă este acum prezent, pentru că o listă de asocieri reîmprospătată în repaus poate arăta identic înainte și după corectare.