IPv6 праз сервер VPN на IPv4 усё роўна патрабуе выйсця IPv6

Тунель паднімаецца, кліент атрымлівае адрас IPv6 з пула, і кожны пункт прызначэння IPv6 усё роўна сканчаецца тайм-аўтам. У тунелі нішто не зламанае: IPv6 цалкам добра едзе ўнутры транспарту IPv4, і гэта ніколі не было цяжкай часткай. Адрас, які вы выдалі, — гэта абяцанне, якое сервер не можа выканаць, бо ў выйсця няма вышэйшага патоку IPv6, куды яго адпраўляць. Рамантаваць трэба на выйсці, а не ў профілі кліента.

Сімптом: адрас ёсць, шляху няма

Праверка на баку кліента паказвае адрас IPv6, які выглядае глабальным, на тунельнай прыладзе і маршрут, які паказвае ўнутр яго, таму гэта памылкова чытаецца як збой кліента. Трафік уваходзіць у тунель, сервер дэкапсулюе яго, і потым пакет апынаецца на хаспе, чыя табліца маршрутызацыі не мае маршруту па змаўчанні для IPv6 ні куды ў рэальны свет. У залежнасці ад стэка вы атрымаеце імгненную недасяжнасць або ціхае скідванне, і ў любым выпадку кліент бачыць тайм-аўт, які выглядае гэтак жа, як міжсеткавы экран.

Прачытайце ўласную табліцу маршрутызацыі сервера, перш чым кранаць кліента, бо менавіта там жыве адсутная палова шляху. Сервер з адным маршрутам па змаўчанні для IPv4 ужо даў вам адказ.

Прасочыце пакет пасля дэкапсуляцыі

Унутры тунеля пакет — звычайны IPv6, а крыніца — адрас кліента. Сервер здымае транспартную інкапсуляцыю і трымае натыўны пакет IPv6, які трэба перадаць на наступны вузел IPv6. Маршрут па змаўчанні для IPv4 не можа яго несці, а ператварэнне яго ў IPv4 — гэта іншая функцыя, якую ніхто не разгортваў. Гэта і ёсць увесь збой, і ён не мае нічога агульнага з тым, ці адказаў слухач VPN праз IPv4.

Механіка інкапсуляцыі IPv6 у IPv4 апісана ў RFC 4213, і важная дэталь там у тым, што канцавыя пункты ўсё яшчэ патрабуюць сапраўднай злучнасці IPv6 па іншы бок тунеля. Абгортванне загалоўка не стварае вышэйшы паток з нічога.

Дзве тунельныя ўзроўні, дзве незалежныя праверкі

Правярайце кожны ўзровень асобна, бо працоўны знешні тунель хавае зламаны ўнутраны. Праверце знешні шлях пінгам IPv4 ад кліента да сервера і пацвердзіце порт, які вы карыстаеце. Затым праверце ўнутраны шлях на серверы, дзе ip -6 route павінен паказаць маршрут па змаўчанні або пэўны маршрут, атрыманы ад рэальнага вышэйшага патоку, а ip -6 addr павінен паказаць прэфікс крыніцы, які прымае вышэйшы паток. Усё меншае — гэта ўпрыгожванне на інтэрфейсе.

Унікальны лакальны адрас або прэфікс, што выглядае глабальным, але нікуды не маршрутызуецца назад, з задавальненнем з’явіцца на інтэрфейсе і нікуды не пойдзе. Публічную дасяжнасць дае вышэйшы паток, а не форма адраса.

Тое ж самае тычыцца кліента: ip -6 route get 2001:4860:4860::8888 павінна назваць тунельную прыладу, і калі яна называе фізічную, то кліент зусім не выкарыстоўвае VPN для IPv6.

Прэфікс крыніцы, памер і ICMPv6

Спытайце ў вышэйшага патоку, якія прэфіксы крыніцы ён прыме для перасылкі, і выкарыстайце адзін з іх для пула кліентаў. Правайдэр, які дае вам /64 для ўласнага інтэрфейса сервера, не абавязкова маршрутызуе вам другі /64 або большы блок, і розніца — гэта паўдня адладкі, якую тыкет падтрымкі вырашае за адно пытанне. Спытайце пісьмова і захавайце адказ побач з канфігурацыяй.

Закладзіце запас на дадатковую інкапсуляцыю, якую ваш стэк фактычна выкарыстоўвае, і трымайце ICMPv6 працаздольным, уключаючы Packet Too Big. Другі загаловак памяньшае карысную нагрузку, таму шлях, які адказвае на малыя пінгі, можа ўсё ж збаіць на перадачы файла, а міжсеткавы экран, што скідвае ўвесь ICMPv6, ператварае папраўную праблему памеру ў чорную дзірку. Праверце адну вялікую перадачу, перш чым аб’яўляць паслугу.

Што зусім іншая праблема

Дасягненне праграмы, якая працуе толькі на IPv4, з кліента, які працуе толькі на IPv6, — гэта трансляцыя, а не тунеляванне, і патрабуе чагосьці накшталт наўмысна разгорнутай схемы NAT64. Пункт прызначэння не зразумее дадатковы тунельны загаловак толькі таму, што вы яго дадалі. Гістарычныя паслугі пераходу заслугоўваюць такой жа ўвагі: RFC 7526 адмяніў мадэль anycast-рэлея 6to4, таму інструкцыя, напісаная вакол яго, апісвае тое, што ўжо не мае падтрымліванага публічнага рэлея.

Калі сервер не мае прыдатнага вышэйшага патоку IPv6, выбар такі: падтрыманы вышэйшы паток, іншае выйсце або дакументаванае рашэнне, што IPv6 застаецца па-за тунелем. Непрымальна — казаць кліентам, што паслуга IPv6 існуе, тады як іх звычайная злучнасць IPv6 ціха абыходзіць VPN.