我已经买了一个基于VIA的路由器，唯一的目的就是运行OpenVPN。 不幸的是，似乎没有使用挂锁。 这是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
我可以通过使用openssl speed命令进行基准testing来validationusercrypto是否已启用。 sysctl也读取：
kern.usercrypto=1
我推断，挂锁没有被使用，这些信息是通过VPN隧道以40 Mbit / sec（最高70 / sec）的速度进行的：
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的互联网连接真是太遗憾了。
请帮忙。 任何build议，将不胜感激 。 几个星期以来，我一直在使用Google。
我不熟悉威盛Padlock，但…
作为参考，我可以给你我的OpenVPN和OpenSSL的性能数字为aes128-cbc密码和至强E5530 2.40GHz的encryption当发生在CPU和平均数据包大小~140bytes：SHA1 HMAC在openssl = 1360Mbit / s openvpn = 320Mbit / s相同的密码）
使用英特尔AES-NI引擎，OpenVPN只能获得30％的改进，而OpenSSL速度testing提高了4倍。
编辑：
您也可以用“密码无”性能testingOpenVPN来排除/certificate与非encryption相关的代码中的瓶颈。 你将获得的带宽将是上限，OpenVPN永远不会比任何encryption引擎的工作更快。
如果事实certificate瓶颈在非encryption代码中，我build议你使用IPSec – 那个开销less（没有TUN，没有用户空间进程，上下文切换，没有涉及TCP / UDP堆栈）。 如果你仍然想坚持使用OpenVPN，那么运行多个OpenVPN进程并尝试加载平衡stream量（只有在路由器上有多个CPU核时才有帮助）。
Google并不总是你的朋友:-)
在这里searchmisc @ openbsd邮件列表存档： http : //marc.info/
最后我记得，威盛的硬件实现还有很多不足之处。
另外，为什么使用OpenVPN包？ OpenBSD具有内置的ipsec vpn和openSSH，并与networking堆栈和pf防火墙集成。 所有这些都得到了跨平台客户的支持，是的，甚至在它们最低效的方面都是:-)
当看到OpenVPN的高CPU占用率时，请记住它是一个用户级应用程序，除了encryption之外，还有很多上下文切换需要将内外封装和非封装数据包进行混洗，以及CPU中断用于实际的networking通信。 假设从远程端到OpenVPN服务器提供的networking的单个ICMP ping数据包：
上下文切换发生在执行从内核上下文到用户空间时改变，所以2-3，4-5，7-8，8-9。 与内核中的IPSec相比，所有封装/解封装都发生在内核环境中。
正如Ansis所说，这就是为什么提高encryption吞吐量并不能直接转化为更好的OpenVPN吞吐量的原因。 随着分组速率的增加，上下文切换压倒硬件encryption加速的收益。