WireGuard-ը աշխատում է միայն այն բանից հետո, երբ սերվերն ուղարկի՝ վերջնակետի իմացություն
Ուղղությունից կախված հաջողությունը սովորաբար նշանակում է, որ մի կողմը երբեք չի իմացել մյուսի հասցեն։ Համեմատե՛ք վերջնակետերը, ապա ստուգե՛ք՝ արդյոք թարգմանության քարտեզագրումը լրացել է։
Թունելը կարծես թե աշխատում է միայն այն բանից հետո, երբ սերվերը նախ ինչ-որ բան է ուղարկում։ Սկսե՛ք հաճախորդից, և ոչինչ չի պատահում, սպասե՛ք մի քանի վայրկյան, նորից փորձե՛ք, և այն հաջողվում է։ Սովորական ախտորոշումը կոտրված NAT-ն է, և սովորական ախտորոշումը սխալ է։ Ինչ փոխվել է՝ մի կողմը իմացել է, թե որտեղ է ապրում մյուսը։
Վերջնակետի իմացություն, ոչ թե հասանելիություն
WireGuard-ի կողմը ձեռքսեղմում չի սկսի, քանի դեռ չի իմանում, թե ուր ուղարկել այն։ Կազմաձևը դա տալիս է որպես հասցեի և պորտի վերջնակետ, և ընթացիկ վիճակը հետևում է այն վերջնակետին, որին այն այժմ հավատում է։
wg show տպում է այդ պատկերի երկու կողմերը, և ելքում վերջնակետ չունեցող կողմը ոչինչ չի կարող սկսել, որքան էլ ճիշտ լինեն նրա հանրային բանալին և թույլատրված նախածանցերը։ Համեմատե՛ք հաճախորդի պատկերացումը սերվերի հետ նախքան որևէ կանոն փոխելը, որովհետև նրանք հաճախ չեն համաձայնում, թե ով ինչ գիտի։
Ինչպես է կողմը սովորում վերջնակետը
WireGuard-ը դիտավորյալ լուռ է։ Երբ ճիշտ նույնականացված փաթեթը գալիս է մի հասցեից, որը կողմը չէր սպասում, իրականացումը թարմացնում է այդ կողմի վերջնակետը նոր աղբյուրի վրա, և հենց այդպես է աշխատում ռոումինգը ցանցերը փոխող նոթբուքի վրա։ Այդ վարքը բացատրում է ուղղությունից կախվածությունը՝ եթե սերվերն առաջինն է ուղարկում, և նրա փաթեթը հասնում է հաճախորդին, հաճախորդը իմանում է սերվերի ընթացիկ հասցեն և կարող է պատասխանել։ Մինչ այդ նա ուղարկելու տեղ չունի։ Մեխանիզմը նույնականացված ռոումինգ է, այլ ոչ թե առաջին օգտագործման վստահության կարճուղի, որովհետև փաթեթը պետք է վավեր լիներ մինչև վերջնակետի տեղաշարժը։
wg-ի գործիքների փաստաթղթերը նկարագրում են այդ թարմացումը, և արժե մեկ անգամ կարդալ, եթե պատրաստվում եք դրա շուրջ նախագծել։
Վիճակ պահող թարգմանությունն ավելացնում է իր ուղղությունը
Երբ UDP-ն անցնում է թարգմանող դարպասով, դարպասը վիճակ է ստեղծում իր տեսած առաջին փաթեթի համար։ RFC 4787-ը նկարագրում է այդ վարքը և այն ժամկետները, որոնք ի վերջո հեռացնում են քարտեզագրումը։ Անգործ քարտեզագրումը լրանում է, և հեռավոր կողմից եկող մուտքային փաթեթն այնուհետև դարպասը դեն է նետում մինչև հոսթին հասնելը։ Ամբողջ առավոտ աշխատած թունելը դադարում է պատասխանել կեսօրից հետո հենց այս պատճառով։
Սա երկրորդ և անկախ մեխանիզմն է, որն առաջացնում է նույն ուղղորդված ախտանիշը։ Ե՛վ վերջնակետի իմացությունը, և՛ թարգմանության վիճակը պետք է ճիշտ լինեն, և մեկի ուղղումը չի ուղղում մյուսը։
Կազմաձևե՛ք այն ուղղությունը, որն իսկապես ուզում եք
Այն հաճախորդի համար, որը պետք է սկսի կապը, տեղադրե՛ք սերվերի վերջնակետը հաճախորդի կողմերի բաժնում և թողե՛ք այն այնտեղ։ Սերվերի առաջին ուղարկելու վրա հույս դնելը հույս դնելն է երթևեկության հերթականության պատահականության վրա, որը կփոխվի հանգիստ ցանցում։ Կազմաձևը պետք է հայտարարի նախատեսված ուղղությունը, ոչ թե հայտնաբերի այն։
Թարգմանության հետևում գտնվող այն կողմի համար, որը պետք է մնա հասանելի, միացրե՛ք մշտական keepalive այդ կողմում։ Յուրաքանչյուր 25 վայրկյանը մեկ keepalive-ը սովորական մեկնարկային արժեքն է, և դրա նպատակը քարտեզագրումը բաց պահելն է, ոչ թե թունելը փորձարկելը։ Ընտրե՛ք մեկ կողմ, որը կկրի այն, որովհետև երկու կողմերում միացնելը կրկնապատկում է երթևեկությունը և մատյանի աղմուկը՝ չբարելավելով արդյունքը։
Համեմատե՛ք վիճակը մինչև ձգանը և դրանից հետո
Գրանցե՛ք երկու տեսքերը ձախողման պահին, ապա նորից այն բանից հետո, երբ սերվերն ուղարկի։ Առաջին հրամանը ցույց է տալիս վերջնակետերը և ձեռքսեղմման տարիքը։ Երկրորդը ցույց է տալիս՝ արդյոք պորտի համար թարգմանության գրառում կա։ Գրանցումը ցույց է տալիս, թե որ ուղղությունն է իրականում անցել լարով, և երթուղու ստուգումը հաստատում է, որ հաճախորդն այդ երթևեկությունը բոլորովին այլ տեղ չի ուղարկում։
wg show conntrack -L -p udp 2>/dev/null | grep 51820 tcpdump -ni any -c 20 'udp port 51820' ip route get 198.51.100.7
Գրե՛ք վերջնակետի սյունակը և թարգմանության գրառումը միասին։ Վերջնակետ չունեցող կողմը և քարտեզագրում չունեցող դարպասը երկու տարբեր խափանումներ են։ Դրանցից միայն մեկն է ուղղվում keepalive-ով։