VPN-ը կտրվում է, երբ էկրանը մթնում է՝ կողպո՞ւմ, մարո՞ւմ, թե՞ քուն
Կողպված նստաշրջանը, մարած էկրանը և քնի մեջ գտնվող մեքենան երեք տարբեր իրադարձություններ են։ Համաձայնեցրեք դրանք journalctl-ի հետ, նախքան VPN-ի միացվածության պահպանման մեխանիզմին մեղադրելը։
Երբ ինչ-որ մեկն ասում է, թե VPN-ը մահացել է, երբ էկրանը մթնել է, առաջին օգտակար հարցն այն է, թե երեք իրադարձություններից որն է իրականում տեղի ունեցել՝ նստաշրջանը կողպվել է, վահանակը մարել է, թե ամբողջ մեքենան քնել է։ Դրանք առանձին մեխանիզմներ են առանձին ժամաչափերի վրա, և դրանցից միայն մեկը կարող է ընդհանրապես կանխել գործընթացի ժամանակացույցը։ Անցեք ստորև նշված ստուգումները հերթականությամբ։ Կանգ առեք առաջինի վրա, որը պատասխանում է հարցին, որովհետև դրանից հետո յուրաքանչյուր ստուգում այլ բանի է պատասխանում։
Առաջին ստուգում՝ առանձնացրեք կողպումը մարումից և քնից
Կողպումը փոխում է, թե ով կարող է օգտվել նստաշրջանից՝ կոմպոզիտորը շարունակում է նկարել, ցանցային կույտը շարունակում է աշխատել, և VPN հաճախորդը ոչինչ չի նկատում։ Էկրանի մարումը անջատում է վահանակը անգործության ինտերվալից հետո և մեքենան թողնում ամբողջովին արթուն։ Քունը կանգնեցնում է պրոցեսորները, այսինքն՝ օգտատիրոջ տարածության ոչ մի գործընթաց չի ժամանակացվում, ուստի ոչ մի պահպանման ազդանշան չի կարող աշխատել, որքան էլ կարճ սահմանեք ինտերվալը։
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Այդ աղյուսակն է պատճառը, որ «էկրանը մթնեց» արտահայտությունը ախտորոշում չէ։ Հինգ րոպեին մարելու և երեսունին քնելու կարգավորված սեղանադիր համակարգիչը վեցերորդ րոպեին ցույց կտա մուգ էկրան՝ լրիվ առողջ թունելով։ Երեսուներորդ րոպեի խափանումը այլ իրադարձություն է՝ այլ լուծումով, և երկուսն էլ սենյակի մյուս ծայրից նույնն են երևում։
Երկրորդ ստուգում՝ էներգիայի և ցանցի իրադարձությունները դրեք մեկ ժամանակագրության վրա
Կարդացեք մատյանը սահմանափակ պատուհանի համար, ոչ թե ամբողջ բեռնման, և ներառեք ինչպես մուտքի կառավարիչը, այնպես էլ միացման տերը՝
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listԱռաջին հրամանը ցույց է տալիս քնի հարցումները, արթնացումը և դրանց հաջորդած ցանցային անցումները։ Երկրորդը ցույց է տալիս, թե ինչն է հիմա պահում արգելափակող կողպեքը, ինչը ձեզ ասում է՝ ինչ-որ բան միտումնավոր արգելափակո՞ւմ է քունը և որ ծրագիրն է դա։ Ուղղեք միավորների անունները, եթե ձեր միացման տերը NetworkManager-ը չէ, և հիշեք, որ մեկ այլ օգտատիրոջ միավոր կամ համակարգի մատյան կարդալը կախված է տեղական քաղաքականությունից։
Բացակայող տողը բացասական արդյունք չէ։ Եթե ընտրված միավորի մատյանը ձեր հաշվին տեսանելի չէ, քնի գրառման բացակայությունը ոչինչ չի ապացուցում, և դատարկ զտիչից «այն երբեք չի քնել» եզրակացնելը այն ուղին է, որով մարդիկ մեկ շաբաթ անցկացնում են պահպանման ազդանշանները կարգաբերելով։
Երրորդ ստուգում՝ եթե այն քնել է, որոշեք՝ դա միտումնավոր էր
Հենց քնի անցումը հայտնվում է ժամանակագրության վրա, հարցը փոխվում է «ինչու VPN-ը կոտրվեց»-ից «արդյոք մեքենան ընդհանրապես պետք է քնե՞ր»։ Դյուրակիր համակարգչում պատասխանը հաճախ այո է, և թունելի ընդհատումը սպասված վարք է, որից հաճախորդը պետք է վերականգնվի արթնանալիս։ Աշխատանքային կայանում, որը պետք է հասանելի մնա, փոխելու ենթակա բանը քնի քաղաքականությունն է։ Որոշելը, թե այս երկու մեքենաներից որին եք նայում, մեկ հարց է պահանջում, և դա այն հարցը չէ, որին մատյանը կարող է պատասխանել ձեր փոխարեն։
Փոխեք այն մուտք գործած նստաշրջանին պատկանող կառավարման տարրերով, կամ ադմինիստրատորի կողմից աջակցվող մեխանիզմով, եթե պահանջը ամբողջ մեքենայի համար է։ Էկրանի կառավարչի կարգավորումը խմբագրելը, երբ մուտք եք գործել այլ հաշվով, նույն գործողությունը չէ և կթվա, թե աշխատել է մինչև հաջորդ նստաշրջանի սկիզբը։ Էներգիայի կառավարումը լրիվ անջատելը լայն առաջին արձագանք է, որը մարտկոցի ժամկետ արժենում է և թաքցնում քաղաքականության իսկական հարցը։
Չորրորդ ստուգում՝ եթե այն արթուն մնաց, նայեք ցանցին և հաճախորդին
Թունելը կորցրած արթուն մեքենան ունի երեք պատմություններից մեկը՝ հասանելիության ցանցն ընկել է, VPN հաճախորդը կանգնել կամ վերագործարկվել է, կամ սերվերի կողմը թույլ է տվել, որ միացումը սպառվի, մինչ հաճախորդը շարունակում էր հավատալ, որ միացած է։ Համեմատեք հիմնական կապի իրադարձության ժամանակադրոշմերը թունելի իրադարձության հետ և եղեք ճշգրիտ, թե որն առաջ եկավ։
Ապա փորձարկեք վերականգնման ուղին առանձին սկզբնական նստաշրջանից։ Վերականգնված թունելով նոր հարցումը կարող է հաջողվել, մինչ ընդհատումից առաջ բացված երկարատև հավելվածային նստաշրջանը մնում է կոտրված, քանի որ հավելվածը պահում է հնացած բնիկ կամ պահված հասցե։ Դա հավելվածի խնդիր է, ոչ թե ապացույց, որ թունելը չվերադարձավ։
Ինչ է պարունակում օգտակար զեկույցը
Գրեք հաջորդականությունը ժամանակադրոշմերով և տերերով՝ երբ նստաշրջանը կողպվեց, երբ էկրանը մարեց, արդյոք քնի հարցում գրանցվեց, երբ կապն ընկավ և վերադարձավ, երբ թունելը փոխեց վիճակը և ինչ արեց հավելվածն իրականում։ Յուրաքանչյուր կետ ունի տեր, այնպես որ յուրաքանչյուր կետ կարելի է հանձնել ճիշտ մարդուն՝ Linux-ի մասին ընդհանուր բողոք դառնալու փոխարեն։
Եթե այդ տողերից որևէ մեկը բացակայում է, դա չափելու հաջորդ բանն է, ոչ թե փոխելու հաջորդ բանը։ Բացվածքով ժամանակագրությունն ավելի տեղեկատվական է, քան ենթադրության վրա արված կարգավորման փոփոխությունը։