Rikthimi i një klienti OpenVPN: tre kontrolle, tre shtrirje

Dikush kërkon që klienti VPN të rilidhet, dhe kërkesa mund të nënkuptojë tre gjëra të ndryshme. Mund të nënkuptojë heqjen e një sesioni të autentikuar, njoftimin e çdo klienti se një server UDP po largohet, ose rindezjen e vetë daemon-it. Secili ka një rreze tjetër ndikimi, dhe zgjedhja e gabuar e kthen një rregullim për një përdorues në një ndërprerje. Shtrirja është vendimi, dhe komanda rrjedh prej saj.

Pyetni kush duhet të preket përpara se të pyesni cilin kontroll të përdorni.

Një instancë: ndërfaqja e administrimit

Një ndërfaqe administrimi e konfiguruar mund të listojë instancat e lidhura dhe të heqë saktësisht njërën prej tyre. Çdo sesion mban një identifikues klienti, dhe client-kill CID synon atë identifikues në vend të një emri të përbashkët. Lexoni identifikuesin e gjallë nga dalja aktuale e statusit, sepse një vlerë e kopjuar nga një log më i vjetër i referohet një sesioni që nuk ekziston më. Heqja e instancës përfundon atë lidhje dhe asgjë tjetër.

Nuk garanton një lidhje të re. Nëse klienti kthehet varet nga cilësimet e ripërpjekjes, hyrjet e mbetura në distancë, kërkesat e autentikimit dhe nëse aplikacioni mbikëqyrës është ende duke punuar. Një klient që kthehet merr një identifikues të ri, dhe për këtë arsye krahasimi i identifikuesve është mënyra e vetme e besueshme për të dalluar të vjetrin nga i riu.

Njoftimi i daljes UDP nuk është komandë për çdo klient

explicit-exit-notify është një direktivë konfigurimi për ngjarjet e daljes dhe rindezjes. Në një klient UDP i thotë palës tjetër se sesioni po përfundon, dhe argumenti numerik kontrollon sa herë përsëritet njoftimi. Kur serveri punon përmes UDP, dërgon një mesazh kontrolli rindezjeje klientëve të lidhur, dhe vlerat e dokumentuara dallojnë rilidhjen me të njëjtin server nga kalimi në një hyrje tjetër në distancë. Ky është një sinjal cikli jetësor me një audiencë të gjerë.

Asgjë në të nuk zgjedh një klient arbitrar në një moment arbitrar. Trajtimi i tij si buton rilidhjeje arrin çdo sesion të lidhur njëherësh.

Sinjalet veprojnë mbi procesin, jo mbi sesionin

SIGUSR1 i kërkon një procesi në punë të rindezë lidhjen e tij pa rilexuar konfigurimin, dhe opsionet e qëndrueshmërisë vendosin çfarë i mbijeton asaj rindezjeje. SIGHUP shkon më tej: rilexon skedarin e konfigurimit dhe rihap burimet e tij. SIGTERM dhe SIGINT kërkojnë një mbyllje të rregullt. Këto janë operacione në nivel procesi: në një server me shumë klientë prekin çdo sesion që mbart procesi, jo atë të përmendur në tiketë.

Kur procesi punon nën një menaxher shërbimesh, përdorni kontrollin e vetë menaxherit në vend që të dërgoni sinjal në një PID që e gjetët në një listë procesesh. Lexoni njësinë për të parë cilin sinjal dërgon menaxheri, sepse rindezja dhe ringarkimi bëjnë gjëra të ndryshme me të njëjtin daemon.

Përcaktoni shtrirjen përpara se të zgjidhni kontrollin

Tre pyetje e zgjidhin. Kush duhet të preket: një përdorues, çdo klient i një serveri, ose daemon-i dhe gjithçka që mbart. Çfarë duhet të mbijetojë: konfigurimi, gjendja e tunelit, ose asnjëra. Kush është i autorizuar: integrimi i administrimit, pronari i shërbimit, ose operatori i rrjetit që kontrollon njoftimin e daljes. Përgjigjuni këtyre dhe përshtatet vetëm një kontroll.

Shtimi i një dëgjuesi kontrolli pa autentikim për të marrë një buton rilidhjeje i jep kujtdo që arrin portën shumë më tepër se ai buton.

Verifikoni sesionin e ri, jo shkëputjen

Një ngjarje shkëputjeje provon që sesioni i vjetër përfundoi. Nuk thotë asgjë për një sesion të ri që autentikohet, merr një adresë, instalon rrugë ose arrin burimin që i duhej përdoruesit. Kontrolloni identifikuesin e ri, pastaj gjendjen e tunelit, pastaj një burim real. Këto tre hapa janë ndryshimi midis një rilidhjeje dhe një lidhjeje që punon.

Shkruani shtrirjen në regjistrin e ndryshimeve. «Rilidha klientin» nuk është përshkrim kur klienti ishte një nga dyzet në një server të përbashkët.