Статические адреса клиентов OpenVPN за OPNsense
Файл пула делает адрес липким, но не постоянным. Закрепите адреса клиентов переопределениями, расширьте диапазон туннеля под арифметику /30, затем опубликуйте их.
Именам нужны адреса, которые не двигаются, а файл пула OpenVPN делает адрес лишь липким. Потеряйте этот файл или перевыпустите сертификат под другим общим именем, и вернувшийся клиент окажется в другом месте пула, пока его запись DNS всё ещё указывает на старый адрес. Долговечный ответ — переопределение для конкретного клиента, которое закрепляет адрес, плюс более широкая сеть туннеля, чтобы закреплённые адреса находились вне динамического диапазона. Арифметика за этим расширением и есть то место, где живёт большая часть путаницы.
OPNsense хранит эти переопределения в настройках сервера, специфичных для клиента, с ключом по общему имени сертификата, что делает общее имя частью плана адресов.
Липкая аренда не является статическим адресом
Файл пула записывает соответствия адрес-клиент и возвращает их, когда известный клиент подключается снова. Это удобство, а не договор: файл можно перегенерировать, соответствие исчезает при смене личности клиента, а два сервера, делящих один пул, не договорятся о нём. Переопределение для конкретного клиента работает иначе, потому что адрес берётся из конфигурации, а не из истории. Оно также переживает перезапуск и переустановку устройства, если переопределение сохранено в резервной копии вместе с остальной конфигурацией.
Динамическая альтернатива, а именно связать VPN с DNS через скрипт client-connect и динамические обновления, работает и требует резолвера, принимающего обновления, плюс скрипт при каждом подключении. На устройстве вы ограничены пакетами, которые поставляет производитель, и обычно именно там этот план останавливается.
Арифметика /30, которой никто не радуется
В топологии net30 по умолчанию каждый клиент получает свою /30: первый пригодный адрес достаётся стороне сервера, второй клиенту. Поэтому переопределения должны находиться вне динамической сети туннеля сервера, а значит, сначала нужно расширить эту сеть. Сервер на 10.8.0.0/24 может перейти на 10.8.0.0/23, оставив половину старого диапазона динамическим клиентам, а другую половину переопределениям. Добавьте исходную /24 как дополнительную локальную сеть IPv4, чтобы трафик к обеим половинам шёл в туннель.
Каждый адрес переопределения должен попадать на границу /30, поэтому последний октет кратен четырём. /30 на 10.8.1.0 даёт клиенту 10.8.1.2, и именно этот адрес несёт запись DNS. Выбор 10.8.1.3 вместо него даёт клиента, который подключается и не может пропускать трафик, потому что адрес принадлежит подсети, которую топология ему никогда не назначала.
План проще держать, если переопределения выделяются сверху расширенного диапазона вниз, так что динамический пул расширяется в свободное пространство, а не вокруг фиксированных островов.
Локальные сети и зона, которую опрашивают клиенты
Трафику между клиентами нужно собственное разрешение. Список локальных сетей IPv4 сервера должен включать обе половины диапазона, динамическую и статическую; без него сервер принимает пакет от одного клиента и не имеет политики, позволяющей пропустить его к другому. Симптом выглядит как сбой DNS, потому что имя разрешается, а соединение всё равно не проходит. Проверьте одновременно и настройку связи между клиентами, поскольку одна запись локальной сети сама по себе не включает пересылку между узлами.
Публикуйте записи в той зоне, которую удалённые клиенты действительно опрашивают. Запись в зоне, которую обслуживает только резолвер LAN, невидима клиенту, чей протолкнутый резолвер указывает в другое место, и добавление новых записей в неправильную зону этого никогда не исправит. Прежде чем что-либо добавлять, подтвердите протолкнутую опцию DNS и домен поиска.
Что проверить при новом подключении
Переподключите клиента и убедитесь, что выданный адрес совпадает с его переопределением, прежде чем проверять что-то ещё. Затем разрешите имя со второго клиента и подключитесь к службе по имени, что проверяет запись DNS, маршрут и межсетевой экран вместе. Подтвердите обратный путь на стороне сервера, потому что имя, которое разрешается, пока служба остаётся недоступной, это проблема маршрутизации или политики, а не именования. Держите таблицу переопределений рядом со списком сертификатов, чтобы обе проверялись вместе.
Сертификат, перевыпущенный под другим общим именем, перестаёт совпадать со своим переопределением и возвращает клиента в динамический пул. Ожидайте этого после любого изменения личности.