Редослед на запирање на VPN и прокси службите во Linux

Застоите при запирање додека работи прокси ретко се грешка во VPN-от, дури и кога VPN-от е последното нешто видливо на екранот. Апликациите зад проксито сѐ уште чекаат патека што наскоро ќе исчезне, а единицата што го поседува тунелот сѐ уште не е замолена да го затвори. Она што изгледа како бавна служба обично е проблем со редоследот. Подредувањето решава повеќе вакви случаи отколку било каква промена на тајмаутот.

Движете се кон надвор во обратен редослед: прво потрошувачите, потоа проксито, а потоа тунелот — секој го запира оној компонент што го започнал.

Направете список на единиците пред да запрете нешто

Запишете ја единицата на апликацијата, единицата на проксито и сопственикот на VPN-от вклучени во нормалното пуштање. Додајте каков било резолвер или помошен компонент со сопствено затворање, бидејќи токму тие се забораваат во два часот наутро. Без тој список, првата команда за запирање што ќе ја напишете избира жртва по случаен избор.

Имињата се слаб доказ. Корисничко прокси, системско прокси и тунел на друга сметка можат да го делат истото име, а да имаат сосема неповрзани животни циклуси.

Прво завршете ја работата, потоа запрете го потрошувачот

Планираното запирање започнува со апликацијата: дозволете ѝ да ги заврши или откаже своите барања, потоа запрете го проксито преку неговата службена единица. Ако апликацијата треба да продолжи да работи откако тунелот ќе исчезне, уредете го тоа намерно, наместо да ја оставите прикачена на маршрута што наскоро ќе исчезне.

Барањата што биле во тек за време на запирањето припаѓаат во записот, бидејќи оттаму доаѓа бурата од повторни обиди при следното пуштање.

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

ExecStop= — тоа е синхрона операција на запирање; ExecStopPost= — тоа е чистење што се извршува дури и по неуспешно пуштање. Командата за запирање што само испраќа сигнал до процесот и се враќа му дозволува на systemd да продолжи додека потрошувачот сѐ уште ги испразнува податоците. Сѐ што мора да се случи без оглед на сѐ припаѓа на пост-варијантата, а сѐ што мора да го блокира запирањето припаѓа на синхроната. Прегледајте ја ефективната единица и нејзините drop-in датотеки наместо да ја менувате датотеката од пакетот на самото место.

Графот на зависности ги подредува задачите за запирање. Тој не претвора асинхрона скрипта во синхрона, ниту пак го тера оддалечената апликација да ги потврди своите податоци.

Ограничете го запирањето и знајте ја цената на тоа ограничување

TimeoutStopSec= го ограничува и командата за запирање и сопственото завршување на службата, а кога лимитот ќе истече systemd преминува на присилно убивање. Изберете ја вредноста според вистинското однесување на апликацијата при испразнување и запишете што може да се загуби кога лимитот ќе се достигне. Број избран затоа што машината треба да се исклучи побрзо е поставка за губење податоци под друго име.

Кога запирањето е сѐ уште бавно, забележете ја единицата, нејзините подредени процеси, интервалот на журналот и резултатот од тајмаутот. Скратувањето на сите тајмаути или посегнувањето по широко убивање е начинот на кој чистите запирања стануваат оштетена состојба при следното пуштање.

Исклучете се преку сопственикот, потоа тестирајте три случаи

Кога потрошувачите се запреани, замолете го менаџерот што го поседува тунелот да се исклучи: инстанцата на systemd, активната врска на NetworkManager или службата на добавувачот. Убивањето на неповрзан OpenVPN процес не ја отстранува нужно сесијата што ја обезбедила маршрутата, а проксито со политика за повторно пуштање може повторно да создаде барање додека ја разградувате патеката. Усогласете ја таа политика со планираното запирање пред да започнете.

Тестирајте нормално запирање, запирање со активно барање и запирање во кое тунелот прв откажува. Повторлива низа со рок е подобра од брзо исклучување што работи само еднаш.