Производительность OpenVPN: сколько клиентов может работать одновременно?

Производительность OpenVPN: сколько клиентов может работать одновременно?

Я оцениваю систему для клиента, где много клиентов OpenVPN подключаются к серверу OpenVPN. «Много» означает 50000 - 1000000.

Зачем я это делаю? Клиенты — это распределенные встроенные системы, каждая из которых находится за маршрутизатором dsl владельца системы. Сервер должен иметь возможность отправлять команды клиентам. Мой первый наивный подход — заставить клиентов подключаться к серверу через сеть openvpn. Таким образом, защищенный туннель связи может использоваться в обоих направлениях.

Это означает, что все клиенты всегда подключены к серверу. Клиентов много, суммируясь за эти годы.

Вопрос в том:сервер OpenVPN взрывается при достижении определенного количества клиентов? Я уже знаю о максимальном лимите числа TCP-подключений, поэтому (и по другим причинам) VPN должен будет использовать транспорт UDP.

Гуру OpenVPN, каково ваше мнение?

решение1

Я сомневаюсь, что когда-либо была предпринята попытка создать такую ​​большую установку, поэтому вы, скорее всего, будете выходить за рамки, когда попробуете. Я мог бы найти статью наРазвертывание VPN для 400 клиентовОднако, судя по тексту, автор просто полагался на грубые оценки того, сколько клиентов может быть запущено на одном процессоре, и не имел представления о том, как будет работать его установка.

В первую очередь вам необходимо рассмотреть следующие два момента:

  1. Пропускная способность, которую будут использовать ваши передачи данных, потребует шифрования/дешифрования на стороне VPN-сервера, что потребляет ресурсы ЦП.

  2. Клиентские соединения OpenVPN потребляют как память, так и ресурсы ЦП на сервере, даже если данные не передаются.

Любое приличное компьютерное оборудование, доступное сегодня, должно легко насытить гигабитное соединение с помощью Blowfish или AES-128, даже встраиваемые устройства стоимостью 100 долларовспособен достигать скоростей около 100 Мбит/с, поэтому узкие места ЦП из-за интенсивности использования полосы пропускания не должны вызывать беспокойства.

Учитывая интервал смены ключей по умолчанию в 3600 секунд, количество клиентов в 1 000 000 будет означать, что сервер должен будет иметь возможность выполнять 278 обменов ключами в секунду в среднем. Хотя обмен ключами является довольно интенсивной задачей для процессора, вы можете переложить ее на выделенное оборудование, если это необходимо - доступные карты криптографического ускорителя легко удовлетворяют и превышают это количество рукопожатий TLS. И ограничения памяти также не должны слишком беспокоить - 64-битный двоичный код должен позаботиться о любых ограничениях виртуальной памяти, с которыми вы, вероятно, столкнетесь в противном случае.

Но настоящая прелесть OpenVPN в том, что вы можете довольно легко масштабировать его — просто настройте произвольное количество серверов OpenVPN и убедитесь, что ваши клиенты их используют (например, с помощью DNS round-robin), настройте протокол динамической маршрутизации по вашему выбору (обычно это RIP из-за его простоты), и ваша инфраструктура сможет поддерживать произвольное количество клиентов, если у вас достаточно оборудования.

решение2

Я действительно сделал это, хотя и с "всего" несколькими сотнями удаленных подключений, аналогично за маршрутизаторами 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-серверу.

К сожалению, не так много материалов о том, как это сделать, но это возможно при тщательной настройке.

решение3

Обновление 2018

Не уверен, что все изменилось с 2012 года. Просто хотел бы предоставить обновленную информацию о моем опыте в 2018 году. Мы развернули сеть openvpn, очень похожую на настройку OP. Наши конечные точки — это полноценные ПК Linux вместо встроенных устройств. Каждая конечная точка имеет монитор, используемый для отображения информации и сигналов тревоги для этого сайта, а наш сервер позволяет нам использовать одну точку для удаленного доступа ко всем конечным точкам. Сеть не слишком активна, но иногда в ней происходит 5-10 удаленных сеансов одновременно.

Используя текущую сборку openvpn примерно на 100 клиентах на образе Azure с одним ядром и 2 ГБ оперативной памяти, мы используем около 0,7% памяти в среднем, а загрузка процессора почти всегда около 0%. На основе того, что я нашел для этого небольшого теста, я полагаю, что один сервер с приличными характеристиками легко справился бы с 50000 одновременных подключений, если бы у него была оперативная память для этого. Если бы использование оперативной памяти масштабировалось линейно, то 16 ГБ могли бы справиться с 50000 пользователей с достаточным количеством на выделенной машине openvpn.

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

При 1000000 вам понадобится 200 ГБ оперативной памяти на одной машине (если масштабировать линейно с дополнительными), хотя это возможно, я думаю, что в этот момент вам захочется иметь 5 машин с 64 ГБ оперативной памяти на каждой, чтобы у вас не было единой точки отказа. Это должно позволить проводить обслуживание, перезапуски и замену 1 или даже 2 машин без существенных проблем.

Мои оценки оперативной памяти, вероятно, сильно преувеличены, поскольку я делю все использование OpenVPN на количество клиентов, где только часть этой оперативной памяти приходится на клиентов.

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

решение4

Я изучаю похожую проблему, хотя количество клиентов исчисляется сотнями, может быть, парой тысяч.

Я понял, что не смогу постоянно держать всех клиентов на связи.

Я думаю о запуске OpenVPN daemon на клиентах в случайные интервалы времени, чтобы они могли проверить, были ли они опрошены. Если они были, они должны отправить электронное письмо или что-то еще, что они онлайн, и отправить пакеты keep alive в течение определенного периода времени, чтобы я мог подключиться к ним.

Если трафик отсутствует в течение некоторого времени, демон останавливается.

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

Связанный контент