AES-NI в OpenSSL чи винесення в ядро: що вам потрібно?

Два ярлики використовують так, ніби це одне й те саме: апаратно прискорено та винесено в ядро. Перший описує, які інструкції виконує процедура AES бібліотеки, другий — де відбувається обробка пакетів. VPN може мати перший без другого, другий без першого або обидва разом. Будь-яке рішення про продуктивність має починатися з називання того, який із двох ви насправді змінюєте.

Дві осі, а не одна оцінка

Перша вісь — реалізація: чи код, що виконує AES-256-GCM, спрямовується у версію, яка використовує спеціальні інструкції процесора, чи в переносну процедуру, що виконує їх як звичайну арифметику. Цей вибір живе всередині криптографічної бібліотеки і робиться під час її ініціалізації.

Друга вісь — розміщення: чи пакет проходить шляхом перетворення ядра, чи демон у просторі користувача читає з тунельного пристрою, шифрує і записує назад.

Жодна вісь не обмежує іншу. VPN у просторі користувача на процесорі з інструкціями AES може використовувати їх увесь час, а шлях через ядро на процесорі без них повертається до програмної реалізації. Ярлики в матеріалах постачальників рідко роблять цю різницю, і тому поради з налаштування, скопійовані між двома ситуаціями, так часто не дають нічого.

Вісь перша: який код виконує шифрування

OpenSSL виявляє особливості процесора під час ініціалізації і використовує результат для вибору оптимізованих шляхів коду, як описує документація про можливості x86. AES-NI — одна із задокументованих можливостей за цим розподілом. Ніщо з цього не вимагає, щоб бібліотека стала компонентом ядра.

Переконайтеся, що особливість видима процесу, перш ніж припускати, що використовується швидкий шлях. У Linux джерелом є поле flags у /proc/cpuinfo, а всередині гостьової системи воно відображає те, що надає гіпервізор, а не назву моделі фізичного хоста.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

Друга команда називає постачальників, завантажених у цій збірці. Вона не повідомляє, з якою бібліотекою пов’язано сервіс VPN, і один хост може нести дві інсталяції OpenSSL, тоді як робочий процес використовує лише одну з них.

Вісь друга: де працює шлях пакетів

Розміщення в ядрі означає, що перетворення відбувається у власному механізмі IPsec ядра або в тунельному драйвері всередині ядра, тому пакетам не потрібна подорож туди й назад через процес у просторі користувача для кожної порції. Це може скоротити копіювання та перемикання контексту і розподілити роботу між ядрами так, як не може однопотоковий демон. Це також переносить лічильники й трасування, які ви читатимете, коли пропускна здатність впаде, бо робота тепер відбувається з іншого боку межі, яку ви не контролюєте. Сприймайте це як витрати на налагодження, а не лише як рішення про продуктивність.

Воно не створює підтримку інструкцій, не налаштовує шифр і не змушує наявний маршрут працювати.

Віртуалізація додає складку і на цій осі. Гостю можуть дати масковану модель процесора, що приховує особливості, які має хост, а вкладений гість може бачити ще менше. Читайте подання можливостей зсередини середовища, де VPN справді працює, а не з консолі гіпервізора.

Що купує кожен вибір і чого він не може

Практичне питання — куди йде час. Якщо пропускну здатність обмежують один зайнятий потік, повторювані копії буфера або системний виклик на кожен пакет, перенесення перетворення на шлях, що усуває ці витрати, може допомогти, за умови що ядро реалізує потрібне вам перетворення.

Якщо межа — перевантажений висхідний канал, шлях із втратами, довгий час кругового обходу, насичений цільовий сервіс або один потік, прикріплений до одного ядра, розміщення не змінює нічого важливого. Те саме стосується вибору інструкцій: AES на спеціальному обладнанні не виправить відсутній маршрут і не допоможе, якщо тунель простоює через збій розв’язання імен.

Там, де діють обидва, вони складаються. Шлях через ядро може використовувати той самий розподіл на рівні інструкцій усередині криптографічного API ядра, а шлях у просторі користувача з добре вибраною бібліотекою вже використовує його. Рішення не в тому, що швидше в абстракції, а в тому, для яких витрат у вас є докази.

Запишіть чотири факти, перш ніж щось змінювати

Запишіть бінарний файл сервісу та криптографічну бібліотеку, з якою він пов’язаний, бо саме вони визначають першу вісь. Потім зафіксуйте узгоджений захист даних, бо шифр без виділеного шляху інструкцій поводиться інакше, ніж із ним, а набір обирають обидві сторони.

Далі — подання можливостей зсередини працюючого середовища і, нарешті, активний шлях пакетів із доказом того, що режим, який ви вважаєте ввімкненим, справді такий. Завантажений модуль не доводить, що профіль його використовує, а рядок конфігурації не доводить, що ядро його прийняло.

Змініть одну річ і порівняйте з рівномірним навантаженням за тих самих кінцевих точок і того самого напрямку передавання. Твердження про швидкість, яке ви не виміряли, коштує менше, ніж нотатка про те, що бекенд ніколи не був під сумнівом.