OpenVPN client-connect-hiba: garantált-e a takarítás disconnectkor?
Egy elutasított kliens nem vonja vissza a tűzfal-szabályt vagy a kiírt rekordot. Hasonlítsa össze a callback-szerződést azzal a visszaállítással, amelyet a hooknak magának kell elvégeznie.
Amikor egy client-connect-szkript nem nulla kóddal lép ki, az OpenVPN elutasítja a klienst, és az üzemeltetők általában azt feltételezik, hogy a megfelelő client-disconnect-szkript rendet tesz. Gyakran soha nem fut le, mert a disconnect feldolgozása attól függ, mit tudott a connect szakasz befejezni. Az elutasítás és a visszaállítás egyetlen mechanizmusként kezelése az, ami egy sikertelen bejelentkezést szivárgó tűzfal-szabállyá vagy gazdátlan rekorddá tesz. Két külön kötelezettség, és csak az egyik automatikus. Olvassa el a hook saját kilépési útvonalát, mielőtt a szervert hibáztatná az otthagyott állapotért.
A nem nulla kilépés elutasítja a klienst; nem vonja vissza a munkáját
A client-connect kilépési állapota belépési döntés. A nulla azt jelenti: beengedés, bármi más azt jelenti: az példány lebontása, mielőtt teljesen létrejönne. Semmi ebben a szerződésben nem vizsgálja, mit tett már a szkript a külvilággal. Ha a szkript iptables-szabályt adott hozzá, sort írt vagy számlálót növelt, ezek a változások túlélik az elutasítást.
Ugyanez az aszimmetria érvényes a bővítményekre, ahol egy példányhoz több connect-függvény is lefuthat. Egy későbbi hiba nem vonja vissza utólag a korábbi sikert, és a korábbi függvénynek nincs módja megtudni, hogy egy testvérfüggvény elbukott.
Az elutasítás automatikus, a takarítás nem
Az OpenVPN 2.6 kézikönyve a client-disconnect feldolgozását a korábbi connect-feldolgozás sikeréhez köti. Egy dokumentált kivétel a kaszkádolt láncokra vonatkozik: ha egy connect-lépés már sikert adott vissza, a megfelelő disconnect-lépések a példány lebontásakor mégis lefutnak, akkor is, ha egy későbbi connect-lépés elbukott. Ez a kivétel szűk, és attól függ, hány callback van beállítva, ezért egyetlen shell-szkript tesztelése semmit nem mond a láncról.
Térképezze fel a tényleges konfigurációt, mielőtt köré tervezne: melyik szkript, melyik bővítmény és milyen sorrendben fut. Az alábbi táblázat felsorolja, mit hagy maga után egy félkész beállítás.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Minden sor ugyanúgy végződik a kliens és másképp a gazdagép számára. A kliens nem tudja megmondani, melyik történt meg, ezért a hooknak vissza kell bontania, amit tett, mielőtt visszaadja a hibaállapotot.
Kompenzáljon az elbukott szkripten belül
Ellenőrizzen mindent, amit lehet, mielőtt megérinti a megosztott állapotot: tanúsítvány mezői, a cím elérhetősége, a csoport, amelyhez a kliens tartozik. A legolcsóbb elutasítás az, amely még bármilyen kiosztás előtt megtörténik. Ha a beállítás több külső műveletre terjed ki, vezessen nyilvántartást arról, melyek fejeződtek be, és a hibaállapot visszaadása előtt bontsa vissza őket fordított sorrendben.
Konkrét eset: a szkript létrehoz egy kliensenkénti tűzfalbejegyzést, majd nem sikerül megírnia az őt leíró állapotsort. A hibázó ágnak el kell távolítania az épp létrehozott bejegyzést, majd nem nulla kóddal kilépnie. Olyan disconnect-eseményre várni, amely talán soha nem lesz ütemezve, az az út, ahogyan egy szabály túléli a szolgálati időt, amelyre szánták.
Tegye a kompenzációt idempotenssé és tulajdonossá
A takarításnak biztonságosnak kell lennie kétszeri futásra, és pontosan kell tudnia, mit törölhet. Egy korábbi kísérlet késői eseménye nem távolíthatja el egy újabb munkamenet kiosztását csak azért, mert mindkettő közös nevet vagy újrahasznosított alagútcímet használ. Rögzítse a konkrét kezelőt vagy művelet-azonosítót az erőforrással együtt, és az alapján a kulcs alapján töröljön, ne név szerint. Az adatbázis-tranzakciók csak az adatbázis saját változásainál segítenek; a határon kívüli tűzfalszabály kifejezett kompenzációs lépést igényel.
Tegyük fel, hogy a folyamat meghalhat a változtatás és a takarítás között, és adjon hozzá egy egyeztetőt, amely ütemezés szerint összehasonlítja a külső állapotot a beengedett kliensek listájával.
Tesztelje a három valóban eltérő útvonalat
Gyakoroljon három esetet: elutasítás, mielőtt bármit kiosztanának, egyet részleges kiosztás után, és egy normál beengedett munkamenetet, amely később véget ér. Ez a három különböző naplósorokat és különböző maradványokat ad. Mindegyik után ellenőrizze a külső állapotot, ne csak a kliens hibaüzenetét, mert a kliens hibája a három közül kettőben a várt eredmény.
Naplózza a hook fázisát, a kilépési állapotot és azt, mi lett kiosztva vagy felszabadítva, a hitelesítő adatok nélkül. Az a hook-napló, amely megnevezi a létrehozott erőforrást, teszi hat hónappal később megtalálhatóvá egy szivárgó szabályt.