A vpn.persistent próbálkozik tovább, de nem tart kapcsolatban

A NetworkManager egyetlen tulajdonságot tesz elérhetővé, vpn.persistent, és az emberek egyszerre négy különböző kérdés megválaszolását kérik tőle. A felsőbb szintű dokumentáció óvatos: a tartósság akkor érvényes, ha a VPN szolgáltatás támogatja és a profil engedélyezi, és ilyenkor a kapcsolattól azt kérik, hogy élje túl a hivatkozás változásait és kieséseit egy kifejezett bontásig. Ugyanez a dokumentáció azt is mutatja, hogy a tulajdonság alapértéke false, amit a legtöbb helyreállítási terv nem feltételez. Kísérletre vonatkozó kérésként olvassa, nem az eredmény ígéretként.

Mihez kötelez valójában a beállítás

A profilban tárolt érték utasítás a kezelőnek, és a kezelőnek ezt az utasítást át kell adnia egy VPN bővítménynek, amely tudja, mit kell vele tenni. Ha a telepített bővítmény figyelmen kívül hagyja a tulajdonságot, a profil akkor is aktiválódik, és a napló csendben marad, ami a két világ legrosszabbja mindenkinek, aki később hibakeresést végez. A profilon belül semmi sem kényszeríthet egy bővítményt olyan viselkedés megvalósítására, amellyel nem rendelkezik, így az egyetlen látható eredmény a hiány.

Ezért fontosabb a dokumentációban szereplő feltétel, mint a kapcsoló. Ellenőrizze, melyik bővítmény és kiadás van valóban a birtokában, és írja a verziót a kapcsolat leírása mellé, hogy a következő embernek ne kelljen újra felfedeznie. A nem megvalósított jelzőre épített helyreállítási szabályzat éppen egyszer bukik el éles környezetben, és mindig a legkellemetlenebb pillanatban.

A tulajdonság kísérletként kezelése a teszteléshez is a helyes elvárást állítja be. Nem azt ellenőrzi, hogy a jelző be van-e állítva; azt ellenőrzi, hogy történt-e valami, amikor a hivatkozás megszakadt. Ezek különböző kísérletek, és csak az egyikük ér meg egy délutánt.

Négy kérdés egybeolvasztva

Az aktiválás azt kérdezi, mi hozza fel egyáltalán a VPN-t. Egy NetworkManager profil egy alapkapcsolathoz köthető, egy külön kezelt OpenVPN szolgáltatás a saját indításával rendelkezik, és egy harmadik indító hozzáadása ehhez az elrendezéshez két tulajdonost ad, akiknek eltérő elképzelésük van arról, ki az úr. Döntse el, melyik összetevő birtokolja az indítást, mielőtt újabb kiváltót ad hozzá.

A helyreállítás azt kérdezi, mi történik, amikor a hivatkozás megváltozik vagy eltűnik, és ez az a szűk kérdés, amelyet a vpn.persistent kezel. Az életképesség azt kérdezi, felismeri-e a kliens, hogy a távoli fél abbahagyta a válaszadást, és erre helyette az OpenVPN keepalive vagy újraindítási viselkedése válaszol; a két mechanizmust gyakran ugyanazzal a szóval írják le, és különböző helyeken valósítják meg. Külön tesztelje őket, különböző eszközökkel, különben az egyik viselkedést a másiknak tulajdonítja.

A szándék azt kérdezi, egyáltalán kívánatos-e az újracsatlakozás, és erre a kérdésre az állapotfelmérés nem tud válaszolni. Egy szándékos leállítás és egy kiesés ugyanazt az inaktív állapotot hozza létre, ezért minden, ami hiány alapján újracsatlakozik, emberi döntésre tippel. A tippelés addig rendben van, amíg át nem gázol valakin.

Egy ellenőrzőlista, amely külön tartja őket

Az eseményeket sorrendben hajtsa végre, ahelyett hogy elolvasná a konfigurációt és érvelne róla, és rögzítse időbélyeggel, hogy melyik mit mutat.

Először aktiválja a szándékolt alapkapcsolatot, és erősítse meg, hogy a VPN a várt kiváltón keresztül jött fel, és nem egy olyan mechanizmuson át, amelyről elfelejtette, hogy telepítve van. Másodszor, egy jóváhagyott megszakítás alatt hasonlítsa össze a kezelő VPN eseményeit, a tulajdonos kliens helyreállítási állapotát és egy privát erőforráshoz intézett friss kérést. Harmadszor, szándékosan bontsa a kapcsolatot, várjon, és erősítse meg, hogy semmi nem indítja újra a profilt a háta mögött.

A harmadik lépés az, amelyet az emberek kihagynak, és ez találja meg legtöbbször a valódi hibát. Egy őrkutya, amely az aktív profil után kutat, és hiányában újracsatlakozik, vidáman visszavonja a felhasználó szándékos bontását. A felhasználó szemszögéből ez nem rugalmasság; ez egy gép, amely nem engedelmeskedik. Kérdezze meg őket, mielőtt ilyet adna hozzá.

Írja az eredményeket ugyanabba a dokumentumba, amelyben a kapcsolat leírása van. Egy helyreállítási szabályzat csak annyit ér, mint amikor utoljára látta valaki szándékosan meghibásodni. Az időbélyegek láthatóvá teszik a különbséget mindenkinek, aki legközelebb elolvassa a jegyzeteket.

A hitelesítés a helyreállítás része

Az újracsatlakozás nem tisztán hálózati cselekedet. Ha a jóváhagyott folyamat új kihívást, egyszer használatos kódot vagy olyan titkot igényel, amelyet az aktiválási környezet nem ér el, egyetlen tartóssági beállítás sem tudja a semmiből előállítani.

Ez magyaráz egy ismerős mintát: a kapcsolat helyreáll egy nyitott kulcstartójú gépen, és ugyanazon a gépen újraindítás után meghiúsul. A hálózati réteg pontosan azt tette, amire kérték, a hitelesítő adatok rétegének pedig nem volt mit kínálnia.

Javítsa a hitelesítő adatok munkafolyamatát ahelyett, hogy lerövidítené az újrapróbálkozási időközt. A gyorsabb újrapróbálkozások egy olyan kérés ellen, amelyre senki nem tud válaszolni, naplózajt és hamis benyomást keltenek arról, hogy valami történik.

A tartósság nem kill switch

A tulajdonság megpróbálja fenntartani vagy helyreállítani a VPN kapcsolatot. Nem dönti el, mit tehetnek az alkalmazások, amíg a VPN le van állva, és önmagában semmit sem blokkol.

Ha a követelmény az, hogy semmilyen forgalom ne hagyja el az alagutat, az egy külön szabályzat saját mechanizmussal, saját tesztekkel és saját hibamódokkal. Ha azt feltételezzük, hogy a tartósság ezt lefedi, egy biztonsági döntést balesetté alakítunk.

Rögzítse mindkét felét a helyreállítási jegyzetekben: mit kísérelt meg a VPN, és milyen alkalmazásforgalom volt engedélyezett a kísérlet idején.