WireGuard-ը ցանցի անվանատարածքում՝ ինչու socket-ը հետ մնաց

Միջերեսը նշված է այն անվանատարածքում, որը ցանկանում էիք, հավելվածը կապված է դրան, և այնուամենայնիվ թունելի երթևեկություն երբեք չի հայտնվում։ Սա Linux միջուկի WireGuard սարքի նշանն է, որը ստեղծվել է մի անվանատարածքում և տեղափոխվել մյուսը. միջերեսը տեղափոխվեց, իսկ նրա գաղտնագրված UDP socket-ը՝ ոչ։ Երկուսն էլ պետք է լինեն ճիշտ տեղում, նախքան ներքին երթևեկությունը նշանակություն կունենա։ Ստուգումը արագ է, հենց որ գիտեք, որ պետք է նայել երկու համատեքստի, այլ ոչ մեկի։

Ախտանիշը. ճիշտ անվանատարածք, բայց փաթեթներ չկան

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

Պատճառն այն է, որ հավելվածի ներքին փաթեթները հասնում են տեղափոխված սարքին, և սարքը փորձում է ուղարկել դրանց socket-ով, որը պատկանում է այլ ցանցային համատեքստի։ Հիմնային ուղին, որն օգտագործում է, և յուրաքանչյուրք firewall-ի կանոնը, որը կիրառվում է դրա նկատմամբ, այն են, որոնք գտնվում են այն անվանատարածքում, որտեղ ստեղծվել է սարքը։

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

Ինչու socket-ն ունի ծննդավայր

WireGuard սարքն ունի մեկ UDP socket իր գաղտնագրված փոխադրման համար, և այդ socket-ը բացվում է այն անվանատարածքում, որտեղ ստեղծվում է սարքը։ Միջերեսը հղմային հրամայով տեղափոխելը տեղափոխում է տեսանելի սարքը, բայց փոխադրումը թողնում է այնտեղ, որտեղ սկսվել է։ Այնուհետև երկու օբյեղտներն ունեն տարբեր սեփականներ։

Հետևանքը հեշտ է բաց թողնել, ցայնրերը ստուգվում են տարբեր վայրերում։ Ներքին ուղին որոշվում է այն անվանատարածքում, որտեղ աշխատում է հավելվածը, իսկ արտաքին ուղին՝ այնտեղ, որտեղ ապրում է socket-ը։ Միայն մեկին ստուգելը տալիս վստահ, բայց սխալ եզրակացություն։ Երկուսն էլ ստուգելը սովորաբար ավարտում է հետազոտությունը մեկ անցումով։

Ստեղծեք այն այնտեղ, որտեղ ցանկանում եք socket-ը

Լուծումն այն է, որ սարքը ստեղծեք թիրախուի անվանատարածքի ներսում, այլ ոչ դրսում ստեղծեք և տեղափոխեք։ Ենթադրելով, որ հաստատված անվանատարածք արդեն գոյություն ունի, և անունը չի օգտագործվում.

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

Վերաբերեք դրանց որպես ցանցի կառավարման հրամանների, ոչ որպես բաղադրատոմսի։ Դրանք ստեղծում են սարք և ցուցադրում վիճակը. բանալիները, գործընկերը, հասցեները և ուղիները դեռ պետք է գան հաստատված կարգավորումից, և գործող արտադրամական միջերեսը երբեք չպետք է փոխարինվի օրինակում։

Կարդացեք ուղու երկու կողմերը

Երբ սարքը ճիշտ տեղում է, ստուգեք երկու որոշումը առանձին։ Սկսեք ներքին որոնումից հավելվածի համատեքստից, ապա ստուգեք արտաքին ուղին այն համատեքստից, որին պատկանում է socket-ը.

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

Ենդս մեկ ստուգում նույնպես պատկանում է գրառությանում. ինչպես է սարքը ստեղծվում վերագործարկումից հետո։ Կառավարիչը, որը վերստեղծում է միջերեսը այլ ստեղծման համատեքստով, փոխում է socket-ի ծննդավայրը։ Ձեքով կատարված տեղափոխումը ապցույց չէ կառավարվող ուղու մասին։