AnyConnect-ը կտրվում է տերմինալը փակելիս. սեսիաների ստուգումներ

Թունելը բաց է, դուք փակում եք ավելորդ տերմինալը, և VPN-ը ընկնում է հաճախորդում ոչ մի ստեղնասեղմում չանելով: Linux-ի AnyConnect հաճախորդում հաղորդված պատճառը սեսիաների հաշվառումն է, ոչ թե երթուղավորումը. հաճախորդը գրանցում է, թե որ մուտքի սեսիաներն էին գոյություն ունեցել թունելը բարձրանալու պահին, և դրանցից ցանկացածի ավարտը համարում է այն քանդելու պատճառ: Ստորև բերված ստուգումները կատարվում են հերթով, և առաջին ձախողվածը ձեզ ասում է՝ արդյոք դուք ընդհանրապես այս վարքագծի առջև եք: Հաճախորդի սովորական ելքում ոչինչ չի հիշատակում տերմինալ, դրա համար էլ առաջին բնազդը՝ մեղադրել concentrator-ին, սովորաբար վատնված ջանք է:

Մի սկսեք համակարգի ֆայլերը խմբագրելուց: Յուրաքանչյուր քայլ կա՛մ բացատրում է անկումը, կա՛մ հեռացնում է թեկնածու, և էժան քայլերն առաջինն են:

Առանձնացրեք սեսիայի անկումը հիմնական ցանցի անկումից

Նորից միացեք անմիջապես անջատումից հետո: Թունելը, որը վերադառնում է վայրկյանների ընթացքում, նույն ցանցում, առանց նոր հավատարմագրերի, մատնանշում է տեղական գործարկիչ, ինչպիսին փակված սեսիան է, և ոչ թե մեռած վերին կապուղի, Wi-Fi ռոումինգ կամ անգործության ժամկետ concentrator-ում. Թունելը, որը կախվում է Connecting-ի վրա կամ ձախողվում է մինչև ցանցը փոխելը, այլ հոդված է:

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

Ստուգեք, թե ինչ գրանցեց հաճախորդը միանալու պահին

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

Թվարկեք, թե ինչ կարող էր տեսնել հաճախորդը նախքան որևէ բան փոխելը:

who
w
last -n 10
sudo ls -l /run/utmp

who-ի յուրաքանչյուր տող utmp-ում օգտատիրոջ պրոցեսի գրառում է: Եթե ձեր սեսիան հայտնվում է երկու անգամ՝ մեկը գրաֆիկական մուտքի, մեկը տերմինալի համար, ապա երկու գրառումներն էլ գոյություն ունեին միանալու պահին, և երկուսն էլ թեկնածու են:

Հեռացրեք utmp-ից միայն ձեր սեփական գրառումը

Հրապարակված լուծումը ձեր օգտագործելիք սեսիան դարձնում է անտեսանելի utmp-ում մինչև հաճախորդի մեկնարկը: Փոքր C ծրագիրը անցնում է getutent()-ով, գտնում է այն գրառումը, որի ut_line-ը հավասար է ստանդարտ մուտքի TTY-ին, ապա վերագրում այդ գրառումը: Հերթականությունը դիտավորյալ է. setutent(), կարդալ գրառումը, պատճենել դրա ut_id-ը, դնել ut_type-ը DEAD_PROCESS, մաքրել օգտատիրոջ և տողի դաշտերը, գրել այն հետ pututline()-ով, ապա endutent():

Կոմպիլյացրեք այն, ապա գործարկեք որպես root այն shell-ից, որը կմեկնարկի հաճախորդը:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Ձախողման երկու եղանակ բացատրում են հաղորդումների մեծ մասը, թե գործիքը ոչինչ չի անում: Այն գործում է ստանդարտ մուտքին կցված TTY-ի վրա, ուստի առանց տերմինալի սկրիպտից կամ cron առաջադրանքից գործարկելը նրան ոչինչ չի թողնում համապատասխանեցնելու: Եվ /run/utmp սովորական օգտատերերի համար գրելի չէ, ուստի առանց root-ի գործարկումը լուռ ձախողվում է, եթե չստուգեք ելքի կարգավիճակը:

Ստուգեք, որ թունելը վերապրում է փակումը

Փորձարկեք մեխանիզմը՝ ենթադրելու փոխարեն: Միացեք այն սեսիայից, որը մտադիր եք պահել, բացեք երկրորդ տերմինալ, փակեք երկրորդը, ապա vpn state-ով և ինտերֆեյսների ցանկին նայելով հաստատեք, որ թունելը դեռ բաց է: Եթե թունելը վերապրեց, գործարկիչը կոնկրետ սեսիայի տեսակ էր, ոչ թե բոլոր սեսիաները, և դուք գտել եք այն սեսիան, որը պետք է բաց մնա:

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

Երբ utmp-ի վերագրումը սխալ պատասխան է

utmp ընդհանուր հաշվառում է, ոչ թե մասնավոր աղյուսակ: Դեռ կենդանի սեսիայի գրառումը վերագրելը ստիպում է, որ who-ը, w-ը և որոշ աուդիտի գործիքներ այն թերագնահատեն, և ծրագիրը, որը հետագայում փակում է նույն գրառումը, կարող է ամբողջությամբ ձախողվել: Սահմանափակեք գործիքը ձեր սեփական սեսիայով, պահպանեք բնօրինակ ֆայլի պատճենը և մի դարձրեք այն բեռնման ծառայություն, որը ջնջում է յուրաքանչյուր գրառում:

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

Մինչ տոմսը փակելը, գրանցեք, թե որ սեսիային էր հաճախորդը հետևում թունելը բարձրանալու պահին: Հենց այդ մեկ տողն է դարձնում խորհրդավոր անջատումը վերարտադրելի պայման մեքենայի մոտ հաջորդ մարդու համար: