OpenVPN hook-események: miért nem kulcs a név és az időbélyeg

Egy leválasztási rekord akkor érkezik, amikor már elindult egy második kapcsolat ugyanazon név alatt, és a legújabb sor frissítő kezelője a rossz munkamenetet zárja le. A hiba nem az időbélyegek összehasonlítása. Hanem az a feltevés, hogy egy név plusz egy egész másodperc egyetlen munkamenetet azonosít. A hook-események kapcsolatokat írnak le, és egy kapcsolatnak olyan kulcsra van szüksége, amely csak hozzá tartozik.

Kezdje azzal, hogy a leválasztási változók valójában mit jelentenek. Csak ezután van értelme az azonosító megválasztásának.

Mit hordoz valójában a leválasztási hook

A Community OpenVPN 2.6-ban a hook-referencia time_unix azt az időpontot határozza meg, amikor az ügyfél csatlakozott; ez a csatlakozási hook futása előtt áll be, és nem definiálódik újra, amikor a leválasztási hook később kiváltódik. time_duration a munkamenet hosszát adja meg másodpercben, tehát a vége nagyjából a csatlakozási idő plusz az időtartam. Mindkettő egész másodperc, és egyik sem az a pillanat, amikor az adatbázisa feldolgozta az eseményt. E három idő szétválasztása az, amitől a korreláció megáll, ahelyett hogy csak a tesztelés alatt tűnne helyesnek.

Ez a számítás megérdemli, hogy le legyen írva, mert ez az egyetlen befejezési idő, amelyet maga a hook kínál. A feldolgozási késleltetés és a gazdagépek közötti óraeltérés továbbra is kívül esik rajta.

Miért nem egyedi a kézenfekvő pár

A név és a csatlakozási idő párosítása szűkíti a keresést, és még mindig nem azonosít munkamenetet. Az ügyfél ugyanazon másodpercen belül újra csatlakozhat, így két munkamenet megoszthatja mindkét értéket. Két démonpéldány, vagy egy kiszolgálócsere, amely ugyanazt a konfigurációt tartja meg, különböző folyamatokból állíthatja elő ezt a párt. Az alagútcímek ugyanezen okból újrahasznosulnak, ami egy munkamenet attribútumaivá teszi őket, nem pedig azonosítóivá.

A hiba módja csendes. Az első munkamenet késői leválasztása a legújabb sorhoz illeszkedik, és visszavon egy olyan kiosztást, amelyet a második munkamenet még használ, így a felhasználó véletlenszerű hozzáférés-vesztést tapasztal, amelyet nem ő okozott. Az utána helyesnek tűnő sorszám nehezebbé teszi a probléma észrevételét.

Honnan jön a stabil identitás

A felügyeleti felület minden ügyfélnek ügyfélpéldány-azonosítót ad, és ez az azonosító ahhoz a démonpéldányhoz kötött, amely kiadta. Egy használható külső kulcs stabil kiszolgáló-azonosítót, a démon indításakor változó korszakot és ezt az ügyfél-ID-t kombinálja. A korszak azért számít, mert az azonosítók a folyamattal együtt újraindulnak, és egy csupasz folyamat-ID-t később valami kapcsolódó dolog újra felhasználhat.

A gyermek csatlakozási szkript belsejében beállított környezeti változók nem jutnak el a szülő démon későbbi leválasztási szkriptjéhez, mert ezek a szkriptek külön folyamatként, saját környezetükkel futnak. Ezért az UUID létrehozása csatlakozáskor csak fél megoldás. A leválasztási oldalnak ugyanezt az UUID-t kell tudnia megnevezni, ami azt jelenti, hogy az identitásnak olyan helyen kell élnie, ahová mindkét esemény eljut.

Tegye feltételessé és idempotenssé a visszavonást

Munkamenet-tulajdonos szerint vonjon vissza, ne felhasználó szerint. Az a kezelő, amely töröl bármilyen, egy névhez tartozó kiosztást, végül a rosszat fogja törölni, és az egyetlen védelem annak ellenőrzése, hogy az eltávolított rekord az a rekord, amelyet ez az esemény leír.

A felügyeleti felület egyszerre egy csatlakozott felügyeleti ügyfelet fogad, ezért integráljon azzal, aki már birtokolja, ahelyett hogy egy második megfigyelőt csatolna, amely ugyanazért a socketért versenyez.

Kezelje az ismétlődő eseményeket anélkül, hogy kétszer változtatná meg az eredményt, és őrizze meg a nem párosított eseményeket egyeztetésre ahelyett hogy eldobná őket. A leválasztási visszahívásnak dokumentált életciklus-feltételei vannak, és összeomlás vagy kemény leállás után esetleg soha nem érkezik meg, ezért a tervezésnek módot kell adnia egy olyan munkamenet ábrázolására, amelynek záró eseménye hiányzik.

Tesztelje szándékosan a kellemetlen eseteket: két újracsatlakozás egy másodpercen belül, két démonpéldány, egy kapcsolat, amelynek feldolgozása meghiúsult, és egy démon újraindítása egy munkamenet közepén. Az a kulcs, amely mind a négyet túléli, megbízhatónak mondható.