Сколько WireGuard-пиров держит один сервер: замер по процессору, а не по конфигам

MAATRIX

«Сколько пиров можно добавить в WireGuard?» — вопрос с обманчиво простым ответом: сколько угодно, конфигурация этого не ограничивает. Но за ним обычно скрывается другой вопрос, на который так просто не ответить: «сколько пиров сервер реально потянет, чтобы всем хватило скорости и туннель не начал сыпаться». Это два разных вопроса с двумя разными ответами, и путать их — верный способ либо переплатить за железо, которое не нужно, либо получить деградацию в момент, когда команда выросла с пяти человек до пятидесяти. Разберём, где на самом деле лежит потолок, при чём тут многопоточность и как замерить свою реальную ёмкость, а не гадать по чужим цифрам.

Лимита на число пиров в конфигурации нет

WireGuard хранит пиров как записи в таблице ядра: публичный ключ, allowed-ips, endpoint, счётчики трафика. Добавить новый пир — это либо секция [Peer] в конфиге интерфейса, либо команда wg set:

wg set wg0 peer <PUBLIC_KEY> allowed-ips 10.0.0.5/32

Никакого встроенного потолка на количество таких записей в самом протоколе или в реализации wireguard-tools нет. Технически можно нагенерировать хоть тысячу пар ключей и прописать их все в один интерфейс — практика, кстати, встречается у VPN-провайдеров и в командных развёртываниях, когда конфиги штампуются скриптом. Пример такого подхода — массовая генерация конфигов и QR-кодов для онбординга: bash-скрипт массовой генерации клиентов WireGuard создаёт сразу N пар ключей и добавляет их в конфиг одной командой, без ручного набора каждого пира.

Единственные по-настоящему технические ограничения на этом уровне — размер адресного пространства, которое вы выделили под VPN-подсеть (в /24 умещается 254 клиентских адреса, в /16 — на порядки больше), и объём памяти ядра под саму таблицу пиров, который на практике исчисляется килобайтами на запись и не станет проблемой раньше, чем счёт пойдёт на десятки тысяч. Для подавляющего большинства сценариев — личный VPN, команда до сотни человек, парк IoT-устройств — этот предел не будет ограничением никогда. Вопрос «сколько пиров влезет в конфиг» в этом смысле почти не имеет практического смысла: влезет любое разумное число.

Где реально упирается сервер: шифрование каждого пакета

WireGuard спроектирован эффективно: шифрование идёт в контексте ядра Linux (модуль wireguard, начиная с ядра 5.6 — часть mainline), без затратных переходов между ядром и пользовательским пространством, и использует ChaCha20-Poly1305 — шифр, который остаётся быстрым даже без аппаратного ускорения AES-NI. Это даёт заметный запас по сравнению с классическим однопоточным OpenVPN — сравнение по CPU-нагрузке подробно разобрано в статье какой протокол VPN легче для CPU. Но «эффективно» не значит «бесплатно»: у любого шифрования есть цена на пакет, и она никуда не девается, просто она ниже, чем у альтернатив.

Важный нюанс, который часто упускают при прикидке ёмкости: нагрузка на CPU определяется не мегабитами в секунду, а пакетами в секунду (pps). Один и тот же объём трафика, переданный крупными пакетами (файл, бэкап, стриминг) или мелкими (голосовой звонок, игра, множество коротких TCP-сессий), создаёт совершенно разную нагрузку на шифрование — потому что криптографические и учётные операции выполняются на пакет, а не на байт. Сервер, который спокойно держит 500 Мбит/с одного стрима с крупными пакетами, может начать задыхаться на трети этой скорости, если трафик — это тысячи мелких UDP-пакетов от множества активных клиентов одновременно.

Поэтому упор в CPU почти всегда выглядит одинаково: во время нагрузочного теста mpstat -P ALL 1 или htop (клавиша 1 для разбивки по ядрам) показывает одно или несколько ядер около 100%, при этом скорость через туннель ниже, чем показывает голый iperf3 без VPN. Это прямой признак того, что упёрлись не в сеть и не в диск, а именно в шифрование, и добавление полосы пропускания канала здесь ничего не даст — нужны либо более быстрые ядра, либо их большее число, либо снижение числа одновременных активных пиров.

Роль многопоточности: WireGuard умеет несколько ядер, но не безгранично

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

Но многопоточность здесь помогает не любой нагрузке одинаково хорошо. Она эффективно раскладывается по ядрам, когда одновременно активно много независимых потоков трафика — то есть много разных пиров или много параллельных соединений в рамках одного пира. А вот один-единственный пир, который гонит непрерывный поток данных через одно TCP- или UDP-соединение, упирается в ограничения, характерные для любой сериализованной обработки одного потока: обработка пакетов одного логического потока трафика склонна выполняться последовательно, чтобы не нарушить порядок доставки, и здесь выигрыш от лишних ядер куда скромнее. Похожая логика разбирается в статье про сетевые прерывания: почему сетевая карта отбирает у вас целое ядро — там же про RSS и распределение прерываний по очередям, которое должно быть настроено до того, как многоядерность WireGuard вообще получит шанс проявиться: если все прерывания сетевой карты садятся на одно ядро, оно станет узким местом раньше, чем криптография успеет загрузить остальные.

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

Сценарии нагрузки: где число пиров имеет значение, а где нет

Один и тот же сервер под разные профили использования ведёт себя совершенно по-разному, и это стоит закладывать в оценку заранее, а не постфактум.

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

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

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

1. Симуляция нескольких активных пиров без парка реальных устройств. Сетевые неймспейсы Linux позволяют поднять несколько виртуальных клиентов на одной машине:

ip netns add peer1
ip netns add peer2
# в каждом неймспейсе — свой wg-интерфейс с отдельным конфигом клиента

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

2. Нагрузка через несколько параллельных iperf3-сессий, имитирующих несколько активных пиров одновременно:

# на сервере — несколько инстансов iperf3 на разных портах
iperf3 -s -p 5201
iperf3 -s -p 5202
iperf3 -s -p 5203

# с разных клиентов через свои туннели, одновременно
iperf3 -c 10.0.0.1 -p 5201 -t 60 -P 2

Запускайте тест волнами: сначала 2 активных пира, затем 5, затем 10, затем 20 — и на каждом шаге фиксируйте суммарную скорость и загрузку CPU. Точка, где суммарная пропускная способность перестаёт расти вместе с числом активных пиров (или начинает падать на пир) — и есть та самая реальная ёмкость сервера под конкретный профиль трафика.

3. Загрузка CPU по ядрам параллельно с тестом — обязательный шаг, без него цифра пропускной способности бессмысленна сама по себе:

mpstat -P ALL 1

Смотрите, растёт ли нагрузка равномерно по всем ядрам (хороший признак — многопоточность WireGuard действительно работает) или упирается в одно-два ядра при простаивающих остальных (признак того, что либо прерывания сетевой карты не распределены, либо трафик состоит из малого числа толстых потоков, которые плохо параллелятся). Отдельно смотрите на %soft — рост этой колонки говорит о нагрузке на обработку прерываний в сетевом стеке, которая может стать потолком ещё до того, как заметно вырастет чистая криптографическая нагрузка.

4. Статистика самого WireGuard по каждому пиру — сколько трафика реально прошло и когда был последний хендшейк:

wg show wg0 transfer
wg show wg0 latest-handshakes

Полезно сверять с результатами iperf3, чтобы убедиться, что тестовый трафик действительно идёт через нужных пиров, а не теряется по дороге из-за ошибки маршрутизации в тестовом стенде.

5. Если сервер — облачная виртуалка, отдельно проверьте steal time во время теста — часть CPU-времени может отбирать гипервизор у соседей по хосту, и тогда упор в производительность будет не в самом WireGuard, а в переподписанном тарифе. Как это распознать — в статье steal time: как понять, что сосед ест ваш CPU.

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

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