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完成解密后会以明文形式注入ipsec0outbound方向明文业务包从应用层下来先送到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段 leftsubnet10.10.10.0/24 rightsubnet192.168.20.0/24 # 添加以下两行 xfrmiipsec0 xfrmi_ifid12.2 实测对比同一台机器三个接口抓包结果全记录我用一台Ubuntu 22.04内核5.15.0 StrongSwan 5.9.8搭建了标准road-warrior隧道客户端Android StrongSwan App访问服务端Nginx10.10.10.10:80。分别在eth0、lo、ipsec0上执行tcpdump并导入Wireshark分析抓包接口inbound方向客户端→服务端outbound方向服务端→客户端Wireshark能否展开TCP头eth0ESP包SPI0xc0a80001Payload[Encrypted ESP Payload]ESP包SPI0x0a0a0a01Payload[Encrypted ESP Payload]❌ 全部显示为加密载荷loIKEv2消息SA_INIT, AUTH等明文可见同上✅ 可见IKE明文但无业务流ipsec0明文HTTP GET / HTTP/1.1源IP192.168.20.100目的IP10.10.10.10明文HTTP响应源IP10.10.10.10目的IP192.168.20.100✅ 完整TCP/IP/HTTP头均可展开这个表格背后是内核网络栈的真实流向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包。结果必然失败。原因有三内核未开放密钥导出接口Linux内核出于安全考虑禁止用户态程序直接读取已加载的xfrm state密钥/proc/net/xfrm_state中key字段始终为0000...。Wireshark无法获取真实密钥材料。解密时机错位即使你硬编码密钥到Lua脚本Wireshark是在pcap包到达后才尝试解密而此时内核早已将原始密文丢弃不会保留解密上下文。缺少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头部只有两个强制字段SPISecurity Parameters Index4字节标识该包属于哪个SASecurity Association。它不是随机数而是StrongSwan在ike_sa_init响应中协商确定的32位整数存于/etc/ipsec.d/ipsec.sql或运行时内存。Sequence Number4字节防重放计数器每发送一个ESP包1。Wireshark将其显示为ESP (SPI0xc0a80001, Seq123)。但Wireshark界面上你看到的远不止这些。关键在于加密状态决定了哪些字段能被解析哪些只能显示为“未知字节”。我们以StrongSwan默认配置aes128gcm16-sha256-modp2048为例对比加密开启与关闭时的Wireshark显示差异字段名加密开启正常IPSec加密关闭仅IPSec SA存在但未启用加密解析原理说明Next Header显示为TCP (6)或UDP (17)显示为Unknown (59)ESP头部后紧跟的协议类型。加密开启时内核在xfrm_input解密后填充此字段关闭时原始IP头被覆盖Wireshark无法推断。Payload Len显示为128 bytes含padding显示为0或错误值加密后载荷长度 原始IP包长 paddingAES要求16字节对齐 ICVGCM为16字节。未加密时该字段无意义。IVInitialization Vector显示为12 bytesGCM模式不显示或显示为00000000...GCM模式下IV固定12字节由内核生成并置于ESP头后。Wireshark可识别其位置但内容不可读因与密钥绑定。ICVIntegrity Check Value显示为16 bytes状态OK或Bad不显示GCM的认证标签用于校验密文完整性。Wireshark可提取并比对但无法计算——它依赖内核解密时返回的校验结果。Encrypted Payload显示为[Encrypted ESP Payload]eth0或[Decrypted Payload]ipsec0显示为[Malformed Packet]或[Truncated]核心区别所在。加密开启时载荷区域为密文关闭时由于缺少正确封装数据结构错乱。提示Wireshark的ESP dissectorepan/dissectors/packet-esp.c并不真正解密它只是根据RFC格式定位各字段偏移。例如它知道GCM模式下ICV总在末尾16字节于是直接截取最后16字节标为ICV但它无法验证这16字节是否真能通过GCM校验——那必须由内核xfrm在解密时完成。3.2 实战判据3秒判断StrongSwan是否真正在加密别再靠猜。打开Wireshark按以下顺序检查3秒内得出结论看SPI值是否合理正常IPSecSPI为非零、非全F的32位十六进制数如0xc0a80001对应192.168.0.1的IP。异常情况SPI0x00000000或0xffffffff表明SA未正确建立StrongSwan未下发xfrm state到内核。验证命令sudo ip xfrm state | grep spi输出应与Wireshark中SPI一致。看Sequence Number是否递增正常连续抓包Seq字段严格1如123→124→125。异常Seq恒为1或跳跃式增长如1→100→200说明replay window未启用或配置错误reauthno导致重连不重置计数器。看ICV状态栏正常Wireshark右下角状态栏显示ESP: ICV OK绿色。异常显示ESP: ICV Bad红色意味着密文在传输中被篡改或两端算法/密钥不匹配。此时/proc/net/xfrm_stat中XfrmInStateInvalid计数器会1。看Next Header字段在ipsec0上必须显示为业务协议TCP/UDP/ICMP。若显示Unknown (59)说明xfrm policy未正确匹配流量检查ip xfrm policy中的selector范围。在eth0上若显示为TCP则100%说明加密未启用——因为eth0上绝不可能出现未加密的业务包除非你禁用了IPSec。看Packet Bytes面板的十六进制视图正常加密ESP头后紧接12字节IV随机然后是密文无ASCII特征最后16字节ICV随机。异常未加密ESP头后直接是明文IP头如45 00 00 40 ...说明espaes128gcm16配置被忽略或StrongSwan降级为NULL加密espnull。这五点是我在线上排查时最常用的“闪电诊断法”。它不依赖日志不重启服务只看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 stateSA是否建立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.port500 || udp.port4500查看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客户端XfrmInStateExpiredSA过期未重协商 → 检查rekeytime30m配置XfrmInStateInvalidICV校验失败 → 密钥不一致或网络篡改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为1500ESP封装后52字节变成1552字节触发分片。但IPSec RFC明确规定ESP不支持分片后的重组。内核xfrm_input在收到第一个分片时因缺少完整ESP头SPI/Seq在首片直接丢弃并计数XfrmInStateInvalid。解决方案只有两个治标在StrongSwan配置中强制降低MTU# /etc/ipsec.conf 中 conn段添加 fragmentationyes # 并在客户端网卡执行 ip link set eth0 mtu 1380治本在网络路径上启用PMTUDPath MTU Discovery确保两端协商出最小MTU。检查/proc/sys/net/ipv4/ip_no_pmtu_disc是否为0默认是0即启用。这个坑我踩过三次。每次都是因为忽略了“Wireshark能看到包不代表内核能处理包”这一基本事实。记住网络层的分片、路由、ARP永远在IPSec加密之前发生。把IPSec当成黑盒之前先确保它的输入是干净的IP包。5. 加密强度的可视化验证如何用Wireshark证明你真的用了AES-GCM-2565.1 安全审计刚需甲方要你“拿出证据”而不是“我说用了”在等保测评、金融行业安全检查中经常遇到这样的要求“请提供技术证据证明你们的IPSec隧道使用了AES-GCM-256加密而非弱算法。” 很多人直接甩出ipsec statusall截图上面写着espaes256gcm16——这不够。甲方会问“这个配置真的生效了吗有没有可能被降级”Wireshark就是你的法庭证人。以下是向审计方交付的标准化证据包制作流程第一步抓取IKEv2协商过程lo接口过滤条件udp.port500 || udp.port4500关键帧IKE_SA_INIT响应包 → 查看Security Association Payload中的Transform Type3 (Encryption)子项Wireshark显示Encryption Algorithm: AES-GCM-16 (16)Key Length: 256 bits截图保存标注“图1IKEv2协商确认AES-GCM-256算法”第二步抓取业务流量ipsec0接口过滤条件tcp.port80或其他业务端口关键帧任意一个HTTP请求包 → 展开ESP层 → 查看ESP (SPI0x..., Seq...)验证点ICV length: 16 bytesGCM固定16字节IV length: 12 bytesGCM标准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中有明确指纹特征AES-GCM-256安全AES-CBC-128降级风险ESP头后字段直接是12字节IVIV后还有Padding Length和Next Header字段CBC必需ICV位置固定末尾16字节无ICV字段依赖单独的AUTH payload在IKE消息中Payload长度总是16字节对齐可能出现非16字节对齐如23字节Wireshark解析显示ESP (GCM)显示ESP (CBC)且Padding字段可见实战中我曾在一个客户网络中发现Wireshark显示ESP (CBC)但ipsec statusall明确写着espaes256gcm16。追查发现客户防火墙启用了“IKE深度检测”在转发IKE包时偷偷修改了SA提案强制插入CBC算法。解决方法关闭防火墙的IKE检测功能或改用TCP封装forceencapsyes绕过。记住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状态管理的关键SPISecurity Parameters Index常被误解为加密密钥的一部分。其实它只是一个32位索引类似数据库主键。StrongSwan用它在内存中快速查找对应的xfrm state。所以当你看到Wireshark里SPI0xc0a80001立刻执行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而是用fragmentationyes让StrongSwan在应用层分片或用dpdactionrestart自动恢复。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的命令行世界里。
