Volgorde voor het afsluiten van VPN- en proxydiensten op Linux

Hangers bij het afsluiten terwijl een proxy draait, zijn zelden een VPN-fout, zelfs wanneer de VPN het laatste is dat op het scherm te zien is. Applicaties achter de proxy wachten nog steeds op een pad dat op het punt staat te verdwijnen, en de unit die de tunnel bezit is nog niet gevraagd hem te sluiten. Wat op een trage dienst lijkt, is meestal een volgordeprobleem. Volgordebepaling lost hier meer van op dan welke time-outwijziging dan ook.

Werk naar buiten in omgekeerde volgorde: eerst de consumenten, dan de proxy en dan de tunnel — elk gestopt door het component dat het heeft gestart.

Maak de lijst van units voordat je iets stopt

Schrijf de applicatie-unit, de proxy-unit en de VPN-eigenaar op die bij een normale run betrokken zijn. Voeg elke resolver of hulpmiddel met eigen afsluiting toe, want juist die worden om twee uur 's nachts vergeten. Zonder die lijst kiest de eerste stopopdracht die je typt willekeurig een slachtoffer.

Namen zijn zwak bewijs. Een gebruikersproxy, een systeemproxy en de tunnel van een ander account kunnen dezelfde naam delen en toch volledig onverwante levenscycli hebben.

Maak het werk af en stop dan de consument

Een geplande stop begint bij de applicatie: laat die zijn verzoeken afronden of annuleren, en stop daarna de proxy via zijn service-unit. Als de applicatie moet blijven draaien nadat de tunnel weg is, regel dat dan bewust, in plaats van hem vastgekoppeld te laten aan een route die op het punt staat te verdwijnen.

Verzoeken die tijdens de stop onderweg waren, horen in het verslag, want daar komt de storm van herhaalpogingen bij de volgende start vandaan.

ExecStop en ExecStopPost zijn verschillende instrumenten

ExecStop= — is de synchrone stopbewerking; ExecStopPost= — is opruiming die zelfs na een mislukte start loopt. Een stopopdracht die alleen een signaal naar een proces stuurt en terugkeert, laat systemd doorgaan terwijl de consument nog aan het flushen is. Alles wat hoe dan ook moet gebeuren, hoort bij de post-variant, en alles wat de stop moet blokkeren, hoort bij de synchrone. Bekijk de effectieve unit en zijn drop-ins in plaats van een pakketbestand ter plekke te bewerken.

Een afhankelijkheidsgraaf ordent stoptaken. Hij maakt een asynchroon script niet synchroon en dwingt een externe applicatie niet zijn gegevens vast te leggen.

Begrens de stop en weet wat die begrenzing kost

TimeoutStopSec= begrenst zowel de stopopdracht als de eigen beëindiging van de dienst, en systemd schakelt over op een geforceerde kill wanneer de limiet verstrijkt. Kies de waarde op basis van het werkelijke flushgedrag van de applicatie en schrijf op wat verloren kan gaan wanneer de limiet wordt bereikt. Een getal dat is gekozen omdat de machine sneller moet uitschakelen, is een instelling voor gegevensverlies onder een andere naam.

Wanneer een stop nog steeds traag is, leg dan de unit, zijn childprocessen, het journal-interval en het time-outresultaat vast. Alle time-outs inkorten of naar een brede kill grijpen is hoe schone stops bij de volgende boot in corrupte staat veranderen.

Verbreek de verbinding via de eigenaar en test dan drie gevallen

Zodra de consumenten omlaag zijn, vraag de beheerder die de tunnel bezit om te verbreken: de systemd-instantie, de actieve NetworkManager-verbinding of de dienst van de leverancier. Een losstaand OpenVPN-proces doden verwijdert niet noodzakelijk de sessie die de route leverde, en een proxy met herstartbeleid kan een verzoek opnieuw aanmaken terwijl je het pad ontmantelt. Stem dat beleid af met de geplande stop voordat je begint.

Test een normale stop, een stop met een actief verzoek en een stop waarbij de tunnel als eerste faalt. Een herhaalbare reeks met een deadline is beter dan een snelle afsluiting die één keer werkt.