Я оцениваю систему для клиента, где многие клиенты OpenVPN подключаются к серверу OpenVPN. «Много» означает 50000 - 1000000.
Почему я это делаю? Клиентами являются распределенные встраиваемые системы, каждый из которых сидит за системным владельцем dsl router. Сервер должен иметь возможность отправлять команды клиентам. Мой первый наивный подход - заставить клиентов подключаться к серверу через сеть openvpn. Таким образом, безопасный коммуникационный туннель может использоваться в обоих направлениях.
Это означает, что все клиенты всегда подключены к серверу. Есть много клиентов, подводящих итоги за эти годы.
Вопрос заключается в следующем: взрывается ли сервер OpenVPN при достижении определенного количества клиентов? Я уже знаю о максимальном количестве подключений TCP, поэтому (и по другим причинам) VPN должен будет использовать транспорт UDP.
Гуру OpenVPN, что вы думаете?
источник
Ответы:
Я сомневаюсь, что такая большая установка когда-либо предпринималась раньше, так что вы, вероятно, будете раздвигать пределы при попытке. Я мог найти статью о развертывании VPN для 400 клиентов, но, судя по тексту, автор просто полагался на приблизительные оценки того, сколько клиентов можно запустить на ЦП, и не понимал, как будут работать его настройки.
В основном вам необходимо учитывать следующие два момента:
Пропускная способность, которую будут использовать ваши передачи данных, потребует шифрования / дешифрования на стороне VPN-сервера, потребляя ресурсы ЦП.
Соединения клиента OpenVPN потребляют как ресурсы памяти, так и ресурсы ЦП на сервере, даже если данные не передаются
Любое приличное оборудование для ПК, доступное сегодня, должно легко насыщать гигабитное соединение с Blowfish или AES-128, даже встроенные устройства стоимостью $ 100 способны развивать скорость около 100 Мбит / с , поэтому узкие места ЦП из-за интенсивности полосы пропускания не должны вызывать беспокойства.
При заданном по умолчанию интервале между 3600 секундами количество клиентов в 1 000 000 будет означать, что серверу потребуется в среднем выполнять 278 обменов ключами в секунду. Хотя обмен ключами является довольно трудоемкой задачей, вы можете при необходимости разгрузить его на выделенное оборудование - доступные карты криптографического ускорителя легко соответствуют и превышают это количество рукопожатий TLS. И ограничения памяти не должны слишком беспокоить - 64-разрядный двоичный файл должен позаботиться о любых ограничениях виртуальной памяти, которые вы могли бы встретить в противном случае.
Но настоящая прелесть OpenVPN в том, что вы можете легко его масштабировать - просто установите произвольное количество серверов OpenVPN и убедитесь, что ваши клиенты их используют (например, через циклический перебор DNS), настройте протокол динамической маршрутизации по вашему выбору. (обычно это будет RIP из-за его простоты), и ваша инфраструктура будет способна поддерживать произвольное количество клиентов, если у вас достаточно оборудования.
источник
На самом деле я сделал это, хотя и с «всего лишь» несколькими сотнями удаленных подключений, аналогично DSL-маршрутизаторам. Я не могу комментировать слишком много вопросов о повторной покупке, но несколько практических вещей, которые я узнал по пути:
1) При развертывании клиентов убедитесь, что вы указали несколько VPN-серверов в клиентском conf, vpn1.example.com, vpn2.example.com, vpn3 ..... Даже если вы предоставляете только один или два из них сейчас, вы даете сам запас При правильной настройке клиенты будут повторять их наугад, пока не найдут тот, который работает.
2) Мы используем настраиваемый образ сервера AWS VPN и можем наращивать дополнительную емкость по требованию, а Amazon DNS (R53) обрабатывает аспекты DNS. Он полностью отделен от остальной части нашей инфраструктуры.
3) На стороне сервера (ов) тщательно используйте маску сети, чтобы ограничить число потенциальных клиентов. Это должно заставить клиентов перейти на альтернативный сервер, уменьшая проблемы с процессором. Я думаю, что мы ограничиваем наши серверы до 300 или около того клиентов. Этот выбор был несколько произвольным с нашей стороны - «чутье», если хотите.
4) Также на стороне сервера вы должны осторожно использовать брандмауэры. Проще говоря, наши настроены так, что клиенты могут подключаться к VPN, но серверы строго запрещают все входящие соединения ssh, кроме как с известного IP-адреса. Мы можем SSH для клиентов, если нам иногда это нужно, они не могут SSH для нас.
5) Не надейтесь, что OpenVPN выполнит переподключение за вас на стороне клиента. 9 раз из 10 так и будет, но иногда застревает. Отдельный процесс для регулярного сброса / перезапуска openVPN на стороне клиента.
6) Вам нужен способ генерирования уникальных ключей для клиентов, чтобы вы могли иногда дезавуировать их. Мы создаем их внутренне с помощью нашего процесса сборки сервера (PXEboot). Никогда с нами не бывало, но мы знаем, что можем это сделать.
7) Вам понадобятся некоторые инструменты управления, сценарии для эффективного мониторинга подключений к вашему VPN-серверу.
К сожалению, не так много материала о том, как это сделать, но это возможно при тщательной настройке.
источник
Обновление 2018
Не уверен, что все изменилось с 2012 года. Я просто хотел дать обновленную информацию о моем опыте в 2018 году. Мы развернули сеть openvpn, очень похожую на настройку OP. Наши конечные точки - полнофункциональные linux-устройства вместо встроенных устройств. У каждой конечной точки есть монитор, используемый для отображения информации и сигналов тревоги для этого сайта, а наш сервер позволяет нам удаленно управлять всеми конечными точками. Сеть не слишком активна, но иногда имеет 5-10 удаленных сеансов одновременно.
Используя текущую сборку openvpn на 100 клиентах на лазурном образе с одним ядром и 2 ГБ оперативной памяти, мы используем в среднем около 0,7% памяти, а загрузка ЦП почти всегда составляет около 0%. Исходя из того, что я нашел для этого меньшего теста, я полагаю, что один сервер с достойными характеристиками легко справится с 50000 одновременными, если у него будет оперативная память для его поддержки. Если бы оперативная память масштабировалась линейно, то 16 ГБ могли бы обрабатывать 50000 пользователей с достаточным количеством дополнительных ресурсов на выделенной машине openvpn.
Мы не в достаточно большом масштабе, чтобы сказать это со значительной уверенностью, но я просто хотел дать недавнее обновление, поскольку при первоначальном развертывании нашей сети я обнаружил это и ожидал гораздо большего использования ресурсов в таком масштабе. Теперь я верю, что процессор, на котором он работает, имеет аппаратное шифрование, и я не уверен, в какой момент это будет перегруженным трафиком, но для конечных точек, которые не очень много общаются, это не должно быть проблемой.
При 1000000 вам понадобится 200 ГБ оперативной памяти на одной машине (если линейно масштабируется с дополнительным), хотя это возможно, я думаю, что в этот момент вам нужно иметь 5 машин с 64 ГБ оперативной памяти, чтобы у вас не было ни одной точки неудачи. Это должно позволить техническое обслуживание, перезапуск и замену 1 или даже 2 машин без существенных проблем.
Мои оценки оперативной памяти, вероятно, слишком излишни, так как я делю все использование openvpn на количество клиентов, где только часть этого оперативной памяти приходится на клиентов.
Мы добавили 74 конечных точки в год с момента первоначального развертывания. Я надеюсь продолжать значительно увеличивать это число и внесу дальнейшие изменения, если мы доберемся до приличных масштабов.
источник
Я смотрю на подобную проблему, хотя число клиентов будет исчисляться сотнями, может быть, пару тысяч.
Я подумал, что не могу постоянно поддерживать связь всех клиентов.
Я думаю о запуске демона OpenVPN на клиентах через случайные промежутки времени, чтобы они могли проверить, были ли они опрошены. Если бы они были, они должны отправить электронное письмо или что-то, что они в сети и отправлять пакеты в течение определенного периода времени, чтобы я мог подключиться к ним.
Если в течение некоторого времени нет трафика, демон будет остановлен.
Проблема, с которой я сейчас сталкиваюсь, заключается в том, что невозможно получить список подключенных VPN-клиентов ...
источник