http://mikrotik.moscow Новое в теме Производительность WireGuard и IPSec форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sun, 24 May 2026 19:07:46 +0300 Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Ну, может, в каких-то особых случаях стоит использовать один туннель. Мощный процессор обычно включает ещё более мощное аппаратное ускорение AES. Если важна производительность — выбирайте IPsec, а если нет — инвестируйте в ферму серверов Wireguard.
15.09.2023 09:57:00, Larsa.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408233 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408233 Fri, 15 Sep 2023 09:57:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
И всё равно – зависит от ситуации. Даже при аппаратном ускорении IPSEC с обеих сторон WG иногда может работать быстрее, например, если процессор достаточно мощный. Сначала посмотрите, что реально подходит именно вам. Проведите тесты для разных вариантов. Выбирайте то, что лучше и практичнее (самое быстрое не всегда самое удобное).
15.09.2023 09:45:00, holvoetn.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408232 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408232 Fri, 15 Sep 2023 09:45:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Итог для достижения максимальной производительности: используйте IPsec, если на обоих концах доступно аппаратное ускорение. В остальных случаях применяйте Wireguard.
15.09.2023 09:07:00, Larsa.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408231 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408231 Fri, 15 Sep 2023 09:07:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Хотя я больше предпочитаю и люблю wireguard, не думайте, что ipsec скоро исчезнет.
15.09.2023 09:06:00, holvoetn.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408230 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408230 Fri, 15 Sep 2023 09:06:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Прощай, IPsec
15.09.2023 09:01:00, mantouboji.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408229 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408229 Fri, 15 Sep 2023 09:01:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Если кто-то интересуется, как Wireguard работает между CCR2004 и hAp ax2, вот результаты тестов. Ссылки с обеих сторон — 1 Гбит/с, пинг — около 1 мс.
15.09.2023 08:25:00, ArunasV.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408228 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408228 Fri, 15 Sep 2023 08:25:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Мне было интересно, как бы выглядело сравнение между IPSec и Wireguard в ситуации с несколькими туннелями — где-то от 600 до 900, с средним трафиком 2-3 Мбит/с на туннель, работающими на CCR1036 с 36 ядрами по 1200 МГц.
15.06.2023 22:51:00, fischerdouglas.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408227 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408227 Thu, 15 Jun 2023 22:51:00 +0300 RouterOS Производительность WireGuard и IPSec RouterOS в форуме RouterOS.
Я провёл несколько тестов с коммерческим VPN-провайдером на hAP ac2. Провайдер поддерживает как WireGuard, так и IKEv2 IPSec, и мне было интересно посмотреть, как в деле проявляется аппаратное ускорение IPSec. Я использовал компьютер с фиксированным IP, который маршрутизировался через VPN, применяя правила маршрутизации для WireGuard и srcnat для IPSec (чтобы совпадать с политикой). Тестировал по одному сценарию, отключая другой.

Результат оказался не таким, как я ожидал. Обе опции полностью загружали мой WAN-канал на 120 Мбит, так что с этим проблем не было. При IPSec один из ядер процессора роутера загружался на 70-80%, иногда доходило до 90%. Профилирование показало, что большая часть времени процессора уходит на сетевые задачи. Другие ядра использовались значительно меньше, четвёртое ядро почти не задействовалось. Общая загрузка процессора была около 35-40%. В окне установленных SA я видел EH - HW-AEAD, что говорит о том, что шифрование выполнялось аппаратно.

С WireGuard общая загрузка CPU была выше, как и ожидалось — 50-60%, но использовались все ядра гораздо лучше. Самое загруженное ядро работало на 60-70% — меньше, чем при IPSec. Два ведущих ядра были загружены почти одинаково. Профилирование показало, что главной категорией была «unclassified», а категория wireguard составляла всего пару процентов.

Поскольку при WireGuard мне не нужно отключать fasttrack, я также следил за графиком этого правила фаервола. Был небольшой fasttracking, примерно 3-8 Мбит/с, часть трафика, вероятно, принадлежала другим устройствам в сети. Но этого было недостаточно, чтобы серьёзно нагрузить CPU в данном тесте.

У меня несколько десятков правил фаервола, включены очередь HTB на интерфейсе и fasttrack. Для IPSec пришлось добавить правило, чтобы обходить fasttrack для устройства, маршрутизированного через VPN. В обоих сценариях masquerade NAT не fasttracked, поскольку после инкапсуляции пакет исходит от самого роутера, значит цепочка вывода никогда не fasttracked. Так что, думаю, fasttrack здесь не играет роли.

Вывод такой: аппаратно ускоренный IPSec в данном случае не дал никаких преимуществ по сравнению с CPU-шифрованием WireGuard. Наоборот, с IPSec быстрее достигается предел одного ядра. Я всегда думал, что IPSec-ускорение — это как запасной аппаратный ресурс. Но оказалось, что в реальной жизни он не так полезен. Конечно, если бы мне IPSec понадобился по другим причинам, уверен, без ускорения было бы значительно хуже.

Ещё я понимаю, что не все устройства имеют 4-ядерные ARM CPU, как у hAP ac2, которые так хорошо справляются с WireGuard. Что-то вроде hEX, скорее всего, отдаст предпочтение IPSec — у него выше тактовая частота CPU (лучше для одноядерной нагрузки) и меньше ядер (хуже для WireGuard). Хотя не уверен, что можно напрямую сравнивать эти архитектуры.

Тем не менее, меня до сих пор удивляет, как получается, что аппаратно ускоренный IPSec использует больше CPU. Да, общая загрузка меньше, но неясно, сколько из этого можно было бы использовать для повышения пропускной способности WAN, если узким местом становится одно ядро.

Поток пакетов между двумя вариантами почти не отличается:

WireGuard:  
Устройство -> правило маршрутизации в WG -> srcnat -> шифрование и инкапсуляция WG -> маршрутизация на WAN -> masquerade NAT

IPSec:  
Устройство -> маршрутизация на WAN -> srcnat -> сопоставление с IPSec политикой -> аппаратное шифрование и инкапсуляция IPSec -> маршрутизация на WAN -> masquerade NAT

Если это правильно, значит обработка сопоставления с IPSec политикой довольно тяжёлая. Я также подозреваю, что аппаратно шифруется только шифрование, а инкапсуляция всё ещё делается CPU. То есть для IPSec получается двойная инкапсуляция (ESP, а затем NAT-T), в отличие от единственной в WireGuard.

Возможно, MTU был не оптимален для IPSec, и если происходила фрагментация пакетов, это добавляло нагрузки на процессор. Хотя в моём случае не пришлось настраивать MTU специально ни для одной из реализаций.

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

Может, я что-то упускаю? Будет интересно услышать ваш опыт работы с аппаратным ускорением IPSec на устройствах MikroTik и как это влияет на загрузку CPU.
25.07.2022 02:16:00, anserk.]]> http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408226 http://mikrotik.moscow/forum/forum57/86576-proizvoditelnost-wireguard-i-ipsec/message408226 Mon, 25 Jul 2022 02:16:00 +0300 RouterOS