De ce un tunel IPsec aglomerat reînnoiește cheile devreme: limite de timp și de volum

Aproximativ la fiecare cincizeci de minute, un tunel pe o legătură aglomerată cade pentru câteva secunde, iar primul suspect este ceasul. Asocierile se pot termina la o limită de timp sau la un număr de octeți, iar granița care sosește prima este cea care le trimite la pensie. Pe o legătură care transportă trafic real, o limită de volum poate intra în acțiune mult înainte de sfârșitul orei configurate. Deci „prea devreme” este o afirmație despre ceas, nu despre asociere.

Numărați ce numără asocierea, nu interfața

Totalul de octeți al unei interfețe, debitul combinat al unui panou și contorul propriu al asocierii sunt trei numere separate, și doar unul dintre ele este comparat cu limita. Înregistrați asocierea de intrare și cea de ieșire separat, cu identificatorii lor, astfel încât o schimbare de chei care atinge o singură direcție să apară ca un eveniment direcțional, nu ca un mister. Contorul asocierii repornește și el la schimbarea cheilor, de aceea un total luat de la interfață crește în timp ce valoarea care contează este resetată.

Merită făcut calculul o dată, ca ordinul de mărime să nu mai pară arbitrar. Un buget numărat de un gibibyte consumat la un ritm constant de 128 mebibyte pe minut se epuizează în opt minute, iar aceasta este o conversie de unități, nu o măsurătoare a tunelului dumneavoastră. Dacă cifra rezultată se află mult sub limita de timp, volumul este mecanismul și nicio observare a ceasului nu va explica intervalul. Dacă se află mult peste, limita de octeți nu este declanșatorul dumneavoastră și căutarea aparține altundeva.

Pragul moale și cel tare sunt două evenimente diferite

Un prag moale cere o înlocuire mult înainte ca limita tare să încheie asocierea, iar implementările adaugă propriile marje și randomizare peste ce ați configurat. De aceea intervalul observat aproape niciodată nu este un număr rotund. arhitectura IPsec descrie durate exprimate în timp și număr de octeți cu cele două tipuri de prag, iar expirarea mai devreme este cea care guvernează. Dacă tratați o durată tipărită ca pe un calendar, veți greși cu mărimea marjei.

Citiți politica efectivă din starea de execuție în loc să o deduceți dintr-un număr dintr-un fișier, pentru că marja aparține implementării, nu intenției dumneavoastră. Rezistați tentației de a întinde limitele spre maximum pentru a potoli simptomul: un tunel care schimbă cheile conform calendarului se comportă așa cum a fost proiectat, iar o durată mai lungă doar amână evenimentul, păstrând o cheie compromisă utilizabilă mai mult timp. Când înlocuirea însăși eșuează, limita este mesagerul, nu vina.

Citiți durata efectivă din starea de execuție

Pe strongSwan, swanctl --list-sas tipărește rezumatul asocierii cu timpii de schimbare a cheilor și de viață, astfel încât valoarea pe care demonul intenționează să o impună este vizibilă fără ghicit. Pe un gazdă Linux fără vizualizare a demonului, ip xfrm state raportează limitele moi și tari de octeți și pachete configurate, lângă contoarele curente. Cele două citiri răspund la întrebări diferite și ambele merită păstrate în tichet.

swanctl --list-sas
ip -s xfrm state

Comparați pragul moale tipărit cu intervalul pe care l-ați măsurat, pentru că o înlocuire care începe cu o marjă sub limita tare este normală, iar una care nu începe niciodată nu este. Dacă demonul arată o durată și starea kernelului arată alta, priviți două straturi care nu sunt de acord, iar aceasta este în sine constatarea.

Urmăriți schimbul care înlocuiește SA

Țineți cele trei reînnoiri separat, pentru că eșuează în moduri diferite: o schimbare de chei IKE SA construiește o nouă asociere de control, o schimbare de chei CHILD SA înlocuiește asocierea de date, iar reautentificarea repetă schimbul de identitate. În IKEv2 fiecare parte decide propriile durate în loc să negocieze o singură valoare comună, așa că un schimb pe care nu l-ați inițiat este obișnuit. O nepotrivire de perfect forward secrecy este o cauză frecventă pentru care o child SA nouă moare exact la intervalul de schimbare a cheilor, și se prezintă exact ca o defecțiune de temporizator până când cineva citește propunerea.

Comparați asocierea veche cu succesoarea ei și cu schimbul care a produs-o. Un identificator care dispare este o înlocuire de rutină; o propunere respinsă, un răspuns lipsă sau absența unei stări succesoare utilizabile este un eveniment diferit, cu alt proprietar. Păstrați acele dovezi înainte de a schimba ceva, pentru că notele specifice versiunii, propunerea partenerului și duratele negociate sunt ceea ce face cazul lizibil o săptămână mai târziu, după ce jurnalele s-au rotit.

Dovediți reînnoirea în loc să o ascundeți

Acceptați implementarea trecând printr-o reînnoire pe care ați planificat-o, nu printr-una care vi se întâmplă. Forțați o singură schimbare de chei într-o fereastră de mentenanță, apoi confirmați că ambele direcții transportă date după aceea și că rezultatul aplicației este neschimbat, nu doar că indicatorul tunelului este verde. Notați ce limită s-a declanșat și ce schimb a fost implicat.

O concluzie de această formă rezistă verificării, în timp ce o valoare de temporizator modificată care a făcut conexiunea să pară liniștită o după-amiază nu rezistă. Dacă doar temporizatorul s-a mișcat, dovezile s-au mișcat împreună cu el.