4、IPsec网络层安全：IPsec在车载网络中的应用场景
IPsec，说白了就是给网络数据包加了一把锁。在车载网络里，这把锁主要锁两个地方：一个是车跟外界通信的V2X，另一个是远程诊断通道。我最早接触IPsec是在一个T-Box项目上，当时客户要求所有诊断流量必须加密，嗯，那会儿我才真正开始啃这个协议栈。
V2X通信中的IPsec应用
V2X通信有个特点——消息是广播式的。你想想看，车跟车之间、车跟路侧单元之间，数据在空中飞来飞去，谁都能收到。但有些消息，比如高精定位的差分修正数据，或者某个车发出的紧急刹车信号，你肯定不希望被篡改。
我个人习惯把V2X的IPsec策略分成两类：
- 广播类消息：只用ESP的认证功能，不做加密。因为广播场景下，接收方不确定是谁发的，没法做单播的密钥协商。我建议用传输模式，只认证IP载荷，不加密，这样延迟最低。
- 单播类消息：比如V2X中的专用短程通信（DSRC）里，车跟某个特定路侧单元交换证书或密钥时，必须用隧道模式，加密+认证全开。
关键点：V2X的IPsec策略必须跟消息优先级配合。我记得有一次，安全策略配置得太重，导致紧急刹车消息延迟增加了30毫秒——这在高速场景下是致命的。后来我们把紧急消息的IPsec策略改成了仅认证，才解决了问题。
远程诊断中的IPsec应用
远程诊断是另一个典型场景。车在4G/5G网络下，诊断仪从云端发起连接，读取ECU的故障码或者刷写固件。这个通道如果不加密，相当于把车的内脏暴露在公网上。
我建议的做法是：
- 建立IKEv2隧道：诊断会话开始时，先通过IKEv2协商一个安全关联（SA）。
- 使用ESP隧道模式：整个诊断IP包都封装在ESP里，包括源IP和目标IP。这样即使中间人截获了流量，也只知道两个网关在通信，不知道具体是哪个ECU。
- 证书双向认证：车端和云端都要出示证书。我在项目中遇到过一个问题——云端只验证了车的证书，但车没有验证云端的证书，结果被伪造的诊断服务器攻击了。嗯，双向认证不能省。
小技巧：远程诊断的IPsec策略可以设置一个超时时间。比如诊断会话空闲超过5分钟，自动拆除SA。这样能节省车载网关的计算资源，毕竟车规级芯片的性能有限。
IKEv2自动密钥管理
IKEv2比IKEv1强在哪？说白了就是更稳定、更抗丢包。车载网络环境里，信号不稳定是常态，隧道建到一半断掉的情况太常见了。
IKEv2的核心流程我简单梳理一下：
| 步骤 | 消息 | 作用 |
|---|---|---|
| 1 | IKE_SA_INIT | 协商加密算法、交换DH公钥，建立初始的IKE SA |
| 2 | IKE_AUTH | 身份认证、交换证书，建立第一个Child SA |
| 3 | CREATE_CHILD_SA | 后续需要更多SA时，比如更换密钥或增加新隧道 |
| 4 | INFORMATIONAL | 删除SA、报告错误等管理消息 |
我个人习惯在车载项目里把IKEv2的重传间隔设短一些。默认的1秒重传太慢了，我一般改成200毫秒，最多重传5次。为什么？因为车在高速移动时，网络切换很快，隧道必须快速重建。我记得有一次测试，隧道重建花了3秒，结果诊断会话超时了——后来改成200毫秒重传，问题就解决了。
注意：IKEv2的DH组选择要谨慎。车载ECU的算力有限，不要用4096位的DH组，否则协商一次可能要好几秒。我建议用256位的椭圆曲线DH（ECP256），安全性和性能平衡得最好。
ESP/AH协议选择策略
ESP和AH，你选哪个？我的答案是：绝大多数场景选ESP。
AH提供的是认证+防重放，但不加密。ESP提供的是加密+认证+防重放。你想想看，车载网络里，数据在公网上传输，不加密等于裸奔。AH唯一的优势是头部开销小一点，但这点节省在车载场景里不值一提。
我总结了一个选择矩阵：
| 场景 | 推荐协议 | 原因 |
|---|---|---|
| V2X广播消息 | ESP（仅认证） | 不需要加密，但必须防篡改 |
| 远程诊断 | ESP（加密+认证） | 数据敏感，必须加密 |
| 车内ECU间通信 | AH | 车内网络相对安全，只需要防篡改 |
| OTA升级 | ESP（加密+认证） | 固件包必须加密传输 |
我的建议：除非你有非常明确的理由（比如车内高速骨干网，延迟要求极高），否则一律用ESP。AH在NAT环境下会出问题，这一点我下面会详细说。
我曾经踩过的IPsec与NAT兼容性坑
这个坑，我印象太深了。那是一个远程诊断项目，车在4G网络下，诊断仪在云端。测试时发现，诊断会话建立后，过几分钟就断掉了，而且断掉后重连特别慢。
查了两天，最后发现是NAT的问题。车载网关在运营商网络里，IP地址是私有的，经过NAT转换后才到公网。而IPsec的ESP协议，在NAT环境下有个致命问题——ESP的头部不包含端口信息，NAT设备没法区分多个ESP隧道。
具体来说，问题出在两个方面：
- ESP的SPI冲突：NAT后面的多个车，如果使用相同的SPI（安全参数索引），NAT设备就不知道把数据包转发给哪辆车。
- IKEv2的UDP封装：IKEv2使用UDP 500/4500端口，但NAT设备可能会修改UDP端口，导致IKE消息无法正确路由。
解决方案是这样的：
- 启用NAT-T（NAT穿越）：这是IPsec的一个扩展，把ESP包封装在UDP里（端口4500）。这样NAT设备就能通过UDP端口来区分不同的隧道。
- 使用IKEv2的NAT检测机制：IKEv2在协商时会检测两端之间是否有NAT设备。如果有，自动切换到UDP封装模式。
- 避免使用AH：AH认证的是整个IP包，包括源IP地址。经过NAT后，源IP变了，AH的认证就会失败。所以，有NAT的环境下，千万别用AH。
血的教训：我曾经在一个项目里，为了省带宽，用了AH协议。结果在NAT环境下，所有隧道都建不起来。后来全部改成ESP+NAT-T，才解决问题。从那以后，我只要看到车载项目有4G/5G网络，第一件事就是检查NAT-T是否启用。
嗯，IPsec在车载网络里的应用，说白了就是三个字：场景化。V2X用轻量级认证，远程诊断用全量加密，NAT环境必须开NAT-T。把这些坑填平了，你的车载网络安全架构才算真正落地。