WireGuard-ի կլիենտը չի՞ հասնում OpenVPN-ի կլիենտին։

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

Ախտանիշին պակասում է մեկ մաս՝ ամեն անգամ

Այս ձևավորումը օգտագործում է WireGuard-ի լողավազան 10.71.0.0/24՝ wg1-ի վրա, և OpenVPN-ի լողավազան 10.72.0.0/24՝ tun1-ի վրա, երկուսն էլ ավարտվում են մեկ դարպասի մոտ։ Փորձարկվող հարցումը գնում է 10.71.0.5-ից դեպի HTTPS՝ 10.72.0.30-ի վրա։ Ներքևի ամեն քայլ այդ մեկ հոսքի մասին է։ Ամեն ստուգում ունի տարբեր ձախողման ստորագրություն, թեև օգտվողը նրանց նույն կերպ է ապրում, և սովորաբար միաժամանակ բացակայում է երեքից միայն մեկը։

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

Ընդլայնեք ճյուղի նշանակակետի ծածկույթը

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

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

Պահեք աղբյուրի սեփականությունը դարպասի մոտ

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

AllowedIPs = 10.71.0.5/32

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

Տվեք OpenVPN-ի կողմին վերադարձի ուղի

Նշանակակետին այժմ պետք է ուղի դեպի WireGuard-ի աղբյուրը, և լողավազանային կլիենտների համար այն սովորաբար գալիս է որպես հրող ուղի OpenVPN-ի սերվերից։ Հրեք այն միայն այն կլիենտներին, ովքեր պետք է ունենան այն, և կլիենտի վրա հաստատեք, որ այն ընդունվել է, փոխանակ ենթադրելու, որ հրահանգը կիրառվել է։

push "route 10.71.0.0 255.255.255.0"

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

Թույլատրեք հենց այն մեկ ծառայությունը, որը մտադիր էիք թույլատրել

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Սրանք փոխանցվող երթևեկության կանոններ են՝ առանձին դարպասի՝ երկու VPN ծառայությունների լսելու կանոններից։ Արտաքին UDP պորտերը բացելը չի լիազորում ներքին հարցումը, և ներքին հարցումը լիազորելը չի պահանջում անսահմանափակ SSH դեպի դարպաս կամ լռելյայն թույլտվություն փոխանցման վրա։ Նշանակակետի սեփական firewall-ը և լսելու հասցեն նույնպես պետք է համընկնեն, քանի որ loopback-ին կապված ծառայությունը մերժում է նույնիսկ ամենախնամ ուղղորդված փաթեթը։ Քաղաքականությունը, որը ծածկում է խոսակցության միայն մեկ ուղղությունը, սովորաբար ձախողվում է հաջող հարցումով և լուռ պատասխանով, ինչը երեք արդյունքներից ամենաշփոթեցնողն է։

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