Някой иска VPN клиентът да бъде свързан отново и тази заявка може да означава три различни неща. Може да означава прекъсване на една удостоверена сесия, уведомяване на всеки клиент, че UDP сървърът си отива, или рестартиране на самия демон. Всяко има различен радиус на въздействие и грешният избор превръща поправка за един потребител в прекъсване на услугата. Обхватът е решението, а командата следва от него.

Попитайте кого трябва да засегне, преди да питате кое средство за управление да използвате.

Един екземпляр: интерфейсът за управление

Конфигуриран интерфейс за управление може да изброи свързаните екземпляри и да прекъсне точно един от тях. Всяка сесия носи идентификатор на клиента и client-kill CID насочва към този идентификатор, а не към общо име. Четете живия идентификатор от текущия изход на състоянието, защото стойност, копирана от по-стар журнал, сочи сесия, която вече не съществува. Прекъсването на екземпляра приключва тази връзка и нищо друго.

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

UDP известието за изход не е команда за отделен клиент

explicit-exit-notify е конфигуративна директива за събитията на изход и рестарт. На UDP клиент тя казва на отсрещната страна, че сесията приключва, а числовият аргумент управлява колко пъти известието се повтаря. Когато сървърът работи през UDP, той изпраща контролно съобщение за рестарт до свързаните си клиенти и документираните стойности различават повторно свързване към същия сървър от преминаване към друг отдалечен запис. Това е сигнал за жизнения цикъл с широка аудитория.

Нищо в него не избира произволен клиент в произволен момент. Да се отнасяте към него като към бутон за повторно свързване достига до всяка свързана сесия наведнъж.

Сигналите действат върху процеса, не върху сесията

SIGUSR1 иска от работещ процес да рестартира връзката си, без да препрочита конфигурацията, а опциите за устойчивост решават какво оцелява след този рестарт. SIGHUP отива по-далеч: препрочита конфигурационния файл и отваря отново ресурсите си. SIGTERM и SIGINT изискват подредено спиране. Това са операции на ниво процес: на сървър с много клиенти те засягат всяка сесия, която процесът носи, а не тази, посочена в заявката.

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

Решете обхвата, преди да изберете средството за управление

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

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

Проверете новата сесия, а не прекъсването

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

Запишете обхвата в записа за промени. „Свързах клиента отново“ не е описание, когато клиентът е бил един от четиридесет на споделен сървър.

Подобни статии