Kial okupata IPsec-tunelo antaŭtempe ŝanĝas ŝlosilojn: tempaj kaj volumenaj limoj

Proksimume ĉiujn kvindek minutojn tunelo sur okupata ligo falas dum kelkaj sekundoj, kaj la unua suspektato estas la horloĝo. Asocioj povas finiĝi per templimo aŭ per bajtokvanto, kaj kiu limo venas unue, tiu ilin emeritigas. Sur ligo portanta realan trafikon, volumena limo povas ekagi longe antaŭ ol la agordita horo finiĝos. Do «tro frue» estas aserto pri la horloĝo, ne pri la asocio.

Kalkulu tion, kion kalkulas la asocio, ne la interfaco

Bajta sumo de interfaco, kombinita trafiko de panelo kaj la propra nombrilo de la asocio estas tri apartaj nombroj, kaj nur unu el ili estas komparata kun la limo. Registru la envenantan kaj elirantan asociojn aparte kun iliaj identigiloj, por ke ŝlosilŝanĝo tuŝanta unu direkton aperu kiel direkta evento anstataŭ enigmo. La nombrilo de la asocio ankaŭ rekomenciĝas ĉe ŝlosilŝanĝo, tial sumo prenita de la interfaco kreskas dum la grava valoro estas restarigita.

Indas fari la kalkulon unufoje, por ke la grandordo ĉesu ŝajni arbitra. Kalkulita buĝeto de unu gibibajto elĉerpata per stabila 128 mebibajtoj minute elĉerpiĝas en ok minutoj, kaj tio estas unuokonverto, ne mezuro de via tunelo. Se la rezulta cifero kuŝas multe sub la templimo, la mekanismo estas volumeno kaj nenia horloĝobservado klarigos la intervalon. Se ĝi kuŝas multe super ĝi, la bajta limo ne estas via ellasilo kaj la serĉado apartenas aliloke.

Molaj kaj malmolaj sojloj estas du malsamaj eventoj

Mola sojlo petas anstataŭon longe antaŭ ol la malmola limo finas la asocion, kaj efektivigoj aldonas proprajn marĝenojn kaj hazardigon super kion ajn vi agordis. Tial la observata intervalo preskaŭ neniam estas ronda nombro. IPsec-arkitekturo priskribas vivdaŭrojn esprimitajn per tempo kaj bajtokvantoj kun la du specoj de sojlo, kaj la pli frua finiĝo regas. Se vi traktos unu presitan vivdaŭron kiel horaron, vi eraros je la marĝeno.

Legu la efikan politikon el la kuranta stato anstataŭ dedukti ĝin el nombro en dosiero, ĉar la marĝeno apartenas al la efektivigo, ne al via intenco. Rezistu la emon etendi limojn al ilia maksimumo por silentigi la simptomon: tunelo, kiu ŝanĝas ŝlosilojn laŭ horaro, kondutas kiel projektite, kaj pli longa vivdaŭro nur prokrastas la eventon tenante kompromititan ŝlosilon pli longe uzebla. Kiam la anstataŭo mem malsukcesas, la limo estas la mesaĝisto, ne la kulpo.

Legu la efikan vivdaŭron el la kuranta stato

Sur strongSwan, swanctl --list-sas presas la resumon de la asocio kun ĝiaj ŝlosilŝanĝaj kaj vivaj tempoj, do la valoro, kiun la demono intencas trudi, estas videbla sen diveni. Sur Linux-gastiganto sen demona vido, ip xfrm state raportas la agorditajn molajn kaj malmolajn limojn de bajtoj kaj pakaĵoj apud la nunaj nombriloj. Tiuj du legaĵoj respondas malsamajn demandojn kaj ambaŭ indas resti en la bileto.

swanctl --list-sas
ip -s xfrm state

Komparu la presitan molan sojlon kun la intervalo, kiun vi mezuris, ĉar anstataŭo, kiu komenciĝas kun marĝeno sub la malmola limo, estas normala, kaj unu, kiu neniam komenciĝas, ne estas. Se la demono montras unu vivdaŭron kaj la kernstato alian, vi rigardas du tavolojn, kiuj malkongruas, kaj tio mem estas la trovajo.

Observu la interŝanĝon, kiu anstataŭigas la SA

Tenu la tri renovigojn aparte, ĉar ili malsukcesas laŭ malsamaj manieroj: ŝlosilŝanĝo de IKE SA konstruas novan kontrolasocion, ŝlosilŝanĝo de CHILD SA anstataŭigas la datum-asocion, kaj reaŭtentigo ripetas la identecinterŝanĝon. En IKEv2 ĉiu partnero decidas siajn proprajn vivdaŭrojn anstataŭ intertrakti unu komunan valoron, do interŝanĝo, kiun vi ne iniciatis, estas ordinara. Malkongruo de perfect forward secrecy estas ofta kaŭzo, ke nova child SA mortas ĝuste ĉe la ŝlosilŝanĝa intervalo, kaj ĝi aspektas ĝuste kiel tajmera difekto ĝis iu legas la proponon.

Komparu la malnovan asocion kun ĝia posteulo kaj kun la interŝanĝo, kiu produktis ĝin. Malaperanta identigilo estas rutina anstataŭo; rifuzita propono, mankanta respondo aŭ manko de uzebla posteula stato estas malsama evento kun malsama posedanto. Konservu tiun pruvon antaŭ ol ŝanĝi ion ajn, ĉar la versiospecifaj notoj, la propono de la partnero kaj la intertraktitaj vivdaŭroj estas tio, kio faras la kazon legebla semajnon poste, post kiam la protokoloj rotaciiĝis.

Pruvu la renovigon anstataŭ kaŝi ĝin

Akiru la disfaldiĝon pasante tra renovigo, kiun vi planis, ne tra unu, kiu okazas al vi. Trudu unu ŝlosilŝanĝon ene de bontenada fenestro, poste konfirmu, ke ambaŭ direktoj portas datumojn poste kaj ke la aplika rezulto estas senŝanĝa, ne nur ke la tunela indikilo estas verda. Notu, kiu limo ekagis kaj kiu interŝanĝo estis implikita.

Konkludo de tia formo eltenas ekzamenon, dum ŝanĝita tajmera valoro, kiu igis la konekton ŝajni kvieta dum posttagmezo, ne eltenas. Se nur la tajmero moviĝis, la pruvo moviĝis kun ĝi.