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.