WireGuard հանգույցն անհասանելի է, մինչ մյուսն աշխատում է. ստուգաթերթ

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

Քայլ 1: Գրեք այն ուղին, որը պետք է անցնի փաթեթը

Նույն հանգույցի վրա գտնվող երկու հաճախորդներ ինքնաբերաբար չեն հասնում միմյանց։ Հանգույցի և ճառագայթների ձևավորման դեպքում սերվերը փաթեթը ստանում է wg0-ի վրա և պետք է այն նորից ուղարկի wg0-ից դեպի մյուս հանգույցը, ինչը պահանջում է IP փոխանցում և փոխանցման կանոն։ Ուղիղ հանգույց-հանգույց ձևավորման դեպքում յուրաքանչյուր կողմին պետք է մյուսի վերջնակետը և մյուսի թունելի հասցեն AllowedIPs-ի ներսում։ Որոշեք, թե որ ձևավորումն եք վրիպազերծում, նախքան որևէ կոնֆիգուրացիա կարդալը։

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

Քայլ 2: Համեմատեք AllowedIPs-ը երկու կողմում, ոչ միայն մեկում

WireGuard-ը AllowedIPs-ը օգտագործում է և՛ որպես երթուղային աղյուսակ, և՛ որպես մուտքի ցանկ։ Ուղարկելիս նպատակակետի հասցեն փնտրվում է հանգույցի AllowedIPs-ի մեջ՝ թունելն ընտրելու համար, իսկ ստանալիս ներքին աղբյուրի հասցեն պետք է ընկնի ուղարկող հանգույցի AllowedIPs-ի ներսում, հակառակ դեպքում փաթեթը դեն է նետվում։ Ցանկացած կողմում բացակայող միջակայքը տալիս է նույն ախտանիշը՝ տրանսպորտն աշխատում է, բեռը անհետանում է։

Կարդացեք կենդանի վիճակը, ոչ թե ֆայլը, որովհետև վերաբեռնումը կարող էր լուռ ձախողվել՝ sudo wg show wg0 allowed-ips։ Սերվերի վրա ձախողված հանգույցի գրառումը պետք է պարունակի դրա թունելի հասցեն, օրինակ՝ 10.90.0.3/32։ Հաճախորդի վրա սերվեր-հանգույցի գրառումը պետք է պարունակի այն նպատակակետը, որը դուք փորձարկում եք՝ լինի դա հանգույցի թունելի հասցեն, թե հեռավոր ենթացանցը։ Համընկնող միջակայքերը որոնումը դարձնում են երկիմաստ և կարող են ընտրել ձեր չուզած հանգույցը, ուստի դրանք առանձին պահեք։

Քայլ 3: Ստուգեք ներքին աղբյուրի հասցեն

Այն հաճախորդը, որը 10.90.0.3-ը երթուղավորում է wg0-ով, բայց փաթեթները ուղարկում է իր Wi-Fi հասցեից, կմերժվի ստացողի կողմից, որովհետև աղբյուրը չի համապատասխանում հանգույցի AllowedIPs-ին։ Հաստատեք, թե ինչն է իրականում ընտրում միջուկը ip route get 10.90.0.3 from 10.90.0.2-ով, և հաստատեք թունելի ինտերֆեյսին տրված հասցեն ip -brief addr show wg0-ով։

Ընդունող Linux հոսթում հակադարձ ուղու զտումը երկրորդ դարպասն է։ Վերադարձի երթուղին ունեցող ինտերֆեյսի վրա խիստ rp_filter-ը կարող է դեն նետել թունելային տրաֆիկը, որի վերադարձի ուղին չի համապատասխանում այն ինտերֆեյսին, որով այն ժամանել է։ Ստուգեք փաստացի արժեքը նախքան այն անջատելը, քանի որ շատ տոպոլոգիաներում ճիշտ լուծումը երթուղին է, ոչ թե թուլացված զտիչը։

Քայլ 4: Վերանայեք հանգույցի փոխանցումը և վերադարձի ուղին

Եթե հանգույցը պետք է փոխանցի հանգույցների միջև, միջուկին անհրաժեշտ է net.ipv4.ip_forward=1, և հրադարակը պետք է ընդունի փոխանցված հոսքը՝ մուտք wg0-ով, ելք wg0-ով, ուղարկողի թունելի հասցեից դեպի ստացողի հասցեն։ Հաճախակի ձախողում է մուտքի կանոնը, որն ընդունում է UDP 51820, բայց փոխանցման կանոն չկա], ուստի ձեռքսեղմումը հաջողվում է, իսկ բեռը մահանում է։ Թվարկեք գործող կանոնները sudo nft list ruleset-ով կամ ձեր հրադարակի կառավարչի համապատասխան տարբերակով։

Այնուհետև ստուգեք պատասխանը։ Նպատակակետ հոսթը պետք է ունենա վերադարձի ուղի դեպի ուղարկողը՝ կա՛մ հանգույցով, կա՛մ իր դարպասով։ Եթե հանգույցը նաև NAT է անում թունելի ենթացանցի համար, հաստատեք, որ թարգմանությունը վերաբերում է փոխանցված հոսքին, և որ պատասխանը հասնում է հանգույցին նախքան վիճակի ժամկետը լրանալը։ Մեկուղղա ձախողումը, որը բանալիի խնդրի տեսք ունի, հաճախ հենց այս վերադարձի ուղին է։

Վերջում առանձնացրեք ձեռքսեղմումը տվյալներից։ Այն հանգույցը, որը ավարտում է ձեռքսեղմումը, բայց կանգ է առնում մեծ փոխանցումների ժամանակ, սովորաբար ունենում է MTU կամ MSS խնդիր հենց այդ ուղու վրա, ոչ թե AllowedIPs խնդիր։ Նախ փորձարկեք փոքր ping-ով, ապա լրիվ չափի ping-ով, և համեմատեք երկու հանգույցներին։

Քայլ 5: Փոխեք մեկ բան և աշխատող հանգույցը թողեք անձեռնմխելի

Կատարեք մեկ փոփոխություն ձախողված ուղու վրա և նորից փորձարկեք երկու հանգույցներին։ Յուրաքանչյուր հանգույցի AllowedIPs-ը 0.0.0.0/0-ով փոխարինելը արդեն աշխատող հանգույցը կոտրելու ամենաարագ ճանապարհն է, որովհետև դա փոխում է այդ ինտերֆեյսի ամբողջ տրաֆիկի երթուղային որոշումը։ Խմբագրեք այդ մեկ գրառումը, վերաբեռնեք և նորից կարդացեք կենդանի վիճակը։

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