Ձեր /64-ի բաժանումը IPv6-ը չի ուղղորդում VPN հաճախորդներին

Հաճախորդը ցույց է տալիս գլոբալ IPv6 հասցե, ձեռքսեղմումն ավարտված է, և ինտերնետից ոչինչ չի վերադառնում։ Փուլի կարգավորումը ճիշտ է երևում, որովհետև այն իսկապես ճիշտ է, հասցեն վավեր է, և թունելը տանում է այն։ Ձախողվում է առաքումը, և առաքումը կախված է VPN սերվերից վերև կայացված որոշումից, որի վրա հաճախորդի կողմի ոչ մի կարգավորում չի կարող ազդել։

Առասպել՝ ձեր /64-ի մի մասն արդեն հասանելի է

Պատմությունը գրավիչ է՝ սերվերն ունի հանրային /64, կիսեք այն, տվեք մյուս կեսը VPN փուլին, և այդ հաճախորդներն արդեն ինտերնետում են։ Նախածանցի բաժանումը իսկապես հասցեներ է հատկացնում առանց բախումների։ Բայց այն չի փոխում, թե ինչպես է upstream ցանցը որոշում, թե ուր պետք է գնա այդ հասցեներից մեկի համար նախատեսված փաթեթը։

IPv6-ը չունի լռելյայն թարգմանության շերտ, որի վրա հենվի, ուստի վերադարձի ուղին պետք է գոյություն ունենա որպես երթուղավորում կամ որպես կապի մակարդակի առաքում։ Հաճախորդի թունելի հասցեին ուղղված փաթեթը հասնում է upstream երթուղիչին, և այդ երթուղիչը փոխանցման որոշում է կայացնում իր աղյուսակից։ Եթե աղյուսակը մատնանշում է ֆիզիկական կապին, փաթեթը գնում է այնտեղ՝ անկախ նրանից, ինչ մտածում է ձեր VPN սերվերը։

Սա է ամբողջ ձախողումը՝ առաջ ուղղությունը աշխատում է, որովհետև ձեր սերվերն է ուղարկում այն, իսկ վերադարձի ուղղությունը մահանում է մեկ ցատկ հեռավորության վրա, որովհետև upstream-ը երբեք չիմացավ, որ հաճախորդը գոյություն ունի։

Ինչ է իրականում պահանջում կապի վրա առաքումը

Երբ upstream-ը ամբողջ /64-ը համարում է ֆիզիկական կապի վրա գտնվող, այն լուծում է յուրաքանչյուր նպատակակետ հասցե հարևանների հայտնաբերմամբ։ Այն հարցում է ուղարկում այդ կապի վրա և ակնկալում, որ հասցեի սեփականատերը կպատասխանի։ Թունելի հետևում նստած VPN հաճախորդը այդ կապի վրա չէ և չի կարող պատասխանել, ուստի հարցումը մնում է անպատասխան, և փաթեթը դեն է նետվում։

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

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

Ինչ է պահանջում երթուղավորված առաքումը

Ավելի մաքուր ձևավորումը հատկացումն է, որը upstream-ը իսկապես երթուղավորում է ձեր դարպասին։ Դա կարող է լինել պատվիրակված նախածանց կամ ստատիկ երթուղի ավելի փոքր բլոկի համար, և պահանջը երկու դեպքում նույնն է՝ upstream-ի աղյուսակը պետք է մատնանշի ձեր սերվերին հաճախորդների տիրույթի համար։ Այնուհետև վերադարձի երթևեկությունը հասնում է դարպասին, և դարպասը փոխանցում է այն թունել։

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

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

Երկու անկախ երթուղի, որոնք պետք է ճիշտ լինեն

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Վերևի նախածանցը փաստագրական տարածք է, և վերահասցեավորումը վերաբերում է միայն IPv6-ին, ինչը հենց այն է, ինչ երկկույտ տեղակայումը հաճախ ուզում է, քանի դեռ IPv6 առաքումը դեռ ուղղվում է։ IPv4 վերահասցեավորումը IPv6 ծածկույթ չի հաստատում, և կարգավորումներից ոչ մեկը չի ենթադրում մյուսը։

Պահեք IPv6-ից կախված կառավարման երթևեկությունը աշխատունակ ցանկացած քաղաքականության ներքո, որը կիրառեք։ Packet Too Big հաղորդագրությունները միայն TCP և UDP թույլատրող հրապատի դասական զոհն են, և դրանք դեն նետելը ստեղծում է կապեր, որոնք հաստատվում են, ապա կանգ են առնում ավելի մեծ փոխանցումների ժամանակ։

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

Գրանցեք ձևավորումը, որպեսզի վերակառուցումը վերարտադրի այն

Գրեք երեք օբյեկտ առանձին՝ հաճախորդի հատկացումը, հաճախորդի նպատակակետ երթուղին և upstream-ի առաքման եղանակը հատկացման համար։ Ընթերցողը, ով ունի բոլոր երեքը, կարող է վերակառուցել տեղակայումը, իսկ ընթերցողը, ով ունի միայն փուլի կարգավորումը, կվերարտադրի սկզբնական սխալը։

Այնուհետև բացահայտ փորձարկեք վերադարձի ուղղությունը՝ փաթեթով, որը պետք է վերադառնա դրսից։ openvpn(8) ձեռնարկը ընդգրկում է server-ipv6 և redirect տարբերակները, և ձեր մատակարարի երթուղավորման հաստատումը ընդգրկում է այն կեսը, որը ձեռնարկը չի կարող։