Стабильные адреса OpenVPN должны следовать идентичности, а не исходному IP

Планы адресов, которые говорят «этот ноутбук получает 10.90.0.10», на самом деле являются утверждениями об идентичности: какое аутентифицированное устройство может держать этот адрес. Текущий публичный IP этого устройства почти не имеет к этому отношения, потому что NAT и роуминг меняют его, не меняя того, кто является пользователем. Построение плана на адресе источника даёт правила, которые ломаются в первой же гостиничной сети. Построение на аутентифицированной идентичности даёт план, который переживает поездки.

Начните с того, что сервер может проверить, затем решите, для чего нужен адрес.

Выберите ключ идентичности до адреса

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

С duplicate-cn несколько одновременных сеансов могут предъявить одно и то же общее имя, поэтому один закреплённый адрес не может отличить их друг от друга. Это свойство модели идентичности, а не то, что может исправить лучший план адресов.

Резервируйте адреса вне динамического диапазона

В сети с топологией подсети, например 10.90.0.0/24, держите младшие адреса для именованных участников, а динамический пул размещайте в отдельном диапазоне. Назначение для закреплённого участника выглядит так ifconfig-push 10.90.0.10 255.255.255.0 в файле, который сервер выбирает для этой идентичности. Второй аргумент при net30 означает другое, поэтому пример не нейтрален по отношению к топологии. Прочитайте топологию, прежде чем копировать его.

Устойчивость пула записывает недавние аренды и склонна возвращать тот же адрес, что является удобством, а не резервированием. Не позволяйте файлу устойчивости стать записью владения, потому что он меняется с историей подключений, а не с политикой.

Приоритет назначения решает, кто победит

Руководство документирует порядок: явное назначение, созданное во время client-connect, может вступить в силу раньше записи client-config-dir, которая, в свою очередь, предшествует обычному выделению из пула. Этот порядок объясняет большинство сообщений «закреплённый адрес не применился». Он также означает, что динамический распределитель, записывающий конфигурацию на каждый сеанс, может тихо переопределить статический файл, который вы считали авторитетным.

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

Динамическому распределителю нужна та же модель

Интеграция client-connect, которая выдаёт адреса на каждый сеанс, — это небольшой распределитель с обычными проблемами распределителя. Он должен проверять идентичность запрашивающего, атомарно резервировать адрес, выдавать только поддерживаемый вывод для соединения и освобождать резервирование при отключении или сбое. Одновременным запросам нужна блокировка или ограничение базы данных, а не последовательность «прочитать, затем записать». Без очистки пул теряет адреса до перезапуска.

Держите состояние распределителя там, где следующий оператор сможет его прочитать, и записывайте решение «идентичность — адрес», а не только адрес.

Решите, адрес — это политика или удобство

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

Запишите план как инвентарь с владельцем для каждой записи, затем пересмотрите его, когда устройство выводится из эксплуатации. Неиспользуемое резервирование — то, которое случайно используется повторно.