Meddig próbálkozzon az OpenConnect egy megszakadt VPN-nel?

--reconnect-timeout egyetlen szűk kérdésre válaszol: miután az alagút leesik, meddig próbálkozik még ez a kliensfolyamat, mielőtt feladja és kilép. Az OpenConnect kézikönyv oldala ezt a beállítást 300 másodperces dokumentált alapértékkel rögzíti az elveszett kapcsolatot vagy a válaszadást abbahagyó partnert követő újrapróbálkozásokhoz, és a szám egy futó kliens határideje, nem pedig bizonyíték arra, hogy a VPN elérhető marad. Az sem egy szabály, amely életben tartja a folyamatot, és a zavar nagy része itt kezdődik.

A zavar fokozódik, amikor egy második mechanizmus ül a tetején. A klienst újraindító felügyelő, az átjárót pingelő vizsgáló és a beépített újrapróbálkozási ablak mind reagálhat egyetlen hibára, és az esemény ekkor három idővonalat ad, amelyeket senki sem tud összeegyeztetni.

Mit korlátoz valójában az újracsatlakozási ablak

Képzelje el, hogy a hozzáférési hálózat eltűnik néhány másodpercre. A kliens látja a kapcsolat leesését, vagy abbahagyja a halott partner válaszainak hallását, és elkezdi újra felépíteni a munkamenetet, amennyi állapotot tud, megtartva. A próbálkozások addig folytatódnak, amíg az átjáró újra el nem fogadja, vagy amíg az ablak le nem jár, és a lejárt ablak nem nulla kóddal való kilépéssel végződik. Ez a kilépés, nem az időkorlát értéke az a pont, ahol az életciklus tulajdonjoga átkerül ahhoz, aki a folyamatot felügyeli.

Az ablak semmit sem mond arról, milyen gyakran fut egy vizsgálat, és nem tudja meghosszabbítani a hitelesítést. Ha az átjáró visszavonta a munkamenetet, vagy a fiók most új második tényezőt kér, a további várakozás nem teszi újra érvényessé a régi munkamenetet. Az újrapróbálkozás csak akkor sikerül, ha az útvonal visszatér, az átjáró még felismeri a munkamenetet, és a kért hitelesítő adatok használhatók maradnak, ezért olvassa a számot határidőnek, nem élettartam-intervallumnak.

Az ablak azt sem szabályozza, mit tesznek az alkalmazások, miközben fut. A platformtól és attól függően, milyen messzire jutott a hiba, a kliens úgy is újracsatlakozhat, hogy az útvonalak még telepítve vannak, vagy miután eltávolították őket. Ezért szokott a kimaradás közepén kiadott kérés inkább az időkorlátig lógni, mintsem gyorsan meghiúsulni.

A felügyelő újraindításai és a kliens újrapróbálkozásai két réteg

Hagyja, hogy a futó kliens a saját ablakát elhasználja, a szolgáltatáskezelő pedig reagáljon a kilépésre. Az előtérben futó kliens systemd alatt, újraindítási szabályzattal pontosan ezt a felosztást adja: próbálkozások korlátozott ideig, majd egyetlen újraindítási döntés. Az eredmény egyetlen idővonal, amelyet utólag még rekonstruálhat.

A háttérben futó kliens plusz egy független vizsgáló, amely új példányt indít, ha nem lát interfészt, az a minta, amely rosszul végződik. Ekkor mindkét folyamat ugyanazért az eszközcsomópontért, útvonalakért és feloldóbeállításokért verseng. Ha valóban daemont akar, tegye a beállítást arra a parancssorra, amellyel a kliens valóban indul:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Két részletnek van súlya ebben a sorban. A --background leválasztja a folyamatot, így a pid-fájl lesz az egyetlen megbízható fogantyú rajta, és az időkorlát csak addig fogy, amíg ugyanaz a folyamat él; a felügyelő, amely megöli, nem hagy költségkeretet a folytatásra.

A szándékos leválasztásoknak saját jelzés kell. A tervezett szünet és a valódi kimaradás egyformán néz ki egy naiv megfigyelőnek, mindkettő „nincs kapcsolat” jelentéssel olvasható. A szünetet a felügyelő leállítási műveletén vagy a burkoló által értett jelölőn keresztül vezérelje, hogy a szándékos leállítás ne indítson újraindítást, amelyet senki sem kért.

Hogyan ne előzze meg az átadás az újrapróbálkozási ciklust

A felügyelet nélküli helyreállítás olyan hitelesítő adatoktól függ, amelyek jelenlévő személy nélkül újulnak meg. Egy csak interaktív asztali munkamenetben nyíló kulcstartó, vagy egy mindig beírt kódot igénylő token ott hagyja a klienst a hitelesítési szakaszban, amint az útvonal visszatér. Rendezze ezt a munkafolyamatot az ablak meghosszabbítása előtt, mert a hosszabb ablak csak ugyanannak a blokkolt kérésnek ad több időt a meghiúsulásra.

A kiszolgáló ellenőrzését nem szabad lazítani a kérések csökkentése érdekében. Éppen az átjárót hitelesítő rögzítés vagy bizalmi horgony teszi biztonságossá az automatikus újracsatlakozást, és ennek kikapcsolása a tanúsítványkérdés elkerülésére egy látható megszakítást cserél láthatatlanra. Tartsa meg az ellenőrzött identitást, és inkább javítsa ki a kérést; az a kliens, amely hajlandó bármely átjáróhoz csatlakozni, rosszabb, mint amelyik megáll és vár.

Az interfész jelenléte sem egészségjel. Egy alagúteszköz létezhet halott munkamenettel a háta mögött, és egy indítófolyamat létezhet alagút nélkül. Egyik megfigyelés sem állja ki egy valódi kérés próbáját. Az egészségnek abból kell jönnie, amire a felhasználónak szüksége van, például egy kérésből, amely az alagúton át egy ismert belső szolgáltatásba megy.

Mit kell ellenőrizni a kimaradás alatt és után

Négy eseményt futtasson külön tesztként: az ablaknál rövidebb megszakítást, annál hosszabb kimaradást, hitelesítési hibát és szándékos leállítást. Mindegyiknek más, kiszámítható állapotban kell végződnie, és az első kettő közötti határ az egész oka annak, hogy értéket választunk.

Tartsa az ellenőrzéseket kifelé fordulva, mert a folyamattábla önmagában nagyon keveset bizonyít. Figyelje, hogy a pid stabilan tart-e a rövid megszakítás alatt, majd erősítse meg, hogy a hosszú után eltűnt és egyszer helyettesítették:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

A rövid megszakítás alatt erősítse meg, hogy a kliens valóban újra próbálkozott, nem lépett ki korán, és hogy az útvonalak és a feloldó bejegyzései duplikátumok nélkül tértek vissza. A hosszabb kimaradáshoz erősítse meg a tiszta kilépést és a pontosan egy utána következő újraindítást. A hitelesítési hibához erősítse meg, hogy a kliens nem pörög olyan átjáróval szemben, amely továbbra is elutasítja. Adjon hozzá ellenőrzést, hogy a pid egyetlen értékre tér vissza, nem halmozódik.

A szándékos leállításhoz az egészség URL-jének elérhetetlennek kell maradnia, és a folyamatnak lent kell maradnia. Ezután zárja le a hurkot az alkalmazás oldaláról: ugyanannak a kérésnek meg kell hiúsulnia, amíg az alagút nincs ott, és sikerülnie kell, miután visszatér, arról a forrásoldalról, amelyet a szabályzata elvár. A zöld alagútikon nem bizonyíték, de egy teljesített kérés az.