Dogodki kljuk OpenVPN: zakaj ime in časovni žig nista ključ

Zapis o prekinitvi prispe po tem, ko se je druga povezava pod istim imenom že začela, in upravljalnik, ki posodablja najnovejšo vrstico za tega uporabnika, zapre napačno sejo. Napaka ni v primerjavi časovnih žigov. Je v predpostavki, da ime plus cela sekunda identifikujeta eno sejo. Dogodki kljuk opisujejo povezave, povezava pa potrebuje ključ, ki pripada samo njej.

Začnite s tem, kaj spremenljivke prekinitve v resnici pomenijo. Šele takrat ima izbira identifikatorja smisel.

Kaj kljuka za prekinitev v resnici nosi

V Community OpenVPN 2.6 referenca kljuk time_unix opredeljuje kot trenutek, ko se je odjemalec povezal; nastavi se pred izvajanjem kljuke za povezavo in se ne ponovno opredeli, ko se kljuka za prekinitev pozneje sproži. time_duration poda dolžino te seje v sekundah, zato je konec približno čas povezave plus trajanje. Oba sta celi sekundi in nobeden ni trenutek, ko je vaša zbirka podatkov obdelala dogodek. Prav ločevanje teh treh časov omogoča, da korelacija zdrži, namesto da bi bila le videti pravilna med testiranjem.

Ta aritmetika si zasluži zapis, ker je edini čas konca, ki ga ponuja sama kljuka. Zakasnitev obdelave in razlike v urah med gostitelji še vedno ostajajo zunaj nje.

Zakaj očitni par ni edinstven

Seznanjanje imena s časom povezave zoži iskanje in še vedno ne identificira seje. Odjemalec se lahko znova poveže v isti sekundi, zato si lahko dve seji delita obe vrednosti. Dva primerka demonskega procesa ali zamenjava strežnika, ki ohrani isto konfiguracijo, lahko ustvarita ta par iz različnih procesov. Naslovi tunela se reciklirajo iz istega razloga, zaradi česar so atributi seje, ne pa identifikatorji zanjo.

Način okvare je tih. Pozna prekinitev prve seje se ujema z najnovejšo vrstico in zaključi dodelitev, ki jo druga seja še uporablja, zato uporabnik doživi naključno izgubo dostopa, ki je ni povzročil. Število vrstic, ki se pozneje zdi pravilno, oteži odkrivanje težave.

Od kod prihaja stabilna identiteta

Upravljalni vmesnik vsakemu odjemalcu dodeli identifikator primerka odjemalca, in ta identifikator je omejen na primerek demonskega procesa, ki ga je izdal. Uporaben zunanji ključ združuje stabilen identifikator strežnika, epoho, ki se spremeni ob zagonu demonskega procesa, in ta ID odjemalca. Epoha je pomembna, ker se identifikatorji znova zaženejo s procesom, goli ID procesa pa lahko pozneje ponovno uporabi nekaj nepovezanega.

Okoljske spremenljivke, nastavljene znotraj podrejenega skripta povezave, ne potujejo v poznejši skript prekinitve nadrejenega demonskega procesa, ker se ti skripti izvajajo kot ločeni procesi z lastnimi okolji. Zato je ustvarjanje UUID ob povezavi pol rešitve. Stran prekinitve mora znati poimenovati isti UUID, kar pomeni, da mora identiteta živeti nekje, kamor lahko prideta oba dogodka.

Zaključevanje naredite pogojno in idempotentno

Zaključite po lastniku seje, ne po uporabniku. Upravljalnik, ki izbriše katero koli dodelitev, ki trenutno pripada imenu, bo prej ali slej izbrisal napačno, in edina obramba je preveriti, da je odstranjeni zapis zapis, ki opisuje ta dogodek.

Upravljalni vmesnik sprejme enega povezanega upravljalnega odjemalca naenkrat, zato se povežite s tistim, ki ga že ima, namesto da pripnete drugega opazovalca, ki tekmuje za isto vtičnico.

Ponavljajoče se dogodke obravnavajte brez dvojne spremembe izida, neparne dogodke pa shranite za usklajevanje, namesto da jih zavržete. Povratni klic prekinitve ima dokumentirane pogoje življenjskega cikla in po sesutju ali trdem zaustavljanju morda nikoli ne pride, zato načrt potrebuje način za predstavitev seje, katere končni dogodek manjka.

Nerodne primere preizkusite namenoma: dve ponovni povezavi v eni sekundi, dva primerka demonskega procesa, povezava, katere obdelava ni uspela, in ponovni zagon demonskega procesa sredi seje. Ključ, ki preživi vse štiri, je ključ, vreden zaupanja.