IPSec协议框架IPsec 不是一个单一协议而是一个框架包含三个核心标准协议ESPEncapsulating Security Payload真正干活的“保镖”负责加密和完整性校验保护用户数据。AHAuthentication Header只负责完整性校验和身份认证不加密现网很少单独使用。IKEInternet Key Exchange幕后“管家”负责自动协商出 ESP/AH 工作所需的各种参数密钥、算法、SPI 等。一句话IKE 负责“谈好条件”ESP/AH 负责“按条件执行”。绝大数现网 VPN 只用IKE ESPAH 几乎被淘汰。完整工作流程以 IKEv1 主模式 ESP 隧道模式为例1. 触发 VPN 流量如访问对端子网 ↓ 2. IKE 第一阶段主模式 ├─ 消息1-2明文协商 IKE 策略加密算法、哈希、DH组等 ├─ 消息3-4DH 交换 → 计算出 DH 共享密钥生成随机数 └─ 消息5-6在加密隧道中交换身份和认证数据 → 建立 IKE SA ↓ 3. IKE 第二阶段快速模式 ├─ 在 IKE SA 保护下协商感兴趣流ACL、新随机数 ├─ 使用 SKEYID_d 随机数派生出 ESP 加密密钥和认证密钥 └─ 建立一对 IPsec SA入方向和出方向 ↓ 4. 数据包处理以 ESP 隧道模式为例 ├─ 原始 IP 包如 PC→Server ├─ 防火墙/网关根据 ACL 匹配决定送入 IPsec 隧道 ├─ 查找出方向的 IPsec SA获得 SPI、加密密钥、认证密钥 ├─ 对原始 IP 包加密加上 ESP 头和尾计算 ICV ├─ 封装在新的 IP 头中源本端公网IP目的对端公网IP协议50 └─ 发送到公网 ↓ 5. 接收端处理 ├─ 收到协议 50 的包提取 SPI查找入方向的 IPsec SA ├─ 验证序列号抗重放 ├─ 验证 ICV完整性 ├─ 解密载荷 └─ 还原原始 IP 包转发给内网服务器在IPsec VPN中IKEInternet Key Exchange是唯一的“谈判官”和“信使”。两台防火墙之间所有关于“如何保护数据”的细节——用什么加密算法、用什么哈希算法、用什么密钥、保护哪些流量、多长时间换一次密钥——都必须由IKE协议来承载和传递。没有IKE就没有自动协商只能靠手工配置现网基本不用。一句话IKE负责所有控制层面的沟通数据层面ESP/AH只管“埋头干”不问“怎么干”。IKE的协商IKE主模式的前4条消息确实是明文发送的其中包含了DH公共值ga mod p 和 gb mod p和随机数Nonce这正是IKE协议的精妙所在。它的设计前提就是让DH交换在公开的、不安全的信道上完成并且交换的内容是安全的。IKEInternet Key Exchange的前期交换IKE_SA_INIT / 主模式前4个包确实是明文传输。但这并不危险因为真正敏感的“身份信息”ID、预共享密钥哈希在加密的交换阶段才发送。用于生成加密密钥的DH公开值公钥即使明文泄露也无法反向计算出共享密钥离散对数难题。设计之初就假设网络是“可窃听但不可篡改”的只防被动攻击不防中间人 – 中间人攻击需要靠预共享密钥或证书来防范。底层原理 设计逻辑以IKEv1为例IKEv1主模式Main Mode交换分3个“交换对”共6个包交换对报文内容是否加密泄露风险1(包1-2)IKE策略提议加密算法、哈希算法、DH组、认证方式❌ 明文低 – 攻击者知道你在用什么算法无法直接破解2(包3-4)DH公开值 (ga mod p)、Nonce随机数❌ 明文极低 –离散对数难题知道g^a mod p和g^b mod p无法算出g^{ab} mod pDH共享密钥3(包5-6)身份IDIP或FQDN、认证数据预共享密钥哈希或证书签名✅已加密无 – 此时双方已用DH共享密钥 Nonce派生出SKEYID_e加密密钥报文加密IKE SA与IPSec SAIKE SA 是“控制通道”IPsec SA 是“数据通道”。IKE SA 负责安全地协商出用于加密数据流的密钥和参数IPsec SA 则使用这些参数实际加密传输业务数据。两者是“司令官”与“士兵”的关系司令IKE SA下达作战方案后士兵IPsec SA执行加密传输任务。IKE SA状态检测机制IKE SA 状态检测DPD / Heartbeat的本质是在无连接的 UDP 协议IKE 基于 UDP 500/4500之上模拟“心跳”机制来探测对端是否存活。由于 IKE 协议本身没有 Keepalive 机制当一端崩溃、链路断开或设备重启另一端会一直保留“僵尸”IKE SA误以为通道正常导致业务数据发向黑洞而丢包。DPDDead Peer Detection对等体失效检测和 Heartbeat 就是填补这个空白的“探针”。IPSec VPNIPSec VPN 点到点应用场景IPSec VPN点到多点应用场景IPsec隧道两端用于定义保护流的ACL规则必须互为镜像比如如果有A和B两个站点你在A端设置ACL规则为源192.168.1.0 → 目的192.168.2.0那么在B端你就必须设置ACL规则为源192.168.2.0 → 目的192.168.1.0。这样两端定义的ACL就形成了互相映射的关系才能保证加密流正常封装。为什么必须这样做IPsec要保护的数据流理论上包括从A端到B端的通信也包括从B端回A端的通信。如果只有一端配置了流向规则另一方没有对应的反向规则会导致SA无法建立或者只能单向通信。只有两端都正确配置了镜像ACL无论哪一端先发起通信协商都能成功建立隧道。IPSec VPN点到多点应用场景GRE over IPSec应用场景
IP安全 SEC VPN_2
发布时间：2026/5/25 8:57:05
IPSec协议框架IPsec 不是一个单一协议而是一个框架包含三个核心标准协议ESPEncapsulating Security Payload真正干活的“保镖”负责加密和完整性校验保护用户数据。AHAuthentication Header只负责完整性校验和身份认证不加密现网很少单独使用。IKEInternet Key Exchange幕后“管家”负责自动协商出 ESP/AH 工作所需的各种参数密钥、算法、SPI 等。一句话IKE 负责“谈好条件”ESP/AH 负责“按条件执行”。绝大数现网 VPN 只用IKE ESPAH 几乎被淘汰。完整工作流程以 IKEv1 主模式 ESP 隧道模式为例1. 触发 VPN 流量如访问对端子网 ↓ 2. IKE 第一阶段主模式 ├─ 消息1-2明文协商 IKE 策略加密算法、哈希、DH组等 ├─ 消息3-4DH 交换 → 计算出 DH 共享密钥生成随机数 └─ 消息5-6在加密隧道中交换身份和认证数据 → 建立 IKE SA ↓ 3. IKE 第二阶段快速模式 ├─ 在 IKE SA 保护下协商感兴趣流ACL、新随机数 ├─ 使用 SKEYID_d 随机数派生出 ESP 加密密钥和认证密钥 └─ 建立一对 IPsec SA入方向和出方向 ↓ 4. 数据包处理以 ESP 隧道模式为例 ├─ 原始 IP 包如 PC→Server ├─ 防火墙/网关根据 ACL 匹配决定送入 IPsec 隧道 ├─ 查找出方向的 IPsec SA获得 SPI、加密密钥、认证密钥 ├─ 对原始 IP 包加密加上 ESP 头和尾计算 ICV ├─ 封装在新的 IP 头中源本端公网IP目的对端公网IP协议50 └─ 发送到公网 ↓ 5. 接收端处理 ├─ 收到协议 50 的包提取 SPI查找入方向的 IPsec SA ├─ 验证序列号抗重放 ├─ 验证 ICV完整性 ├─ 解密载荷 └─ 还原原始 IP 包转发给内网服务器在IPsec VPN中IKEInternet Key Exchange是唯一的“谈判官”和“信使”。两台防火墙之间所有关于“如何保护数据”的细节——用什么加密算法、用什么哈希算法、用什么密钥、保护哪些流量、多长时间换一次密钥——都必须由IKE协议来承载和传递。没有IKE就没有自动协商只能靠手工配置现网基本不用。一句话IKE负责所有控制层面的沟通数据层面ESP/AH只管“埋头干”不问“怎么干”。IKE的协商IKE主模式的前4条消息确实是明文发送的其中包含了DH公共值ga mod p 和 gb mod p和随机数Nonce这正是IKE协议的精妙所在。它的设计前提就是让DH交换在公开的、不安全的信道上完成并且交换的内容是安全的。IKEInternet Key Exchange的前期交换IKE_SA_INIT / 主模式前4个包确实是明文传输。但这并不危险因为真正敏感的“身份信息”ID、预共享密钥哈希在加密的交换阶段才发送。用于生成加密密钥的DH公开值公钥即使明文泄露也无法反向计算出共享密钥离散对数难题。设计之初就假设网络是“可窃听但不可篡改”的只防被动攻击不防中间人 – 中间人攻击需要靠预共享密钥或证书来防范。底层原理 设计逻辑以IKEv1为例IKEv1主模式Main Mode交换分3个“交换对”共6个包交换对报文内容是否加密泄露风险1(包1-2)IKE策略提议加密算法、哈希算法、DH组、认证方式❌ 明文低 – 攻击者知道你在用什么算法无法直接破解2(包3-4)DH公开值 (ga mod p)、Nonce随机数❌ 明文极低 –离散对数难题知道g^a mod p和g^b mod p无法算出g^{ab} mod pDH共享密钥3(包5-6)身份IDIP或FQDN、认证数据预共享密钥哈希或证书签名✅已加密无 – 此时双方已用DH共享密钥 Nonce派生出SKEYID_e加密密钥报文加密IKE SA与IPSec SAIKE SA 是“控制通道”IPsec SA 是“数据通道”。IKE SA 负责安全地协商出用于加密数据流的密钥和参数IPsec SA 则使用这些参数实际加密传输业务数据。两者是“司令官”与“士兵”的关系司令IKE SA下达作战方案后士兵IPsec SA执行加密传输任务。IKE SA状态检测机制IKE SA 状态检测DPD / Heartbeat的本质是在无连接的 UDP 协议IKE 基于 UDP 500/4500之上模拟“心跳”机制来探测对端是否存活。由于 IKE 协议本身没有 Keepalive 机制当一端崩溃、链路断开或设备重启另一端会一直保留“僵尸”IKE SA误以为通道正常导致业务数据发向黑洞而丢包。DPDDead Peer Detection对等体失效检测和 Heartbeat 就是填补这个空白的“探针”。IPSec VPNIPSec VPN 点到点应用场景IPSec VPN点到多点应用场景IPsec隧道两端用于定义保护流的ACL规则必须互为镜像比如如果有A和B两个站点你在A端设置ACL规则为源192.168.1.0 → 目的192.168.2.0那么在B端你就必须设置ACL规则为源192.168.2.0 → 目的192.168.1.0。这样两端定义的ACL就形成了互相映射的关系才能保证加密流正常封装。为什么必须这样做IPsec要保护的数据流理论上包括从A端到B端的通信也包括从B端回A端的通信。如果只有一端配置了流向规则另一方没有对应的反向规则会导致SA无法建立或者只能单向通信。只有两端都正确配置了镜像ACL无论哪一端先发起通信协商都能成功建立隧道。IPSec VPN点到多点应用场景GRE over IPSec应用场景
