Почему /24 в OpenVPN заканчивается клиентами раньше, чем вы ожидаете

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

Две топологии, две арифметические модели, и только одна из них соответствует префиксу, который обычно предполагают.

net30 расходует четыре адреса на клиента

net30 выделяет блок /30 на клиента, потому что каждая сессия моделируется как соединение «точка-точка» с адресом на каждом конце. В этот блок входят четыре адреса, а два пригодны к использованию, поэтому эффективное число клиентов — четверть подсети. На /24 это оставляет 64 блока, прежде чем выйдут собственный блок сервера и любые фиксированные назначения. Сообщаемый потолок около 63 — это арифметика, которая проявляется, а не настроенный максимум.

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

Границы пула важнее префикса

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

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

Найдите лимит, который действительно отказал клиенту

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

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

Смена топологии меняет план адресов

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

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

Определяйте размер пула от плана, а не от маски

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

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