Статический IP OpenVPN для каждого клиента: ifconfig-push, а не ipp.txt

Редактирование строки в ipp.txt кажется резервированием адреса, но это не так. Этот файл, именуемый ifconfig-pool-persist, записывает, какой адрес был у общего имени в прошлый раз, чтобы пул мог вернуть тот же, когда это удобно. Ничто в нём не привязывает следующее подключение к этому номеру.

Выполните проверки ниже по порядку. Каждая либо подтверждает механизм, либо говорит остановиться и исправить входные данные.

Для чего нужен файл сохранения

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

Если вам нужен конкретный адрес для конкретного клиента, документированный механизм — ifconfig-push, и он принадлежит конфигурации, которая владеет этим клиентом.

Проверьте, что выбран правильный клиент

Явное назначение ищется по общему имени клиента, поэтому файл, названный для неверной личности, просто никогда не читается. Подтвердите, что сервер считает именем этого клиента, особенно там, где username-as-common-name меняет его после аутентификации. Затем подтвердите, что имя файла точно соответствует этому значению, включая регистр.

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

Проверьте, что числа соответствуют топологии

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

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

Проверьте результат на новом подключении

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

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

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