Я купил маршрутизатор на базе VIA с единственной целью, чтобы запустить на нем OpenVPN. К сожалению, похоже, что Padlock не используется. Вот важная часть dmesg:
OpenBSD 4.8 (GENERIC) #136: Mon Aug 16 09:06:23 MDT 2010
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA C7 Processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR
В моем OpenVPN-Config есть следующие параметры, связанные с шифрованием / замком:
cipher AES-128-CBC
engine cryptodev
Я могу проверить, включен ли usercrypto, проведя сравнительный анализ с помощью команды openssl speed. В sysctl также говорится:
kern.usercrypto=1
Я делаю вывод, что Padlock не используется из этих основных данных, которые берутся со скоростью 40 Мбит / с (максимум 70 / с), проходящей через туннель VPN:
load averages: 0.66, 0.62, 0.54 crypto.b0nd4ge.de 21:03:04
28 processes: 2 running, 25 idle, 1 on processor
CPU states: 1.9% user, 0.0% nice, 2.9% system, 3.2% interrupt, 92.1% idle
Memory: Real: 30M/142M act/tot Free: 839M Swap: 0K/1214M used/tot
PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
20161 root 59 0 1224K 2676K run - 116:45 53.42% openvpn
11092 named 2 0 18M 19M sleep select 67:50 0.10% named
Что еще я могу сделать, чтобы Padlock работал с OpenVPN? Очень жаль, что я не могу максимизировать свое интернет-соединение с помощью этого VPN.
Пожалуйста помоги. Любое предложение будет оценено. Я искал это в Google уже пару недель.
Я не знаком с VIA Padlock, но ...
Для справки я могу предоставить вам свои показатели производительности OpenVPN и OpenSSL для шифра aes128-cbc и sha1 HMAC на Xeon E5530 2,40 ГГц, когда шифрование происходит на ЦП, и средний размер пакета ~ 1400 байт: openssl = 1360 Мбит / с openvpn = 320 Мбит / с (с тот же шифр)
С движком Intel AES-NI мне удалось получить только 30% улучшений для OpenVPN, в то время как тест скорости OpenSSL улучшился примерно в 4 раза.
Редактировать:
Вы также можете протестировать производительность OpenVPN с «без шифрования», чтобы исключить / подтвердить узкие места в коде, не связанном с шифрованием. Полоса пропускания, которую вы получите, будет верхней границей, и OpenVPN никогда не будет работать быстрее, чем с любым криптографическим движком.
Если окажется, что узкое место связано с некриптографическим кодом, я бы посоветовал вам использовать IPSec - у него меньше накладных расходов (без TUN, без процессов пользовательского пространства, переключения контекста, без задействованного стека TCP / UDP). Если вы все еще хотите придерживаться OpenVPN, запустите несколько процессов OpenVPN и попытайтесь сбалансировать нагрузку трафика (помогает, только если у вас есть несколько ядер ЦП на маршрутизаторе).
Увидев высокую загрузку ЦП с OpenVPN, помните, что это пользовательское приложение, и помимо шифрования требуется много переключений контекста для перетасовки инкапсулированных и неинкапсулированных пакетов в ядро и из ядра, а также прерываний ЦП. для фактического сетевого взаимодействия. Предполагая, что один пакет ping ICMP от удаленного конца к сети предоставлен сервером OpenVPN:
Переключение контекста происходит всякий раз, когда выполнение переключается с контекста ядра на пользовательскую среду, поэтому 2-3, 4-5, 7-8, 8-9. Сравните это с IPSec, который встроен в ядро, поэтому вся эта инкапсуляция / деинкапсуляция происходит в контексте ядра.
Вот почему, как говорит Ансис, увеличение пропускной способности шифрования напрямую не приводит к повышению пропускной способности OpenVPN. По мере увеличения скорости передачи пакетов переключение контекста подавляет преимущества аппаратного криптоускорения.
Google не всегда твой друг :-)
Выполните поиск в архиве списка рассылки misc @ openbsd здесь: http://marc.info/
Насколько я помню, аппаратная реализация VIA оставляет желать лучшего.
Кроме того, зачем использовать пакет OpenVPN? OpenBSD имеет встроенные ipsec vpn и openSSH, интегрированные с сетевым стеком и брандмауэром pf. Все это поддерживается кроссплатформенными клиентами, и да, даже на самых неэффективных из них :-)