Շտկել VPN-ի անջատումները անգործության ժամանակ: ստուգաթերթ Wi-Fi-ի էներգախնայողության համար
Անցեք VPN-ի անգործության անջատումները հերթով: հաստատեք ժամանակը, առանձնացրեք ռադիոն թունելից, կարդացեք էներգախնայողության իրական վիճակը, ապա փոխեք մեկ կարգավորում և նորից ստուգեք։
Ձեր թունելը մահանում է այն բանից հետո, երբ նոութբուքը որոշ ժամանակ մնում է անձեռնմխելի, և վերադառնում է այն պահին, երբ դիպչում եք թաչփադին։ Այս օրինաչափությունը ցույց է տալիս, որ անլար կապը մտնում է էներգախնայողության ռեժիմ, ոչ թե VPN դարպասը մերժում է ձեր հավատարմագրերը։ Նույն պրոֆիլով զբաղված առավոտը դրա ապացույցն է՝ թունելը ապրում է, քանի դեռ տրաֆիկը հոսում է, և ընկնում է հենց ռադիոն լռում է։ Անցեք ստորև բերված ստուգումները հերթով, կանգ առեք առաջին ձախողվածի վրա և միայն դրանից հետո փոխեք մեկ կարգավորում։
Առաջին ստուգում: արդյո՞ք անջատումը հետևում է անգործությանը։
Սկսեք կապը ապացուցելով, ոչ թե ենթադրելով։ Գրանցեք վերջին ուղարկված փաթեթի պատի ժամացույցի ժամանակը, այն պահը, երբ հաճախորդը հայտնել է թունելի անկման մասին, և արդյո՞ք էկրանն այդ ընթացքում անջատվել է։ Եթե բացը ամեն անգամ նույնն է, ապա խնդիրը անգործության ուղու վրա է; եթե անջատումները պատահական են ակտիվ օգտագործման ընթացքում, անցեք հինգերորդ ստուգմանը։
Էժան փորձարկում, որի չեղարկումը ոչինչ չարժե: քսան րոպե ուղարկեք հավասարաչափ ցածր արագության ping ձեր դարպասին և մեքենան թողեք մենակ։ Եթե թունելը դիմանա ամբողջ ընթացքում, մշտական փոքր տրաֆիկը քողարկում է ախտանիշը՝ փոխարենը շտկելու, ինչը դեռ օգտակար ապացույց է։ Ես այդ ping-ի արտածումը պահում եմ սևագրային տերմինալում և հետո համեմատում հաճախորդի մատյան հետ, որովհետև երկու ժամացույցները հազվադեպ են համընկնում։
Երկրորդ ստուգում: միայն VPN տրաֆի՞կ է։
Նախքան թունելին մեղադրելը, պարզեք՝ կապն ինքնին դեռ օգտագործելի՞ է։ Մինչ թունելը մեռած է, բայց էկրանը դեռ անջատված, փորձեք հասնել մուտքի կետի հասցեին և հանրային հոսթին IP-ով։ Եթե սովորական ping-ն էլ ձախողվի, ռադիոն կամ մուտքի կետը ձեզ գցել են, և VPN հաճախորդը միայն դիտորդ է։
Եթե սովորական տրաֆիկը հոսում է, մինչ թունելը լուռ է, կապը առողջ է, և խնդիրը հենց թունելի ժամաչափերի մեջ է կամ այն բանում, թե ինչպես է հաճախորդը վարվում վերսկսման հետ։ Սրանք երկու տարբեր ուղղումներ են, ուստի չբացակայեք այս քայլից։ Նոութբուքի վրա, որտեղ և՛ Wi-Fi, և՛ Ethernet կա, անջատեք մալուխը և կրկնեք անգործության փորձարկումը: լարային Ethernet-ում անհետացող անգործության անջատումը ուժեղ ապացույց է անլար շերտի օգտին։
Երրորդ ստուգում: կարդացեք էներգախնայողության վիճակը
Աշխատասեղանների մեծ մասը ձեզ տալիս է նշիչ, բայց նշիչը այն վիճակը չէ, որում գտնվում է դրայվերը։ Նախ կարդացեք դրայվերի սեփական հաշվետվությունը, ապա որոշեք։ mac80211-ով Linux-ում ինտերֆեյսը պատասխանում է ուղղակիորեն:
iw dev wlan0 get power_save # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnectԵրկրորդ հրամանը փորձարկում է, ոչ թե ուղղում։ Այն չի դիմանում անջատմանը, քնին կամ վերաբեռնմանը, ինչը դարձնում է այն վարկածը ստուգելու մաքուր միջոց՝ առանց մշտական փոփոխություններ թողնելու։
Windows-ում powercfg /q SCHEME_CURRENT տպում է ակտիվ սխեման, և անլար ադապտերի ենթածառը ցույց է տալիս՝ հնարավո՞ր է ադապտերին հրահանգել էներգիա խնայել; նույն ընտրությունը կա նաև Device Manager-ում՝ ադապտերի էներգիայի կառավարման ներդիրում։ macOS-ում ինտերֆեյսի համար 802.11 էներգախնայողությունը ձեզ չի ցուցադրվում, ուստի փոխարենը նայեք pmset -g քնի և սպասման վարքագծին։ Այնտեղ խափանումը սովորաբար պարզվում է, որ քնի և արթնացման ուղին է, այլ ոչ թե ռադիոյի անգործության վարքագիծը։
Չորրորդ ստուգում: փոխեք մեկ բան, ապա նորից փորձարկեք
Փոխեք ուղիղ մեկ փոփոխական յուրաքանչյուր գործարկման համար և կրկնեք նույն ծանրաբեռնվածությունը։ Եթե թունելը հիմա դիմանում է մեկ ժամ անգործության՝ անջատված էներգախնայողությամբ, դուք իրական բան սովորեցիք։ Եթե այն դեռ ընկնում է, վերադարձրեք փոփոխությունը մինչև հաջորդ գաղափարը փորձարկելը, այլապես կմնաք երեք համընկնող կարգավորումներով և առանց գաղափարի, թե որն է կարևոր։
Կապը կենդանի պահելը մյուս անկախ փոփոխականն է, և այն անընդհատ շփոթում են էներգախնայողության հետ։ WireGuard-ի PersistentKeepalive = 25 տաք է պահում NAT-ի քարտեզագրումը;OpenVPN երկու ծայրերում keepalive և ping-restart օգտագործում է։ Երկուսն էլ տրաֆիկ են ստեղծում այլապես լուռ թունելում, ուստի կապը կենդանի պահելը, որը կարծես շտկում է անջատումը, կարող է թաքցնել ռադիոյի խնդիրը՝ փոխարենը լուծելու։ Փորձարկեք դրանք առանձին՝ մեկ առ մեկ:
[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25Հինգերորդ ստուգում: երբ ռադիոն անմեղ է
Եթե անգործության անջատումները շարունակվում են անջատված էներգախնայողությամբ և միացված կենդանի պահմամբ, նայեք նոութբուքից դուրս։ Մուտքի կետերը և տնային երթուղիչները ժամկետանց են դարձնում անգործ NAT-ի կամ սեսիայի գրառումները իրենց իսկ գրաֆիկով, և VPN սերվերը կարող է գցել առանց տրաֆիկի սեսիան։Մեկ SSID կիսող մուտքի կետերի միջև ռոումինգը նույնպես կարող է վերակայել կապը՝ առանց հաճախորդի դա հստակ ասելու։
Ապա համեմատեք նույն ցանցում նույն անգործության փորձարկումը կատարող երկրորդ սարքի հետ։ Երկու սարք, որոնք ընկնում են նույն միջակայքում, ուղու կամ սերվերի պատմություն է; մեկ սարք, որ ընկնում է, տեղական դրայվերի կամ էներգիայի պատմություն է։ Այդ համեմատությունը տասը րոպե արժե և փրկում է ձեզ սխալ կարգավորումը վերաշարադրելուց։
Նախքան այն մշտական դարձնելը
Որոշեք, թե ինչ եք պատրաստ պահել։ Յուրաքանչյուր պրոֆիլի համար սցենարը, որը անջատում է էներգախնայողությունը միայն այն ցանցերում, որտեղ տեսել եք անջատումը, պաշտպանելի է։ Համընդհանուր կարգավորումը, որը անջատում է ամեն ինչ և վճարվում է մարտկոցի կյանքով յուրաքանչյուր ցանցում, սովորաբար ոչ։
- Գրանցեք էներգախնայողության սկզբնական արժեքը սցենարի կողքին, որպեսզի այն հնարավոր լինի վերականգնել։
- Կրկնեք անգործության փորձարկումը յուրաքանչյուր դրայվերի կամ հաճախորդի թարմացումից հետո; լռելյայն արժեքները փոխվում են։
- Խնդիրը հաղորդելիս ping-ի մատյանը և հաճախորդի մատյանը պահեք միասին։
- Եթե երկրորդ քայլը ձախողվել է, դադարեցրեք VPN-ի կարգավորումները փոխելը և ընդունեք այն որպես կապի տեղական խափանում։
Եթե անում եք միայն մեկ բան, արեք երկրորդ ստուգումը։ Այն է որոշում՝ արդյո՞ք այս ցանկի մնացած մասը ձեզ առնչվում է ընդհանրապես, և հենց այդ քայլն են մարդիկ բաց թողնում, երբ արդեն որոշել են, որ պատասխանը էներգախնայողությունն է։