IPv4 VPN сервері арқылы IPv6 әлі де нақты 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 туннель құрылғысын атауы керек, ал егер физикалық құрылғыны атаса, клиент IPv6 үшін VPN-ды мүлде қолданбайды.

Бастапқы префикс, өлшем және ICMPv6

Upstream-нен оның қайта жіберу үшін қандай бастапқы префикстерді қабылдайтынын сұра, және солардың біреуін клиент пулы үшін қолдан. Сервердің өз интерфейсі үшін саған /64 беретін провайдер саған екінші /64 немесе үлкенірек блокты міндетті түрде маршруттамайды, ал айырмашылық — бір түстен кейінгі жөндеу, оны қолдау билеті бір сұрақпен шешеді. Жазбаша сұра және жауапты конфигурациямен бірге сақта.

Стекің нақты қолданатын қосымша инкапсуляцияға бюджет қой, және ICMPv6-ны жұмысқа қабілетті ұста, Packet Too Big-ті қоса. Екінші тақырып пайдалы жүктемені кішірейтеді, сондықтан кішкентай ping-дерге жауап беретін жол файл жіберуде бәрібір сәтсіздікке ұшырауы мүмкін, ал барлық ICMPv6-ны тастайтын қорғаныс қабырғасы түзетуге болатын өлшем мәселесін қара құрдымға айналдырады. Қызметті жарияламас бұрын бір үлкен жіберуді сынап көр.

Қандай нәрсе мүлде басқа мәселе

Тек IPv4 жұмыс істейтін қолданбаға тек IPv6 жұмыс істейтін клиенттен жету — бұл туннельдеу емес, аударма, және әдейі орналастырылған NAT64 тәрізді нәрсе қажет етеді. Меже тек сен бір қосымша туннель тақырыбын қосқаның үшін оны түсінбейді. Тарихи өту қызметтері де сол күтімге лайық: RFC 7526 6to4 anycast реле моделін жойды, сондықтан оның айналасында жазылған нұсқаулық енді қолдау көрсетілетін жария релесі жоқ нәрсені сипаттайды.

Егер серверде пайдалануға жарамды IPv6 upstream жоқ болса, таңдау — қолдау көрсетілетін upstream, басқа шығыс немесе IPv6 туннельден тыс қалады деген құжатталған шешім. Қабылдауға болмайтыны — клиенттерге IPv6 қызметі бар деп айту, ал сол уақытта олардың кәдімгі IPv6 байланысы VPN-ды үнсіз айналып өтеді.