Pfsense+Proxmox+AMD Ryzen+AES-NI
-
Но тот же https://nguvu.org рекомендует указывать в настройках OpenVPN RDRAND
Ес-но, потому что у него Intel. Об этом он и указал ранее.
Можно же и проверить (имея гигабитную сеть), создав на LAN openvpn-сервер и потестить, пользуя iperf\jperf.
-
Ес-но, потому что у него Intel. Об этом он и указал ранее.
Как раз выбор RDRAND и не кажется естественным.
Почему RDRAND, не имеющий отношения к шифорованию AES, а не BSD cryptodev engine?Официальный мануал, хотя, похоже, несколько устаревший:
https://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported#OpenVPNТут разработчики вообще советуют не включать поддержку:
https://www.reddit.com/r/PFSENSE/comments/5lric3/aesni_not_selectable_in_24_beta/
https://www.reddit.com/r/PFSENSE/comments/5nnwzy/openvpn_throughput_question/[–]jim-p 2 points 9 months ago
OpenVPN will use what it can find automatically.
Only AES-GCM will be accelerated with OpenVPN 2.4 and the AES-NI module loaded, so you might want to unload that so OpenVPN/OpenSSL can use AES-NI directly.
[–]jim-p 2 points 9 months ago
So unload aes-ni.
It should not be loaded as the same time as the BSD cryptodev engine.
Правда информация могла и устареть.
Можно же и проверить (имея гигабитную сеть), создав на LAN openvpn-сервер и потестить, пользуя iperf\jperf.
Непременно, но сейчас такой возможности нет. -
Немного по AES + HMAC
https://www.reddit.com/r/PFSENSE/comments/5l45jk/openvpn_240_is_now_available_on_pfsense_24/
OpenVPN 2.4 ignores the auth directive when using AES-GCM so it doesn't matter what you choose there, actually. That's handy, it prevents accidentally hobbling the setting.
Choose AES-NI in misc, then select "Intel RDRAND engine (RAND)" at the OpenVPN client editor. If you can select AES-NI, you should be good to go for hardware accel. You can push data directly to your CPU over virtualization with modern CPUs, so your environment should support it.
https://www.mail-archive.com/list@lists.pfsense.org/msg09463.html
The other issue is that encryption without a HMAC is all but worthless. (It
increases privacy, but not security.) Typically the HMAC involves an entire
second pass over the packet, and this isn’t accelerated. Very new Intel CPUs
have some acceleration support for SHA (SHA1, SHA256, etc), but it’s not
anything like hardware offload.https://forum.pfsense.org/index.php?topic=107329.0
AES-CBCis accelerated by AES-NI. The issue is that the HMAC is not. This is one of the two reasons why AES-GCM is faster.
-
Хороший конспект, свели многое, что читал и сам в единый список.
Придется считать, что выбор rdrand для поддержки AES-NI - это багофича особенность реализации.
И да, у вас с Ryzen rdrand выбрать возможно? -
Bug #7810
openssl/openvpn need to have loaded booth AESNI and cryptodev to accelerate AES operations , but gui alows you load only one at once
Будет исправлено в 2.4.1
https://redmine.pfsense.org/issues/7810https://doc.pfsense.org/index.php/2.4.1_New_Features_and_Changes
-
Несколько недель сам разбирался с OpenVPN и аппаратным шифрованием, в версии 2.4.0 (и девелоп 2.4.2а) AES-NI вкл/вкл в настройках PFSense практически никак не влияют на результаты работы / тестов OpenVPN, т.к. если есть AES-NI, то он используется автоматически.
Для CPU intel лучше использовать GCM шифрование в виду большей оптимизации процессора под этот алгоритм, RDRAND не имеет никакого отношения к AMD процессорам, это алгоритм аппараттной генерации рандомных чисел от интел начиная с процессоров Ivy Bridge. В некоторых сценариях шифрования незначительно повышает производительность на процессорах Intel.Для сравнения (процессор Celeron 3865U 2x1.8 ГГц):
openssl speed -elapsed -evp aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 443432.92k 472857.02k 477686.25k 482970.28k 483590.14kopenssl speed -elapsed -evp aes-256-gcm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-gcm 293267.67k 786376.13k 1204654.15k 1294190.33k 1331465.46kНа GCM разница с CBC колоссальная.
На практике при шифровании 256-GCM скорость туннеля на данном процессоре порядка 50 МБ/с (до 500 мбит).
Для AMD не могу знать, т.к. нет под руками ничего современно-толкового.
-
На GCM разница с CBC колоссальная
Однако минус в том, что многие "железные" клиентские устройства c OpenVPN о GCM понятия не имеют.
Можно ли спросить на каких настойках остановились? Чтоиз crypto выбрано в настройках собственно сервера OpenVPN?
-
У меня установлено Intel RDRAND Engine, хотя что с ним что без него - практически никакой разницы… AES-NI работает по умолчанию.
-
А каков реальный выигрыш, не в тестах openssl speed, а в Open VPN? Болше скорости? Меньше загрузка CPU?
-
Больше скорость канала и меньше нагрузка на процессор — без оптимизации загрузка процессора под 90% и скорость до 100 мбит, с оптимизацией загрузка процессора менее 50% скорость до 500 мбит.
Есть понятие аппаратная оптимизация и если софт оптимизирован под железо, то на относительно дешевом железе можно получить приличные результаты.
-
Спасибо.
Это цифры с AES-GCM?
Если да - то каковы будут результаты с AES-CBC? -
Это с GCM, CBC точно не помню, но по-моему около 300 мбит было. Загрузку процессора при CBC не помню.
-
Еще немного синтетики на Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (pfSense 2.4.0 отдано 1 ядро под Hyper-V 2016):
openssl speed -elapsed aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 104734.30k 107559.70k 108202.41k 254901.25k 258236.42kopenssl speed -elapsed -evp aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 550018.00k 585781.97k 597035.43k 603340.80k 604815.36kopenssl speed -elapsed -evp aes-256-gcm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-gcm 383488.66k 940133.85k 2013853.10k 2815626.58k 3424714.75kGCM на интел однозначно рулит )))
-
Заело меня немножко использование AES NI в реале. Решил смастерить стенд. Нашел у себя бук с i3 U6060, поставил на него ppfSense 2.4.1 в виртуалку под VirtualBox, отдал одно ядро для чистоты эксперимента, чтобы уж точно было видно, кто будет тупить. Сетка гигабитная.
IPSEC AES-GCM. Во результаты ниже:–---------------------------------------------------------------------
CrystalDiskMark 5.2.0 x64 (C) 2007-2016 hiyohiyo
Crystal Dew World : http://crystalmark.info/- MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
- KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 11.534 MB/s
Sequential Write (Q= 32,T= 1) : 10.380 MB/s
Random Read 4KiB (Q= 32,T= 1) : 7.028 MB/s [ 1715.8 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 8.680 MB/s [ 2119.1 IOPS]
Sequential Read (T= 1) : 7.969 MB/s
Sequential Write (T= 1) : 9.857 MB/s
Random Read 4KiB (Q= 1,T= 1) : 2.133 MB/s [ 520.8 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 2.349 MB/s [ 573.5 IOPS]Test : 4096 MiB [W: 31.1% (37.0/118.8 GiB)] (x5) [Interval=5 sec]
Date : 2017/10/27 9:36:19
OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)
AES NI off–---------------------------------------------------------------------
CrystalDiskMark 5.2.0 x64 (C) 2007-2016 hiyohiyo
Crystal Dew World : http://crystalmark.info/- MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
- KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 20.379 MB/s
Sequential Write (Q= 32,T= 1) : 15.336 MB/s
Random Read 4KiB (Q= 32,T= 1) : 15.471 MB/s [ 3777.1 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 12.260 MB/s [ 2993.2 IOPS]
Sequential Read (T= 1) : 19.923 MB/s
Sequential Write (T= 1) : 14.889 MB/s
Random Read 4KiB (Q= 1,T= 1) : 2.554 MB/s [ 623.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 2.562 MB/s [ 625.5 IOPS]Test : 4096 MiB [W: 31.0% (36.9/118.8 GiB)] (x5) [Interval=5 sec]
Date : 2017/10/27 9:49:10
OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)
AES NI ONЗагрузка проца на pfSense была под 100 процентов, для себя сделал вывод AES NI в реальной работе очень даже рулит!
