Перападключэнне кліента OpenVPN: тры сродкі кіравання і тры абсягі

Нехта просіць перападключыць VPN-кліент, і гэтая просьба можа азначаць тры розныя рэчы. Яна можа азначаць скід адной аўтэнтыфікаванай сесіі, паведамленне кожнаму кліенту пра тое, што UDP-сервер сыходзіць, або перазапуск самога дэмана. Кожны варыянт мае іншы радыус уздзеяння, і няправільны выбар ператварае выпраўленне для аднаго карыстальніка ў збой. Абсяг — гэта рашэнне, а каманда вынікае з яго.

Спытайцеся, каго гэта павінна закрануць, перш чым пытацца, які сродак кіравання выкарыстоўваць.

Адзін асобнік: інтэрфейс кіравання

Наладжаны інтэрфейс кіравання можа пералічыць падключаныя асобнікі і скінуць роўна адзін з іх. Кожная сесія мае ідэнтыфікатар кліента, а client-kill CID нацэльвае менавіта гэты ідэнтыфікатар, а не агульнае імя. Чытайце жывы ідэнтыфікатар з бягучага вываду стану, бо значэнне, скапіяванае са старога журнала, спасылаецца на сесію, якой ужо няма. Скід асобніка спыняе гэтае злучэнне і больш нічога.

Ён не гарантуе новага злучэння. Ці вернецца кліент, залежыць ад яго налад паўторных спроб, пакінутых аддаленых запісаў, патрабаванняў аўтэнтыфікацыі і таго, ці яшчэ працуе кіруючая праграма. Кліент, які вяртаецца, атрымлівае новы ідэнтыфікатар, таму параўнанне ідэнтыфікатараў — адзіны надзейны спосаб адрозніць старое ад новага.

Паведамленне пра выхад UDP — не каманда для асобнага кліента

explicit-exit-notify — гэта дырэктыва канфігурацыі пра падзеі выхаду і перазапуску. На UDP-кліенце яна паведамляе суразмоўцу, што сесія заканчваецца, а лікавы аргумент кіруе тым, колькі разоў паведамленне паўтараецца. Калі сервер працуе праз UDP, ён дасылае падключаным кліентам кіруючае паведамленне пра перазапуск, і дакументаваныя значэнні адрозніваюць перападключэнне да таго ж сервера ад пераходу на іншы аддалены запіс. Гэта сігнал жыццёвага цыкла з шырокай аўдыторыяй.

Нішто ў ім не выбірае адвольнага кліента ў адвольны момант. Стаўленне да яго як да кнопкі перападключэння дасягае ўсіх падключаных сесій адначасова.

Сігналы дзейнічаюць на працэс, а не на сесію

SIGUSR1 просіць працуючы працэс перазапусціць сваё злучэнне, не перачытваючы канфігурацыю, а параметры захавання вызначаюць, што перажыве гэты перазапуск. SIGHUP ідзе далей: ён перачытвае файл канфігурацыі і паўторна адкрывае свае рэсурсы. SIGTERM і SIGINT патрабуюць упарадкаванага спынення. Гэта аперацыі ўзроўню працэсу: на серверы з многімі кліентамі яны закранаюць кожную сесію, якую трымае працэс, а не тую, што названая ў заяўцы.

Калі працэс працуе пад кіраўніком службаў, выкарыстоўвайце ўласнае кіраванне кіраўніка, а не пасылайце сігнал на PID, знойдзены ў спісе працэсаў. Прачытайце юніт, каб убачыць, які сігнал пасылае кіраўнік, бо перазапуск і перазагрузка робяць з адным і тым жа дэманам розныя рэчы.

Вызначце абсяг перад выбарам сродку кіравання

Тры пытанні вырашаюць справу. Каго гэта павінна закрануць: аднаго карыстальніка, усіх кліентаў аднаго сервера або дэман і ўсё, што ён трымае. Што павінна захавацца: канфігурацыя, стан тунеля або нішто. Хто ўпаўнаважаны гэта рабіць: інтэграцыя кіравання, уладальнік сэрвісу або сеткавы аператар, які кіруе паведамленнем пра выхад. Адкажыце на гэта — і падыходзіць толькі адзін сродак кіравання.

Даданне неаўтэнтыфікаванага слухача кіравання, каб атрымаць кнопку перападключэння, перадае камусьці, хто можа дасягнуць порта, значна больш, чым гэтая кнопка.

Праверце новую сесію, а не разрыў

Падзея разрыву даказвае, што старая сесія скончылася. Яна нічога не кажа пра тое, што новая сесія аўтэнтыфікуецца, атрымае адрас, усталюе маршруты або дасягне рэсурсу, патрэбнага карыстальніку. Праверце новы ідэнтыфікатар, затым стан тунеля, затым адзін рэальны рэсурс. Гэтыя тры крокі — розніца паміж перападключэннем і працоўным злучэннем.

Запішыце абсяг у запіс пра змены. «Перападключыў кліента» — не апісанне, калі кліент быў адным з сарака на агульным серверы.