当pfSense连接处于活动状态时，如何解决ipSec的高平“尖峰”问题？
背景信息：
我们的pfSense存在延迟/冻结问题。为了能够回答这个问题，我将首先提供一些一般性的背景资料：
- 我们在以下硬件上运行pfSense V2.6.0：
- 超微型主板
- 英特尔(R)奔腾(R) CPU N3710 / AES-NI CPU密码:是(非活动)/ QAT密码:否
- 4Gb内存
- CPU负载从未超过50%的使用率(尖峰)/怠速5-8%
- 内存的使用率从未超过15%
- 交换使用率始终为0%
- 我们有大约45个活动的ipSec连接
我们的问题：
我们有一个内部的PBX (3CX)，当我们不在办公室的时候，我们会和他们的(智能手机)应用一起使用。我们在谈话中注意到hick /结冰，所以我们开始寻找原因。
我们注意到，pfSense有时具有很高的ping延迟。当我在桌面上切换pfSense时，延迟通常是1ms。有时我们看到2000+ms的尖峰(见图)，这些尖峰对应于电话通话期间的冻结。注意，尖峰是随机发生的。
经过一些测试后，我们注意到禁用所有ipSec连接可以修复这些尖峰。ipSec连接仅用于在内部客户系统之间定期发送的非常少量的数据。大多数情况下，没有数据发送的连接。
我们还监控我们的输入和输出带宽，它甚至从未接近我们的DSL限制。
ipSec configurations
大多数ipSec连接使用相同的配置。对于调查，我们禁用了所有不同的(约5)配置，但仍然有问题。我们使用的“默认”ipSec配置：
<phase1>
<ikeid>*********</ikeid>
<iketype>ikev2</iketype>
<interface>wan</interface>
<remote-gateway>*********</remote-gateway>
<protocol>inet</protocol>
<myid_type>myaddress</myid_type>
<myid_data></myid_data>
<peerid_type>fqdn</peerid_type>
<peerid_data>*********</peerid_data>
<encryption>
<item>
<encryption-algorithm>
<name>aes</name>
<keylen>128</keylen>
</encryption-algorithm>
<hash-algorithm>sha256</hash-algorithm>
<dhgroup>14</dhgroup>
</item>
</encryption>
<lifetime>28800</lifetime>
<pre-shared-key>*********</pre-shared-key>
<private-key></private-key>
<certref></certref>
<caref></caref>
<authentication_method>pre_shared_key</authentication_method>
<descr>*********</descr>
<nat_traversal>on</nat_traversal>
<mobike>off</mobike>
<closeaction></closeaction>
<startaction>none</startaction>
</phase1>
<phase2>
<ikeid>*********</ikeid>
<uniqid>*********</uniqid>
<mode>tunnel</mode>
<reqid>39</reqid>
<localid>
<type>network</type>
<address>*********</address>
<netbits>16</netbits>
</localid>
<remoteid>
<type>network</type>
<address>*********</address>
<netbits>24</netbits>
</remoteid>
<protocol>esp</protocol>
<encryption-algorithm-option>
<name>aes</name>
<keylen>128</keylen>
</encryption-algorithm-option>
<encryption-algorithm-option>
<name>aes128gcm</name>
<keylen>128</keylen>
</encryption-algorithm-option>
<hash-algorithm-option>hmac_sha256</hash-algorithm-option>
<pfsgroup>14</pfsgroup>
<lifetime>3600</lifetime>
<pinghost>*********</pinghost>
<descr>*********</descr>
</phase2>问题:我们如何解决这些高结冰问题？
回答 2
Network Engineering用户
发布于 2022-11-30 15:28:04
如果更强大的硬件解决了我们的问题，我们试过了。我们用一个pfSense将我们的Intel(R) Xeon(R) CPU E3-1220 v6 @ 3.00GHz克隆到硬件上。100% CPU的峰值仍然存在，但是ping响应时间是最大600 of，而不是最大3000 of。这意味着更强的硬件并不能解决100%的CPU峰值，但是在例如电话会议期间，这个问题就不那么明显了。
由于更强大的硬件不是解决方案(即使需要一些压力来解决这个问题)，我们对pfSense进行了密集的监视。我们注意到，pfctl是导致高ping的原因，因为它正是在发生高ping时提高了CPU的使用率。
我们在pfSense红霉素(https://redmine.pfsense.org/issues/12045)上发现了一个符合我们发现的bugreport。这一行Yes, we are aware, but 2.6.0 will get the fix when we do a full sync with FreeBSD sources next, which wasn't an option for 2.5.2 (so we picked only the necessary commits there).告诉我们，我们可能不是第一个/唯一一个。这个Reddit主题也是相关的：https://www.reddit.com/r/PFSENSE/comments/nz8fmw/high_cpu_用法_sbinpfctl_ss/？_source=share&utm_medium=ios_app&utm_name=iossmf
正如他们提到的，这个问题将通过full FreeBSD同步来解决，让我们认为这是FreeBSD中的一个bug/问题。我们还在网络上找到了一些其他的话题，它们为我们指明了这个方向。
pfSense 2.7是具有最新FreeBSD版本的第一个版本，因此我们决定建立一个pfSense克隆，并将其升级到pfSense 2.7-dev。自更新以来，我们不再经历任何尖峰。
pfSense v2.7运行稳定(到目前为止)并解决了我们的问题，所以我们决定继续使用v2.7-dev，直到最后版本v2.7。
Network Engineering用户
发布于 2022-11-15 19:07:32
查看pfsense命令行中“top-aSH”的输出，以查看在出现高峰时进程使用了多少CPU。如果它是可靠的，在一定的时间(每30秒或每5分钟等)然后，它可能是系统上的cron条目，或者是PFSense中的一些预定任务或特性。您需要与PFSense检查，以确保您的系统是完全更新的，并查看是否有任何与反复出现的CPU负载高峰相关的打开错误。
我不知道IPsec会话的数量，对于一个小型平台来说，这是一个很大的数目，但是如果CPU通常处于低负载状态，那么保留该硬件可能是可以的，除非您能够确定峰值的时间与实际带宽的使用是一致的。您可能有45个隧道在使用，但它们可能在大多数时间几乎没有通过任何交通，导致非常低的CPU负载。如果某些用户每隔几分钟就会做一些导致流量激增和相应CPU尖峰的事情，那么这个问题与硬件供电不足有关。
另外，我同意你应该使用AES-NI硬件加速.显然，您必须手动激活它，或者至少检查一下是否启用了它。
https://forum.netgate.com/topic/124357/aes-in-inactive/3
在实际载荷作用下，它的性能有了很大的提高。
https://networkengineering.stackexchange.com/questions/80541
复制相似问题
腾讯云开发者
