OpenVPN-haakgebeurtenisse: waarom naam en tydstempel nie ’n sleutel is nie

’n Ontkoppelrekord kom aan nadat ’n tweede verbinding onder dieselfde naam reeds begin het, en ’n hanteerder wat die nuutste ry vir daardie gebruiker bywerk, sluit die verkeerde sessie. Die fout is nie die tydstempelvergeliking self nie. Dit is die aanname dat ’n naam plus ’n hele sekonde een sessie identifiseer. Haakgebeurtenisse beskryf verbindings, en ’n verbinding het ’n sleutel nodig wat alleen aan hom behoort.

Begin met wat die ontkoppelveranderlikes werklik beteken. Eers dan maak die keuse van identifiseerder sin.

Wat die ontkoppel-haak werklik dra

In Community OpenVPN 2.6 definieer die haakverwysing time_unix as die oomblik toe die kliënt verbind het, gestel voordat die verbind-haak loop, en dit word nie herdefinieer wanneer die ontkoppel-haak later vuur nie. time_duration gee die lengte van daardie sessie in sekondes, so die einde is ongeveer die verbindingstyd plus die duur. Albei is heel sekondes, en nie een is die oomblik toe jou databasis die gebeurtenis verwerk het nie. Om daardie drie tye apart te hou, is wat ’n korrelasie laat hou in plaas van om net reg te lyk tydens toetsing.

Die rekenkunde verdien om neergeskryf te word, want dit is die enigste eindtyd wat die haak self bied. Verwerkingsvertraging en klokverskille tussen hosts bly steeds daarbuite.

Waarom die ooglopende paar nie uniek is nie

Om die naam met die verbindingstyd te paar, vernou die soektog en identifiseer steeds nie ’n sessie nie. ’n Kliënt kan binne dieselfde sekonde weer verbind, so twee sessies kan albei waardes deel. Twee daemon-instanties, of ’n bedienervervanging wat dieselfde konfigurasie behou, kan daardie paar uit verskillende prosesse lewer. Tonneladresse word om dieselfde rede hergebruik, wat hulle eienskappe van ’n sessie maak eerder as identifiseerders vir een.

Die foutmodus is stil. ’n Late ontkoppeling vir die eerste sessie pas by die nuutste ry en beëindig ’n toewysing wat die tweede sessie nog gebruik, so die gebruiker ervaar ’n toevallige verlies van toegang wat hulle niks gedoen het om te veroorsaak nie. ’n Ry-telling wat daarna korrek lyk, maak die probleem moeiliker om raak te sien.

Waar ’n stabiele identiteit vandaan kom

Die bestuurskoppelvlak ken aan elke kliënt ’n kliënt-instantie-identifiseerder toe, en daardie identifiseerder is beperk tot die daemon-instantie wat dit uitgereik het. ’n Werkbare eksterne sleutel kombineer ’n stabiele bedieneridentifiseerder, ’n epog wat verander wanneer die daemon begin, en daardie kliënt-ID. Die epog maak saak omdat identifiseerders saam met die proses herbegin, en ’n blote proses-ID kan later deur iets onverwants hergebruik word.

Omgewingsveranderlikes wat binne ’n kind-verbindskrip gestel word, reis nie na die ouer-daemon se latere ontkoppelskrip nie, want daardie skripte loop as aparte prosesse met hul eie omgewings. Om ’n UUID tydens verbinding te genereer, is dus half ’n oplossing. Die ontkoppelkant moet dieselfde UUID kan noem, wat beteken die identiteit moet êrens woon waar albei gebeurtenisse dit kan bereik.

Maak aftrede voorwaardelik en idempotent

Tree af volgens sessie-eienaar, nie volgens gebruiker nie. ’n Hanteerder wat enige toewysing wat tans aan ’n naam behoort, verwyder, sal uiteindelik die verkeerde een verwyder, en die enigste verdediging is om te kontroleer dat die rekord wat verwyder word, die rekord is wat hierdie gebeurtenis beskryf.

Die bestuurskoppelvlak aanvaar een gekoppelde bestuurskliënt op ’n slag, so integreer met wie dit reeds besit eerder as om ’n tweede waarnemer te koppel wat vir dieselfde socket meeding.

Hanteer herhaalde gebeurtenisse sonder om die uitkoms twee keer te verander, en hou ongepaarde gebeurtenisse vir versoening eerder as om hulle weg te gooi. ’n Ontkoppel-terugroep het gedokumenteerde lewensiklusvoorwaardes en kom dalk nooit ná ’n ineenstorting of ’n harde stop nie, so die ontwerp het ’n manier nodig om ’n sessie voor te stel wie se eindgebeurtenis ontbreek.

Toets die ongemaklike gevalle doelbewus: twee herverbindings binne een sekonde, twee daemon-instanties, ’n verbinding wie se verwerking misluk het, en ’n daemon-herbegin in die middel van ’n sessie. ’n Sleutel wat al vier oorleef, is ’n sleutel werd om te vertrou.