OpenConnect үзілген VPN-ге қанша уақыт қайта қосылуға тырысуы керек?

--reconnect-timeout бір тар сұраққа жауап береді: туннель құлағаннан кейін бұл клиент процесі табандылықтан бас тартып шыққанша қанша уақыт әрекет ете береді. OpenConnect нұсқаулық беті бұл опцияны жоғалған байланысқа немесе жауап беруді тоқтатқан серіктеске кейінгі қайта әрекеттер үшін құжатталған 300 секундтық әдепкі мәнмен жазады, ал бұл сан бір жұмыс істеп тұрған клиент үшін мерзім, VPN қолжетімді болып қалатынының дәлелі емес. Ол сондай-ақ процесті тірі ұстау саясаты емес, және шатасудың көбі осы жерден басталады.

Үстіне екінші механизм отырғанда шатасу артады. Клиентті қайта іске қосатын қадағалаушы, шлюзге ping жіберетін тексеруші және кіріктірілген қайта әрекет терезесі бір ақауға жауап бере алады, содан кейін оқиға ешкім келістіре алмайтын үш уақыт желісін береді.

Қайта қосылу терезесі шын мәнінде нені шектейді

Қатынау желісі бірнеше секундқа жоғалып кетті деп елестетіңіз. Клиент байланыстың үзілгенін көреді немесе өлі серіктестің жауаптарын естуді тоқтатады және өзі сақтай алатын күйді ұстап, сессияны қайта орнатуға кіріседі. Әрекеттер шлюз қайта қабылдағанша немесе терезе таусылғанша жалғасады, ал таусылған терезе нөлдік емес шығумен аяқталады. Дәл сол шығу, таймаут мәні емес, өмірлік цикл иелігі процесті қадағалаушыға өтетін жер.

Терезе тексерушінің қаншалықты жиі іске қосылатыны туралы ештеңе айтпайды және аутентификацияны ұзарта алмайды. Егер шлюз сессияны кері қайтарса немесе тіркелгі енді жаңа екінші факторды талап етсе, ұзағырақ күту ескі сессияны қайта жарамды етпейді. Қайта әрекет тек жол қайта оралғанда, шлюз сессияны әлі танығанда және сұралатын тіркелгі деректері пайдалануға жарамды болғанда ғана сәтті болады, сондықтан бұл санды өміршеңдік аралығы емес, мерзім ретінде оқыңыз.

Терезе сонымен қатар ол жүріп жатқанда қолданбалардың не істейтінін реттемейді. Платформаға және ақаудың қаншалықты алыс кеткеніне байланысты клиент маршруттар әлі орнатылған кезде немесе олар алынып тасталғаннан кейін қайта қосылуы мүмкін. Сондықтан үзілістің ортасында берілген сұраныс жылдам сәтсіз болудың орнына таймаут біткенше ілулі қалады.

Қадағалаушының қайта іске қосуы мен клиенттің қайта әрекеттері екі қабат

Жұмыс істеп тұрған клиент өз терезесін жұмсасын, ал қызмет менеджері шығуға жауап берсін. systemd астында қайта іске қосу саясаты бар алдыңғы пландағы клиент дәл осы бөлісті береді: шектеулі кезеңге әрекеттер, содан кейін бір қайта іске қосу шешімі. Нәтиже — кейінірек те қайта құруға болатын бір уақыт желісі.

Фондық клиент пен интерфейсті көрмегенде басқа көшірмені іске қосатын тәуелсіз тексеруші — бұл дұрыс емес жұмыс істейтін үлгі. Сонда екі процесс те бір құрылғы түйіні, маршруттар және resolver параметрлері үшін таласады. Егер шынымен демон қаласаңыз, опцияны клиент нақты басталатын пәрмен жолына қойыңыз:

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)"

Қысқа үзіліс кезінде клиенттің шынымен қайта әрекет жасағанын, ерте шықпағанын және маршруттар мен resolver жазбаларының қайталаусыз қайтқанын растаңыз. Ұзағырақ үзіліс үшін таза шығуды және одан кейін дәл бір қайта іске қосуды растаңыз. Аутентификация сәтсіздігі үшін клиенттің оны қабылдамайтын шлюзге қарсы айналмайтынын растаңыз. pid жинақталмай, бір мәнге қайтатынын тексеретін тексеру қосыңыз.

Әдейі тоқтату үшін денсаулық URL қолжетімсіз болып қалуы, ал процесс төменде тұруы керек. Содан кейін циклды қолданба жағынан жабыңыз: сол сұраныс туннель жоқ кезде сәтсіз болуы және ол қайта оралғаннан кейін сіздің саясатыңыз күтетін бастау мекенжайынан сәтті болуы тиіс. Жасыл туннель белгішесі дәлел емес, бірақ орындалған сұраныс дәлел.