Добавляем приватный IPv6 в лабораторию OpenVPN, по одной контрольной точке

Оставьте внешний транспорт на IPv4 и расширьте внутренний план. Пять контрольных точек: префиксы, помощник, продвижение маршрута, пересылка и проверка со стороны клиента.

У вас уже есть клиент, который подключается по IPv4 и достигает приватной рабочей нагрузки IPv4 за сервером. Цель — достичь приватной рабочей нагрузки IPv6 через тот же туннель, не трогая внешний транспорт. Этот порядок важен: внешний путь остаётся IPv4, а меняются только внутренний план адресов, маршрут клиента и обратный путь от сервера к LAN. Пять контрольных точек, в каждой есть что-то конкретное, что стоит проверить, прежде чем двигаться дальше.

Контрольная точка первая: соединение, которое уже работает

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

Запишите пул, топологию и продвигаемые маршруты, на которые вы уже полагаетесь. Работа с IPv6 расширяет эту конфигурацию, а не заменяет её.

Контрольная точка вторая: выберите внутренние префиксы

Выберите ULA /48 для площадки и вырежьте из неё две /64: одну для клиентов туннеля, одну для сегмента LAN с рабочей нагрузкой IPv6. Сгенерируйте 40-битный глобальный ID вместо копирования примера префикса, и проверьте обе подсети против каждой сети, которую площадка уже маршрутизирует:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Две независимые /64 не дают вырезать пул клиентов из сегмента LAN, что важно позже при написании обратного маршрута. Значения выше — один проработанный пример, а не префикс для повторного использования.

Контрольная точка третья: добавьте помощник и продвижение маршрута

Прочитайте текущую конфигурацию сервера, прежде чем что-то дописывать. Вторая копия существующей директивы не сливается с первой, и возникшая ошибка называет директиву, а не IPv6. При наличии помощника IPv4 две строки расширяют его. Каждая отвечает на свой вопрос:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

Помощник не сосуществует со статическим пулом IPv6 или с nopool. Если развёртывание намеренно выдаёт адреса статически, сохраните эту политику и явно спроектируйте эквивалент для IPv6, а не удаляйте политику, чтобы подогнать под пример.

Контрольная точка четвёртая: пересылка и маршрут ответа

Включите пересылку IPv6 на сервере через штатного владельца конфигурации системы, а не одноразовой записью во время работы, которую вы забудете. Форма времени выполнения полезна для быстрой проверки. Постоянная конфигурация относится в drop-in файл, который читает сетевой владелец дистрибутива:

sysctl -w net.ipv6.conf.all.forwarding=1

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

Затем дайте LAN обратный маршрут к пулу туннеля. Шлюз IPv6 рабочей нагрузки — это маршрутизатор LAN, а не сервер VPN, поэтому маршрут принадлежит этому маршрутизатору и указывает на адрес сервера в LAN:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Сохраните типы ICMPv6, нужные каналу, включая обратную связь по MTU пути. Правило межсетевого экрана IPv4 не означает правило IPv6, а сплошная блокировка IPv6 ломает обнаружение соседей так, что это выглядит как сбой маршрутизации.

Контрольная точка пятая: прочитайте клиента, затем проверьте

Переподключите клиента и прочитайте адреса, которые он действительно получил, вместо того чтобы выводить их из адреса помощника на сервере. Список интерфейсов показывает оба семейства на одном устройстве:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Маршрут, выбирающий туннель, доказывает, что клиент знает, куда отправить пакет. Он не доказывает, что сервер его пересылает, что у маршрутизатора LAN есть обратный маршрут или что приложению разрешено отвечать.

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

Публикуйте запись AAAA только тогда, когда путь IPv6 отвечает от начала до конца. DNS, запрошенный по IPv4, всё ещё может вернуть адрес IPv6, поэтому разрешимое имя не доказывает, что кто-то слушает. Рекомендации RFC 4193 по ULA охватывают генерацию глобального ID, который делает эти префиксы вашими, а не копией.

Похожие статьи