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 від клієнта до сервера й підтвердьте порт, який використовуєте. Далі перевірте внутрішній шлях на сервері, де 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. Другий заголовок зменшує корисне навантаження, тож шлях, що відповідає на малі пінги, усе одно може збійти на передаванні файлу, а міжмережевий екран, що відкидає весь ICMPv6, перетворює виправну проблему розміру на чорну діру. Перевірте одне велике передавання, перш ніж оголошувати послугу.

Що є зовсім іншою проблемою

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

Якщо сервер не має придатного upstream IPv6, варіанти — підтримуваний upstream, інший вихід або задокументоване рішення, що IPv6 залишається поза тунелем. Неприйнятно казати клієнтам, що послуга IPv6 існує, тоді як їхнє звичайне з’єднання IPv6 тихо обходить VPN.