ServerAliveInterval-ը SSH-ի վրա VPN-ով․ ո՞ր ծայրն է ուղարկում փորձարկումը։

SSH-ի կապը կենդանի պահելու վերաբերյալ խորհուրդների մեծ մասը կանգ է առնում «ավելացրու ServerAliveInterval 30» արտահայտության վրա և դուրս է թողնում օգտակար մասերը։ Բանալի բառը հաճախորդի կողմի ժամաչափ է, որը գործարկվում է միայն այն ժամանակ, երբ ալիքը լուռ է եղել, այն հաշվում է անպատասխան փորձարկումները, ոչ թե վայրկյանները, և ապրում է մի ֆայլում, որտեղ հաղթում է առաջին համապատասխան արժեքը։ Սխալվեք այս երեք հատկություններում, և առողջ VPN նստաշրջանը միևնույն է կընկնի, մինչ դեռ մեռածը կմնա կախված։

Երկու ուղղությունները պատկանում են տարբեր դեմոնների

ServerAliveInterval-ը կարդում է ձեր ssh հաճախորդը։ ClientAliveInterval-ը կարդում է հեռավոր կողմի sshd-ն և փորձարկում է հակառակ ուղղությամբ՝ սերվերից հաճախորդ։ Դրանք նույնանուններ չեն և չեն համագործակցում, ուստի մեկի կարգավորումը որևէ ազդեցություն չի ունենում մյուս ծայրի վարքագծի վրա։ Դրանք իրար հետ շփոթելը սովորական պատճառն է, թե ինչու ուղղումը թվում է աշխատող մի հոսթում և ոչ՝ հաջորդում։

Երկուսն էլ ընդունում են զրո։ Զրոյի դեպքում հաճախորդը բնավ ոչինչ չի ուղարկում, իսկ սերվերի կողմում զրո ClientAliveCountMax-ը անջատում է այն անջատումը, որը հակառակ դեպքում կհետևեր անպատասխան ստուգումներին։

Ինչ է ապացուցում փորձարկումը և ինչ՝ ոչ

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

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

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

Հերթականությունն է որոշում, թե որ արժեքը կմնա

OpenSSH-ը կիրառում է առաջին արժեքը, որը ստանում է յուրաքանչյուր պարամետրի համար, ուստի կոնկրետ Host բլոկը պետք է հայտնվի ցանկացած ավելի լայն բլոկից առաջ, որը նույնպես կհամապատասխանի։ Տեղադրեք ձևանշանային լռելյայն արժեքները ֆայլի ներքևում, ոչ թե վերևում, և հիշեք, որ ավելի ներքև գտնվող Match բլոկը չի կարող վերացնել արդեն սահմանված արժեքը։ OpenSSH հաճախորդի կարգավորման տեղեկատուն ուղղակիորեն նշում է առաջին արժեքի կանոնը, և արժե այն մեկ անգամ կարդալ նախքան ընդհանուր կարգավորումը վերակազմակերպելը։

Հրամանի տողի ընտրանքները հաղթում են ֆայլին, ինչը ժամանակավոր փորձը դարձնում է էժան՝

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

Ինչ են անում keepalive-ները թունելի վրայով

Պարբերական երթևեկությունը խանգարում է վիճակային NAT-ի կամ ֆայրվոլի քարտեզագրման ժամկետի լրանալուն, ինչը իրական օգուտ է VPN-ում, որի դարպասը մի քանի րոպե հետո գցում է անգործ հոսքերը։ Յուրաքանչյուր 60 վայրկյանում եկող փորձարկումները թարմացնում են այդ քարտեզագրումը՝ առանց որևէ հավելվածային տվյալ կրելու։

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

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

Կարգավորման հաստատումը սկզբից մինչև վերջ

Սերվերում արտահանեք դեմոնի գործող կարգավորումը, փոխանակ ֆայլը կարդաք և գուշակեք, թե որ include-ը հաղթեց՝

sshd -T | grep -i clientalive

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

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