Reconectarea unui client OpenVPN: trei controale, trei domenii

Cineva cere ca clientul VPN să fie reconectat, iar cererea poate însemna trei lucruri diferite. Poate însemna renunțarea la o sesiune autentificată, anunțarea fiecărui client că un server UDP pleacă, sau repornirea demonului însuși. Fiecare are o rază de impact diferită, iar alegerea greșită transformă o remediere pentru un utilizator într-o întrerupere. Domeniul este decizia, iar comanda decurge din ea.

Întrebați cine trebuie afectat înainte de a întreba ce control să folosiți.

O instanță: interfața de administrare

O interfață de administrare configurată poate lista instanțele conectate și poate renunța la exact una dintre ele. Fiecare sesiune poartă un identificator de client, iar client-kill CID vizează acel identificator în locul unui nume comun. Citiți identificatorul viu din ieșirea de stare curentă, pentru că o valoare copiată dintr-un jurnal mai vechi se referă la o sesiune care nu mai există. Renunțarea la instanță încheie acea conexiune și nimic altceva.

Nu garantează o conexiune nouă. Dacă clientul revine depinde de setările de reîncercare, de înregistrările la distanță rămase, de cerințele de autentificare și de dacă aplicația de supraveghere încă rulează. Un client care revine primește un identificator nou, de aceea compararea identificatorilor este singura modalitate fiabilă de a distinge vechiul de nou.

Un anunț de ieșire UDP nu este o comandă pentru fiecare client

explicit-exit-notify este o directivă de configurare despre evenimentele de ieșire și repornire. Pe un client UDP anunță cealaltă parte că sesiunea se termină, iar argumentul numeric controlează de câte ori se repetă anunțul. Când serverul rulează peste UDP, trimite un mesaj de control al repornirii clienților conectați, iar valorile documentate disting reconectarea la același server de trecerea la o altă înregistrare la distanță. Este un semnal de ciclu de viață cu un public larg.

Nimic din el nu selectează un client arbitrar într-un moment arbitrar. Tratarea lui ca buton de reconectare ajunge la fiecare sesiune conectată deodată.

Semnalele acționează asupra procesului, nu asupra sesiunii

SIGUSR1 cere unui proces care rulează să repornească conexiunea fără a reciti configurația, iar opțiunile de persistență decid ce supraviețuiește acelei reporniri. SIGHUP merge mai departe: recitește fișierul de configurare și își redeschide resursele. SIGTERM și SIGINT cer o oprire ordonată. Sunt operațiuni la nivel de proces: pe un server cu mulți clienți afectează fiecare sesiune pe care o duce procesul, nu pe cea numită în tichet.

Când procesul rulează sub un manager de servicii, folosiți controlul propriu al managerului în loc să trimiteți un semnal către un PID găsit într-o listă de procese. Citiți unitatea pentru a vedea ce semnal trimite managerul, pentru că o repornire și o reîncărcare fac lucruri diferite aceluiași demon.

Stabiliți domeniul înainte de a alege controlul

Trei întrebări o rezolvă. Cine trebuie afectat: un utilizator, fiecare client al unui server sau demonul și tot ce duce el. Ce trebuie să supraviețuiască: configurația, starea tunelului sau niciuna. Cine este autorizat: integrarea de administrare, proprietarul serviciului sau operatorul de rețea care controlează anunțul de ieșire. Răspundeți la acestea și se potrivește un singur control.

Adăugarea unui ascultător de control neautentificat pentru a obține un buton de reconectare oferă oricui ajunge la port mult mai mult decât acel buton.

Verificați sesiunea nouă, nu deconectarea

Un eveniment de deconectare dovedește că sesiunea veche s-a încheiat. Nu spune nimic despre una nouă care se autentifică, primește o adresă, instalează rute sau ajunge la resursa de care utilizatorul avea nevoie. Verificați noul identificator, apoi starea tunelului, apoi o resursă reală. Acei trei pași sunt diferența dintre o reconectare și o conexiune care funcționează.

Scrieți domeniul în registrul de modificări. „Am reconectat clientul” nu este o descriere când clientul era unul dintre patruzeci pe un server partajat.