IPv6-префикс филиала: iroute-ipv6 или route-ipv6 на сервере?

Две директивы с почти одинаковым именем встречаются в каждом работающем примере, и копирование одной без другой даёт туннель, который выглядит правильным и молча теряет префикс филиала. Они делают разную работу по разные стороны одной границы: одна учит ядро сервера, где живёт префикс, а другая учит OpenVPN, какой прошедший проверку клиент его несёт. Если верны обе, префикс течёт; если одна, у пакетов есть маршрут, но нет владельца.

Две директивы, две разные задачи

route-ipv6 — это обычная установка маршрута: сервер добавляет маршрут ядра, указывающий префикс на его туннельный интерфейс. iroute-ipv6 относится к контексту конкретного клиента и объявляет внутреннюю принадлежность, так что демон знает: трафик для этого префикса нужно отправлять определённому клиенту, а не тому пиру, который случайно назван в маршруте ядра.

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

В традиционной userspace-схеме нужны обе, и они дополняют друг друга. Один маршрут ядра оставляет демон без возможности выбрать пира. Один iroute оставляет ядро без пути к туннелю. Отсюда же и большая часть путаницы с файлами для отдельных клиентов: файл — не запись таблицы маршрутов, а запись маршрута — не заявление о принадлежности.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Где место каждой

Маршрут идёт в управляемую конфигурацию сервера, где он действует для этого процесса. iroute идёт в файл, специфичный для клиента, названный по проверенной личности устройства филиала.

Имя файла, не совпадающее с фактической личностью, никогда не читается, и симптом совпадает с отсутствующим iroute. Проверьте личность, которую подтвердил сервер, а затем проверьте имя файла символ за символом.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Держите пул и префикс филиала раздельно, потому что их перекрытие создаёт загадку, которую не решит ни одна директива.

Что нужно другому клиенту

Второму клиенту, который должен дотянуться до этого филиала, нужно объявление, а не принадлежность. Отправьте префикс тем клиентам, которым нужно, в клиентском или групповом контексте, подходящем вашей конфигурации.

Не отправляйте его самому филиалу, потому что у этого устройства префикс уже есть как подключённая сеть.

Отправка всем — выбор с последствиями: тогда каждый клиент считает, что филиал доступен через туннель, включая клиентов, которым вы никогда не собирались давать этот доступ. Объявление на практике является решением о доступе, хотя директива выглядит как сантехника. справка по параметрам сервера описывает iroute-ipv6 как принадлежность конкретному клиенту, и именно это различие стоит сохранить.

Обратный путь на устройстве филиала

Принадлежность помогает, только если филиал пересылает пакеты и его LAN знает, как отвечать. Включите пересылку IPv6 на устройстве филиала и убедитесь, что хосты в его LAN отправляют трафик для пула VPN обратно к филиалу, а не к маршруту по умолчанию, который этот пул не знает.

Этот обратный путь — эквивалент для IPv6 той проблемы с отсутствующим маршрутом, с которой люди сталкиваются в IPv4.

Проверьте это с хоста в LAN запросом адреса пула VPN, а не с самого филиала. Запрос на маршрутизаторе отвечает на другой вопрос, чем вопрос ваших пользователей, и эти ответы достаточно часто расходятся, чтобы лишняя команда того стоила.

Когда пары всё ещё не хватает

Некоторые развёртывания вовсе не используют этот путь. Путь данных ядра и серверы под управлением продукта имеют собственную поддерживаемую обработку маршрутов, и пример для userspace может не переноситься напрямую.

Проверьте, какой путь данных использует ваша сборка, прежде чем копировать директивы из руководства, написанного для другого.

И напоследок помните про область адресов: уникальный локальный префикс вроде fd00:7a::/64 является приватным по замыслу и ничего не говорит о публичной доступности IPv6. Считайте его внутренним доступом, а выход в интернет держите отдельным вопросом с собственной политикой.