Планирование частного доступа по IKEv2 с двойным стеком и strongSwan

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

Три вида адресов, решённых отдельно

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

Внешний транспорт только по IPv4 с внутренним трафиком двойного стека — нормальная и хорошо поддерживаемая схема.

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

Выделите виртуальный адрес в каждом семействе

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

Просите оба семейства, когда нужны оба, и одно, когда не нужно, потому что неиспользуемый адрес — это поверхность политики без пользы. Конкретный запрос — это запрос, а не резервирование, и ответчик может вернуть другое значение по своей политике. Эта деталь важна везде, где адрес жёстко записан в правило межсетевого экрана или в проверку мониторинга. Ссылайтесь на пулы по имени в соединении и держите сети сервисов вне них.

vips = 0.0.0.0, ::

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

Опишите назначения отдельно от пулов

Селекторы трафика описывают, что каждая сторона ожидает обменять, поэтому локальные селекторы шлюза должны называть защищённые префиксы сервисов, а не пулы клиентов. Удалённые селекторы клиента отражают это намерение. Когда оба списка описывают разные объекты, туннель может подняться и всё равно не нести ничего полезного.

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

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

Сделайте DNS и обратные пути осознанными

Разрешение имён не следует за транспортом. Резолвер может вернуть записи A и AAAA через туннель только с IPv4, и клиент тогда попробует семейство, которое вы никогда не планировали. Решите, какие имена сервисов должны нести пригодные ответы двойного стека, и сделайте оба этих пути осознанными. Имя, которое разрешается в семейство без работающего пути, даёт зависание, а не чистую ошибку, а зависания диагностировать гораздо труднее.

Задокументируйте доступность внешней конечной точки отдельно, включая то, задействовано ли прохождение NAT и какое семейство оно использует.

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