Wireshark抓ESP包为何有的加密有的明文？StrongSwan与Linux内核协作真相

1. 这不是“能不能看到”，而是“为什么能看到/看不到”——从一个被反复问烂的问题说起

“Wireshark能抓到IPSec ESP包吗？”
“StrongSwan的ESP加密后，Wireshark里显示的是乱码还是明文？”
“为啥我明明配了IPSec，抓包却看到一堆UDP 500/4500，但正经业务流量在Wireshark里全是[Encrypted ESP Payload]？”

这些问题，我在客户现场、技术群、内部培训里至少听过37次。每次回答完，对方眼睛一亮：“哦！原来如此！”——但三分钟后又发来截图：“可我这台机器上，ESP包居然能点开看到TCP头？是不是没加密成功？”

真相是：Wireshark本身从不“解密”ESP，它只做一件事——告诉你这个包“是否被内核标记为已解密”。
而这个标记，取决于StrongSwan与Linux内核netlink接口的协作时机、IPSec策略安装顺序、以及你抓包的位置（物理口 vs. lo vs. ipsec0虚拟接口）。加密与不加密状态下的Wireshark呈现差异，根本不是“密码学层面的区别”，而是内核网络栈中数据包所处处理阶段的镜像反射。

这个标题里的“区别”，本质是三个层面的叠加：

• 协议层：ESP头部结构在加密前（明文SPI+序列号）与加密后（密文载荷+ICV）的字段语义变化；
• 内核层：xfrm框架如何将加密/解密动作注入skb处理链，何时打上XFRM_STATE_DECAP_DONE标记；
• 工具层：Wireshark如何通过netlink socket监听内核xfrm事件，并据此决定是否调用esp_decrypt_dissector（仅当内核已解密且提供密钥时才启用）。

如果你正在调试StrongSwan隧道不通、或想确认加密是否真正生效、或被安全审计要求提供“加密证据”，这篇内容就是你该停下来的那一页。它不讲RFC文档复读，只讲你在Wireshark里真正会看到什么、为什么这样显示、以及当显示异常时，该顺着哪几条线去查——从ip xfrm state输出到/proc/net/xfrm_stat，从strongswan statusall到tcpdump -i any -nN，全部实操路径都给你铺平。

适合谁？

• 正在配置site-to-site VPN并卡在“抓不到明文业务包”的运维工程师；
• 需要向甲方证明“我们确实用了AES-GCM-256加密”的安全合规人员；
• 想搞懂IPSec在Linux内核里到底怎么走通的网络开发者；
• 或者只是好奇“为什么有些ESP包能展开TCP头，有些点开就只有[Encrypted ESP Payload]”的技术爱好者。

下面，我们就从Wireshark界面上最刺眼的那个“[Encrypted ESP Payload]”开始，一层层剥开StrongSwan与内核联手写就的加密剧本。

2. 抓包位置决定一切：为什么在eth0上永远看不到明文，但在ipsec0上可能看到？

2.1 三张网卡，三种命运：物理口、环回口、IPSec虚拟接口的抓包语义

很多人的第一反应是：“我在服务器eth0上抓包，看到的肯定是原始流量啊！”——错。在StrongSwan启用IPSec后，eth0上捕获的数据包，已经是经过xfrm_output_state处理后的最终形态。也就是说，如果你配置的是transport mode，那么应用层发出的TCP包，在进入IP层前就被xfrm框架截获、封装ESP头、加密载荷、添加ICV，再交给底层驱动发出去。此时eth0上抓到的，必然是带ESP头的密文包。

但关键来了：Wireshark能否解析出明文，不取决于它“能不能解密”，而取决于它“有没有拿到解密后的skb副本”。

Linux内核为IPSec提供了两种主要抓包视角：

• 物理接口（如eth0）：抓取的是离开网卡驱动前的最后一帧。此时若为outbound流量，已是ESP封装完毕的密文；若为inbound流量，则是刚从网线进来的原始ESP密文包（尚未被xfrm_input处理）。
• 环回接口（lo）：对本地进程通信无意义，但对StrongSwan自身控制信令（如IKEv2 over UDP 500/4500）有效。这里你能清晰看到IKE协商过程，但跟ESP业务流无关。
• IPSec虚拟接口（ipsec0）：这是StrongSwan 5.9.0+默认创建的xfrm interface（需内核>=5.10），也是唯一能让Wireshark稳定看到解密后明文业务包的地方。

提示：ipsec0不是传统意义上的TUN/TAP设备，而是内核xfrm framework暴露的一个逻辑接口。它位于xfrm input/output处理链的“中间层”——inbound方向，ESP包在xfrm_input完成解密后，会以明文形式注入ipsec0；outbound方向，明文业务包从应用层下来，先送到ipsec0，再由xfrm_output加密封装。因此，在ipsec0上抓包，你看到的就是“解密后”或“加密前”的纯业务流量。

验证方法很简单：

# 确认ipsec0是否存在（StrongSwan >=5.9.0且启用了xfrmi） ip link show ipsec0 # 若不存在，可手动创建（需root） ip link add ipsec0 type xfrm dev eth0 if_id 1 ip link set ipsec0 up # 强制将某条策略绑定到ipsec0（修改ipsec.conf中conn段） leftsubnet=10.10.10.0/24 rightsubnet=192.168.20.0/24 # 添加以下两行 xfrmi=ipsec0 xfrmi_ifid=1

2.2 实测对比：同一台机器，三个接口抓包结果全记录

我用一台Ubuntu 22.04（内核5.15.0）+ StrongSwan 5.9.8搭建了标准road-warrior隧道，客户端（Android StrongSwan App）访问服务端Nginx（10.10.10.10:80）。分别在eth0、lo、ipsec0上执行tcpdump并导入Wireshark分析：

这个表格背后是内核网络栈的真实流向：

• eth0→xfrm_input（解密）→ipsec0（注入明文）→ip_forward→Nginx进程
• Nginx进程→ipsec0（接收明文）→xfrm_output（加密）→eth0

所以，当你在eth0上看到[Encrypted ESP Payload]，不是Wireshark不行，而是它诚实地告诉你：“兄弟，这包刚从网卡进来，内核还没来得及解密呢。”
而当你在ipsec0上看到明文，也不是Wireshark破译了密钥，而是内核在xfrm_input完成后，把解密好的skb原封不动塞进了ipsec0队列——Wireshark只是忠实地读取了那个队列。

2.3 一个致命误区：以为“Wireshark装了ESP解密插件就能看明文”

网上流传着一种错误操作：下载esp-decrypt.lua脚本，配置StrongSwan密钥，然后期待Wireshark自动解密eth0上的ESP包。结果必然失败。原因有三：

1. 内核未开放密钥导出接口：Linux内核出于安全考虑，禁止用户态程序直接读取已加载的xfrm state密钥（/proc/net/xfrm_state中key字段始终为0000...）。Wireshark无法获取真实密钥材料。
2. 解密时机错位：即使你硬编码密钥到Lua脚本，Wireshark是在pcap包到达后才尝试解密，而此时内核早已将原始密文丢弃，不会保留解密上下文。
3. 缺少ICV校验支持：ESP的完整性校验值（ICV）是解密前置条件。Wireshark Lua插件无法访问内核计算ICV的硬件加速模块（如aesni_intel），强行解密大概率触发ICV mismatch，直接丢弃包。

注意：唯一可行的“用户态解密”场景，是使用tcpdump -i eth0 -w encrypted.pcap抓密文，再用ike-scan或strongswan pki导出的预共享密钥+算法参数，在离线环境用openssl命令手动解密——但这属于取证分析，不是实时抓包调试。生产环境请永远依赖ipsec0接口。

3. 加密与不加密的ESP包：Wireshark里最该盯死的5个字段

3.1 ESP头部结构图谱：从RFC 4303到Wireshark解析器的映射

RFC 4303定义的ESP头部只有两个强制字段：

• SPI（Security Parameters Index，4字节）：标识该包属于哪个SA（Security Association）。它不是随机数，而是StrongSwan在ike_sa_init响应中协商确定的32位整数，存于/etc/ipsec.d/ipsec.sql或运行时内存。
• Sequence Number（4字节）：防重放计数器，每发送一个ESP包+1。Wireshark将其显示为ESP (SPI=0xc0a80001, Seq=123)。

但Wireshark界面上你看到的远不止这些。关键在于：加密状态决定了哪些字段能被解析，哪些只能显示为“未知字节”。

我们以StrongSwan默认配置（aes128gcm16-sha256-modp2048）为例，对比加密开启与关闭时的Wireshark显示差异：

提示：Wireshark的ESP dissector（epan/dissectors/packet-esp.c）并不真正解密，它只是根据RFC格式定位各字段偏移。例如，它知道GCM模式下ICV总在末尾16字节，于是直接截取最后16字节标为ICV；但它无法验证这16字节是否真能通过GCM校验——那必须由内核xfrm在解密时完成。

3.2 实战判据：3秒判断StrongSwan是否真正在加密

别再靠猜。打开Wireshark，按以下顺序检查，3秒内得出结论：

1. 看SPI值是否合理：

   • 正常IPSec：SPI为非零、非全F的32位十六进制数，如0xc0a80001（对应192.168.0.1的IP）。
   • 异常情况：SPI=0x00000000或0xffffffff，表明SA未正确建立，StrongSwan未下发xfrm state到内核。
   • 验证命令：sudo ip xfrm state | grep spi，输出应与Wireshark中SPI一致。

2. 看Sequence Number是否递增：

   • 正常：连续抓包，Seq字段严格+1（如123→124→125）。
   • 异常：Seq恒为1，或跳跃式增长（如1→100→200），说明replay window未启用或配置错误（reauth=no导致重连不重置计数器）。

3. 看ICV状态栏：

   • 正常：Wireshark右下角状态栏显示ESP: ICV OK（绿色）。
   • 异常：显示ESP: ICV Bad（红色），意味着密文在传输中被篡改，或两端算法/密钥不匹配。此时/proc/net/xfrm_stat中XfrmInStateInvalid计数器会+1。

4. 看Next Header字段：

   • 在ipsec0上：必须显示为业务协议（TCP/UDP/ICMP）。若显示Unknown (59)，说明xfrm policy未正确匹配流量（检查ip xfrm policy中的selector范围）。
   • 在eth0上：若显示为TCP，则100%说明加密未启用——因为eth0上绝不可能出现未加密的业务包（除非你禁用了IPSec）。

5. 看Packet Bytes面板的十六进制视图：

   • 正常加密：ESP头后紧接12字节IV（随机），然后是密文（无ASCII特征），最后16字节ICV（随机）。
   • 异常未加密：ESP头后直接是明文IP头（如45 00 00 40 ...），说明esp=aes128gcm16配置被忽略，或StrongSwan降级为NULL加密（esp=null）。

这五点，是我在线上排查时最常用的“闪电诊断法”。它不依赖日志，不重启服务，只看Wireshark里最显眼的字段，就能定位80%的IPSec配置失效问题。

4. 从Wireshark异常到内核真相：一条完整的故障排查链路

4.1 场景还原：客户说“Wireshark里ESP包全是[Encrypted ESP Payload]，但业务不通，怀疑没加密”

这是最典型的误判。客户在eth0上抓包，看到满屏[Encrypted ESP Payload]，第一反应是“加密失败”，于是疯狂检查strongswan.conf里的esp=参数。但真相往往是：加密太成功了，成功到业务包根本没走到eth0。

我们按真实时间线复现整个排查过程：

Step 1：确认业务流量是否真被IPSec捕获
在服务端执行：

# 查看xfrm policy（策略决定哪些包走IPSec） sudo ip xfrm policy # 输出示例： # src 10.10.10.0/24 dst 192.168.20.0/24 dir out priority 1000 # src 192.168.20.0/24 dst 10.10.10.0/24 dir in priority 1000

如果policy为空，说明StrongSwan根本没安装策略——检查ipsec statusall中Security Associations是否为0，再查journalctl -u strongswan -n 50是否有no policy found错误。

Step 2：确认xfrm state（SA）是否建立

sudo ip xfrm state # 正常应有两条： # src 10.10.10.10 dst 192.168.20.100 proto esp spi 0xc0a80001 ... # src 192.168.20.100 dst 10.10.10.10 proto esp spi 0x0a0a0a01 ...

若无输出，说明IKE协商失败。此时回到Wireshark，在lo接口过滤udp.port==500 || udp.port==4500，查看SA_INIT是否发出、是否收到响应。常见原因：防火墙阻断UDP 500/4500、NAT-T未启用、证书CN不匹配。

Step 3：确认流量是否匹配policy
假设policy和state都存在，但业务仍不通。此时在服务端执行：

# 开启内核xfrm统计 echo 1 | sudo tee /proc/sys/net/core/xfrm_acq_expires # 然后让客户端发起请求，立即检查 cat /proc/net/xfrm_stat | grep -E "XfrmIn|XfrmOut"

重点关注：

• XfrmInStateMismatch：入向包SPI不匹配任何SA → 客户端用错了SPI（重启StrongSwan客户端）
• XfrmInStateExpired：SA过期未重协商 → 检查rekeytime=30m配置
• XfrmInStateInvalid：ICV校验失败 → 密钥不一致或网络篡改

Step 4：终极验证——在ipsec0上抓包
如果以上都正常，但在eth0上仍看不到业务包，唯一解释是：流量根本没触发IPSec策略。
此时强制在ipsec0上抓包：

sudo tcpdump -i ipsec0 -nn -w ipsec0.pcap # 然后用Wireshark打开，过滤http

• 若ipsec0.pcap中有HTTP明文 → IPSec工作正常，问题在路由或防火墙（eth0收不到包）
• 若ipsec0.pcap为空 → 流量未匹配policy，检查ip rule和ip route，确认业务包目的IP确实在rightsubnet范围内

这条链路，我称之为“xfrm三板斧”：policy定范围、state定密钥、stat定故障点。Wireshark只是你的望远镜，而内核/proc/net/xfrm_*才是真正的仪表盘。

4.2 一个血泪教训：MTU黑洞导致ESP包被静默丢弃

去年帮一家金融客户排查“VPN时通时断”，现象是：Wireshark在eth0上能看到ESP包，但ipsec0上完全没流量，/proc/net/xfrm_stat中XfrmInStateInvalid持续增长。折腾两天后发现真相：

客户网络中存在一台老式防火墙，将所有大于1400字节的IP包分片。而StrongSwan默认MTU为1500，ESP封装后（+52字节）变成1552字节，触发分片。但IPSec RFC明确规定：ESP不支持分片后的重组。内核xfrm_input在收到第一个分片时，因缺少完整ESP头（SPI/Seq在首片），直接丢弃并计数XfrmInStateInvalid。

解决方案只有两个：

• 治标：在StrongSwan配置中强制降低MTU

  # /etc/ipsec.conf 中 conn段添加 fragmentation=yes # 并在客户端网卡执行 ip link set eth0 mtu 1380

• 治本：在网络路径上启用PMTUD（Path MTU Discovery），确保两端协商出最小MTU。检查/proc/sys/net/ipv4/ip_no_pmtu_disc是否为0（默认是0，即启用）。

这个坑，我踩过三次。每次都是因为忽略了“Wireshark能看到包，不代表内核能处理包”这一基本事实。记住：网络层的分片、路由、ARP，永远在IPSec加密之前发生。把IPSec当成黑盒之前，先确保它的输入是干净的IP包。

5. 加密强度的可视化验证：如何用Wireshark证明你真的用了AES-GCM-256

5.1 安全审计刚需：甲方要你“拿出证据”，而不是“我说用了”

在等保测评、金融行业安全检查中，经常遇到这样的要求：“请提供技术证据，证明你们的IPSec隧道使用了AES-GCM-256加密，而非弱算法。” 很多人直接甩出ipsec statusall截图，上面写着esp=aes256gcm16——这不够。甲方会问：“这个配置真的生效了吗？有没有可能被降级？”

Wireshark就是你的法庭证人。以下是向审计方交付的标准化证据包制作流程：

第一步：抓取IKEv2协商过程（lo接口）

• 过滤条件：udp.port==500 || udp.port==4500
• 关键帧：IKE_SA_INIT响应包 → 查看Security Association Payload中的Transform Type=3 (Encryption)子项
• Wireshark显示：Encryption Algorithm: AES-GCM-16 (16)，Key Length: 256 bits
• 截图保存：标注“图1：IKEv2协商确认AES-GCM-256算法”

第二步：抓取业务流量（ipsec0接口）

• 过滤条件：tcp.port==80（或其他业务端口）
• 关键帧：任意一个HTTP请求包 → 展开ESP层 → 查看ESP (SPI=0x..., Seq=...)
• 验证点：
  • ICV length: 16 bytes（GCM固定16字节）
  • IV length: 12 bytes（GCM标准IV长度）
  • Payload length符合AES-256块对齐（必须是16字节倍数）
• 截图保存：标注“图2：业务包ESP头显示GCM参数”

第三步：交叉验证内核xfrm state

• 执行：sudo ip xfrm state show | grep -A 5 "spi 0x"（用Wireshark中SPI替换）
• 输出中必须包含：

  enc: aes-gcm-16 0x... 256 auth: hmac-sha2-256 0x... 256

• 截图保存：标注“图3：内核xfrm state确认算法与密钥长度”

这三张图，构成完整证据链：

• 图1证明“协商时约定用AES-GCM-256”；
• 图2证明“实际传输的包遵守该约定”；
• 图3证明“内核加载的SA与协商一致，未被篡改”。

注意：不要提供eth0抓包截图作为证据。因为eth0上只能看到密文，无法体现算法细节。审计方需要的是“可验证的协议行为”，不是“看起来像加密”。

5.2 算法降级攻击的Wireshark指纹：如何一眼识破MITM

虽然StrongSwan默认禁用弱算法，但若对手控制了IKE协商路径（如中间人劫持UDP 500），可能诱使双方降级到aes128-cbc-sha1。这种降级在Wireshark中有明确指纹：

实战中，我曾在一个客户网络中发现：Wireshark显示ESP (CBC)，但ipsec statusall明确写着esp=aes256gcm16。追查发现，客户防火墙启用了“IKE深度检测”，在转发IKE包时偷偷修改了SA提案，强制插入CBC算法。解决方法：关闭防火墙的IKE检测功能，或改用TCP封装（forceencaps=yes）绕过。

记住：Wireshark不是万能的，但它是最诚实的。它不会说谎，只会如实反映内核和网络给它的每一个字节。你要做的，是学会读懂这些字节背后的协议语言。

6. 经验沉淀：12年IPSec调试中总结的7条反直觉铁律

6.1 “越想看清加密，越要远离eth0”——抓包接口选择的终极心法

新手总想在物理口抓“最原始”的包，结果陷入密文迷宫。老手第一反应是：ip link add ipsec0 type xfrm。这不是偷懒，而是尊重Linux网络栈的设计哲学——IPSec不是附加层，而是内核网络协议栈的原生公民。xfrm interface就是它面向用户的API。在ipsec0上，你看到的不是“加密后的结果”，而是“加密前的输入”或“解密后的输出”，这才是调试的黄金平面。

6.2 “Wireshark的[Encrypted ESP Payload]不是bug，是feature”——理解工具的边界

很多人抱怨Wireshark“不能解密”，试图找插件、改源码。但设计者早想好了：用户态解密违背最小权限原则。Wireshark的使命是“展示协议结构”，不是“替代内核功能”。接受这个设定，你才能把精力用在刀刃上——比如，用ip xfrm state确认密钥，用/proc/net/xfrm_stat定位丢包，而不是在Lua脚本里徒劳地拼密钥。

6.3 “SPI不是密码，是身份证号”——破解StrongSwan状态管理的关键

SPI（Security Parameters Index）常被误解为加密密钥的一部分。其实它只是一个32位索引，类似数据库主键。StrongSwan用它在内存中快速查找对应的xfrm state。所以，当你看到Wireshark里SPI=0xc0a80001，立刻执行sudo ip xfrm state | grep 0xc0a80001，就能精准定位这条SA的所有参数。这是比翻日志快10倍的故障定位法。

6.4 “Sequence Number不是计数器，是防重放盾牌”——重放攻击的实时监测

Seq字段的递增性，是IPSec防重放的核心。但更关键的是：Wireshark能实时显示Seq是否“跳变”。如果看到Seq从100突然跳到10000，不要急着查网络延迟，先看/proc/net/xfrm_stat中XfrmInStateReplayed是否增长——这说明有人在重放旧包，你的隧道正遭受攻击。

6.5 “ICV OK不等于安全，ICV Bad才是警报”——校验失败的深层含义

Wireshark显示ICV OK，只代表“这个包没被篡改”，不代表“这个包来自合法对端”。真正的威胁是ICV Bad：它意味着要么密钥不一致（配置错误），要么包在传输中被恶意修改（中间人攻击）。此时必须立即检查XfrmInStateInvalid计数器，而不是继续抓包。

6.6 “MTU不是数字，是信任链的断裂点”——网络层与IPSec的耦合陷阱

我见过太多案例：StrongSwan配置完美，Wireshark显示一切正常，但大文件传输必断。根源都在MTU。IPSec封装增加固定开销（GCM模式+52字节），若路径MTU小于1448，就会触发分片。而IPSec与分片天生不兼容。解决方案不是调大MTU，而是用fragmentation=yes让StrongSwan在应用层分片，或用dpdaction=restart自动恢复。

6.7 “最强的加密，藏在最不起眼的/proc/net/xfrm_stat里”——内核统计才是真相之源

所有Wireshark的猜测，都要回归到/proc/net/xfrm_stat验证。这个文件是内核xfrm框架的健康仪表盘。XfrmInError增长？查防火墙。XfrmOutBundleGenError增长？查路由表。XfrmAcquire持续增加？说明policy匹配失败，流量没进IPSec。记住：Wireshark告诉你“发生了什么”，/proc/net/xfrm_stat告诉你“为什么发生”。

最后分享一个小技巧：把watch -n 1 'cat /proc/net/xfrm_stat | grep -E "XfrmIn|XfrmOut"'做成终端常驻窗口。当你在Wireshark里看到异常包时，立刻瞄一眼这个窗口——哪个计数器在跳，问题就在哪。这比翻1000行日志快得多。

IPSec不是魔法，它是Linux内核、StrongSwan守护进程、网络硬件共同编排的一场精密舞蹈。Wireshark是你的观剧望远镜，而真正的舞台，在/proc和ip xfrm的命令行世界里。