Я провёл несколько тестов с коммерческим 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.
Результат оказался не таким, как я ожидал. Обе опции полностью загружали мой 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.
