Продуктивність OpenVPN: скільки можливих одночасних клієнтів?

Я оцінюю систему для клієнта, де багато клієнтів OpenVPN підключаються до сервера OpenVPN. "Багато" означає 50000 - 1000000.

Чому я це роблю? Клієнтам розповсюджуються вбудовані системи, кожен сидить за власником системи маршрутизатора dsl. Сервер повинен мати можливість відправляти команди клієнтам. Перший мій наївний підхід - змусити клієнтів підключатися до сервера через мережу openvpn. Таким чином, безпечний тунель зв'язку може використовуватися в обох напрямках.

Це означає, що всі клієнти завжди підключені до сервера. За багато років клієнтів підбиваються підсумки.

Питання: чи вибухає сервер OpenVPN при досягненні певної кількості клієнтів? Мені вже відомо максимальне обмеження кількості TCP-з'єднань, тому VPN (і з інших причин) VPN повинен був би використовувати UDP-транспорт.

Гуру OpenVPN, що ви думаєте?

Я сумніваюся, що велика установка раніше не робилася спроб, тому ви, ймовірно, будете висувати обмеження при спробі. Я міг знайти статтю про розгортання VPN для 400 клієнтів, але, судячи з тексту, автор просто спирався на приблизні оцінки щодо того, скільки клієнтів можна запустити в одному процесорі, і не вистачило розуміння того, як буде працювати його налаштування.

В основному вам слід врахувати ці два моменти:

1. Пропускна здатність, яку будуть використовувати ваші передачі даних, потребує шифрування / дешифрування на стороні сервера VPN, що споживає ресурси ЦП.

2. Підключення клієнта OpenVPN споживають обидва, пам'ять та ресурси процесора на сервері, навіть коли дані не передаються

Будь-яке гідне обладнання, доступне сьогодні для ПК, повинно легко насичувати гігабітну зв’язок із Blowfish або AES-128, навіть 100 вбудованих пристроїв здатні зі швидкістю близько 100 Мбіт / с , тому вузькі місця процесора через інтенсивність пропускної здатності не повинні турбувати.

Зважаючи на інтервал перезавантаження за замовчуванням 3600 секунд, кількість 1 000 000 клієнтів означатиме, що серверу в середньому потрібно мати змогу завершити 278 обмінів ключів. Хоча обмін ключами є досить інтенсивним процесором завданням, ви можете перевантажити його на спеціальне обладнання, якщо потрібно - доступні криптографічні картки прискорювачів легко збираються та перевищують цю кількість рукостискань TLS. І обмеження пам’яті також не повинні сильно турбувати - 64-бітний двійковий файл повинен піклуватися про будь-які обмеження віртуальної пам’яті, на які ви, ймовірно, потрапите в іншому випадку.

Але справжня краса OpenVPN полягає в тому, що ви можете легко їх масштабувати - просто встановіть довільну кількість серверів OpenVPN і переконайтеся, що ваші клієнти ними користуються (наприклад, через DNS-круглий робот), налаштуйте динамічний протокол маршрутизації на ваш вибір. (як правило, це RIP через свою простоту), і ваша інфраструктура змогла б підтримувати довільну кількість клієнтів до тих пір, поки у вас достатньо обладнання.

Я фактично зробив це, хоча і з "лише" кількома сотнями віддалених з'єднань аналогічно за маршрутизаторами 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-сервера.

Тут не так багато матеріалів про те, як це зробити, на жаль, але можливо, при ретельному налаштуванні.

Оновлення 2018 року

Не впевнений, що все змінилося з 2012 року. Просто хотів дати оновлення щодо свого досвіду в 2018 році. Ми розгорнули мережу openvpn, дуже схожу на налаштування ОП. Наші кінцеві точки - це повноцінні комп'ютери Linux, а не вбудовані пристрої. Кожна кінцева точка має монітор, який використовується для відображення інформації та тривоги для цього сайту, і наш сервер дозволяє нам віднести одну точку до всіх кінцевих точок. Мережа не надто активна, але іноді має 5-10 віддалених сеансів одночасно.

Використовуючи поточну збірку openvpn у близько 100 клієнтів на блакитному зображенні з одним ядром та 2 Гб оперативної пам’яті, ми використовуємо в середньому близько 0,7% пам'яті, а використання процесора майже завжди становить близько 0%. Виходячи з того, що я знайшов для цього меншого тесту, я вважаю, що один сервер з гідними специфікаціями легко оброблятиме 50000 одночасно, якби у нього був таран, щоб його підтримати. Якщо використання оперативної пам’яті лінійно масштабується, то 16 Гб зможе обробляти 50000 користувачів з достатньою кількістю додаткових коштів на спеціальній машині openvpn.

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

При 1000000 вам знадобиться 200 Гб оперативної пам’яті на одній машині (якщо це лінійно масштабується із додатковими), хоча це можливо, я б подумав, що в цей момент ви хочете мати 5 машин у кожній із 64 ГБ оперативної пам’яті, щоб у вас не було жодної точки невдачі. Це повинно дозволити технічне обслуговування, перезавантаження та заміну 1 або навіть 2 машин без значних проблем.

Мої оцінки оперативної пам'яті, ймовірно, є надмірними, оскільки я ділю все використання openvpn на кількість клієнтів, де лише частина цього барана належить клієнтам.

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

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

Я подумав, що я не можу постійно підтримувати всіх клієнтів.

Я думаю запустити демон на OpenVPN для клієнтів через рандомізовані інтервали часу, щоб вони могли перевірити, чи опитували їх. Якщо вони були, вони повинні надіслати електронний лист або щось таке, що вони в Інтернеті, і надіслати збережені пакети протягом періоду часу, щоб я міг з ними підключитися.

Якщо на деякий час немає руху, демон буде зупинений.

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