榨干算力!从700M到近3G,Linux原生IPsec极限调优实战

在测试了使用swanctl配置基于策略的IPsec VPN之后（告别老旧配置！Ubuntu 26.04玩转swanctl配置IPsec全通关指南），我们发现这种配置方式，明确指定了本端网段和对端网段，跟H3C配置ACL感兴趣流一样（配置strongSwan和H3C VSR的IPsec对接案例）。在实际使用中，如果我们要调整业务网段，配置会非常麻烦，必须修改两端IPsec的配置，调整ts参数，甚至要重启强拆隧道，可谓是牵一发而动全身。

如果改为基于路由的IPsec VPN（零停机、性能小升！手把手教你甩掉策略包袱，玩转路由模式IPsec），维护起来就犹如打通了任督二脉，所有的局域网流量都可以仅仅通过写简单的ip route系统路由，就能决定是否走加密隧道，停机时间为零。甚至，我们不仅可以配置静态路由，还能使用OSPF/BGP等动态路由协议让网络自动收敛。

此外，我们还发现，因为实现机制问题，使用基于路由的IPsec VPN时，CPU负载会低于基于策略的配置方式，转发效率自然更胜一筹。

既然现在的平均带宽已经达到了700 Mbps，离跑满千兆就差临门一脚了，那我们能不能优化一下呢？

提到提升网络性能，大家的第一反应往往是上VPP（十倍性能提升！Ubuntu 26.04深度实测：当VPP遇上OpenVPN，带宽直接冲破 6.5Gbps！）。当然，通过前面的测试，VPP已经证实为提升性能的利器（破天荒的8.36 G！Ubuntu 26.04下VPP加持L2TP极限性能调优实测），但对于普通用户而言，门槛有点偏高。杀鸡焉用牛刀，在纯Linux内核态下，我们哪些优化手段呢？

实验环境基于上次基于路由的IPsec VPN（零停机、性能小升！手把手教你甩掉策略包袱，玩转路由模式IPsec）。

第一步，我们先调整一下加密算法（使用vSRX测试一下IPsec VPN各加密算法的性能差异），按照之前的经验，AES-GCM算法支持CPU的AES-NI硬件指令集加速，相比传统AES-CBC + SHA1需要分别进行加密和哈希验证的方式，具有极高的性能优势，我们果断修改配置：

esp_proposals = aes128gcm16

好家伙，改个算法就一步到位了，平均带宽已经突破1.06 Gbps，而且相对稳定，最高带宽为1.09 Gbps，我准备了十八般武艺还没亮相呢。

不管了，继续上手段。

通过观察CPU负载，我们发现现在依旧是一核有难、15核围观的名场面，我们配置接收侧软件多核分发Software RPS，尝试让这个核心通过软件方式把中断工作分发给其他15个闲置核心。

echo ffff > /sys/class/net/ens192/queues/rx-0/rps_cpus

不过，配置之后，流量依旧死磕在同一个CPU上，未能打散。究其原因，软件RPS依赖流哈希机制，对于ESP封装后的打流报文，五元组信息完全一致，由于缺乏L4端口信息，Linux内核的RPS哈希算法无法有效拆分单一IP对之间的ESP流量流。

换个思路，要是协商建立多条SA安全联盟，并配置ECMP等价路由呢？

我们创建4条独立的IPsec隧道，分别对应4个xfrm接口，再配置Linux ECMP将流量均匀打散到4条隧道上，利用4个不同的内核队列和SPI编号让网卡分发给4个CPU核心解密。

sysctl -w net.ipv4.fib_multipath_hash_policy=1

实际测试时，虽然发送端成功将流量分发到了4个xfrm接口，但在接收端，并不能实现多核并发，CPU 7的软中断依然飙升到98 %，总带宽死死卡在单核水平，没有提升。

究其原因，跟虚拟网卡有关，我们使用的是VMXNET3虚拟网卡，其硬件接收侧缩放RSS算法存在盲区，无法解析IPsec协议内部的SPI。最外层的五元组依然完全相同，网卡硬件算出的Hash永远是同一个值！这导致4条隧道的加密包依然被硬件死板地塞入同一个RX队列，被同一个CPU核心接收。

如果要解决这个问题，即让VMXNET3触发多核分发，必须让底层物理网卡配置多个外网IP，让这4条隧道运行在不同的外层IP组合上，这就破坏了网络结构，我们先记下这个方法。

还记得我们才尝试过的XDP和eBPF终极卸载吗（一顿操作猛如虎，带宽反而倒退五？带你复盘虚拟机下XDP性能调优的那些硬坑）？引入目前最强大的Linux网络转发技术，绕过传统内核网络栈，会有效果吗？

实际测试不仅没有效果，性能不升反降，究其原因，跟我们之前的结论类似：IPsec隧道重度依赖密码学运算，而XDP的eBPF虚拟机内部无法直接调用CPU的AES-NI硬件指令集，所有的eBPF网络插件在遇到IPsec加密流量时，都会选择回退给Linux XFRM传统协议栈进行解密处理，反而增加了系统负载。

如果真要卸载，可能的途径就是购买支持硬件加密卸载的高性能智能网卡，例如我们之前项目上的Mellanox ConnectX-6 25Gbps网卡，基本能跑到20 Gbps以上的IPsec性能。

突然想起来，我们现在还是用的动态省电模式，切换成静态高性能模式试一下。

哎呀，这下就舒服多了，最高带宽2.93 Gbps，平均带宽逼近2.5 Gbps，差别不多能跑满家庭宽带上限了。

当然，好马配好鞍，如果我们调整服务器资源，预留所有计算资源，并将虚拟机延迟敏感度调整为高，进一步锁死资源分配，就可以把性能稳定下来。

可以看到，带宽基本稳定在2.9 Gbps以上了，最高能达到2.97 Gbps，一条近乎完美的水平线，治愈了一切强迫症，看来资源调度也很重要。

回顾这次从700 Mbps到近3 Gbps的IPsec性能狂飙之旅，我们可以得出Linux内核态IPsec调优的黄金三角法则：

1、密码学硬件加速是第一生产力。弃用老旧算法，换上支持AES-NI的AES-GCM，是性价比最高的提速手段。

2、警惕虚拟化与底层硬件的隐形墙。不要盲信RPS和ECMP那么多花里胡哨的软件分发，在ESP报文面前，没有源目IP和端口的差异，网卡RSS哈希就是个睁眼瞎。

3、计算资源调度是性能的基石。在虚拟化环境中，电源策略、CPU 预留和延迟敏感度的设置，往往能带来大力出奇迹的成效。

***推荐阅读***

2048卡H100算力中心100G无阻塞存储网建设方案