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

Это изменение работающего сервиса, поэтому относитесь к нему как к операционной задаче: сначала инвентаризация, затем применение через обычный жизненный цикл, проверка новым клиентом и подготовленный откат.

Начните с подсети, которая уже есть

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

Добавьте nopool и объявите диапазон

Вспомогательное ключевое слово принимает nopool, которое сохраняет конфигурацию подсети и отключает автоматический динамический пул, как описывает руководство OpenVPN 2.6. Затем явная строка ifconfig-pool задаёт нужный включающий диапазон, а её сетевая маска совпадает с подсетью. Обе строки относятся к одному блоку сервера, потому что пул без своей подсети не имеет смысла. Порядок между ними важен только для читаемости, так как помощник разворачивает пару при запуске сервиса.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

Размер диапазона и одновременность — разные ограничения. Сто адресов не означают сто одновременных клиентов, если max-clients говорит иное, а пул больше предела одновременности — это норма, а не расточительство. Важно, чтобы оба ограничения выбирались осознанно, а не наследовались от значения по умолчанию.

Держите фиксированные назначения вне динамического диапазона

Клиентский ifconfig-push — иной механизм, чем распределение из пула, и он должен использовать параметры, соответствующие активной топологии. В режиме подсети это один адрес и сетевая маска; перенос пары net30 только потому, что она встретилась в старом примере, — частая ошибка.

История распределения — подсказка, а не власть. Файл persist помнит, у какого клиента был какой адрес, поэтому переподключающиеся клиенты обычно получают тот же, и он не резервирует адреса, не освобождает их и не заменяет фиксированное назначение. Если конкретное устройство всегда должно иметь конкретный адрес, используйте фиксированное назначение, а не полагайтесь на файл persist.

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

Примените через жизненный цикл, затем проверьте

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Подключите клиента, который раньше не подключался, и подтвердите, что адрес попадает внутрь объявленного диапазона и вне зарезервированного набора. Затем подтвердите обратный путь: клиент должен достигать того, что разрешает политика, и не больше. Адрес, соответствующий плану, но без работающего маршрута, — не успешное изменение.

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

Откат изменения диапазона

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

Два предупреждения относятся к журналу. Клиенты, уже подключённые к моменту отката, сохраняют текущие адреса до переподключения, поэтому откат не мгновенен для всего парка. И если старый диапазон пересекался с фиксированным назначением, восстановление вернёт и конфликт; именно это пересечение было причиной изменения, и оно требует иного решения, чем откат.

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

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