Я оцениваю систему для клиента, в которой многие клиенты OpenVPN подключаются к серверу OpenVPN. «Многие» означает 50000 - 1000000.
Зачем я это делаю? Клиенты - это распределенные встроенные системы, каждый из которых находится за маршрутизатором dsl, владельцем которого является система. Сервер должен иметь возможность отправлять команды клиентам. Мой первый наивный подход - заставить клиентов подключаться к серверу через сеть openvpn. Таким образом, безопасный коммуникационный туннель можно использовать в обоих направлениях.
Это означает, что все клиенты всегда подключены к серверу. Многие клиенты подводят итоги годами.
Вопрос в том: взрывается ли сервер OpenVPN при достижении определенного количества клиентов? Мне уже известно о максимальном ограничении количества TCP-соединений, поэтому (и по другим причинам) VPN должен будет использовать транспорт UDP.
Гуру OpenVPN, каково ваше мнение?
Я действительно сделал это, хотя и «всего» с несколькими сотнями удаленных подключений точно так же за маршрутизаторами DSL. Я не могу слишком много комментировать вопросы смены ключей, но несколько практических вещей я узнал по пути:
1) При развертывании клиентов убедитесь, что вы указали несколько серверов VPN в конфигурации клиента, 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-сервера.
К сожалению, материала о том, как это сделать, не так много, но это возможно при тщательной настройке.
Я сомневаюсь, что когда-либо пытались создать такую большую установку, поэтому вы, вероятно, будете выходить за рамки, пытаясь. Я мог найти статью о Развертывание VPN на 400 клиентов но, судя по тексту, автор просто полагался на приблизительные оценки того, сколько клиентов может быть запущено на один процессор, и не понимал, как будет работать его установка.
В основном вам нужно учитывать эти два момента:
Пропускная способность, которую будут использовать ваши передачи данных, потребует шифрования / дешифрования на стороне сервера VPN, потребляя ресурсы ЦП.
Клиентские подключения OpenVPN потребляют ресурсы как памяти, так и ЦП на сервере, даже если данные не передаются.
Любое достойное оборудование для ПК, доступное сегодня, должно легко заполнить гигабитный канал Blowfish или AES-128, даже встроенные устройства за 100 долларов скорость около 100 Мбит / с, поэтому узкие места ЦП из-за высокой пропускной способности не должны вызывать беспокойства.
Учитывая интервал смены ключей по умолчанию, равный 3600 секундам, число 1000000 клиентов будет означать, что серверу потребуется в среднем 278 обменов ключами в секунду. Хотя обмен ключами является довольно интенсивной задачей для ЦП, при необходимости вы можете переложить его на выделенное оборудование - доступные карты криптографического ускорителя легко соответствуют и превышают это количество подтверждений TLS. И ограничения памяти тоже не должны сильно беспокоить - 64-битный двоичный файл должен позаботиться о любых ограничениях виртуальной памяти, которые вы могли бы столкнуться в противном случае.
Но настоящая прелесть OpenVPN в том, что вы можете легко масштабировать его - просто настройте произвольное количество серверов OpenVPN и убедитесь, что ваши клиенты используют их (например, с помощью циклического перебора DNS), настройте протокол динамической маршрутизации по вашему выбору. (обычно это RIP из-за его простоты), и ваша инфраструктура будет способна поддерживать произвольное количество клиентов, если у вас достаточно оборудования.
Обновление 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 ...