Udalosti háčikov OpenVPN: prečo názov a časová pečiatka nie sú kľúčom

Záznam o odpojení prichádza po tom, čo sa už začalo druhé pripojenie pod rovnakým názvom, a obsluha, ktorá aktualizuje najnovší riadok pre tohto používateľa, zatvorí nesprávnu reláciu. Chyba nie je v porovnávaní časových pečiatok. Je v predpoklade, že názov plus celá sekunda identifikujú jednu reláciu. Udalosti háčikov opisujú pripojenia a pripojenie potrebuje kľúč, ktorý patrí iba jemu.

Začnite tým, čo premenné odpojenia skutočne znamenajú. Až potom má voľba identifikátora zmysel.

Čo háčik odpojenia skutočne nesie

V Community OpenVPN 2.6 referencia háčikov time_unix definuje ako okamih, keď sa klient pripojil; nastavuje sa pred spustením háčika pripojenia a nie je nanovo definovaný, keď neskôr zasiahne háčik odpojenia. time_duration udáva dĺžku tejto relácie v sekundách, takže koniec je približne čas pripojenia plus trvanie. Obidva sú celé sekundy a ani jeden nie je okamih, keď vaša databáza udalosť spracovala. Práve oddelenie týchto troch časov spôsobuje, že korelácia vydrží, namiesto toho, aby len počas testovania vyzerala správne.

Táto aritmetika si zaslúži zápis, pretože je to jediný čas konca, ktorý háčik sám ponúka. Oneskorenie spracovania a rozdiely hodín medzi hosťami zostávajú mimo neho.

Prečo evidentná dvojica nie je jedinečná

Spárovanie názvu s časom pripojenia zúži hľadanie a stále reláciu neidentifikuje. Klient sa môže znovu pripojiť v tej istej sekunde, takže dve relácie môžu zdieľať obe hodnoty. Dve inštancie démona alebo výmena servera, ktorá zachová rovnakú konfiguráciu, môžu túto dvojicu vytvoriť z rôznych procesov. Adresy tunela sa recyklujú z rovnakého dôvodu, čo z nich robí atribúty relácie, nie identifikátory pre ňu.

Režim zlyhania je tichý. Neskoré odpojenie prvej relácie zodpovedá najnovšiemu riadku a ukončí pridelenie, ktoré druhá relácia stále používa, takže používateľ zažije náhodnú stratu prístupu, ktorú nespôsobil. Počet riadkov, ktorý potom vyzerá správne, robí problém ťažšie odhaliteľným.

Odkiaľ pochádza stabilná identita

Rozhranie na správu prideľuje každému klientovi identifikátor klientskej inštancie a tento identifikátor je obmedzený na inštanciu démona, ktorá ho vydala. Použiteľný externý kľúč kombinuje stabilný identifikátor servera, epochu, ktorá sa mení pri štarte démona, a toto klientske ID. Epocha je dôležitá, pretože identifikátory sa reštartujú spolu s procesom a holé ID procesu môže neskôr znovu použiť niečo nesúvisiace.

Premenné prostredia nastavené vnútri podriadeného skriptu pripojenia sa neprenášajú do neskoršieho skriptu odpojenia nadradeného démona, pretože tieto skripty bežia ako samostatné procesy s vlastnými prostrediami. Preto je generovanie UUID v čase pripojenia polovica riešenia. Strana odpojenia musí dokázať pomenovať rovnaké UUID, čo znamená, že identita musí žiť niekde, kam dosiahnu obe udalosti.

Ukončovanie urobte podmienené a idempotentné

Ukončujte podľa vlastníka relácie, nie podľa používateľa. Obsluha, ktorá zmaže akékoľvek pridelenie, ktoré práve patrí nejakému názvu, nakoniec zmaže nesprávne, a jedinou obranou je skontrolovať, že odstraňovaný záznam je záznam, ktorý táto udalosť opisuje.

Rozhranie na správu prijíma vždy jedného pripojeného klienta správy, preto sa integrujte s tým, kto ho už vlastní, namiesto pripájania druhého pozorovateľa, ktorý súťaží o ten istý socket.

Opakované udalosti spracúvajte bez dvojnásobnej zmeny výsledku a nespárované udalosti uchovávajte na zmierenie, namiesto toho, aby ste ich zahadzovali. Spätné volanie odpojenia má dokumentované podmienky životného cyklu a po páde alebo tvrdom zastavení nemusí nikdy prísť, takže návrh potrebuje spôsob, ako znázorniť reláciu, ktorej udalosť konca chýba.

Otestujte nepríjemné prípady zámerne: dve opätovné pripojenia v priebehu jednej sekundy, dve inštancie démona, pripojenie, ktorého spracovanie zlyhalo, a reštart démona uprostred relácie. Kľúč, ktorý prežije všetky štyri, si zaslúži dôveru.