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

Порядок, которого придерживается распределитель

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

SituationAddress chosenPractical effect
Reconnect, old address still freeThe remembered addressRules appear stable for days
Old address taken by another clientLeast recently used free addressA working rule silently stops matching
Concurrent sessions, same nameFirst free address, per sessionOne identity can hold several leases

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

Почему аренда выглядит стабильной, а затем смещается

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

Пиковая одновременность — это число, под которое нужно проектировать, а не количество пользователей. Кто-то, тестирующий с двух устройств сразу, или клиент, переподключающийся до истечения старой сессии, на время занимает две аренды. Пул, рассчитанный только по числу людей, породит именно ту текучку, в которой люди винят сервер.

Файл постоянства помнит, но не резервирует

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

ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0

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

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

Как правильно закрепить адрес

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

# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0

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

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

Удалённый адрес — отдельный вопрос

Адрес в строке remote у клиента должен быть достижим до того, как появится какой-либо туннель. Если вписать туда адрес пула, например собственный конечный туннельный адрес сервера, клиент будет пытаться достичь этой точки через туннель, который ещё не построен, и результатом станет петля или тихий тайм-аут вместо короткого пути.

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

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