Opětovné připojení klienta OpenVPN: tři ovládací prvky a tři rozsahy

Někdo žádá, aby se klient VPN znovu připojil, a tato žádost může znamenat tři různé věci. Může znamenat odpojení jedné ověřené relace, uvědomění všech klientů, že server UDP končí, nebo restart samotného procesu. Každá má jiný dosah a špatná volba promění opravu pro jednoho uživatele ve výpadek. Rozsah je rozhodnutí a příkaz z něj vyplývá.

Než se zeptáte, který ovládací prvek použít, zeptejte se, koho se to má dotknout.

Jedna instance: rozhraní pro správu

Nakonfigurované rozhraní pro správu umí vypsat připojené instance a odpojit přesně jednu z nich. Každá relace nese identifikátor klienta a client-kill CID cílí na tento identifikátor, nikoli na společné jméno. Čtěte živý identifikátor z aktuálního výstupu stavu, protože hodnota zkopírovaná ze staršího logu odkazuje na relaci, která už neexistuje. Odpojení instance ukončí toto spojení a nic jiného.

Nezaručuje nové připojení. Zda se klient vrátí, závisí na jeho nastavení opakování, zbývajících vzdálených položkách, požadavcích na ověření a na tom, zda dohledová aplikace stále běží. Vracející se klient dostane nový identifikátor, a proto je porovnávání identifikátorů jediný spolehlivý způsob, jak rozeznat staré od nového.

Oznámení o ukončení UDP není příkaz pro jednotlivého klienta

explicit-exit-notify je konfigurační direktiva o událostech ukončení a restartu. Na klientu UDP říká protistraně, že relace končí, a číselný argument řídí, kolikrát se oznámení opakuje. Když server běží přes UDP, posílá připojeným klientům řídicí zprávu o restartu a dokumentované hodnoty rozlišují opětovné připojení ke stejnému serveru od přechodu na jinou vzdálenou položku. To je signál životního cyklu se širokým publikem.

Nic v něm nevybírá libovolného klienta v libovolném okamžiku. Považovat ho za tlačítko opětovného připojení zasáhne všechny připojené relace najednou.

Signály působí na proces, ne na relaci

SIGUSR1 žádá běžící proces, aby restartoval své spojení bez opětovného načtení konfigurace, a volby trvalosti rozhodují, co tento restart přežije. SIGHUP jde dál: znovu načte konfigurační soubor a znovu otevře své prostředky. SIGTERM a SIGINT žádají o spořádané vypnutí. To jsou operace na úrovni procesu: na serveru s mnoha klienty zasahují každou relaci, kterou proces nese, ne tu uvedenou v tiketu.

Když proces běží pod správcem služeb, použijte vlastní ovládání správce místo posílání signálu PID, který jste našli ve výpisu procesů. Přečtěte jednotku a zjistěte, který signál správce posílá, protože restart a reload dělají se stejným procesem různé věci.

Určete rozsah dřív, než vyberete ovládací prvek

Rozhodnou tři otázky. Koho se to má dotknout: jednoho uživatele, všech klientů jednoho serveru, nebo procesu a všeho, co nese. Co má přežít: konfigurace, stav tunelu, nebo nic. Kdo je k tomu oprávněn: integrace správy, vlastník služby, nebo síťový operátor, který ovládá oznámení o ukončení. Odpovězte a pasuje jen jeden ovládací prvek.

Přidání neověřeného posluchače správy kvůli tlačítku opětovného připojení předá tomu, kdo dosáhne na port, mnohem víc než to tlačítko.

Ověřte novou relaci, ne odpojení

Událost odpojení dokazuje, že stará relace skončila. Nic neříká o tom, že se nová ověřuje, dostává adresu, instaluje trasy nebo dosahuje na prostředek, který uživatel potřeboval. Zkontrolujte nový identifikátor, potom stav tunelu, potom jeden skutečný prostředek. Tyto tři kroky jsou rozdíl mezi opětovným připojením a funkčním spojením.

Zapište rozsah do záznamu o změně. „Znovu jsem připojil klienta“ není popis, když byl klient jeden ze čtyřiceti na sdíleném serveru.