Разделение вашего /64 не маршрутизирует IPv6 до VPN-клиентов

Клиент показывает глобальный адрес IPv6, рукопожатие завершено, и ничего не возвращается из интернета. Настройка пула выглядит правильной, потому что она правильная; адрес действителен, и туннель его несёт. Отказывает доставка, а доставка зависит от решения, принятого выше VPN-сервера, на которое никакая конфигурация на стороне клиента не может повлиять.

Миф: часть вашего /64 уже доступна

История заманчива: у сервера есть публичный /64, разрежьте его пополам, отдайте вторую половину пулу VPN, и эти клиенты уже в интернете. Разделение префикса действительно выделяет адреса без коллизий. Но оно не меняет того, как сеть upstream решает, куда должен идти пакет для одного из этих адресов.

У IPv6 нет слоя трансляции по умолчанию, на который можно положиться, поэтому обратный путь должен существовать как маршрутизация или как доставка на уровне канала. Пакет, адресованный туннельному адресу клиента, приходит на маршрутизатор upstream, и этот маршрутизатор принимает решение о пересылке по собственной таблице. Если таблица указывает на физический канал, пакет идёт туда, независимо от того, что думает ваш VPN-сервер.

В этом и состоит весь отказ: прямое направление работает, потому что его отправляет ваш сервер, а обратное умирает через один переход, потому что upstream так и не узнал, что клиент существует.

Что на самом деле требует доставка на канале

Когда upstream считает весь /64 находящимся на физическом канале, он разрешает каждый адрес назначения через обнаружение соседей. Он отправляет запрос по этому каналу и ожидает, что владелец адреса ответит. VPN-клиент за туннелем не находится на этом канале и не может ответить, поэтому запрос остаётся без ответа, а пакет отбрасывается.

Выделение /65 не меняет этого ожидания. Upstream по-прежнему рассматривает диапазон как находящийся на канале, потому что единственное, что могло бы изменить его мнение, — это маршрут или прокси, отвечающий от имени клиента. Ни то, ни другое не появляется, потому что вы отредактировали конфигурацию VPN. Именно этот разрыв объясняет, почему пул может прекрасно работать между своими клиентами и всё равно быть недоступным откуда-либо ещё.

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

Что требует маршрутизируемая доставка

Более чистая схема — это выделение, которое upstream действительно маршрутизирует на ваш шлюз. Это может быть делегированный префикс или статический маршрут для меньшего блока, и требование в обоих случаях одно: таблица upstream должна указывать на ваш сервер для клиентского диапазона. Тогда обратный трафик приходит на шлюз, и шлюз передаёт его в туннель.

Маршрутизируемая доставка полностью снимает вопрос обнаружения соседей, поэтому стоит попросить её у провайдера до того, как строить что-то хитрое. Попросите маршрут в письменном виде и подтвердите, что следующий переход — это адрес, до которого upstream действительно может добраться.

Обе схемы по-прежнему требуют включённой пересылки IPv6 на шлюзе и правил брандмауэра, разрешающих пересылаемый поток в обоих направлениях. Доставка — это предпосылка, а не замена для остальной части пути. Работающий маршрут с отключённой пересылкой даёт ровно ту же тишину, что и отсутствующий маршрут, поэтому проверьте оба варианта, прежде чем что-либо переделывать.

Два независимых маршрута, которые нужно настроить правильно

Префикс пула и собственный маршрут клиента по умолчанию — это отдельные параметры, и их смешение даёт частичную связность, которая выглядит как сломанный туннель. Пул сообщает серверу, какие адреса выдавать. Маршруты клиента решают, к каким назначениям клиент вообще отправляет трафик в туннель.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Префикс выше — это пространство документации, а перенаправление относится только к IPv6, что как раз и нужно часто двойному стеку, пока доставка IPv6 ещё исправляется. Перенаправление IPv4 не устанавливает покрытие IPv6, и ни один из параметров не подразумевает другой.

Поддерживайте управляющий трафик, от которого зависит IPv6, работающим при любой применяемой политике. Сообщения Packet Too Big — классическая жертва брандмауэра, разрешающего только TCP и UDP, и их отбрасывание создаёт соединения, которые устанавливаются, а затем застревают на больших передачах.

Объявления маршрутизатора — третья движущаяся часть. Если шлюз начнёт объявлять на вышестоящем канале, это может изменить то, что клиенты и соседи думают о префиксах на канале, и это может тихо отменить только что задокументированную схему.

Запишите схему, чтобы пересборка её воспроизвела

Запишите три объекта отдельно: выделение клиента, маршрут назначения клиента и метод доставки выделения со стороны upstream. Читатель, у которого есть все три, сможет пересобрать развёртывание; читатель, у которого есть только настройка пула, воспроизведёт исходную ошибку.

Затем явно проверьте обратное направление пакетом, который должен вернуться извне. Руководство openvpn(8) описывает параметры server-ipv6 и redirect, а подтверждение маршрутизации от вашего провайдера покрывает ту половину, которую руководство не может.