Ponovno povezivanje OpenVPN klijenta: tri kontrole i tri obima

Neko traži da se VPN klijent ponovo poveže, a taj zahtjev može značiti tri različite stvari. Može značiti prekid jedne autentifikovane sesije, obavještavanje svakog klijenta da UDP server odlazi ili restartovanje samog demona. Svaki ima drugačiji radijus uticaja, a pogrešan izbor pretvara popravku za jednog korisnika u ispad. Obim je odluka, a naredba slijedi iz njega.

Pitajte koga treba zahvatiti prije nego što pitate koju kontrolu koristiti.

Jedna instanca: upravljački interfejs

Konfigurisani upravljački interfejs može izlistati povezane instance i prekinuti tačno jednu od njih. Svaka sesija nosi identifikator klijenta, a client-kill CID cilja taj identifikator, a ne zajedničko ime. Čitajte živi identifikator iz trenutnog izlaza statusa, jer vrijednost kopirana iz starijeg zapisa odnosi se na sesiju koja više ne postoji. Prekid instance završava tu vezu i ništa drugo.

On ne garantuje novu vezu. Da li će se klijent vratiti zavisi od njegovih postavki ponovnog pokušaja, preostalih udaljenih unosa, zahtjeva za autentifikaciju i toga da li nadzorna aplikacija još radi. Klijent koji se vrati dobija novi identifikator, zbog čega je poređenje identifikatora jedini pouzdan način da se staro razlikuje od novog.

UDP obavještenje o izlazu nije naredba za pojedinačnog klijenta

explicit-exit-notify je konfiguracijska direktiva o događajima izlaza i restarta. Na UDP klijentu govori drugoj strani da se sesija završava, a numerički argument kontroliše koliko se puta obavještenje ponavlja. Kada server radi preko UDP-a, šalje kontrolnu poruku o restartu svojim povezanim klijentima, a dokumentovane vrijednosti razlikuju ponovno povezivanje na isti server od prelaska na drugi udaljeni unos. To je signal životnog ciklusa sa širokom publikom.

Ništa u njemu ne bira proizvoljnog klijenta u proizvoljnom trenutku. Tretiranje toga kao dugmeta za ponovno povezivanje doseže svaku povezanu sesiju odjednom.

Signali djeluju na proces, ne na sesiju

SIGUSR1 traži od pokrenutog procesa da restartuje svoju vezu bez ponovnog čitanja konfiguracije, a opcije trajnosti odlučuju šta preživi taj restart. SIGHUP ide dalje: ponovo čita konfiguracijsku datoteku i ponovo otvara svoje resurse. SIGTERM i SIGINT zahtijevaju uredno zaustavljanje. To su operacije na nivou procesa: na serveru s više klijenata djeluju na svaku sesiju koju proces nosi, a ne na onu navedenu u tiketu.

Kada proces radi pod upraviteljem servisa, koristite vlastitu kontrolu upravitelja umjesto slanja signala PID-u koji ste našli u listi procesa. Pročitajte jedinicu da vidite koji signal upravitelj šalje, jer restart i reload rade različite stvari istom demonu.

Odredite obim prije nego što odaberete kontrolu

Tri pitanja to rješavaju. Koga treba zahvatiti: jednog korisnika, sve klijente jednog servera ili demon i sve što nosi. Šta treba da preživi: konfiguracija, stanje tunela ili ništa. Ko je ovlašten to učiniti: upravljačka integracija, vlasnik servisa ili mrežni operater koji kontroliše obavještenje o izlazu. Odgovorite na to i odgovara samo jedna kontrola.

Dodavanje neautentifikovanog upravljačkog slušača radi dugmeta za ponovno povezivanje predaje onome ko može doći do porta mnogo više od tog dugmeta.

Provjerite novu sesiju, a ne prekid

Događaj prekida dokazuje da je stara sesija završila. Ne govori ništa o tome da se nova autentifikuje, prima adresu, instalira rute ili doseže resurs koji je korisniku trebao. Provjerite novi identifikator, zatim stanje tunela, zatim jedan stvarni resurs. Ta tri koraka su razlika između ponovnog povezivanja i veze koja radi.

Upišite obim u evidenciju promjena. „Ponovo sam povezao klijenta“ nije opis kada je klijent bio jedan od četrdeset na dijeljenom serveru.