Сеть только с IPv6 ломает VPN ещё до запуска туннеля

Ноутбук подключается к Wi-Fi конференции, который раздаёт только IPv6, клиент VPN крутится и падает, а тот же профиль работал в гостинице час назад. В учётных данных ничего не изменилось. Изменилось то, что клиент теперь должен достичь адресата IPv4 через сеть, которая несёт только IPv6, и не каждый клиент знает, как это сделать.

Пройдите те же пять шагов, что проходят пакеты.

Шаг 1: наблюдайте за поиском имени

Если профиль использует имя хоста, первый вопрос — что возвращает резолвер. dig AAAA vpn.example.com в сети только с IPv6 возвращает настоящую запись AAAA, синтезированную из DNS64 или вообще ничего. Синтезированный ответ кодирует адресата IPv4 внутри префикса трансляции, и только тогда клиент без адресата IPv6 может до него добраться. Профиль с жёстко заданным адресом IPv4 никогда не доходит до этого, потому что нет имени для синтеза.

Это единственное различие объясняет большинство отчётов «там работает, здесь падает», и чтобы это увидеть, достаточно одной команды.

Шаг 2: посмотрите, какое семейство вызвал клиент

Смотрите на сокет, а не на индикатор прогресса. Клиент, открывающий сокет IPv4 к адресу IPv4 на канале только с IPv6, не имеет куда его отправить, и сбой проявляется как тайм-аут, а не как ошибка имени. ss -tanp во время подключения клиента показывает удалённый адрес и семейство, которое он попробовал. Сравните это с ip -6 route, чтобы убедиться, что маршрут по умолчанию — настоящий следующий хоп IPv6.

Семейство адресов в таблице сокетов — это факт. Индикатор прогресса — это сводка, которую написал кто-то другой.

Шаг 3: отделите трансляцию от туннеля

NAT64 и DNS64 — это то, как сеть доступа достигает адресатов IPv4, и после подъёма туннеля они для него ничего не делают. Туннель, построенный поверх транслированного пути, всё равно согласует собственную внутреннюю адресацию, а внутреннее покрытие IPv4 или IPv6 — отдельный вопрос политики. Если клиент подключается и затем ничего не достигает, вы уже прошли трансляцию и находитесь в маршрутизации, а это другое расследование с другими доказательствами.

Сбой трансляции выглядит как отсутствие подключения. Сбой внутреннего покрытия выглядит как подключение без достижения чего-либо.

Шаг 4: проверьте тот же профиль в другой сети

Возьмите тот же профиль, версию клиента и учётные данные в сеть с двойным стеком и повторите. Если там работает, а на пути только с IPv6 падает, переменная — сеть доступа, а не профиль. Запишите в тикет версию клиента и состояние сети, потому что окончательное исправление — обновление клиента или другой адресат.

Отчёт «VPN сломан» не даёт возможности действовать. Отчёт «падает только при доступе только с IPv6» — это отчёт об ошибке.

Шаг 5: исправьте путь, а не настройки безопасности

Все заманчивые исправления делают хуже. Отключение IPv6 убирает единственный путь, который предлагает сеть. Направление клиента на публичный резолвер ломает синтез DNS64, потому что этот синтез должен приходить от резолвера за транслятором. Отключение проверки сертификата даёт соединение с чем-то, что вы не можете опознать. Ни одно из них не является исправлением, а два — регрессии безопасности, которые переживут инцидент.

Реальные варианты — клиент с поддержкой модели сетевой трансляции или адресат с доступным адресом IPv6. Попросите один из них.