Спиране на VPN и прокси услугите в Linux в правилния ред

Зависването при спиране, докато работи прокси, рядко е дефект на VPN, дори когато VPN е последното нещо на екрана. Приложенията зад проксито все още чакат път, който ей сега ще изчезне, а юнитът, който притежава тунела, още не е помолен да го затвори. Това, което изглежда като бавна услуга, обикновено е проблем с реда. Подредбата решава повече от тези случаи, отколкото всяка промяна на таймаута.

Работете навън в обратен ред: първо потребителите, после проксито, после тунелът, като всеки се спира от компонента, който го е стартирал.

Избройте юнитите, преди да спрете нещо

Запишете юнита на приложението, юнита на проксито и собственика на VPN, участващи в нормален цикъл. Добавете всеки resolver или помощник със собствено разглобяване, защото точно тях хората забравят в два през нощта. Без този списък първата команда за спиране, която напишете, избира жертва на случаен принцип.

Имената са слабо доказателство. Потребителско прокси, системно прокси и тунел на друг акаунт могат да споделят име, а жизнените им цикли да са напълно несвързани.

Довършете работата, после спрете потребителя

Планираното спиране започва с приложението: оставете го да завърши или да отмени заявките си, после спрете проксито през неговия юнит за услуга. Ако приложението трябва да продължи да работи след изчезването на тунела, уредете го нарочно, вместо да го оставите вързано към маршрут, който ей сега ще изчезне.

Заявките, които са били в движение по време на спирането, принадлежат в записа, защото точно оттам идва бурята от повторни опити при следващото стартиране.

ExecStop и ExecStopPost са различни инструменти

ExecStop= е синхронната операция по спиране; ExecStopPost= е почистване, което се изпълнява дори след неуспешно стартиране. Команда за спиране, която само подава сигнал на процес и се връща, позволява на systemd да продължи, докато потребителят още изчиства. Всичко, което трябва да се случи при всички положения, принадлежи на пост варианта, а всичко, което трябва да блокира спирането — на синхронния. Прегледайте ефективния юнит и неговите допълнения, вместо да редактирате файл от пакета на място.

Графът на зависимости подрежда задачите за спиране. Той не превръща асинхронен скрипт в синхронен, нито кара отдалечено приложение да запише данните си.

Ограничете спирането и знайте какво струва ограничението

TimeoutStopSec= ограничава както командата за спиране, така и собственото прекратяване на услугата, а systemd преминава към принудително убиване, когато лимитът изтече. Изберете стойността според реалното поведение на приложението при изчистване и запишете какво може да се загуби, когато тя се задейства. Число, избрано защото машината трябва да се изключи по-бързо, е настройка за загуба на данни под прикритие.

Когато спирането все още е бавно, запишете юнита, дъщерните му процеси, интервала в журнала и резултата от таймаута. Съкращаването на всеки таймаут или посягането към широко убиване е начинът чистите спирания да се превърнат в повредено състояние при следващото зареждане.

Прекъснете връзката през собственика, после тествайте три случая

След като потребителите са спрени, помолете мениджъра, който притежава тунела, да прекъсне връзката: инстанцията на systemd, активното свързване на NetworkManager или услугата на доставчика. Убиването на несвързан процес OpenVPN не премахва непременно сесията, която е осигурила маршрута, а прокси с политика за рестартиране може да пресъздаде заявка, докато разглобявате пътя. Съгласувайте тази политика с планираното спиране, преди да започнете.

Тествайте нормално спиране, спиране с активна заявка и спиране, при което тунелът се проваля пръв. Повтаряема последователност с краен срок е по-добра от бързо изключване, което работи веднъж.