Az első munkamenet nyer: OpenVPN-bejelentkezések korlátozása a kiszorítás előtt
Egy későbbi bejelentkezés elutasítása nem ugyanaz, mint a régi lecserélése. A döntésnek az azonos nevű kiszorítás előtt kell megszületnie, és a hely-ellenőrzésnek atomikusnak kell lennie.
Az egy munkamenetet fiókonként engedélyező szabály rendezettnek tűnik, amíg meg nem érkezik a második bejelentkezés. Két kimenet lehetséges: az új érkező lecseréli a futó munkamenetet, vagy a futó munkamenet megtartja a helyet, és az új érkezőt elutasítják. Csak a második az első munkamenet nyer szabálya. Az az ügyfél-beállítás, amelyhez a legtöbben nyúlnak, engedélyezi az egyidejűséget, és ezért nem azt eredményezi.
Két szerződés rejtőzik egy beállítás mögött
Kikapcsolt egyidejűség mellett egy második kapcsolat, amely ugyanazt a tanúsítványnevet mutatja, kiszoríthatja a már futó munkamenetet. Az egyidejűség bekapcsolása több munkamenetet engedélyez egyszerre, ami a korlát ellentéte. Egyik állapot sem elutasítási szabály, ezért a döntést egészen máshol kell meghozni.
Írja le a szerződést, mielőtt bármit megvalósít: kit utasítanak el, milyen bizonyíték azonosítja a futó munkamenetet, és mi történik, ha egy munkamenet tiszta bontás nélkül hal meg. Egy szabályt, amelyet senki nem így fogalmazott meg, később nem lehet tesztelni.
A kiszorítás a csatlakozási kampó előtt történik
A 2.6-os kiszolgáló kódútvonalán az új ügyfél korai előkészítése eltávolítja a meglévő, azonos nevű példányokat, ha az egyidejűség ki van kapcsolva. Ez az eltávolítás a csatlakozáskezelő lánc futása előtt történik. Ezért egy szkript, amely észleli a duplikátumot és hibát ad vissza, azután utasítja el az új érkezőt, hogy a futó munkamenetet már eldobták - pontosan az az eredmény, amelyet a szabálynak meg kellett volna akadályoznia. Az upstream megvalósítás visszahívási sorrendje az egyetlen megbízható válasz az Ön buildje számára.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Az állapotfájl lekérdezése sem kapu. Két egyszerre érkező kísérlet mindkettő láthat üres helyet, mielőtt bármelyik lefoglalná, és mindkettő továbbmegy.
Helyezze a döntést a hitelesítésbe
A felügyeleti felület a tanúsítvány ellenőrzése után átveheti a hitelesítési döntést. Ebben az elrendezésben a vezérlő nem megfigyelő: fogad minden csatlakozó ügyfélpéldányt, és válaszol, hogy az a példány továbbmehet-e. Mivel a válasz a létrehozás előtt érkezik, az elutasítás érintetlenül hagyja a futó munkamenetet. Ugyanez a csatorna jelenti a bontásokat, és így a vezérlő megtudja, hogy egy hely jogszerűen felszabadult.
Minden új példánynak át kell haladnia ezen a kapun, beleértve az újracsatlakozásokat és minden olyan útvonalat, amely kérés nélkül újrahitelesít. Egy kapu, amelyet egyes példányok soha nem érnek el, semmit nem véd, és a kihagyás láthatatlan marad, amíg valaki ki nem próbálja a megkerülést.
A tokenek elsétálhatnak a kapu mellett
Miután egy token kiadásra került, a kiszolgáló belsőleg érvényesítheti, és átugorhatja a külső hitelesítést arra a kapcsolatra. A felügyeleti hívás soha nem történik meg, ezért a csak ott megvalósított helyellenőrzés soha nem látja az új példányt. Ez a viselkedés kényelem a felhasználóknak és lyuk az egyidejűségi szabályban. Kényszerítse a tokennel hitelesített kapcsolatokat egyenértékű, mérvadó ellenőrzésre, vagy kapcsolja ki a token útvonalát, ha a szabály minden kapcsolatnál döntést követel.
Ne kompenzálja azzal, hogy minden tokent feltétel nélkül elfogad. Egy lejárt vagy érvénytelen tokennek továbbra is meg kell buknia, és ugyanazon a döntési ponton kell megbuknia, mint minden másnak.
A foglalást példányhoz kösse, ne címhez
A cím gyenge identitás: az ugyanarról a laptopról induló újracsatlakozás más címről érkezhet, és egy másolt hitelesítő adat ugyanarról a címről érkezhet. A foglalást ahhoz az ügyfélpéldányhoz kösse, amelyet a kiszolgáló kioszt, hogy a már beengedett példány újrahitelesítése tulajdonosként legyen felismerhető. Egy új példányazonosítónak saját helyet kell szereznie az első nyer döntéssel akkor is, ha ugyanazt a tokent mutatja be.
Csak a sikertelen kísérlethez tartozó foglalást szabadítsa fel. Egy korábbi kísérlet késleltetett bontási eseménye nem törölheti egy újabb tulajdonos helyét, ezért a felszabadítás a példányt nevezi meg a fiók helyett. A vezérlő újraindítása után egyeztesse az élő munkameneteket, mielőtt bárkit beenged, és ugyanezt a szabályt alkalmazza minden átjárón, amely a fiókot kiszolgálja.
Külön döntse el, hogyan állítják helyre a valóban elavult helyet. A rendszergazdának dokumentált módra van szüksége a törléshez, és ez az útvonal nem lehet elérhető olyan felhasználó számára, aki csak az újracsatlakozásra kattint.
Tesztelje a fontos párokat: két csaknem egyidejű bejelentkezés, újracsatlakozás tiszta bontás után, a futó munkamenet újrahitelesítése, egy elutasított új érkező és a vezérlő újraindítása. Minden esetben a futó munkamenetnek használhatónak kell maradnia, és az új érkezőt más fiókok kárára történő következmények nélkül kell elutasítani.