Колико дуго 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 враћа на једну вредност уместо да се гомила.

За намерно заустављање адреса здравља треба да остане недоступна, а процес заустављен. Затим затворите петљу са стране апликације: исти захтев мора да падне док тунела нема и мора да успе после његовог повратка, са изворне адресе коју ваша политика очекује. Зелена икона тунела није доказ, али завршен захтев јесте.