OpenVPN-hookhendingar: kvifor namn og tidsstempel ikkje er ein nøkkel

Ein fråkoplingspost kjem etter at ei andre tilkopling under same namnet allereie har starta, og ein behandlar som oppdaterer den nyaste rada for den brukaren, lukkar feil økt. Feilen er ikkje sjølve tidsstempelsamanlikninga. Det er føresetnaden om at eit namn pluss eitt heilt sekund identifiserer éi økt. Hookhendingar skildrar tilkoplingar, og ei tilkopling treng ein nøkkel som berre høyrer til henne.

Byrja med kva fråkoplingsvariablane eigentleg tyder. Fyrst då gir valet av identifikator meining.

Kva fråkoplingshooken eigentleg ber

I Community OpenVPN 2.6 definerer hook-referansen time_unix som augneblunken klienten kopla til; han blir sett før tilkoplingshooken køyrer, og han blir ikkje omdefinert når fråkoplingshooken seinare blir utløyst. time_duration gir lengda på den økta i sekund, så slutten er om lag tilkoplingstida pluss varigheita. Begge er heile sekund, og ingen av dei er augneblunken då databasen din handsama hendinga. Det er å halde desse tre tidene frå kvarandre som gjer at ein korrelasjon held, i staden for berre å sjå rett ut under testing.

Denne aritmetikken fortener å bli skriven ned, fordi det er den einaste slutttida hooken sjølv tilbyr. Handsamingforsinking og klokkeforskjellar mellom vertar ligg framleis utanfor.

Kvifor det openberre paret ikkje er unikt

Å pare namnet med tilkoplingstida snevrar inn søket og identifiserer framleis ikkje ei økt. Ein klient kan kopla til på nytt innanfor same sekundet, så to økter kan dela begge verdiane. To daemon-instansar, eller ei serverutskifting som held same konfigurasjonen, kan produsere det paret frå ulike prosessar. Tunneladresser blir resirkulerte av same grunn, noko som gjer dei til attributt for ei økt snarare enn identifikatorar for henne.

Feilmodusen er stille. Ei sein fråkopling for den første økta treffer den nyaste rada og avsluttar ei tildeling som den andre økta framleis brukar, så brukaren opplever eit tilfeldig tap av tilgang som han ikkje forårsaka. Eit radtal som ser rett ut etterpå, gjer problemet vanskelegare å oppdage.

Kvar ein stabil identitet kjem frå

Administrasjonsgrensesnittet tildeler kvar klient ein klientinstans-identifikator, og den identifikatoren er avgrensa til daemon-instansen som gav han ut. Ein brukbar ekstern nøkkel kombinerer ein stabil serveridentifikator, ein epoke som endrar seg når daemonen startar, og den klient-ID-en. Epoken er viktig fordi identifikatorar startar på nytt med prosessen, og ein berr prosess-ID kan seinare bli brukt på nytt av noko urelatert.

Miljøvariablar som blir sette inne i eit underordna tilkoplingsskript, reiser ikkje til det seinare fråkoplingsskriptet til den overordna daemonen, fordi desse skripta køyrer som separate prosessar med eigne miljø. Derfor er generering av ein UUID ved tilkopling berre halve løysinga. Fråkoplingssida må kunne namngje den same UUID-en, noko som tyder at identiteten må leve ein stad der begge hendingane kan nå han.

Gjer avsluttinga vilkårleg og idempotent

Avslutt etter eigaren av økta, ikkje etter brukar. Ein behandlar som slettar tildelinga som for augneblunken høyrer til eit namn, vil etter kvart slette den feile, og det einaste forsvaret er å kontrollere at posten som blir fjerna, er posten denne hendinga skildrar.

Administrasjonsgrensesnittet godtek éin tilkopla administrasjonsklient om gongen, så integrer med den som allereie eig det, i staden for å feste ein andre observatør som konkurrerer om same sokkel.

Handsam gjentekne hendingar utan å endre resultatet to gonger, og ta vare på upara hendingar for avstemming i staden for å kaste dei. Ein fråkoplingscallback har dokumenterte livssyklusvilkår og kjem kanskje aldri etter eit krasj eller ein hard stopp, så designet treng ein måte å representere ei økt der slutthendinga manglar.

Test dei vanskelege tilfella med vilje: to gjenoppkoplingar innan eitt sekund, to daemon-instansar, ei tilkopling der handsaminga mislykkast, og ein daemon-omstart midt i ei økt. Ein nøkkel som overlever alle fire, er ein nøkkel som er verdt å stole på.