IPv6-ը IPv4 VPN սերվերի միջով դեռ պահանջում է IPv6 ելք

Թունելը բարձրանում է, հաճախորդը լողավազանից IPv6 հասցե է ստանում, և այդուհանդերձ յուրաքանչյուր IPv6 նպատակատեղ դադարում է պատասխանել։ Թունելում ոչինչ կոտրված չէ՝ IPv6-ը լիովին լավ է ընթանում IPv4 տրանսպորտի ներսում, և դա երբեք դժվար մասը չէր։ Այն հասցեն, որը դու տրամադրեցիր, խոստում է, որը սերվերը չի կարող կատարել, որովհետև ելքը չունի IPv6 upstream, ուր այն ուղարկի։ Վերանորոգումը ելքի մոտ է, ոչ թե հաճախորդի պրոֆիլում։

Ախտանիշը՝ հասցե կա, ուղի չկա

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

Կարդա սերվերի սեփական երթուղային աղյուսակը նախքան հաճախորդին դիպչելը, որովհետև ուղու պակասող կեսը հենց այնտեղ է ապրում։ Մեկ IPv4 լռելյայն երթուղի ունեցող սերվերն արդեն տվել է քեզ պատասխանը։

Հետևիր փաթեթին փաթաթանը բացելուց հետո

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

IPv6-ի՝ IPv4-ի վրա փաթաթելու մեխանիկան նկարագրված է RFC 4213-ում, և այնտեղ կարևոր մանրամասն այն է, որ ծայրերը դեռ պահանջում են իրական IPv6 կապ թունելի մյուս կողմում։ Վերնագիր փաթաթելը upstream չի ստեղծում։

Երկու թունելային շերտ, երկու անկախ ստուգում

Ստուգիր յուրաքանչյուր շերտը առանձին, որովհետև աշխատող արտաքին թունելը թաքցնում է կոտրված ներքինը։ Ստուգիր արտաքին ուղին IPv4 ping-ով հաճախորդից սերվեր և հաստատիր օգտագործվող պորտը։ Ապա ստուգիր ներքին ուղին սերվերում, որտեղ ip -6 route պետք է ցույց տա լռելյայն կամ իրական upstream-ից սովորած կոնկրետ երթուղի, և ip -6 addr պետք է ցույց տա աղբյուրի նախածանց, որն ընդունում է upstream-ը։ Դրանից պակաս ամեն ինչ ինտերֆեյսի վրա զարդարանք է։

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

Նույնը վերաբերում է հաճախորդին՝ ip -6 route get 2001:4860:4860::8888 պետք է անվանի թունելի սարքը, և եթե անվանում է ֆիզիկականը, ապա հաճախորդն ընդհանրապես VPN չի օգտագործում IPv6-ի համար։

Աղբյուրի նախածանց, չափ և ICMPv6

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

Բյուջե դիր այն լրացուցիչ փաթաթանքի համար, որն իրականում օգտագործում է քո ստեկը, և պահիր ICMPv6-ը աշխատունակ, ներառյալ Packet Too Big-ը։ Երկրորդ վերնագիրը փոքրացնում է օգտակար բեռը, այնպես որ փոքր ping-ների պատասխանող ուղին կարող է ձախողվել ֆայլի փոխանցման ժամանակ, և հրապատը, որը գցում է ամբողջ ICMPv6-ը, վերանորոգելի չափի խնդիրը վերածում է սև խոռոչի։ Ծառայությունը հայտարարելուց առաջ փորձիր մեկ մեծ փոխանցում։

Ինչն է բոլորովին այլ խնդիր

Միայն IPv4 հավելվածին միայն IPv6 հաճախորդից հասնելը թարգմանություն է, ոչ թունելավորում, և պահանջում է նման մի բան դիտավորյալ տեղակայված NAT64 կարգավորման։ Նպատակակետը չի հասկանա լրացուցիչ թունելային վերնագիր միայն այն պատճառով, որ դու մեկն ավելացրիր։ Պատմական անցումային ծառայությունները նույն խնամքին արժանի են՝ RFC 7526-ը չեղարկեց 6to4 anycast relay մոդելը, ուստի դրա շուրջ գրված ուղեցույցը նկարագրում է մի բան, որը այլևս չունի պահվող հանրային relay։

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