Поновно повезивање OpenVPN клијента: три контроле, три обима
Одбацивање једне сесије, обавештавање сваког UDP клијента и поновно покретање демона су различите операције. Прво одредите обим, затим проверите нову сесију.
Неко тражи да се VPN клијент поново повеже, а тај захтев може значити три различите ствари. Може значити одбацивање једне аутентификоване сесије, обавештавање сваког клијента да UDP сервер одлази или поновно покретање самог демона. Свака има другачији радијус утицаја, а погрешан избор претвара поправку за једног корисника у прекид услуге. Обим је одлука, а наредба следи из ње.
Питајте кога то треба да захвати пре него што питате која контрола да се користи.
Једна инстанца: интерфејс за управљање
Конфигурисани интерфејс за управљање може набројати повезане инстанце и одбацити тачно једну од њих. Свака сесија носи идентификатор клијента, а client-kill CID циља тај идентификатор, а не заједничко име. Читајте живи идентификатор из тренутног излаза стања, јер вредност копирана из старијег дневника односи се на сесију која више не постоји. Одбацивање инстанце завршава ту везу и ништа друго.
То не гарантује нову везу. Да ли ће се клијент вратити зависи од његових подешавања поновног покушаја, преосталих удаљених записа, захтева за аутентификацију и тога да ли надзорна апликација још ради. Клијент који се врати добија нови идентификатор, и зато је поређење идентификатора једини поуздан начин да се старо разликује од новог.
UDP обавештење о излазу није наредба за појединачног клијента
explicit-exit-notify је конфигурацијска директива о догађајима излаза и поновног покретања. На UDP клијенту она саопштава другој страни да се сесија завршава, а нумерички аргумент контролише колико се пута обавештење понавља. Када сервер ради преко UDP-а, шаље контролну поруку о поновном покретању својим повезаним клијентима, а документоване вредности разликују поновно повезивање са истим сервером од преласка на други удаљени запис. То је сигнал животног циклуса са широком публиком.
Ништа у њему не бира произвољног клијента у произвољном тренутку. Третирање тога као дугмета за поновно повезивање достиже сваку повезану сесију одједном.
Сигнали делују на процес, не на сесију
SIGUSR1 тражи од процеса који ради да поново покрене своју везу без поновног читања конфигурације, а опције трајности одлучују шта преживљава то поновно покретање. SIGHUP иде даље: поново чита конфигурацијску датотеку и поново отвара своје ресурсе. SIGTERM и SIGINT захтевају уредно заустављање. То су операције на нивоу процеса: на серверу са много клијената делују на сваку сесију коју процес носи, а не на ону наведену у тикету.
Када процес ради под менаџером услуга, користите његову сопствену контролу уместо да шаљете сигнал PID-у који сте нашли у листи процеса. Прочитајте јединицу да видите који сигнал менаџер шаље, јер поновно покретање и поновно учитавање раде различите ствари на истом демону.
Одредите обим пре него што изаберете контролу
Три питања то решавају. Кога треба да захвати: једног корисника, све клијенте једног сервера или демон и све што он носи. Шта треба да преживи: конфигурација, стање тунела или ништа. Ко је за то овлашћен: интеграција управљања, власник услуге или мрежни оператер који контролише обавештење о излазу. Одговорите на то и одговара само једна контрола.
Додавање неаутентификованог слушаоца управљања да би се добило дугме за поновно повезивање предаје ономе ко може да достигне порт много више од тог дугмета.
Проверите нову сесију, не прекид
Догађај прекида доказује да је стара сесија завршена. Не говори ништа о новој сесији која се аутентификује, прима адресу, инсталира руте или достиже ресурс који је кориснику требао. Проверите нови идентификатор, затим стање тунела, затим један стварни ресурс. Та три корака су разлика између поновног повезивања и везе која ради.
Упишите обим у евиденцију измена. „Поново сам повезао клијента“ није опис када је клијент био један од четрдесет на дељеном серверу.