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

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