Какой протокол VPN легче для CPU: сравнение

MAATRIX

Сервер с VPN упирается не в диск и не в память — он упирается в процессор. Каждый пакет нужно зашифровать или расшифровать, а на слабом или сильно загруженном CPU это превращается в узкое место раньше, чем закончится канал. Разбираемся, почему WireGuard, OpenVPN и IPsec грузят процессор по-разному, откуда берётся разница и как посчитать, сколько ядер понадобится под вашу нагрузку.

Почему протокол решает, сколько клиентов потянет сервер

VPN — это, по сути, конвейер: пакет приходит на сетевой интерфейс, шифруется (или расшифровывается), заворачивается в туннель и уходит дальше. На каждый пакет тратится время CPU — на криптографию, на копирование данных между областями памяти, на переключения контекста между ядром и пользовательским процессом. Чем больше накладных расходов на пакет, тем меньше пакетов в секунду выдержит одно ядро при том же уровне загрузки.

Это напрямую влияет на экономику сервера. Если протокол тратит на пакет вдвое больше CPU-времени, то и клиентов на той же машине он обслужит примерно вдвое меньше, прежде чем упрётся в потолок. На VPS с 1-2 vCPU, которые чаще всего берут под личный или небольшой командный VPN, разница ощущается быстрее всего: недорогой тариф с WireGuard может свободно тянуть то, что на OpenVPN уже начинает тормозить.

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

WireGuard: шифрование в ядре и ChaCha20-Poly1305

WireGuard спроектирован с прицелом именно на минимальные накладные расходы. Он работает как модуль ядра Linux (начиная с ядра 5.6 — уже часть mainline, на более старых системах ставится отдельным модулем), а значит пакет обрабатывается прямо в контексте ядра, без лишних переходов в пользовательское пространство и обратно. Каждый такой переход — это переключение контекста и копирование данных, и именно от них WireGuard избавляется почти полностью.

Для шифрования по умолчанию используется связка ChaCha20-Poly1305 (AEAD-шифр) вместе с Curve25519 для обмена ключами и BLAKE2s для хеширования — фиксированный набор без права выбора. ChaCha20 создавался как шифр, который быстро работает программно, без обязательной аппаратной поддержки: в отличие от AES, ему не нужен отдельный набор инструкций процессора, чтобы быть эффективным. На серверах без AES-NI (бюджетные ARM-инстансы, старые или урезанные виртуальные CPU) WireGuard не проседает так, как AES-шифрование без аппаратного ускорения.

Дополнительный выигрыш даёт компактность кода — реализация WireGuard на порядки меньше, чем у OpenVPN, а меньше кода означает меньше точек, где процессорное время теряется на служебную логику вместо полезной работы. На практике WireGuard хорошо утилизирует несколько ядер: обработка трафика разных пиров распараллеливается силами планировщика ядра, а не упирается в один поток одного процесса.

OpenVPN: userspace, TUN/TAP и цена гибкости

OpenVPN в классической конфигурации работает как процесс в пользовательском пространстве. Пакет из TUN-интерфейса ядра нужно скопировать в память процесса OpenVPN, обработать (расшифровать, проверить целостность), а затем передать обратно в сеть — и на каждом таком проходе происходит переключение между ядром и пользовательским процессом. Это фундаментальная разница с WireGuard: даже при одинаковом шифре OpenVPN тратит больше CPU-времени просто на архитектуру передачи данных.

Криптографическая часть у OpenVPN гибкая — можно выбрать AES-256-GCM, AES-256-CBC и другие шифры через OpenSSL. Ключевой фактор здесь — поддержка AES-NI на процессоре. На современных серверных CPU (Intel и AMD последних поколений) AES-NI есть, и AES-256-GCM обрабатывается аппаратно быстро — разрыв с WireGuard по чистой криптографии сокращается. Но стоит потерять AES-NI — на старом железе, урезанных виртуальных CPU, отдельных ARM-платформах — и AES без аппаратного ускорения становится заметно тяжелее для процессора, тогда как ChaCha20 у WireGuard просаживается меньше.

Ещё один нюанс — многопоточность. Классический процесс OpenVPN обрабатывает канал данных преимущественно в одном потоке на один процесс: даже на многоядерном сервере один инстанс не размажет нагрузку по всем ядрам сам по себе. Чтобы задействовать несколько ядер, приходится поднимать несколько инстансов OpenVPN на разных портах и балансировать клиентов между ними вручную — рабочий, но не самый удобный путь по сравнению с тем, как WireGuard использует многоядерность через сетевой стек ядра.

IPsec: тоже ядро, но другая история накладных расходов

IPsec (в связке с strongSwan, Libreswan или встроенным стеком, например через IKEv2) часто ошибочно ставят в один ряд с OpenVPN по нагрузке на CPU — но это не совсем справедливо. Сам канал данных IPsec на Linux обрабатывается ядром через подсистему XFRM, то есть шифрование пакетов тоже происходит в контексте ядра, а не в userspace-процессе. По архитектуре передачи данных это ближе к WireGuard, чем к классическому OpenVPN.

Разница в другом. Во-первых, IPsec тяжелее по протоколу согласования: IKEv1/IKEv2 — сложные протоколы с множеством фаз согласования параметров, что создаёт дополнительную нагрузку при установлении и переустановлении сессий (заметно при частых реконнектах или массовом подключении клиентов). Во-вторых, инкапсуляция ESP и обвязка NAT-T добавляют служебные заголовки поверх самого шифрования. В-третьих, IPsec с AES-GCM так же сильно зависит от AES-NI, как и OpenVPN — без аппаратного ускорения нагрузка на пакет растёт.

Итог по IPsec: на сервере с AES-NI и не слишком частыми переподключениями нагрузка на канал данных сопоставима с WireGuard, потому что оба работают в ядре. Но по совокупной нагрузке — с учётом согласования сессий и служебных заголовков — IPsec почти всегда требует больше CPU, чем WireGuard, и его сложнее предсказуемо масштабировать под большое число клиентов.

Сравнение и практический ориентир по ядрам

Как это переносится на практику. Если у вас 1-2 vCPU и десяток-другой клиентов с обычным веб-трафиком — разница между протоколами вряд ли будет заметна, упереться в CPU на таком профиле сложно. Она проявляется под нагрузкой: много одновременных клиентов, высокая пропускная способность, слабый или урезанный виртуальный CPU без AES-NI. В таких условиях WireGuard обычно даёт заметный запас по CPU по сравнению с OpenVPN на том же железе — это подтверждают и независимые бенчмарки сообщества, и измерения авторов WireGuard, хотя точная кратность разницы всегда зависит от конкретного CPU, ядра и профиля трафика (мелкие пакеты нагружают иначе, чем крупные) — конкретные цифры лучше не переносить с чужого железа на своё, а измерить на месте.

Если вы уже выбираете протокол под конкретный сценарий, а не только под нагрузку на CPU, пригодится более широкий разбор: WireGuard или OpenVPN: что выбрать для сервера — там учтены ещё маскировка трафика и обход блокировок, которые иногда важнее чистой производительности.

Как измерить нагрузку на своём сервере

Не верьте на слово ни чужим бенчмаркам, ни этой статье — на своём железе разница может отличаться от типичной картины. Вот рабочий набор команд, чтобы посмотреть реальную нагрузку.

Общая загрузка CPU по ядрам во время теста — mpstat из пакета sysstat:

mpstat -P ALL 1

Смотрите на колонки %usr и %sys — если %sys (время в ядре) резко растёт при включении OpenVPN, это цена переходов ядро-userspace, о которой шла речь выше. В htop процесс openvpn виден отдельной строкой: если он упирается в 100% на одном ядре, пока остальные простаивают, — явный признак того, что процесс не масштабируется на несколько ядер.

Тест пропускной способности через поднятый туннель — iperf3 (сервер на одной стороне, клиент на другой):

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

# на клиенте через VPN-туннель
iperf3 -c 10.0.0.1 -t 30 -P 4

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

Статистика самого WireGuard — сколько трафика прошло через каждый пир:

wg show all transfer

Для OpenVPN полезна встроенная статистика через management-интерфейс (если он включён в конфиге директивой management):

echo "status" | nc -q 1 127.0.0.1 7505

Запускайте mpstat и htop параллельно с тестом iperf3 под разной нагрузкой (1, 4, 16 параллельных потоков) — так видно не только пиковую пропускную способность, но и то, как растёт нагрузка на CPU по мере роста числа клиентов. Именно эта зависимость, а не разовый замер на пустом канале, и определяет, сколько пользователей реально потянет сервер.

Что выбрать под свою нагрузку

Если сервер один, клиентов немного и канал не насыщен — берите WireGuard просто потому, что он проще в настройке и не создаёт лишней работы админу, а запас по CPU у него в любом случае больше. Подробная установка есть в отдельной инструкции: Как установить и настроить WireGuard на VPS.

Если важнее обход блокировок и маскировка под HTTPS, а не чистая производительность, — понадобится OpenVPN, и тогда закладывайте CPU с запасом: тариф на 2+ vCPU, шифр AES-256-GCM вместо устаревшего CBC, и проверка, что AES-NI действительно проброшен гипервизором: cat /proc/cpuinfo | grep aes. Установка описана здесь: Как установить и настроить OpenVPN на VPS.

Если инфраструктура завязана на IPsec по требованиям совместимости (корпоративные или встроенные VPN-клиенты ОС) — держите в уме нагрузку от согласования сессий, а не только от передачи данных, особенно при частых реконнектах. Альтернативная реализация через Libreswan разобрана в статье L2TP/IPsec через Libreswan: альтернатива.

Для всех трёх протоколов справедливо одно: на слабом CPU без AES-NI и под плотной нагрузкой запас у WireGuard больше при прочих равных — если задача выжать максимум клиентов с минимального тарифа, начинать стоит с него.

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