Mbyllja me radhë e shërbimeve VPN dhe proxy në Linux

Ngrirjet gjatë mbylljes kur proxy-ja po punon rrallë janë defekt i VPN-së, edhe kur VPN-ja është gjëja e fundit që duket në ekran. Aplikacionet pas proxy-së presin ende një rrugë që është gati të zhduket, dhe njësia që zotëron tunelin nuk është kërkuar ende ta mbyllë atë. Ajo që duket si shërbim i ngadaltë është zakonisht problem radhitjeje. Radhitja zgjidh më shumë nga këto sesa çdo ndryshim timeout-i.

Lëvizni nga brenda jashtë në rend të kundërt: së pari konsumuesit, pastaj proxy-ja, pastaj tuneli — secili ndalet nga komponenti që e nisi.

Bëni listën e njësive përpara se të ndaloni çdo gjë

Shkruani njësinë e aplikacionit, njësinë e proxy-së dhe pronarin e VPN-së të përfshirë në një nisje normale. Shtoni çdo resolver ose komponent ndihmës me mbyllje të vetën, sepse pikërisht ata harrohen në orën dy të mëngjesit. Pa atë listë, komanda e parë e ndalimit që shkruani zgjedh një viktimë rastësisht.

Emrat janë provë e dobët. Një proxy përdoruesi, një proxy sistemi dhe tuneli i një llogarie tjetër mund të ndajnë të njëjtin emër, ndërsa kanë cikle jete krejt të palidhura.

Përfundoni punën, pastaj ndaloni konsumuesin

Një ndalim i planifikuar fillon me aplikacionin: lëreni të përfundojë ose të anulojë kërkesat e tij, pastaj ndaloni proxy-n përmes njësisë së shërbimit të saj. Nëse aplikacioni duhet të vazhdojë të punojë pasi tuneli të zhduket, organizojeni atë me qëllim, në vend që ta lini të lidhur me një rrugë që është gati të zhduket.

Kërkesat që ishin në fluturim gjatë ndalimit i përkasin regjistrit, sepse prej andej vjen stuhia e ripërpjekjeve në nisjen e radhës.

ExecStop dhe ExecStopPost janë instrumente të ndryshme

ExecStop= — është operacioni sinkron i ndalimit; ExecStopPost= — është pastrim që ekzekutohet edhe pas një nisjeje të dështuar. Një komandë ndalimi që thjesht i dërgon një sinjal një procesi dhe kthehet e lë systemd të vazhdojë ndërsa konsumuesi ende po shkarkon të dhënat. Çdo gjë që duhet të ndodhë pa kushte i përket variantit post, dhe çdo gjë që duhet të bllokojë ndalimin i përket atij sinkron. Inspektoni njësinë efektive dhe drop-in-et e saj në vend që të redaktoni një skedar pakete në vend.

Një grafik varësish rendit punët e ndalimit. Ai nuk e kthen një skript asinkron në sinkron, as e detyron një aplikacion të largët të kryejë të dhënat e tij.

Kufizoni ndalimin dhe dini sa kushton ky kufi

TimeoutStopSec= kufizon si komandën e ndalimit ashtu edhe përfundimin e vetë shërbimit, dhe systemd kalon në një vrasje të dhunshme kur kufiri skadon. Zgjidhni vlerën sipas sjelljes reale të shkarkimit të aplikacionit dhe shkruani çfarë mund të humbet kur të godasë kufiri. Një numër i zgjedhur sepse makina duhet të fiket më shpejt është një rregullim humbjeje të dhënash i maskuar.

Kur një ndalim është ende i ngadaltë, regjistroni njësinë, proceset e saj fëmijë, intervalin e ditarit dhe rezultatin e timeout-it. Shkurtimi i çdo timeout-i ose të kapurit pas një vrasjeje të gjerë është mënyra se si ndalimet e pastra kthehen në gjendje të korruptuar në nisjen tjetër.

Shkëputuni përmes pronarit, pastaj provoni tre raste

Pasi konsumuesit të jenë ndalur, kërkoni nga menaxheri që zotëron tunelin të shkëputet: instanca systemd, lidhja aktive e NetworkManager-it ose shërbimi i furnizuesit. Vrasja e një procesi OpenVPN të palidhur nuk e heq domosdoshmërisht sesionin që dha rrugën, dhe një proxy me politikë rinisjeje mund të krijojë përsëri një kërkesë ndërsa ju po çmontoni rrugën. Koordinoni atë politikë me ndalimin e planifikuar përpara se të filloni.

Provoni një ndalim normal, një ndalim me një kërkesë aktive dhe një ndalim ku tuneli dështon i pari. Një sekuencë e përsëritshme me afat është më e mirë se një mbyllje e shpejtë që funksionon vetëm një herë.