Որքա՞ն պետք է OpenConnect-ը շարունակի նորից փորձել կտրված VPN-ը։

--reconnect-timeout պատասխանում է մեկ նեղ հարցի՝ թունելն ընկնելուց հետո որքա՞ն է այս հաճախորդ-գործընթացը շարունակում փորձել, մինչև հանձնվի և դուրս գա։ OpenConnect-ի ձեռնարկի էջը գրանցում է այդ ընտրանքը փաստաթղթավորված 300 վայրկյան լռելյայն արժեքով՝ կորցրած կապին կամ պատասխանելը դադարեցրած գործընկերոջը հաջորդող կրկնափորձերի համար, և թիվը մեկ աշխատող հաճախորդի վերջնաժամկետ է, ոչ թե ապացույց, որ VPN-ը մնում է հասանելի։ Այն նաև գործընթացը կենդանի պահելու քաղաքականություն չէ, և հենց այստեղից է սկսվում շփոթության մեծ մասը։

Շփոթությունը մեծանում է, երբ վերևում նստում է երկրորդ մեխանիզմ։ Հաճախորդը վերագործարկող հսկիչը, դարպասը pingող ստուգիչը և ներկառուցված կրկնափորձի պատուհանը կարող են բոլորը արձագանքել մեկ խափանման, և միջադեպն այնուհետև տալիս է երեք ժամանակագիծ, որոնք ոչ ոք չի կարող հաշտեցնել։

Ինչն է իրականում սահմանափակում վերակապակցման պատուհանը

Պատկերացրեք, որ մուտքի ցանցը մի քանի վայրկյան անհետանում է։ Հաճախորդը տեսնում է կապի անկումը կամ դադարում է լսել մեռած գործընկերոջ պատասխանները և սկսում է վերականգնել նստաշրջանը՝ պահելով այն վիճակը, ինչ կարող է։ Փորձերը շարունակվում են, մինչև դարպասը նորից ընդունի կամ պատուհանը սպառվի, և սպառված պատուհանը ավարտվում է ոչ զրոյական ելքով։ Հենց այդ ելքն է, ոչ թե ժամկետի արժեքը, այն տեղը, որտեղ կենսացիկլի սեփականությունը անցնում է գործընթացը հսկողին։

Պատուհանը ոչինչ չի ասում այն մասին, թե որքան հաճախ է աշխատում ստուգիչը, և այն չի կարող երկարացնել նույնականացումը։ Եթե դարպասը չեղարկել է նստաշրջանը, կամ հաշիվն այժմ պահանջում է թարմ երկրորդ գործոն, ավելի շատ սպասելը հին նստաշրջանը նորից վավեր չի դարձնի։ Կրկնափորձը հաջողվում է միայն այն ժամանակ, երբ ուղին վերադառնում է, դարպասը դեռ ճանաչում է նստաշրջանը, և պահանջվող հավատարմագրերը մնում են օգտագործելի, ուստի թիվը կարդացեք որպես վերջնաժամկետ, ոչ թե կենսունակության միջակայք։

Պատուհանը նաև չի կարգավորում, թե ինչ են անում հավելվածները, քանի դեռ այն ընթանում է։ Կախված հարթակից և նրանից, թե որքան հեռու գնաց խափանումը, հաճախորդը կարող է վերակապակցվել, երբ երթուղիները դեռ տեղադրված են, կամ դրանք հեռացնելուց հետո։ Այդ պատճառով ընդհատման կեսին տրված հարցումը սովորաբար կախված է մնում մինչև ժամկետի լրանալը՝ արագ ձախողվելու փոխարեն։

Հսկիչի վերագործարկումները և հաճախորդի կրկնափորձերը երկու շերտ են

Թող աշխատող հաճախորդը ծախսի իր պատուհանը, և թող ծառայության կառավարիչն արձագանքի ելքին։ 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-ը պետք է մնա անհասանելի, իսկ գործընթացը՝ իջեցված։ Ապա փակեք հանգույցը հավելվածի կողմից, քանի որ նույն հարցումը պետք է ձախողվի, քանի դեռ թունելը բացակայում է, և պետք է հաջողվի այն վերադառնալուց հետո՝ այն աղբյուրի հասցեից, որը ձեր քաղաքականությունը սպասում է։ Կանաչ թունելի պատկերակը ապացույց չէ, բայց ավարտված հարցումը ապացույց է։