IPSec工作原理——TK

如果要实现加密或者完整性校验，我们肯定需要加密的密钥key，还得要有算法。

密钥跟算法可以手工配置，但是手工配置，就固定住了，所以用IKE，IKE可以认为是一个框架（互联网密钥交换），它是一个框架，里面包含很多协议

IPSec与IKE的本质区别

核心思想：IPsec负责"加密数据"，IKE负责"安全地商量怎么加密"

一句话 ：IPsec本身只是一个数据平面协议（如何封装、加密、认证），但它没有规定密钥和算法从哪里来。你可以手工把密钥和算法"写死"在两端设备里，但这样做有严重问题。IKE就是解决这些问题的控制平面协议。

一、手工配置密钥和算法：静态、脆弱、难维护

假设两个网关之间要建立IPsec VPN，管理员手工配置：

加密算法：AES256
认证算法：SHA256
密钥：0123456789abcdef0123456789abcdef（32字节）

两端配成一样，IPsec就能工作。

缺点：

密钥固定不变：同一个密钥长期使用，攻击者收集大量密文后可以尝试密码分析破解。即使不破解，内部人员离职、怀疑泄露，必须手动更换密钥------需通知所有对端，改配置，重启SA，业务中断。

无身份认证：手工配置只能验证"对方知道这个密钥"，但无法确认对方是不是合法的设备。如果密钥泄露，任何人都可以冒充。

无法扩展：10个站点两两建立VPN，需要45个手工配置的密钥对（每个 pair 一个），管理噩梦。100个站点几乎不可行。

无法动态更新：当需要更换算法（如发现SHA1有弱点），所有设备重新配置。

无完美前向保密（PFS）：如果攻击者记录了所有密文，未来某天拿到了长期密钥，可以解密所有历史流量。手工配置无法做到一次一密。

二、IKE框架：自动、安全、动态

IKE（Internet Key Exchange）是一个框架，包含多个协议（IKEv1、IKEv2、扩展如NAT-T、DPD等），核心功能：

自动协商算法：双方互相交换支持的加密、认证、DH组列表，选择共同的最优组合。

动态生成密钥：通过Diffie-Hellman（DH）交换，每次通信或定期生成全新的密钥。

身份认证：使用预共享密钥（PSK）或数字证书，确认对方身份。

定期重密钥：IKE SA和IPsec SA都有生命周期（如3600秒），到期后自动重新协商新密钥。

完美前向保密（PFS）：每次IPsec SA重新协商时，重新执行DH交换，即使长期密钥泄露，也无法解密过去的会话。

IKE不是一个单独的加密算法，而是一套流程：包括两个阶段（IKEv1）或两个交换（IKEv2），里面用到DH、非对称签名、哈希、对称加密等许多密码学组件。

IPsec：数据平面，负责加密、封装、认证具体报文。
IKE：控制平面，负责安全地协商IPsec使用的密钥、算法、参数，并定期更新。

IKE、ISAKMP、Oakley、SKEME的关系

在IKE的学习中，ISAKMP是需要精通的绝对核心，因为它既是定义报文格式和交换过程的"骨架"，也是 IKE 本身真正的"本质协议"，更是我们日常配置IPsec VPN时唯一能直接操作的协议。Oakley和SKEME作为贡献具体方法和算法的鼻祖，对我们来说了解其理念即可。

简单理解：IKE、ISAKMP、Oakley、SKEME的关系

ISAKMP ：定义通用框架 （报文格式、交换阶段、状态机），不关心具体密钥交换算法。它像一个"协议骨架"。

Oakley ：定义具体的密钥交换模式 ，核心是Diffie-Hellman + 身份保护 + 完美前向保密。它提供"算法和机制"。

SKEME ：定义多种认证方式 （预共享密钥、数字签名、公钥加密）和快速重定密钥方法。它提供"认证和灵活重协商"。

IKE = ISAKMP骨架 + Oakley机制 + SKEME认证方法，再加上一些实际部署的修正（如NAT-T、DPD）。

ISAKMP是重点：因为我们在配置IKE时，直接操作的就是ISAKMP定义的策略（如主模式/野蛮模式、IKE提议中的加密/哈希/DH组等），这些最终都会被编码成ISAKMP报文。Oakley和SKEME是底层贡献者，已融入IKE内部，我们不需要单独配置它们。

ISAKMP就像HTTP协议：HTTP规定了请求-响应的格式、方法（GET/POST）、状态码（200/404），但HTTP本身不关心你传输的是HTML还是JSON。ISAKMP也不关心你具体用什么加密算法或密钥交换算法，它只定义"怎么封装这些信息"

IKE配置 → ISAKMP"载荷"映射

在设备上敲下的每一行IKE配置，最终都会被打包成ISAKMP报文中的不同"载荷"，在网络中进行交换和协商。

1. IKE提议 → SA载荷（Security Association Payload）

包含内容 ：ike proposal里定义的加密算法、哈希算法、DH组、认证方式、SA存活时间等都会被放入SA载荷。

工作原理 ：发起方将本地所有IKE安全提议封装成SA载荷，发送给对端。对端接收到后，从载荷中解析出这些策略，并查找本地匹配的策略，将选中的结果通过SA载荷回复。你可以把它理解为"能力集宣告"：我支持这些算法，你选一个大家都能用的。

2. 密钥参数 → KE载荷 & Nonce载荷

KE载荷 (Key Exchange Payload)：用于交换Diffie-Hellman（DH）公开值。这是双方后续独立计算出相同共享密钥（SKEYID）的基础。

Nonce载荷 (随机数载荷)：用于传递一个伪随机数，用来防止重放攻击，并作为后续密钥衍生的一个参数。

可以把DH交换理解为"隔空握手生成共同秘密"，Nonce则是防止别人重放这个握手过程的"防伪水印"。

预共享密钥 → 认证载荷（如HASH Payload）

包含内容 ：pre-shared-key本身不会直接传输。在阶段1的最后两条消息中，双方会基于PSK以及之前交换的信息，计算出一个哈希值（HASH Payload）。

工作原理：这两个载荷使用之前协商好的算法和密钥进行加密和完整性保护。通过验证对方发来的哈希值，即可确认对方是否拥有相同的PSK，从而完成身份认证。

Peer地址与Cookie → UDP报文头 & ISAKMP头Cookie

IP地址 ：remote-address是协商的对端IP，会被填入UDP/IP头的目的IP字段。 '

】交换模式 ：exchange-mode会映射到ISAKMP头部的交换类型（Exchange Type）字段，告诉对端本次协商使用的是主模式还是野蛮模式。

Cookies ：IKE协商基于UDP，Cookies是ISAKMP头部的两个关键字段。发起方Cookie由发起者生成，响应方Cookie由响应者生成。

Cookie的作用是"防伪标识"，确保这不是别人伪造的协商请求。 它们共同唯一标识了一个IKE SA（IKE安全联盟），是处理大量并发协商时的关键标识。

为什么ISAKMP是排障核心？------ 抓包！抓包！

掌握了上述映射关系后，当隧道不通时，通过Wireshark抓取UDP 500端口（或NAT-T下的4500端口）的包，就可以精准定位问题。

IKE SA（第一阶段）主模式

IKE第一阶段（主模式）三步详解

IKE第一阶段的设计非常巧妙：前两步明明是明文传输，却能安全地产生只有双方知道的密钥；第三步用这个密钥加密传输身份，从而保证身份不泄露。

一、整体流程（主模式6个包，分3对）

步骤	包序号	传输内容	是否加密	作用
1. 参数协商	包1-2	加密算法、哈希算法、DH组、认证方式	❌ 明文	双方选定一套共同支持的算法
2. 密钥素材交换	包3-4	DH公开值（ga mod p）、Nonce（随机数）	❌ 明文	双方计算出相同的共享密钥（SKEYID）
3. 身份认证	包5-6	身份ID + HASH（认证数据）	✅ 加密	证明自己就是声称的身份，且完成认证

二、详细讲解每一步

步骤1：参数协商（包1-2）

发送内容（以发起方为例）：

一个或多个IKE提议：每个提议包含加密算法（如AES-256）、哈希算法（如SHA-256）、DH组（如Group 14）、认证方式（如预共享密钥PSK）、生命周期等。

为什么是明文？

因为此时双方还没有任何共享密钥，无法加密。但明文泄露这些信息没关系------攻击者知道了你们用的算法，但他没有密钥，仍然无法破解后续通信。

举例：

发起方说："我支持AES-128、AES-256，哈希用SHA-1或SHA-256，DH用Group2或Group14，认证用PSK。"

响应方回答："我选AES-256、SHA-256、Group14、PSK。"

安全性：攻击者知道你们选了AES-256，这本身不危险------就像你知道别人家用了"C级锁芯"，但没有钥匙还是打不开。

步骤2：密钥素材交换（包3-4）

发送内容：

KE载荷 ：Diffie-Hellman公开值（即 g^a mod p，其中a是发送方自己生成的私密随机数）。

Nonce载荷：一个随机数（用于防止重放攻击，并作为密钥派生的一部分）。

为什么是明文？

因为DH公开值的设计就是可以公开传输 的。即使攻击者截获了 g^a mod p 和 g^b mod p，他也无法计算出 g^{ab} mod p（这是离散对数难题，目前计算不可行）。

双方各自计算：

发起方知道自己的私有指数a，收到对方的g^b mod p，计算出 (g^b)^a = g^{ab} mod p。

响应方知道自己的私有指数b，收到对方的g^a mod p，计算出 (g^a)^b = g^{ab} mod p。

结果：双方得到了相同的共享秘密 SKEYID_BASE = g^{ab} mod p。

然后，双方用SKEYID_BASE加上Nonce、Cookie等，通过一个伪随机函数（PRF，即哈希）派生出三个密钥材料：

SKEYID_d：用于派生IPsec SA的密钥。

SKEYID_a：用于IKE阶段2（快速模式）消息的完整性认证。

SKEYID_e：用于加密IKE阶段2（快速模式）消息。

注意：此时SKEYID_e和SKEYID_a已经产生，但步骤2的包3-4本身还是明文。步骤3（包5-6）将使用SKEYID_e和SKEYID_a进行加密和认证。

安全性关键 ：攻击者抓到了g^a mod p和g^b mod p，但由于离散对数难题，他无法计算出g^{ab} mod p。即使他拿到这些数据，也无法得到SKEYID_e和SKEYID_a。

步骤3：身份认证（包5-6）

发送内容（加密的）：

ID载荷：身份信息（如IP地址、FQDN、User FQDN）。

HASH载荷 ：基于预共享密钥（PSK）或证书私钥计算出的哈希值。这个哈希值能够证明发送方拥有相同的PSK或正确的私钥。

加密方式 ：使用步骤2中派生出的SKEYID_e（加密密钥）对ID和HASH进行加密，使用SKEYID_a计算完整性校验（防止篡改）。

作用：

证明身份：对方解密后验证HASH，确认你拥有合法的PSK或证书。

防止中间人：因为PSK从未在线路上传输，攻击者无法伪造HASH（他没有PSK）。

攻击者能看到什么？

抓包看到的是乱码（密文），无法解密，因为解密需要SKEYID_e，而该密钥只有通信双方通过DH计算得到，攻击者无法算出。

关键：即使攻击者在步骤1和2中嗅探了所有明文，他仍然无法获得SKEYID_e，因此无法解密步骤3的身份信息，也无法伪造一个合法的HASH来冒充其中一方。

IKE第一阶段步骤3的必要性

IKE SA的配置

接下来里面有默认的配置

这是IKE的第一个包跟第二个包做的事情

查看ike proposal 的默认配置

bash 复制代码

dis ike proposal default

IPSec SA（第二阶段）快速模式

这个协商是为数据服务的，现在IPSec SA再去协商的时候就保密了，因为IKE SA已经协商好了算法跟秘钥了。

IPSec SA的必要性

一、第一阶段（IKE SA）做了什么？

结果：建立了一个安全的控制通道（IKE SA）。

产出的密钥 ：SKEYID_e（加密密钥）、SKEYID_a（认证密钥）、SKEYID_d（派生密钥）。

用途：只保护后续的IKE协商消息 （第二阶段快速模式的3个包），不保护任何业务数据。

二、第二阶段（IPsec SA）做了什么？

结果：建立了一个数据通道（IPsec SA，包含一对或多对单向SA）。

产出的密钥 ：从第一阶段的SKEYID_d派生出来，用于加密和认证真实的业务流量（如ping、HTTP、FTP等）。

用途：保护用户数据。

三、本质区别（对比表）

对比项	IKE SA（第一阶段）	IPsec SA（第二阶段）
角色	控制通道	数据通道
保护对象	IKE协商消息（阶段2快速模式）	真实的业务数据（用户流量）
方向性	双向（一个IKE SA即可双向通信）	单向（一个方向一个SA）
生命周期	较长（通常24小时）	较短（通常1小时）
密钥来源	DH + PSK/证书派生	从`SKEYID_d`派生
承载协议	UDP 500/4500	ESP（50）或 AH（51）
SPI长度	无（用Cookie标识）	32位（在ESP/AH头中）

四、为什么必须要有第二阶段？第一阶段不是已经协商好了吗？

误解：第一阶段已经算出了密钥，为什么不能直接用这些密钥加密业务数据？

答案：第一阶段算出的密钥（SKEYID_e、SKEYID_a）是专用于保护IKE消息的，不能直接用于业务数据，原因如下：

密钥用途分离：加密协商消息和加密业务数据需要不同的密钥，避免密码学攻击（密钥重用风险）。

生命周期不同：业务数据需要更频繁地更换密钥（如每小时一次），而控制通道可以保持更久（如24小时）。第二阶段可以独立重协商，不触动第一阶段。

方向性要求 ：业务数据需要单向SA（便于统计、防重放窗口独立），而IKE SA是双向的。

SPI管理：IPsec SA需要独立的SPI来在接收方快速查找解密参数，IKE SA使用Cookie。

灵活的多SA：一个IKE SA可以为多个不同的数据流生成多个IPsec SA（例如不同的子网对，或同时使用AH和ESP）。

为什么IPsec SA是单向的，而IKE SA是双向的？

一句话本质：IKE SA是"控制通道"，只需双向通信协商即可；IPsec SA是"数据通道"，加密/解密方向必须独立管理，才能防重放、单独统计。

IPSec SA的过程

IPsec SA建立的前提：IKE SA已建立

在第二阶段（快速模式）开始之前，第一阶段必须已经完成，即：

双方已通过主模式或野蛮模式协商出IKE SA。

IKE SA提供了SKEYID_e（加密密钥）、SKEYID_a（认证密钥）、SKEYID_d（派生密钥）。

所有第二阶段的消息都使用IKE SA进行加密和完整性保护（因此抓包看到的快速模式报文是密文）。

快速模式（Quick Mode）的三条消息交换

快速模式使用3个包，全部通过IKE SA进行加密和完整性保护（即所有载荷都加密，并带HMAC）。下图是基本流程：

HDR = ISAKMP报文头部（固定格式的元数据）

HDR = 设置了加密标志位的ISAKMP头部 + 后续所有载荷被加密*

bash 复制代码

发起方 (A)                                    响应方 (B)
    |                                               |
    | (1) HDR*, HASH(1), SA, Ni, [KE], [IDci, IDcr] |
    |---------------------------------------------->|
    |                                               |
    | (2) HDR*, HASH(2), SA, Nr, [KE], [IDci, IDcr] |
    |<----------------------------------------------|
    |                                               |
    | (3) HDR*, HASH(3)                             |
    |---------------------------------------------->|
    |                                               |

HDR*：IKE消息头（加密后的），包含SPI（即IKE SA的Cookie）。
HASH(1/2/3)：用于验证消息完整性和身份。
SA载荷：IPsec提议（加密算法、认证算法、封装模式、协议类型等）。
Ni, Nr：随机数（Nonce），用于生成密钥材料和防重放。
[KE]：可选，用于完美前向保密（PFS）。如果启用PFS，双方会再次交换DH公开值，生成新的密钥材料，保证即使第一阶段的私钥泄露，也不能破解本阶段生成的IPsec SA密钥。
[IDci, IDcr] ：可选，用于指定受保护的通信双方身份（即感兴趣流，如192.168.1.0/24到192.168.2.0/24）。通常此处传递的是IP地址范围或协议端口。

IPSec SA的配置

完整的配置

接口下调用

还有有去往172.16.1.0/24 网段的路由，出接口是1/0/1

利用之前的逻辑口建BGP邻居

（安全策略暂时全放）

测试

点开SA

第一、二个报文协商参数

第三、四个报文是发送秘钥素材 -- KE 、Nonce值

安全策略的放行

做实验的时候，右边全部放行，左边明细去放

复制代码

1、IKE报文： Local  ---> Untrust   （放行UDP500）

2、ICMP报文：Trust  ---> Untrust  

封装了VPN之后，就不走安全策略了，直接出去了

但是对方回来的ESP报文是需要放行的


3、回来的ESP：Untrust  --->  Local （Esp）