4、网络层安全：IPSec协议栈配置、IKEv2密钥协商、隧道模式与传输模式
各位好，咱们今天聊聊小基站网络层安全的核心——IPSec。说实话，我在做小基站安全方案时，IPSec 是我最依赖的协议之一。它不像应用层加密那样灵活，但胜在透明、高效，对上层应用完全无感。你想想看，小基站跑在运营商的回传链路上，数据一旦被截获，后果很严重。IPSec 就是那道最后的防线。
4.1 IPSec 协议栈：到底长什么样？
IPSec 不是一个单一的协议，而是一整套协议栈。我习惯把它拆成三块来看：
- 认证头（AH）：提供数据完整性校验和源认证，但不加密。说白了，它能保证数据没被篡改，但内容还是明文的。我在项目中很少单独用 AH，因为小基站场景下，加密往往是刚需。
- 封装安全载荷（ESP）：这才是主角。它既提供加密，又提供完整性校验。我建议你默认就用 ESP，别折腾 AH 了。
- 安全关联（SA）：这是 IPSec 的“契约”。通信双方必须协商出一套 SA，里面规定了用什么算法、什么密钥、什么模式。没有 SA，IPSec 就是空壳。
核心要点：IPSec 的工作流程就是“先建 SA，再传数据”。SA 是单向的，所以双向通信需要两个 SA。
4.2 IKEv2 密钥协商：比 IKEv1 强在哪？
IKE（Internet Key Exchange）负责自动协商 SA。早期版本是 IKEv1，但我强烈建议你直接上 IKEv2。为什么？
我曾经在某个项目中踩过 IKEv1 的坑——它需要 9 个报文才能完成一次协商，而且对 NAT 穿越的支持很差。小基站经常部署在 NAT 后面，结果 IKEv1 动不动就超时重传，搞得我头大。
IKEv2 就聪明多了：
- 它只用 4 个报文就能完成一次完整的密钥协商（2 个请求 + 2 个响应）。
- 它内置了 NAT 穿越支持，不用额外打补丁。
- 它支持 EAP 认证，方便对接运营商的 AAA 服务器。
嗯，这里要注意：IKEv2 的协商过程分为两个阶段：
- 阶段一（IKE_SA_INIT）：交换加密算法、DH 公钥、nonce，生成 IKE SA。这个阶段是明文交换的，所以一定要用强 DH 组（比如 Group 14 或 16）。
- 阶段二（IKE_AUTH）：在 IKE SA 的保护下，交换身份信息和证书，生成子 SA（也就是 IPSec SA）。这个阶段是加密的。
我的经验：IKEv2 的 DPD（Dead Peer Detection）机制很实用。我曾经用它来检测小基站与核心网之间的链路是否存活，一旦发现对端挂了，立即触发 SA 重建，避免了数据黑洞。
4.3 隧道模式 vs 传输模式：怎么选？
这是 IPSec 配置中最容易让人纠结的地方。我直接说结论：
| 特性 | 隧道模式 | 传输模式 |
|---|---|---|
| 保护范围 | 整个 IP 包（包括原 IP 头） | 仅 IP 载荷（传输层及以上） |
| 新增 IP 头 | 是，添加外层 IP 头 | 否，复用原 IP 头 |
| 适用场景 | 站点到站点（网关到网关） | 端到端（主机到主机） |
| 小基站场景 | 推荐（小基站 ↔ 核心网网关） | 不常用（除非是直连场景） |
说白了，隧道模式就是在原始 IP 包外面再套一层 IP 头。小基站回传时，原始 IP 包里的源地址可能是内网 IP，经过隧道封装后，外层 IP 头用的是公网 IP。这样内网拓扑就被隐藏了。
传输模式则更轻量，它不改变 IP 头，只加密传输层数据。但问题是，它要求两端 IP 地址必须可达。小基站通常通过 NAT 上网，传输模式很难直接工作。
避坑指南：我曾经在一个项目中，为了省带宽选了传输模式，结果小基站上报的 GTP-U 数据包因为 IP 头被篡改（NAT 改了源端口），导致完整性校验失败。后来老老实实改回隧道模式，问题解决。所以，小基站场景下，无脑选隧道模式就对了。
4.4 配置示例：用 strongSwan 实现 IKEv2 + 隧道模式
下面是我在实际项目中用过的配置片段。strongSwan 是 Linux 上最流行的 IKEv2 实现，小基站通常跑在 OpenWrt 或定制 Linux 上，这套配置可以直接移植。
服务端（核心网网关）配置：
# /etc/strongswan/swanctl.conf
connections {
enb-gw {
local_addrs = 203.0.113.1
remote_addrs = %any
local {
auth = pubkey
certs = gatewayCert.pem
id = "CN=gateway.example.com"
}
remote {
auth = pubkey
id = "CN=enb001.example.com"
}
children {
enb-net {
local_ts = 10.0.0.0/24 # 核心网侧子网
remote_ts = 192.168.1.0/24 # 小基站侧子网
esp_proposals = aes256-sha256-modp2048
mode = tunnel
}
}
version = 2
proposals = aes256-sha256-modp2048
}
}
客户端（小基站）配置：
# /etc/strongswan/swanctl.conf
connections {
gw {
local_addrs = 192.168.1.100
remote_addrs = 203.0.113.1
local {
auth = pubkey
certs = enbCert.pem
id = "CN=enb001.example.com"
}
remote {
auth = pubkey
id = "CN=gateway.example.com"
}
children {
core-net {
local_ts = 192.168.1.0/24
remote_ts = 10.0.0.0/24
esp_proposals = aes256-sha256-modp2048
mode = tunnel
}
}
version = 2
proposals = aes256-sha256-modp2048
}
}
关键点：
local_ts和remote_ts定义了哪些流量需要走 IPSec 隧道。只有匹配的流量才会被加密。esp_proposals指定了加密和完整性算法。我习惯用 AES-256 + SHA-256 + DH Group 14（modp2048），安全性和性能平衡得不错。mode = tunnel明确指定隧道模式。
4.5 性能与调优建议
IPSec 加密会消耗 CPU 资源。小基站的 CPU 通常不强，所以我有几点建议：
- 硬件加速：如果 SoC 支持 IPSec 卸载（比如 Crypto Engine），一定要开启。我在某款高通平台的小基站上，开启硬件加速后，吞吐量从 200 Mbps 飙升到 900 Mbps。
- SA 生命周期：别设得太短。我见过有人把 IKE SA 设成 1 小时，结果频繁重建 SA 导致 CPU 飙升。建议 IKE SA 设 24 小时，子 SA 设 8 小时。
- MTU 问题：隧道模式会增加 50-60 字节的开销。如果原始 MTU 是 1500，隧道后的实际 MTU 只有 1440 左右。记得在接口上设置
mtu 1400，避免分片。
一个小技巧：用 ipsec statusall 命令可以查看当前 SA 的状态和流量统计。我排查问题时，第一件事就是看 bytes 字段——如果加密流量一直为 0，说明策略没匹配上。
好了，IPSec 这块就聊到这儿。说白了，配置本身不复杂，难的是理解背后的原理和踩坑经验。你只要记住：小基站场景下，IKEv2 + ESP + 隧道模式，这套组合拳基本能应对 90% 的安全需求。下一章咱们聊聊传输层安全——TLS 在小基站信令面保护中的应用。