OpenVPN-hookhendelser: hvorfor navn og tidsstempel ikke er en nøkkel

En frakoblingspost kommer etter at en andre tilkobling under samme navn allerede har startet, og en behandler som oppdaterer den nyeste raden for den brukeren, lukker feil økt. Feilen er ikke selve tidsstempelsammenligningen. Det er antakelsen om at et navn pluss ett helt sekund identifiserer én økt. Hookhendelser beskriver tilkoblinger, og en tilkobling trenger en nøkkel som bare tilhører den.

Begynn med hva frakoblingsvariablene egentlig betyr. Først da gir valget av identifikator mening.

Hva frakoblingshooken egentlig bærer

I Community OpenVPN 2.6 definerer hook-referansen time_unix som øyeblikket klienten koblet til; den settes før tilkoblingshooken kjører, og den redefineres ikke når frakoblingshooken senere utløses. time_duration gir lengden på den økten i sekunder, så slutten er omtrent tilkoblingstiden pluss varigheten. Begge er hele sekunder, og ingen av dem er øyeblikket da databasen din behandlet hendelsen. Det er å holde disse tre tidene fra hverandre som gjør at en korrelasjon holder, i stedet for bare å se riktig ut under testing.

Denne aritmetikken fortjener å bli skrevet ned, fordi det er den eneste sluttiden hooken selv tilbyr. Behandlingsforsinkelse og klokkeforskjeller mellom verter ligger fortsatt utenfor.

Hvorfor det åpenbare paret ikke er unikt

Å pare navnet med tilkoblingstiden snevrer inn søket og identifiserer fortsatt ikke en økt. En klient kan koble til på nytt innenfor samme sekund, så to økter kan dele begge verdiene. To daemon-instanser, eller en serverutskiftning som beholder samme konfigurasjon, kan produsere det paret fra forskjellige prosesser. Tunneladresser resirkuleres av samme grunn, noe som gjør dem til attributter for en økt snarere enn identifikatorer for den.

Feilmodusen er stille. En sen frakobling for den første økten treffer den nyeste raden og avslutter en tildeling som den andre økten fortsatt bruker, så brukeren opplever et tilfeldig tap av tilgang som de ikke forårsaket. Et radantall som ser riktig ut etterpå, gjør problemet vanskeligere å oppdage.

Hvor en stabil identitet kommer fra

Administrasjonsgrensesnittet tildeler hver klient en klientinstans-identifikator, og den identifikatoren er begrenset til daemon-instansen som utstedte den. En brukbar ekstern nøkkel kombinerer en stabil serveridentifikator, en epoke som endres når daemonen starter, og den klient-ID-en. Epoken er viktig fordi identifikatorer starter på nytt med prosessen, og en bar prosess-ID kan senere gjenbrukes av noe urelatert.

Miljøvariabler som settes inne i et underordnet tilkoblingsskript, reiser ikke til den overordnede daemonens senere frakoblingsskript, fordi disse skriptene kjører som separate prosesser med egne miljøer. Derfor er generering av en UUID ved tilkobling bare halve løsningen. Frakoblingssiden må kunne navngi den samme UUID-en, noe som betyr at identiteten må leve et sted der begge hendelsene kan nå den.

Gjør avslutningen betinget og idempotent

Avslutt etter øktens eier, ikke etter bruker. En behandler som sletter tildelingen som for øyeblikket tilhører et navn, vil etter hvert slette den feile, og det eneste forsvaret er å kontrollere at posten som fjernes, er posten denne hendelsen beskriver.

Administrasjonsgrensesnittet godtar én tilkoblet administrasjonsklient om gangen, så integrer med den som allerede eier det, i stedet for å feste en andre observatør som konkurrerer om samme sokkel.

Håndter gjentatte hendelser uten å endre resultatet to ganger, og ta vare på uparede hendelser for avstemming i stedet for å forkaste dem. En frakoblingscallback har dokumenterte livssyklusvilkår og kommer kanskje aldri etter et krasj eller en hard stopp, så designet trenger en måte å representere en økt der slutthendelsen mangler.

Test de vanskelige tilfellene med vilje: to gjenoppkoblinger innen ett sekund, to daemon-instanser, en tilkobling hvis behandling mislyktes, og en daemon-omstart midt i en økt. En nøkkel som overlever alle fire, er en nøkkel som er verdt å stole på.