WireGuard-ի հոսթային պրեֆիքսը. ինչու է աշխատում մեկ հասցեն, իսկ մյուսները՝ ոչ

Թունելը բարձրացված է, handshake-ը տեղի է ունենում ամեն երկու րոպեն մեկ, և մյուս կողմում ճիշտ մեկ հասցե է պատասխանում։ Փինգերը դեպի փիրի թունելի հասցեն աշխատում են, դրա հետևում ոչինչ։ Ինչ-որ մեկը կարդում է ինտերֆեյսի կոնֆիգուրացիան, տեսնում հոսթային պրեֆիքս և եզրակացնում, որ դիմակը սխալ է։ Այն /24-ի ընդլայնելը փինգը որոշ ժամանակ ուղղում է, ապա կոտրում է այլ բան։ Պրեֆիքսը երբեք մեղավոր չի եղել, իսկ բացակայող երթուղին այն չէ, ինչը կառավարում է դիմակը։

Ինչ է իրականում ստեղծում ինտերֆեյսի պրեֆիքսը

Linux-ում ինտերֆեյսին հասցե վերագրելը ստեղծում է կապակցված երթուղի այդ պրեֆիքսի համար։ Եթե վերագրեք հոսթային պրեֆիքս, կապակցված երթուղին կընդգրկի մեկ հասցե։ Եթե վերագրեք /24, այն կընդգրկի 256-ը, և դրանցից յուրաքանչյուրն այժմ համարվում է հասանելի այդ կապով։

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

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

AllowedIPs-ը երկու կանոն է մեկ անվան տակ

WireGuard-ի փիրի համար թույլատրված ցանկը միաժամանակ երկու աշխատանք է կատարում, և կոնֆիգուրացիայի շարահյուսությունը դրանց մեկի տեսք է տալիս։ Մուտքի մոտ այն թույլատրում է, թե որ աղբյուր հասցեները փիրը կարող է ներկայացնել։ Ելքի մոտ այն ընտրում է, թե որ փիրին ուղարկել փաթեթը՝ գտնելով ամենակոնկրետ համընկնումը։

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

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

Որտեղից է գալիս երթուղին

Եթե օգտագործում եք wg-quick, երթուղիները ձեզ համար ստեղծվում են յուրաքանչյուր փիրի թույլատրված ցանկից, եթե դուք չեք սահմանել Table = off և ինքներդ չեք վերցրել վերահսկողությունը։ Սա գործիքի փաստաթղթավորված վարքն է, և դա է պատճառը, որ բացահայտ երթուղային հրահանգներ չունեցող կոնֆիգուրացիան միևնույն է աշխատում է։

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Համեմատեք թույլատրված ցանկը փաստացի գոյություն ունեցող երթուղիների հետ։ Փիրը, որը թույլատրում է ամբողջ ենթացանցը, բայց ստեղծել է միայն հոսթային երթուղի, նշանակում է, որ օգնականը երբեք չի գործարկվել, կամ որ ինտերֆեյսը ղեկավարում եք ուղղակիորեն wg-ով և ip-ով, և այդ դեպքում ոչինչ ձեզ համար երթուղիներ չի ստեղծում։

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

Ավելի լայն պրեֆիքսը չի ավելացնում փիրի գրառումը

Գայթակղիչ ուղղումը հասցեն /24-ի փոխելն է, որպեսզի կապակցված երթուղին ընդգրկի սերվերի տեղական ցանցը։ Թվում է, թե աշխատում է, և այն, թե ինչու է թվում, թե աշխատում է, այն է, որ կապակցված երթուղին հիմա համընկնում է, այլ ոչ թե WireGuard-ը նոր բան է սովորել։

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

Կրիպտոգրաֆիկ կողմը ոչ մի դեպքում չի տուժում։ WireGuard-ին դեռ պետք է թույլատրված ցանկի գրառում, որն ընդգրկում է նպատակակետը՝ փիր ընտրելու համար, իսկ մյուս կողմին դեռ պետք է գրառում, որն ընդգրկում է ձեր աղբյուրը՝ այն ընդունելու համար։ Ավելի լայն ինտերֆեյսի պրեֆիքսը ոչ մեկը չի կարող տալ։

Հաստատեք երկու ուղղությունները՝ նախքան ինչ-որ բան փոխելը

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

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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