4、IPsec协议：IPsec工作模式（传输模式与隧道模式）、安全关联（SA）、IKE密钥交换、在遥测中的应用
聊到遥测链路的加密，IPsec 绝对是个绕不开的老大哥。我最早接触它是在一个跨地域的工业遥测项目里，那时候数据要穿越公网，领导一拍桌子说「必须加密」。我第一反应就是 IPsec——这玩意儿成熟、稳定，而且操作系统原生支持，省去了很多应用层改造的麻烦。
说白了，IPsec 不是单个协议，而是一整套安全框架。它工作在 IP 层，对上层应用完全透明。你的遥测程序根本不知道底下在加密，它只管发 UDP 或 TCP 包就行。这一点在遥测场景里特别香——你想想看，很多老旧的遥测设备，你根本没法改它的代码，IPsec 正好能兜底。
4.1 IPsec 的两种工作模式
IPsec 有两种模式：传输模式和隧道模式。我刚开始学的时候老搞混，后来在项目里踩了坑才彻底弄明白。
传输模式
传输模式只加密 IP 包的数据部分，不碰 IP 头。说白了，它就是在原始 IP 头和传输层头之间插一个 IPsec 头。这种模式的好处是开销小，但缺点也很明显——原始 IP 地址是明文的。
我在一个内部遥测网络里用过传输模式。两台服务器之间直连，中间没有 NAT 设备，跑得很稳。但如果你要穿越公网，我建议你慎重——因为 IP 头暴露了，攻击者能知道谁在和谁通信。
隧道模式
隧道模式就狠多了。它把整个原始 IP 包都加密，然后外面再套一个新的 IP 头。新 IP 头通常是网关的地址，原始 IP 包里的源目地址完全隐藏。
遥测场景里，隧道模式是绝对的主流。举个例子，你有一个遥测站点的数据要回传中心，中间经过公网。你在站点网关和中心网关之间建一条 IPsec 隧道，所有遥测数据包都被加密封装。公网上的攻击者只能看到两个网关在通信，根本不知道里面是啥。
核心区别一句话总结：传输模式加密数据但不隐藏 IP，隧道模式连 IP 一起加密。遥测跨公网传输，无脑选隧道模式。
4.2 安全关联（SA）
SA 是 IPsec 的灵魂。没有 SA，IPsec 就是一具空壳。SA 定义了通信双方怎么加密、怎么认证、密钥是什么、有效期多久。你可以把它理解成一份「加密合同」。
SA 是单向的。什么意思？A 到 B 需要一个 SA，B 到 A 需要另一个 SA。所以一个双向通信至少需要两个 SA。我记得第一次配 IPsec 时，只配了一个方向的 SA，结果数据只能发出去收不回来——嗯，这个坑我替你们踩过了。
每个 SA 由三个要素唯一标识：
- 安全参数索引（SPI）：一个 32 位的数字，接收方用它来查找对应的 SA
- 目的 IP 地址：SA 接收端的 IP
- 安全协议：是 AH 还是 ESP
实际项目中，SA 的维护是个细活。我见过一个遥测系统，SA 超时时间设得太短，导致频繁重建，CPU 飙升。后来我建议把 SA 生命周期设到 8 小时，配合 IKE 的定期重认证，既安全又稳定。
4.3 IKE 密钥交换
SA 里的密钥怎么来的？靠 IKE（Internet Key Exchange）。IKE 负责在通信双方之间协商加密参数、认证身份、生成密钥。它分两个阶段：
第一阶段：建立 IKE SA
这个阶段是保护后续协商的通道。双方先互相认证身份，然后生成一个共享密钥。认证方式可以是预共享密钥（PSK），也可以是证书。我个人习惯用证书，尤其是在遥测节点数量多的时候，证书管理比 PSK 靠谱得多。
我曾经遇到过一个项目，几十个遥测站点都用同一个 PSK。后来一个站点被攻破，所有站点的 IPsec 都得重新配密钥——那叫一个酸爽。从那以后，我再也不敢偷懒了，每个站点单独配证书。
第二阶段：建立 IPsec SA
第一阶段的安全通道建好后，第二阶段就在这个通道里协商具体的 IPsec SA。这里会确定用哪种加密算法（AES-256 是标配）、哪种认证算法（SHA-256 起步）、以及 SA 的生命周期。
我的建议：遥测数据通常对实时性要求高，但数据量不大。IKE 的 DPD（Dead Peer Detection）一定要开，间隔设到 10 秒。这样对端挂了能快速感知，避免数据黑洞。
4.4 在遥测中的应用
遥测链路加密，IPsec 是首选方案之一。为什么？因为遥测设备五花八门，有的跑 Modbus，有的跑 DNP3，有的干脆是私有协议。IPsec 在 IP 层工作，不管你上层跑什么协议，统统加密。
我参与过一个风电场的遥测项目。每个风机上有一个 RTU，通过 4G 网络把数据发回集控中心。4G 网络是公网，数据裸奔肯定不行。我们在每个 RTU 和中心网关之间建了 IPsec 隧道，用的隧道模式 + ESP + AES-256。
部署的时候有个细节：4G 网络的 IP 地址是动态分配的。IKE 支持用域名或者 DDNS 来标识对端，这样即使 IP 变了，隧道也能自动重建。嗯，这个坑我也踩过——一开始用的静态 IP，结果运营商一换 IP，隧道全断了。
注意：IPsec 会增加一定的延迟和 CPU 开销。在遥测场景里，如果数据量不大（比如每分钟几条报文），这点开销可以忽略。但如果你的遥测系统是高频采样（比如每秒上千条），建议先做性能测试。我曾经在一个高频振动监测项目里，IPsec 加密导致 CPU 占用到 70%，后来换了硬件加速卡才解决。
另外，IPsec 对 NAT 不太友好。ESP 协议是 IP 协议号 50，很多 NAT 设备不认识。解决办法是用 NAT-T（NAT Traversal），把 ESP 包封装在 UDP 里。现在主流的 IPsec 实现都支持 NAT-T，但记得两端都要开启。
最后说一句，IPsec 不是银弹。如果你的遥测系统对延迟极其敏感，或者设备性能太差，可以考虑轻量级的方案比如 WireGuard。但如果你要的是成熟、稳定、标准兼容，IPsec 依然是那个最靠谱的选择。
公众号:蓝海资料掘金营，微信deep3321