WireGuard-ը ձախողվում է անգործությունից հետո. նախ ստուգեք ուղղությունը

Ցանկացած կարգավորման փոփոխությունից առաջ չորս հարց է լինում. աշխատում է արդյոք նույն ռեսուրսը, երբ հաճախորդը ակտիվ է, որքան տևեց անգործության շրջանը, քնե՞ց սարքը, թե՞ փոխեց ցանցը, և արդյոք խափանումը հայտնվում է միայն հակառակ կողմի սկսած երթևեկության մեջ։ Պատասխանները ժամկետանց NAT քարտեզագրումը տարբերում են քնած ռադիոյից և հնացած հավելվածից։ Դրանք նաև ասում են՝ արդյոք keepalive-ը ընդհանրապես տեղին է։ Սկսեք ուղղությունից, որովհետև այն արժե մեկ հրաման և վերացնում է հնարավոր պատճառների կեսը։

Ո՞ր ուղղությունն է ձախողվում։

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

Նշեք, թե որքան տևեց հանդարտ շրջանը և արդյոք սարքը քնեց կամ միջանկյալ անցավ այլ ցանցի։ Այս երկու փաստերը փոխում են ախտորոշումը ցանկացած կարգավորումից առաջ։

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Գործարկեք այդ երեքը հանդարտ շրջանից առաջ և հետո, որովհետև յուրաքանչյուրը պատասխանում է հարցի տարբեր մասին։ Չշարժված handshake-ի ժամադրոշմը ասում է, որ կողմերը դադարել են խոսել, մինչդեռ փոխված վերջնակետը ասում է, որ քարտեզագրումը տեղափոխվել է, այլ ոչ թե մահացել։ Փոխանցման հաշվիչները ցույց են տալիս՝ ընդհանրապես ինչ-որ բան հասե՞լ է, և դա է տարբերությունը հնացած քարտեզագրման և լուռ հավելվածի միջև։ Գրեք թվերը երկու կետերում էլ, որովհետև համեմատությունն է ապացույցը։

Քուն, ռադիո և հավելվածի վիճակ

Հեռախոսում կամ նոթբուքում քնած սարքը կարող է ամբողջությամբ կորցրել ցանցային հասանելիությունը, և keepalive-ը չի կարող վերականգնել անջատված ռադիոն կամ ավարտել չբավարարված captive portal-ը։ Բջջային հարթակները քաղաքականությամբ դադարեցնում են ֆոնային աշխատանքը, ուստի պարբերական երթևեկությունը շարունակվում է, թե ոչ՝ կախված է հարթակից և նրանից, ինչ հավելվածը պայմանավորվել է նրա հետ։ Պահված կապը երրորդ դեպքն է և ամենամոլորիչը, որովհետև թունելի վերադարձը նույնը չէ, ինչ հավելվածի նորից միանալը դրան։

Անգործության շրջանից հետո նորից բացեք հավելվածը՝ փոխարենը չվստահելով բաց մնացած ներդիրին։ Եթե նոր հարցումը հաջողվում է այնտեղ, որտեղ հին նստաշրջանը ձախողվել էր, թունելը երբեք խնդիրը չի եղել։

Ինչ է իրականում անում keepalive-ը

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

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

Սպասեք այն միջակայքին, որ նախկինում ձախողվում էր

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

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