Колко дълго 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 се връща към една стойност, вместо да се натрупва.

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