Linux-VPN- en proxy-tsjinsten yn de krekte folchoarder út sette

Hingjen by it ôfsluten wylst in proxy rint is selden in VPN-flater, sels as de VPN it lêste is dat op it skerm te sjen is. Tapassingen efter de proxy wachtsje noch op in paad dat op it punt stiet te ferdwinen, en de ienheid dy't de tunnel besit is noch net frege om dy te sluten. Wat op in stadige tsjinst liket is meastentiids in folchoarderprobleem. Folchoarder lost mear fan dizze gefallen op as hokker feroaring fan 'e tiidlimit dan ek.

Wurkenje fan bûten nei binnen yn omkearde folchoarder: earst de konsuminten, dan de proxy, dan de tunnel, elk stoppe troch it ûnderdiel dat it begûn is.

List de ienheden op foardat jo eat stopje

Skriuw de tapassingsienheid, de proxy-ienheid en de VPN-eigenerm op dy't by in normale rin belutsen binne. Foegje elke resolver of helper ta mei syn eigen ôfbrekken, want dat binne dejingen dy't minsken om twa oere nachts ferjitte. Sûnder dy list kiest it earste stopkommando dat jo typpe in slachtoffer samar.

Nammen binne swak bewiis. In brûkersproxy, in systeemproxy en de tunnel fan in oar akkount kinne deselde namme diele wylst har libbenssyklussen folslein ûnferbûn binne.

Meitsje it wurk ôf, stop dan de konsumint

In pland stop begjint by de tapassing: lit dy syn oanfragen ôfmeitsje of annulearje, stop dan de proxy fia syn tsjinstienheid. As de tapassing trochrinne moat nei't de tunnel fuort is, regel dat dan bewust ynstee fan it oan in rûte te hingjen dy't op it punt stiet te ferdwinen.

Oanfragen dy't ûnder it stop ûnderweis wiene hearre yn it register, want dêrfandinne komt de stoarm fan nije besykjen by de folgjende start.

ExecStop en ExecStopPost binne ferskillende ynstruminten

ExecStop= is de syngroane stopbewurking; ExecStopPost= is opromjen dat sels nei in mislearre start rint. In stopkommando dat allinnich in sinjaal nei in proses stjoert en weromkomt, lit systemd fierder gean wylst de konsumint noch oan it spieljen is. Alles wat yn alle gefallen barre moat heart yn 'e neifariant, en alles wat it stop blokkearje moat heart yn 'e syngroane. Undersykje de effektive ienheid en har drop-ins ynstee fan in pakketbestân op it plak te bewurkjen.

In ôfhinklikensgraf oardere stopbanen. It makket in asyngroan skript net syngroan, en it twingt in remote tapassing ek net om har gegevens fêst te lizzen.

Behein it stop en wit wat de beheining kostet

TimeoutStopSec= beheint sawol it stopkommando as de eigen beëiniging fan 'e tsjinst, en systemd giet oer op twongen deadzjen as de limyt ferrint. Kies de wearde op grûn fan it echte spielgedrach fan 'e tapassing, en skriuw op wat ferlern gean kin as it berikt wurdt. In getal dat keazen is om't de masine flugger út moat, is in ynstelling foar gegevensferlies yn ferklaaiïng.

As in stop noch stadich is, liz dan de ienheid, har bernprosessen, it tiidskriftinterval en it resultaat fan 'e tiidlimit fêst. Elk tiidlimit ferkoartsje of nei breed deadzjen gripe is hoe't skjinne ôfslutings by de folgjende boot yn skansearre steat feroarje.

Ferbrek fia de eigenerm, test dan trije gefallen

As de konsuminten del binne, freegje de behearder dy't de tunnel besit om te ferbrekken: de systemd-ynstânsje, de aktive NetworkManager-ferbining of de tsjinst fan 'e leveransier. It deadzjen fan in net besibbe OpenVPN-proses ferwideret net needsaaklikerwiis de sesje dy't it paad levere, en in proxy mei in werstartbelied kin in oanfraach opnij meitsje wylst jo it paad útinoar helje. Koördinearje dat belied mei it plande stop foardat jo begjinne.

Test in normaal stop, in stop mei in aktive oanfraach en in stop wêrby't de tunnel earst mislearret. In werhellbere sekwinsje mei in deadline ferslacht in flugge ôfsluting dy't ien kear wurket.