Zašto zauzet IPsec tunel rano mijenja ključeve: vremenski i volumenski limiti

Otprilike svakih pedeset minuta tunel na zauzetom linku padne na nekoliko sekundi, a prvi osumnjičeni je sat. Asocijacije mogu završiti po vremenskom limitu ili po broju bajtova, i koja granica prva stigne, ona ih umirovljava. Na linku koji nosi stvarni promet, ograničenje obima može se aktivirati mnogo prije nego što istekne konfigurirani sat. Zato je „prerano“ izjava o satu, a ne o asocijaciji.

Brojite ono što asocijacija broji, a ne interfejs

Ukupni broj bajtova na interfejsu, kombinirani protok na nadzornoj ploči i vlastiti brojač asocijacije tri su odvojena broja, i samo se jedan od njih poredi s limitom. Bilježite ulaznu i izlaznu asocijaciju odvojeno s njihovim identifikatorima, da se promjena ključeva koja dotiče jedan smjer pojavi kao smjerni događaj, a ne kao misterija. Brojač asocijacije također počinje iznova pri promjeni ključeva, zato ukupan iznos uzet s interfejsa raste dok se vrijednost koja je važna resetuje.

Računicu vrijedi napraviti jednom da red veličine prestane djelovati proizvoljno. Budžet od jednog gibibajta koji se troši stalnom brzinom od 128 mebibajta u minuti iscrpljuje se za osam minuta, i to je preračunavanje jedinica, a ne mjerenje vašeg tunela. Ako dobijena brojka stoji daleko ispod vremenskog limita, obim je mehanizam i nikakvo gledanje u sat neće objasniti interval. Ako stoji daleko iznad njega, ograničenje bajtova nije vaš okidač i potraga pripada negdje drugdje.

Meki i tvrdi prag su dva različita događaja

Meki prag traži zamjenu znatno prije nego tvrdi limit okonča asocijaciju, a implementacije slažu vlastite margine i randomizaciju povrh svega što ste konfigurisali. Zato promatrani interval gotovo nikad nije okrugli broj. IPsec arhitektura opisuje životne vijekove izražene vremenom i brojem bajtova s dvije vrste pragova, a raniji istek je mjerodavan. Tretirate li jedan ispisani životni vijek kao raspored, pogriješit ćete za iznos margine.

Čitajte efektivnu politiku iz tekućeg stanja umjesto da je izvodite iz broja u datoteci, jer margina pripada implementaciji, a ne vašoj namjeri. Odupirite se rastezanju limita prema maksimumu da ušutkate simptom: tunel koji mijenja ključeve po rasporedu ponaša se kako je projektovan, a duži životni vijek samo odgađa događaj držeći kompromitovani ključ duže upotrebljivim. Kada sama zamjena ne uspije, limit je glasnik, a ne krivica.

Pročitajte efektivni životni vijek iz tekućeg stanja

Na strongSwanu swanctl --list-sas ispisuje sažetak asocijacije s vremenima promjene ključeva i životnog vijeka, pa je vrijednost koju demon namjerava provesti vidljiva bez nagađanja. Na Linux hostu bez pogleda demona ip xfrm state prijavljuje konfigurisane meke i tvrde limite bajtova i paketa uz trenutne brojače. Ta dva očitanja odgovaraju na različita pitanja i oba vrijedi sačuvati u tiketu.

swanctl --list-sas
ip -s xfrm state

Uporedite ispisani meki prag s intervalom koji ste izmjerili, jer je zamjena koja počinje s marginom ispod tvrdog limita normalna, a zamjena koja nikad ne počinje nije. Ako demon pokazuje jedan životni vijek, a stanje kernela drugi, gledate u dva sloja koja se ne slažu, i to je samo po sebi nalaz.

Pratite razmjenu koja zamjenjuje SA

Držite tri obnove odvojeno, jer oni ne uspijevaju na različite načine: promjena ključeva IKE SA gradi novu kontrolnu asocijaciju, promjena ključeva CHILD SA zamjenjuje podatkovnu asocijaciju, a ponovna autentifikacija ponavlja razmjenu identiteta. U IKEv2 svaka strana odlučuje o vlastitim životnim vijekovima umjesto da pregovara jednu zajedničku vrijednost, pa je razmjena koju niste pokrenuli uobičajena. Nesklad perfect forward secrecy čest je razlog da novi child SA umre upravo na intervalu promjene ključeva, i izgleda točno kao kvar tajmera dok neko ne pročita prijedlog.

Uporedite staru asocijaciju s njenim nasljednikom i s razmjenom koja ju je stvorila. Nestanak identifikatora rutinska je zamjena; odbijen prijedlog, nedostajući odgovor ili odsustvo upotrebljivog stanja nasljednika drugi je događaj s drugim vlasnikom. Sačuvajte te dokaze prije nego što bilo šta promijenite, jer verzijski zapisi, prijedlog druge strane i pregovarani životni vijekovi čine slučaj čitljivim sedmicu kasnije, nakon što se logovi rotiraju.

Dokažite obnovu umjesto da je skrivate

Prihvatite implementaciju prolaskom kroz obnovu koju ste planirali, a ne kroz onu koja vam se dogodi. Forsirajte jednu promjenu ključeva unutar prozora za održavanje, zatim potvrdite da oba smjera nakon toga nose podatke i da je rezultat aplikacije nepromijenjen, a ne samo da je indikator tunela zelen. Zabilježite koji je limit aktiviran i koja je razmjena bila uključena.

Zaključak takvog oblika prolazi provjeru, a promijenjena vrijednost tajmera koja je učinila vezu tihom na jedno poslijepodne ne prolazi. Ako se pomaknuo samo tajmer, dokazi su se pomaknuli s njim.