DS-Lite-ը արգելափակում է մուտքային IPv4 հոսթինգը, ոչ թե ելքային VPN-ը

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

Որ կողմն է սկսում կապը

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

Կապերի սպասող սերվերը նման վիճակ չունի ստեղծելու։ Դրսից ինչ-որ մեկը պետք է հասնի հասցեի և պորտի, որը մատակարարը չի համաձայնել քարտեզագրել, և դա բոլորովին այլ հարցում է։

Հետևեք ելքային հարցմանը

Ճարտարապետությունը RFC 6333 անվանում է երկու ծայրերը։ Հաճախորդի կողմի տարրը B4-ն է, որը IPv4-ը փաթեթավորում է IPv6-ի մեջ։ Մատակարարի կողմի տարրը AFTR-ն է, որը կատարում է հասցեի թարգմանությունը և փոխանցում փաթեթը որպես IPv4։

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN սերվերը ստանում է սովորական IPv4 կապ մատակարարի թարգմանված հասցեից։ Նրան պետք չեն DS-Lite ռեժիմ, հատուկ պորտ կամ իմացություն, որ հաճախորդի մուտքի ցանցը միայն IPv6 է։ Սա այն մասն է, որը մարդիկ բաց են թողնում. հեռավոր կողմը չի կարող դա իմանալ։

Հաճախորդի սեփական կարգավորումը նույնքան սովորական է։ Նրան պետք է աշխատող IPv4 ուղի դեպի սերվեր, որը տրամադրում են B4-ը և AFTR-ը, և պետք է, որ սերվերի հոսթի անունը լուծվի IPv4 հասցեի։

Ինչու է մուտքային հոսթինգը ձախողվող դեպքը

Տանը IPv4 VPN սերվեր վարելը այն լուծումն է, որը բախվում է մատակարարի համօգտագործվող հասցեավորմանը։ Մատակարարի թարգմանիչը տիրապետում է հանրային հասցեին և քարտեզագրման աղյուսակին, և նա պատճառ չունի մեկ բաժանորդի համար մշտական մուտքային քարտեզագրում ստեղծելու։

Տնային երթուղիչի պորտի փոխանցման կանոնը չի կարող կարգավորել AFTR-ը։ Կանոնն իրական է և ճիշտ տեղական սարքում, և այն վերևում ոչինչ չի փոխում, դրա համար ախտանիշը նման է չանհետացող հրապատի խնդրի։

Այստեղ է, որ օպերատորի մակարդակի թարգմանությունը տարբերվում է մեկ հանրային հասցեից. նույնիսկ ճիշտ տեղական փոխանցումը կարող է հայտնվել հասցեում, որը կիսում են շատ բաժանորդներ։

Ախտորոշեք մինչև մուտքի պլանը փոխելը

Նախ հաստատեք տրամադրված ռեժիմը։ Բնիկ կրկնակի կույտը, DS-Lite-ը և այլ թարգմանության մեխանիզմ օգտագործող միայն-IPv6 ցանցը երեք տարբեր դասավորություններ են, և մատակարարի մարքեթինգային անվանումները միշտ չէ, որ համընկնում են տեխնիկականի հետ։

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

Այդ չորս պատասխանները մատնանշում են զտումը, թարգմանության վիճակի ժամկետի լրանալը, սխալ վերջնակետը կամ փաթեթի չափի մշակումը։ Դրանցից ոչ մեկը չի հաստատվում հաշվի էջում DS-Lite տեսնելով։

Զգուշորեն կարդացեք մատակարարի փոփոխությունները

Հաշվի փոփոխությունը կարող է համընկնել աշխատող կապի հետ՝ միաժամանակ փոխելով մի քանի հատկություն։ Գրանցեք, թե որ հատկությունը փոխվեց, որովհետև փաթեթի նոր անունը տեխնիկական բացատրություն չէ։

Կրկնակի կույտը միացնելու հրահանգը երկիմաստ է, քանի դեռ ինչ-որ մեկը չի հաստատել, թե ինչ է իրականում տրամադրում մատակարարը։ Այն IPv4 VPN հաճախորդների համար համընդհանուր պահանջ համարելը ենթադրությունը վերածում է քաղաքականության։

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