Linux-VPN- en proxy-dienste in die regte volgorde afskakel

Herstarts wat hang terwyl ’n proxy loop, is selde ’n VPN-fout, selfs wanneer die VPN die laaste ding is wat op die skerm sigbaar is. Toepassings agter die proxy wag steeds op ’n pad wat op die punt staan om te verdwyn, en die eenheid wat die tonnel besit, is nog nie gevra om dit te sluit nie. Wat soos ’n stadige diens lyk, is gewoonlik ’n probleem met die volgorde. Volgorde los meer van hierdie gevalle op as enige verandering aan die tydlimiet.

Werk omgekeerd van buite na binne: eers die verbruikers, dan die proxy, dan die tonnel, elk gestop deur die komponent wat dit begin het.

Lys die eenhede voordat jy enigiets stop

Skryf die toepassingseenheid, die proxy-eenheid en die VPN-eienaar neer wat by ’n normale loop betrokke is. Voeg enige resolver of helper by wat sy eie afbreek het, want dit is die dinge wat mense om twee in die oggend vergeet. Sonder daardie lys kies die eerste stop-opdrag wat jy tik ’n slagoffer na willekeur.

Name is swak bewyse. ’n Gebruikerproxy, ’n stelselproxy en ’n ander rekening se tonnel kan dieselfde naam deel terwyl hulle heeltemal onverwante lewenssiklusse het.

Maak die werk klaar en stop dan die verbruiker

’n Beplande stop begin by die toepassing: laat dit sy versoeke klaarmaak of kanselleer, en stop dan die proxy deur sy dienseenheid. As die toepassing moet aanhou loop nadat die tonnel weg is, reël dit doelbewus eerder as om dit aan ’n roete te laat hang wat op die punt staan om te verdwyn.

Versoeke wat tydens die stop onderweg was, hoort in die rekord, want dit is waar die herprobeer-storm by die volgende opstart vandaan kom.

ExecStop en ExecStopPost is verskillende instrumente

ExecStop= is die sinchroniese stopbewerking; ExecStopPost= is opruiming wat selfs ná ’n mislukte opstart loop. ’n Stop-opdrag wat net ’n proses ’n sein gee en terugkeer, laat systemd aanbeweeg terwyl die verbruiker nog besig is om te spoel. Enigiets wat in elk geval moet gebeur, hoort in die na-variant, en enigiets wat die stop moet blokkeer, hoort in die sinchroniese een. Inspekteer die effektiewe eenheid en sy drop-ins eerder as om ’n pakketlêer ter plekke te wysig.

’n Afhanklikheidsgrafiek orden stop-take. Dit maak nie ’n asinchrone skrip in ’n sinchroniese een om nie, en dit laat ook nie ’n afgeleë toepassing sy data vaslê nie.

Beperk die stop en weet wat die beperking kos

TimeoutStopSec= beperk beide die stop-opdrag en die diens se eie beëindiging, en systemd skakel oor na ’n gedwonge doodmaak wanneer die limiet verstryk. Kies die waarde op grond van die toepassing se werklike spoelgedrag, en skryf neer wat verlore kan gaan wanneer dit bereik word. ’n Getal wat gekies is omdat die masjien vinniger moet afskakel, is ’n dataverlies-instelling in vermomming.

Wanneer ’n stop steeds stadig is, teken die eenheid, sy kindprosesse, die joernaal-interval en die tydlimiet-uitslag vas. Om elke tydlimiet te verkort of na ’n breë doodmaak te gryp, is hoe skoon afskakelings by die volgende selflaai in korrupte toestand verander.

Ontkoppel deur die eienaar en toets dan drie gevalle

Sodra die verbruikers af is, vra die bestuurder wat die tonnel besit om te ontkoppel: die systemd-instansie, die aktiewe NetworkManager-verbinding of die verskaffer se diens. Om ’n onverwante OpenVPN-proses dood te maak, verwyder nie noodwendig die sessie wat die roete verskaf het nie, en ’n proxy met ’n herbegin-beleid kan ’n versoek herskep terwyl jy die pad afbreek. Stem daardie beleid met die beplande stop af voordat jy begin.

Toets ’n normale stop, ’n stop met ’n aktiewe versoek en ’n stop waar die tonnel eerste misluk. ’n Herhaalbare volgorde met ’n sperdatum klop ’n vinnige afskakeling wat net een keer werk.