大家好，欢迎来到IT知识分享网。
IKE是IPsec的核心组成部分，如果说IPsec是负责给网络数据“上锁”（加密）和“验身”（认证），IKE则用于“商量怎么锁”，“怎么交换钥匙”的。它是 IPsec 的助手，负责密钥和安全规则的交换。
在讲流程前，先理解两个关键术语，后面会反复用到：
① IKE SA，专门保护“IKE 协商过程”的规范手册（确保协商过程是安全的）。我们可以将其看做是“安全屋”。
② IPsec SA：真正用于给通信数据加密的规则手册。
SA可以理解为“安全规范手册”。里面记录了双方协商好的加密算法（如 AES）、认证算法（如 HMAC-SHA）、密钥、生存期（多久换一次规则）等。IPsec要工作，必须先有SA，IKE生成两类 SA。
IKE 的流程（以最经典的 IKEv1 为例）
IKEv1 的工作分两个阶段，可以类比成“先搭建用于谈判的安全屋，再在里面商量具体怎么保护数据”。
第一阶段 建立“IKE SA”（建立安全屋）
双方协商出一套保护 “后续协商” 的规则（IKE SA），并安全交换密钥材料，最后确认对方身份。
这个阶段有两种模式，分别是主模式（更安全，6 个消息）和野蛮模式（更快，3 个消息）。我们重点讲更通用的主模式（6 个消息，分 3 步）。
① 协商 “谈判室的基本规则”（消息 1-2）
协商过程就像两个人见面，先商量 “我们用中文聊，还是英文聊？”“说话时要不要用暗号加密？”，最后定下来 “用中文，加暗号”。
消息1（发起方→响应方）
发起方谈判：“我支持这些加密算法（如 AES-256）、认证算法（如 HMAC-SHA256）、密钥交换算法（如 DH 组 2），你看看能用哪个？”（相当于递一份 “安全规范清单”）。
消息2（响应方→发起方）
响应方从清单里挑一个双方都支持的组合，回复：“就用 AES 加密、SHA 认证、DH 组 2 吧！”（确定 “谈判室” 的基础规则）。
② 安全交换“密钥材料”（消息 3-4，核心！）
双方生成一个“共享密钥”，但不直接传递密钥（直接传会被截获），而是用Diffie-Hellman（DH）算法间接生成。
消息3（发起方→响应方）
发起方生成一个随机数（比如3），用DH算法处理后，把结果（3的公开计算结果）发给对方。
消息4（响应方→发起方）
响应方也生成一个随机数（比如5），用同样的DH算法处理后，把结果（5的公开计算结果）发给对方。
此时，双方都能根据自己的随机数和对方发来的 “计算结果”，算出同一个“共享密钥”（比如 3 和 5 通过 DH 算法，双方都能算出15）。
③ 确认对方身份（消息 5-6）
有了共享密钥后，双方要验证 “对方是不是自己人”（防止中间人冒充）。
（1）预共享密钥，双方提前约定一个“暗号”（比如“芝麻开门 123”）。发起方用共享密钥加密暗号发给对方，响应方解密后如果能对上，就确认身份。
（2）电子证书，类似“数字身份证”。发起方用自己的私钥给身份信息（如 IP 地址）签名，响应方用对方的公钥（从证书里取）验证签名，确认身份。
消息5（发起方）
发起方发送 “身份 + 身份验证信息”（加密的）。
消息6（响应方）
响应方发送 “身份 + 身份验证信息”（加密的），并确认收到。
到这里，“IKE SA”就建立好了，双方有了保护后续继续协商的“安全屋”。
第二阶段 建立“IPsec SA”（商量怎么保护数据）
在第一阶段建立的“安全屋”（IKE SA）里，协商出真正用于保护实际数据的规则（IPsec SA）。这个阶段叫快速模式（3 个消息）。
① 协商 “数据保护规则”（消息 1-2）
消息 1（发起方→响应方）
发起方说：“我想给数据加密，支持这些方式：隧道模式（包裹整个数据包）/ 传输模式（只加密数据部分）、AES-128 加密、HMAC-SHA1 认证，你看行吗？”
消息 2（响应方→发起方）
响应方确认一个双方都支持的组合，回复：“就用隧道模式、AES-128、SHA1！”
这个过程相当于在安全屋里，商量“给货物装箱时，是整个箱子锁起来（隧道模式），还是只锁箱子里的东西（传输模式）？用什么锁（加密算法）？怎么贴封条（认证算法）？”
② 生成 “会话密钥” 并确认（消息 3）
双方基于第一阶段的共享密钥，再结合新的随机数，生成专门用于IPsec的“会话密钥”（更短期，更安全）。
消息 3（发起方→响应方）
发起方确认“规则已收到”，并附上一个“确认码”（用新密钥计算的哈希值），证明自己确实生成了正确的密钥。
响应方收到后，验证确认码，若正确，IPsec SA 就正式生效。
Wireshark分析
通过Wireshark去观察IKE的交互全过程（1.1.1.1 是发起方路由，2.2.2.1是接收方路由），可以看到整个交互过程共分为9个UDP包，对应两个阶段，第一阶段6个包用于创建 IKE SA“安全屋”；第二阶段3个包则是用于建立 IPsec SA。
IKE交互共2阶段9个包
第一个阶段 IKE SA（6个消息包）
为了方便理解第一阶段的6个消息内容，特给出 H3C MSR36-20路由器中IKE配置。将Wireshark解析出的包内容，结合IKE配置去看，能更清晰的理解 IKE SA 功能。
H3C MSR36-20 发起方IKE配置 ike proposal 10 #加密、认证、秘钥交换算法 套餐 encryption-algorithm aes-cbc-128 dh group2 authentication-algorithm sha256 # ike keychain SiteB #预共享秘钥 pre-shared-key address 2.2.2.1 255.255.255.255 key cipher $c$3$Sb2R4dpt+nOikJ4kdHQ/TLQc/KmGpTNazlvoXxxaZQ== # ike profile SiteB keychain SiteB local-identity address 1.1.1.1 match remote identity address 2.2.2.1 255.255.255.255 proposal 10 ----------------分割线-------------- H3C MSR36-20 响应方IKE配置 ike proposal 10 encryption-algorithm aes-cbc-128 dh group2 authentication-algorithm sha256 # ike keychain SiteA pre-shared-key address 1.1.1.1 255.255.255.255 key cipher $c$3$ey0Mf+z0q7DzOAJaOXaIG1PkZhDjbiN5WAnP4PJVqA== # ike profile SiteA keychain SiteA local-identity address 2.2.2.1 match remote identity address 1.1.1.1 255.255.255.255 proposal 10 #第一个包（发起消息1）
第一个包 加密、认证等协商列表
发起方H3C MSR36-20：“我支持加密算法AES-CBC-128、认证算法SHA256、密钥交换算法DH 组 2，还有预共享秘钥，你呢？”
第二个包（响应消息2）
第二个包 加密、认证等协商列表
响应方回复：“我也有这个安全套餐，就用它吧”。
第三个包（发起消息3）
发起方生成一个随机数用DH算法处理后，把结果（Key Exchange Data）发给对方。
第四个包（响应消息4）
响应方也生成一个随机数，用同样的DH算法处理后，把结果（Key Exchange Data）发给对方。
此时，双方都能根据自己的随机数和对方发来的结果，算出同一个“共享密钥”
第五个包（消息5）
第五包 使用 pre-shared-key 加密
发起方：“我们把刚刚算出来的‘共享秘钥’对下账吧。嘘！小心有人窃听，我们使用‘预共享秘钥’加密后再交流。”
从第五个包已经是加密信息了，但这个加密信息是根据设备中“预共享秘钥”进行加密。
第六个包（消息6）
第六包 同样使用 pre-share-key 加密
发送方：“好的，我将我算出的‘共享秘钥’使用‘预共享秘钥’加密一下传送给你”
第六个包也是通过设备中“预共享秘钥”进行加密的。
IKE SA总结：可以看出整个第一阶段 IKE SA 的目标就是为了秘密地，不被窃取地生成“共享秘钥”，这个“共享秘钥”就是后续交流的“安全屋”，第二阶段IPsec SA交流都要使用这个“共享秘钥”来加密交流。
第二阶段 IPsec SA
IPsec SA整个阶段交互信息都是加密的，加密方法都是使用第一阶段 IKE SA 生成的“共享秘钥”。
第7，8，9都是加密信息了
由于都是加密信息，Wireshark失去了分析能力。我们根据H3C MSR36-20发起方与响应方的配置去理解。
H3C MSR36-20 发起方配置 ipsec transform-set ESP-AES-SHA esp encryption-algorithm 3des-cbc esp authentication-algorithm sha1 encapsulation-mode tunnel protocol esp # ipsec policy VPN-POLICY 10 isakmp transform-set ESP-AES-SHA security acl 3001 remote-address 2.2.2.1 ike-profile SiteA # --------分割线-------- H3C MSR36-20 响应方配置 ipsec transform-set ESP-AES-SHA esp encryption-algorithm 3des-cbc esp authentication-algorithm sha1 encapsulation-mode tunnel protocol esp # ipsec policy VPN-POLICY 10 isakmp transform-set ESP-AES-SHA security acl 3001 remote-address 1.1.1.1 ike-profile SiteB #第二阶段 IPsec SA 交互信息如下：
发起方说：“我想给数据加密，我支持隧道模式tunnel，协议是esp，加密算法3des-cbc，认证方式SHA1，你呢？”
响应方说：“我也支持隧道模式tunnel，协议也是esp，加密算法3des-cbc，认证方式SHA1。”
发起方确认：“规则已收到”，并附上一个“确认码”（用新密钥计算的哈希值），证明自己确实生成了正确的密钥。
响应方收到后，验证确认码，若正确，IPsec SA 就正式生效。
IPsec SA总结：这个阶段交流都要使用第一阶段IKE SA 生成“共享秘钥”来加密交流。第二阶段目的是新协商一套加密、认证以及传输协议的规则。一旦协商成功后，后续数据封装、交互都按照此规则来执行。
总结 IKEv1 的完整流程
第一阶段（主模式 6 消息），搭好 “安全屋”（IKE SA），确定保护协商的规则，用 DH 生成共享密钥，互相验明身份。
第二阶段（快速模式 3 消息）：在“安全屋”里商量好“保护数据的规则”（IPsec SA），生成会话密钥，确认生效。
之后，IPsec 就可以用 IPsec SA 里的规则，给实际传输的数据加密、认证了。
补充IKEv2的改进
IKEv1虽然经典，但流程较长（9 个消息），IKEv2 简化了流程。
合并两个阶段，用4个消息就能同时建立 IKE SA 和第一个 IPsec SA；
支持更灵活的密钥更新、NAT 穿越（比如在家用路由器后也能正常协商）；
更适合移动场景（比如手机切换网络时，能快速重连）。
但核心逻辑不变：先建立保护协商的安全通道，再协商保护数据的规则。
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://haidsoft.com/189708.html
