OpenVPN-kliens újracsatlakoztatása: három vezérlő, három hatókör

Valaki azt kéri, hogy csatlakozzon újra a VPN-kliens, és ez a kérés három különböző dolgot jelenthet. Jelentheti egy hitelesített munkamenet eldobását, minden kliens értesítését arról, hogy egy UDP-kiszolgáló távozik, vagy magának a démonnak az újraindítását. Mindegyiknek más a hatósugara, és a rossz választás egy felhasználói javítást teljes kieséssé alakít. A hatókör a döntés, és a parancs abból következik.

Kérdezze meg, kit érintsen, mielőtt azt kérdezné, melyik vezérlőt használja.

Egy példány: a felügyeleti felület

Egy beállított felügyeleti felület képes felsorolni a csatlakozott példányokat, és pontosan egyet eldobni közülük. Minden munkamenet ügyfél-azonosítót hordoz, és client-kill CID erre az azonosítóra céloz, nem egy közös névre. Az élő azonosítót az aktuális állapotkimenetből olvassa, mert egy régebbi naplóból másolt érték olyan munkamenetre utal, amely már nem létezik. A példány eldobása azt a kapcsolatot fejezi be, és semmi mást.

Nem garantál új kapcsolatot. Hogy a kliens visszatér-e, az újrapróbálkozási beállításaitól, a fennmaradó távoli bejegyzéseitől, a hitelesítési követelményeitől és attól függ, hogy a felügyelő alkalmazás még fut-e. A visszatérő kliens új azonosítót kap, ezért az azonosítók összehasonlítása az egyetlen megbízható módja annak, hogy megkülönböztessük a régit az újtól.

Az UDP kilépési értesítés nem kliensenkénti parancs

explicit-exit-notify egy kilépési és újraindítási eseményekről szóló konfigurációs direktíva. UDP-kliensen jelzi a partnernek, hogy a munkamenet véget ér, és a numerikus argumentum szabályozza, hányszor ismétlődik az értesítés. Amikor a kiszolgáló UDP fölött fut, újraindítási vezérlőüzenetet küld a csatlakozott klienseinek, és a dokumentált értékek megkülönböztetik az ugyanahhoz a kiszolgálóhoz való újracsatlakozást a másik távoli bejegyzésre váltástól. Ez széles közönségű életciklus-jelzés.

Semmi benne nem választ ki tetszőleges klienst tetszőleges pillanatban. Ha újracsatlakozás-gombként kezeljük, egyszerre minden csatlakozott munkamenetet elér.

A szignálok a folyamatra hatnak, nem a munkamenetre

SIGUSR1 arra kéri a futó folyamatot, hogy indítsa újra a kapcsolatát a konfiguráció újraolvasása nélkül, és a tartóssági beállítások döntik el, mi éli túl azt az újraindítást. SIGHUP tovább megy: újraolvassa a konfigurációs fájlt, és újranyitja az erőforrásait. SIGTERM és SIGINT rendezett leállítást kér. Ezek folyamatszintű műveletek: többklienses kiszolgálón minden munkamenetre hatnak, amelyet a folyamat hordoz, nem csak a jegyben megnevezettre.

Amikor a folyamat szolgáltatáskezelő alatt fut, használja a kezelő saját vezérlését, ahelyett hogy szignált küldene egy folyamatlistában talált PID-nek. Olvassa el az unitot, hogy lássa, melyik szignált küldi a kezelő, mert az újraindítás és az újratöltés különböző dolgokat tesz ugyanazzal a démonnal.

A vezérlő kiválasztása előtt döntse el a hatókört

Három kérdés dönti el. Kit érintsen: egy felhasználót, egy kiszolgáló minden kliensét vagy a démont és mindent, amit hordoz. Mi maradjon meg: a konfiguráció, az alagút állapota, vagy egyik sem. Ki jogosult rá: a felügyeleti integráció, a szolgáltatás tulajdonosa vagy a hálózati üzemeltető, aki a kilépési értesítést vezérli. Válaszoljon ezekre, és csak egy vezérlő illik.

Egy hitelesítés nélküli felügyeleti figyelő hozzáadása egy újracsatlakozás-gombért sokkal többet ad annak, aki eléri a portot, mint az a gomb.

Az új munkamenetet ellenőrizze, nem a bontást

A bontási esemény bizonyítja, hogy a régi munkamenet véget ért. Semmit nem mond arról, hogy egy új hitelesít, címet kap, útvonalakat telepít vagy eléri azt az erőforrást, amelyre a felhasználónak szüksége volt. Ellenőrizze az új azonosítót, majd az alagút állapotát, majd egy valódi erőforrást. Ez a három lépés a különbség az újracsatlakozás és egy működő kapcsolat között.

Írja be a hatókört a változási rekordba. Az „újracsatlakoztattam a klienst” nem leírás, amikor a kliens negyvenből egy volt egy megosztott kiszolgálón.