Колькі часу OpenConnect павінен паўтараць спробы падключэння да абарванай VPN?

--reconnect-timeout адказвае на адно вузкае пытанне: пасля падзення тунэля колькі часу гэты працэс кліента працягвае спрабаваць, перш чым здацца і выйсці. Старонка даведкі OpenConnect фіксуе гэтую опцыю з дакументаваным значэннем па змаўчанні 300 секунд для паўтораў пасля страчанай лініі або партнёра, які перастаў адказваць, і гэты лік — крайні тэрмін для аднаго працуючага кліента, а не доказ таго, што VPN застаецца дасягальным. Гэта таксама не палітыка ўтрымання працэсу жывым, і менавіта адсюль пачынаецца большасць блытаніны.

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

Што насамрэч абмяжоўвае акно перападключэння

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

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

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

Перазапускі наглядальніка і паўторы кліента — два ўзроўні

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

У гэтым радку важныя дзве дэталі. --background аддзяляе працэс, таму файл pid становіцца адзінай надзейнай ручкай на ім, і тайм-аўт выдаткаўваецца толькі пакуль гэты ж працэс жывы; наглядальнік, які забівае яго, не пакідае бюджэту на працяг.

Наўмысныя адключэнні патрабуюць уласнага сігналу. Запланаваная паўза і сапраўдны перапынак выглядаюць аднолькава для наіўнага назіральніка, абодва чытаюцца як «не падключана». Кіруйце паўзай праз аперацыю прыпынку наглядальніка або праз маркер, які разумее абгортка, каб наўмысны стоп не выклікаў перазапуску, якога ніхто не прасіў.

Як не даць перадачы дагнаць цыкл паўтораў

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

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

Наяўнасць інтэрфейсу таксама не сігнал здароўя. Тунэльная прылада можа існаваць з мёртвым сеансам за ёй, а працэс запуску можа існаваць зусім без тунэля. Ні адно з гэтых назіранняў не вытрымлівае рэальнага запыту. Здароўе павінна паходзіць з таго, што патрэбна карыстальніку, напрыклад з запыту, які ідзе праз тунэль да вядомай унутранай службы.

Што правяраць падчас перапынку і пасля яго

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

Для наўмыснага стопу адрас здароўя павінен заставацца недасягальным, а працэс — спыненым. Затым завяршыце цыкл з боку праграмы: той жа запыт павінен праваліцца, пакуль тунэль адсутнічае, і паспець пасля яго вяртання, з адраса крыніцы, які чакае ваша палітыка. Зялёная іконка тунэля не доказ, а завершаны запыт — доказ.