Пропускная способность VPN-сервера: от чего зависит

MAATRIX

Вы арендовали сервер с «безлимитным гигабитным каналом», подняли WireGuard или OpenVPN — а по факту получаете 150-300 Мбит/с вместо ожидаемого гигабита. Первая мысль обычно «провайдер режет канал», но в девяти случаях из десяти дело не в сети, а в том, что происходит на самом сервере: однопоточный процесс шифрования упирается в частоту одного ядра CPU, а не в пропускную способность порта. Разберём по порядку, где на самом деле возникает потолок и как его сдвинуть.

Сеть провайдера: что реально ограничивает канал

Заявленная скорость порта (1 Гбит/с, 10 Гбит/с) — это физическая пропускная способность линка между сервером и коммутатором дата-центра. Она почти никогда не является узким местом для VPN на 1-50 одновременных пользователей: чтобы упереться в гигабит трафиком, нужно гнать сотни мегабит стабильно с нескольких клиентов одновременно, что для домашнего или малого офисного сценария избыточно.

Реальные ограничения на стороне сети три:

• Биллинговый лимит порта — часть тарифов физически даёт 100 Мбит/с или 200 Мбит/с даже на «гигабитной» карте, если это прописано в тарифе. Проверяется простым iperf3 тестом до сервера без VPN — если голый TCP уже упирается в цифру ниже заявленной, это ограничение провайдера, а не ваша настройка.
• Overselling канала — на бюджетных VPS канал делится между соседями по гипервизору. В часы пик скорость может проседать не из-за VPN, а из-за нагрузки соседей. Это не лечится настройками сервера — только сменой тарифа или провайдера.
• Маршрут и RTT до клиента — пропускная способность одного TCP-соединения (в том числе внутри VPN-туннеля) ограничена формулой окно / RTT. Если сервер в США, а клиент в Москве с RTT 150-180 мс, даже при свободном канале одна TCP-сессия может не выбрать всю полосу — помогает UDP-based протокол (WireGuard) и несколько параллельных потоков.

Прежде чем разбирать шифрование и CPU, стоит убедиться, что базовый канал вообще даёт нужную скорость — тест iperf3 -c IP -t 30 без поднятого туннеля снимает половину вопросов сразу.

CPU: где на самом деле упирается VPN

Это самое частое и самое неочевидное узкое место. VPN-туннель — это шифрование/дешифрование каждого пакета в реальном времени, и у большинства протоколов это либо однопоточный процесс, либо процесс с ограниченной параллелизацией.

OpenVPN в классической конфигурации (без --multihome и без нескольких инстансов) обрабатывает весь туннель одним процессом на одном ядре. Если у вас 8-ядерный сервер, но top во время нагрузочного теста показывает 100% на одном ядре openvpn и простаивающие остальные семь — это и есть потолок. Поднять его без смены протокола можно только повышением частоты CPU (не количества ядер) или переходом на несколько параллельных инстансов OpenVPN с балансировкой между ними.

WireGuard устроен иначе: шифрование идёт в ядре Linux (или через оптимизированный userspace на других ОС), и современные версии умеют использовать несколько ядер для обработки разных потоков одновременно, особенно при множестве параллельных клиентов. Поэтому на многоядерном сервере WireGuard почти всегда даёт заметно более высокую суммарную пропускную способность, чем OpenVPN на том же железе — какой протокол VPN выбрать разбирает это сравнение подробнее по сценариям.

Ключевой момент — наличие аппаратного ускорения шифрования AES-NI в процессоре. Проверить его наличие:

grep -m1 -o aes /proc/cpuinfo

Если команда вернула aes — инструкция есть, шифрование AES-256-GCM обрабатывается на уровне процессора почти бесплатно по CPU-времени. Если пусто — сервер работает на софтверном шифровании, и разница в пропускной способности между таким сервером и сервером с AES-NI может быть кратной, особенно под нагрузкой от нескольких клиентов сразу. Практически все современные серверные CPU (Xeon, EPYC) AES-NI поддерживают, но на дешёвых виртуалках со старыми хостами стоит проверить явно — не гадать по описанию тарифа.

Соответствие: AMD EPYC в выделенном сервере — если для вас критична пропускная способность VPN под нагрузкой, современный EPYC с AES-NI и высокой частотой ядра — разумный выбор, а не переплата.

Протокол шифрования: цена алгоритма в мегабитах

Не все шифры стоят одинаково по CPU. Порядок актуален для конца 2026 года:

Практический вывод: если у вас сервер без AES-NI (редко, но бывает на бюджетных нодах) — выбирайте ChaCha20-Poly1305 явно, не полагайтесь на дефолт. В WireGuard это не выбор — там ChaCha20-Poly1305 зашит по умолчанию, что отчасти объясняет его стабильно высокую пропускную способность на любом железе. В OpenVPN шифр задаётся явно:

# server.conf — современная безопасная и быстрая связка
data-ciphers AES-256-GCM:CHACHA20-POLY1305
data-ciphers-fallback AES-256-GCM

Отдельно стоит упомянуть AmneziaWG — форк WireGuard с обфускацией трафика для обхода DPI-блокировок. Обфускация добавляет небольшой, но ненулевой оверхед по CPU на каждый пакет (дополнительное преобразование заголовков). На практике разница в пропускной способности между чистым WireGuard и AmneziaWG на одном железе обычно в пределах 5-15%, но это ориентир, а не измеренная константа — зависит от конкретных параметров обфускации (Jc, Jmin, Jmax). Если DPI-блокировки не актуальны для вашего сценария, чистый WireGuard даст более предсказуемую полосу. Подробнее — в статье AmneziaWG против обычного WireGuard.

Число одновременных клиентов: как масштабируется нагрузка

Пропускная способность VPN-сервера — это не фиксированное число, а функция от количества активных сессий и характера их трафика.

Для WireGuard каждый клиент — это по сути отдельный набор ключей и счётчик пакетов, обработка которых у современного ядра Linux хорошо распараллеливается между CPU-ядрами через NAPI и multiqueue. Практически это значит: сервер с 4-8 ядрами и AES-NI/ChaCha20 может держать десятки одновременных клиентов с суммарной пропускной способностью, близкой к пропускной способности сетевого порта — если, конечно, все клиенты не пытаются одновременно выкачать данные на максимальной скорости.

Для OpenVPN картина хуже: если сервер держит один процесс openvpn, то все клиенты этого процесса делят одно ядро CPU. 5 клиентов, каждый качающий на 100 Мбит/с, суммарно требуют обработки 500 Мбит/с трафика одним ядром — и если частота ядра этого не тянет, каждый клиент получит меньше, чем ожидал, причём деградация будет одинаковой для всех, а не только для «лишних».

Практическая рекомендация для сценария с большим числом клиентов (компания, удалённая команда): VPN для удалённой команды: типовая схема описывает, как считать нагрузку заранее. Грубая прикидка для планирования:

• До 10-15 клиентов с умеренным трафиком (RDP, SSH, офисные приложения) — хватит 2-4 ядер с AES-NI на любом из протоколов.
• 15-50 клиентов или сценарий с постоянной передачей больших файлов/видео — WireGuard предпочтительнее, закладывайте 4-8 ядер современного CPU.
• 50+ клиентов на одном сервере — стоит думать не о наращивании ядер на одной ноде, а о горизонтальном масштабировании (несколько VPN-серверов с балансировкой) или о WireGuard mesh-конфигурации.

Отдельно учитывайте паттерн трафика: 50 клиентов, которые держат туннель открытым для эпизодического доступа к внутренним ресурсам, — это совсем не то же самое по нагрузке, что 50 клиентов, качающих backup или стримящих видео одновременно. Оценивайте по пиковому, а не по среднему сценарию.

Как измерить реальную пропускную способность туннеля

Не полагайтесь на «ощущение скорости» в браузере — измеряйте отдельно. Порядок диагностики:

1. Голый канал без VPN — iperf3 между сервером и клиентом напрямую по публичному IP. Это верхняя граница, выше которой туннель прыгнуть не может.
2. Канал через туннель — тот же iperf3, но клиент подключается к серверу iperf3 через VPN-адрес (10.x.x.x или что у вас в конфиге). Разница между шагом 1 и 2 — это цена туннелирования и шифрования на вашем железе.
3. Загрузка CPU во время теста — параллельно держите открытым htop (клавиша 1 покажет ядра по отдельности) или mpstat -P ALL 1 на сервере. Если во время iperf3-теста одно ядро уходит в 100%, а остальные простаивают — это подтверждает однопоточное узкое место (характерно для классического OpenVPN).

# на сервере
iperf3 -s

# на клиенте, вне туннеля
iperf3 -c <публичный_IP_сервера> -t 30 -P 4

# на клиенте, через туннель
iperf3 -c <VPN_IP_сервера> -t 30 -P 4

Флаг -P 4 запускает 4 параллельных потока — это важно, потому что один TCP-поток может не выбрать всю доступную полосу из-за окна и RTT, о чём говорилось выше. Если результат с -P 4 заметно выше, чем с -P 1, — задумайтесь о том, что приложение или тестовый инструмент клиента использует одно соединение и недооценивает реальный потолок.

Если тест показывает провал именно на шаге 2 (голый канал быстрый, через VPN медленный) при низкой загрузке CPU — ищите проблему не в шифровании, а в MTU (фрагментация пакетов режет скорость сильнее, чем кажется) или в буферах сокетов ядра — это уже смежная тема, разобранная в статье про канал 1G против 10G применительно к общей пропускной способности сервера.

Частые вопросы