技术文章

网络协议 — IPSec 安全隧道协议族

范桂飓

An editor at Blogzine

2023-05-26
6天前
2716
41 Views
100

IPSec 安全隧道协议族

IPSec（Internet Protocol Security，互联网协议安全）是一个基于 IP 网络的安全隧道协议族，包含了一系列认证、加密、隧道封装协议。

IPSec 通过以下 4 个方面的考量来实现安全通信：

机密性（Confidentiality）：发送方对数据进行加密，以密文的形式在 IP 网络上传送，接收方对接收的加密数据进行解密后处理或直接转发。
完整性（Integrity）：接收方对接收的数据进行校验，以判定报文是否被篡改。
身份认证（Data Authentication）：接收方验证发送方身份是否合法。
防重放（Anti-Replay）：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。

IPSec 协议族主要由以下协议组成：

安全认证协议（Authentication Header，AH）
安全封装协议（Encapsulating Security Payload，ESP）
安全偶联协议（Security Association，SA）
安全密钥交换协议（Internet Key Exchange，IKE）

这些协议公共构建了 IPSec 的安全框架：

加密算法：
- 对称加密算法：AES、DES、3DES 等。
- 非对称加密算法：RSA、DH（Diffie-Hellman，交换及密钥分发）等。
验证算法：MD5、SHA-1、SHA-2 等 HASH 算法。
封装协议：ESP、AH 等协议。
封装模式：
- 传输模式（Transport）：不改变 IP Header。
- 隧道模式（Tunnel）：生成新的 IP Header。

在这里插入图片描述

封装协议

IPSec 具有 2 种封装协议，根据各自的特性被应用到不同的场景中。

在这里插入图片描述

Authentication Header

安全认证协议（Authentication Header，AH）本质是一种封装协议，对 IP 协议进行封装，会试图保护 IP 数据包的所有字段（包括：IP Header 和 Playload）。

AH 的 Header 封装格式如下图所示：

下一个头：标识被传送数据所属的协议。
载荷长度：认证头包的大小。
保留：为将来的应用保留，目前都置为 0。
安全参数索引：与 IP 地址一同用来标识安全参数。
串行号：单调递增的数值，用来防止重放攻击。
认证数据：包含了认证当前包所必须的数据。

在这里插入图片描述

Encapsulating Security Payload

安全封装协议（Encapsulating Security Payload，ESP）也是一种封装协议，与 AH 不同的是，ESP 会将 IP 数据包中的 Payload 进行加密后再封装到 IP 数据包，以保证数据的机密性，但 ESP 没有专门对 IP Header 的内容进行保护。

ESP 的 Header 封装格式如下图所示：ESP 处了在每一个 IP Header 后面添加一个 ESP Header 之外，还会在 IP 数据包末尾追加一个 ESP 尾部（包括：ESP Tail 和 ESP Auth data）。

安全参数索引：与 IP 地址一同用来标识安全参数。
串行号：单调递增的数值，用来防止重放攻击。
载荷数据：实际要传输的数据。
填充：某些块加密算法用此将数据填充至块的长度。
填充长度：以位为单位的填充数据的长度。
下一个头：标识被传送数据所属的协议。
认证数据：包含了认证当前包所必须的数据。

在这里插入图片描述

封装模式

IPSec 也提供了 2 种不同的封装模式，可以根据不同的应用场景进行选择：

安全性角度：Tunnel 优于 Transport。Tunnel 可以完全地对原始 IP 数据包进行验证和加密，所以 Tunnel 可以隐藏内部 IP 地址、协议类型和端口等信息。
性能角度：Tunnel 低于 Transport。因为 Tunnel 有一个额外的 IP 头，所以它会比 Transport 占用更多带宽。

在这里插入图片描述

传输模式

传输模式（Transport）：不改变 IP Header。

在这里插入图片描述

隧道模式

隧道模式（Tunnel）：生成新的 IP Header。

在这里插入图片描述

安全偶联协商

Security Association

IPSec 隧道需要在两端建立 Security Association（安全偶联），通过 SA 协议的交互流程来提供并保存两端约定好的加密协议、对称秘钥、对端 IP 地址等信息，这些信息是 AH 或 ESP 封装协议所需要使用到的参数。

SA 建立成功之后，就可以对原始的 IP 数据包进行安全传输了（认证和加密）。其中，对称秘钥要通过 IKE 协议来进行互换，然后通过在原始网络包外层添加 AH 或 ESP Header 来实现加密。

SA 由一个三元组来唯一标识，包括：

SPI（Security Parameter Index，安全参数索引）
目的 IP 地址
安全协议号（AH 或 ESP）

SA 中的 SPI 是用于唯一标识一个 SA 的 32bits 数值，它在 AH 或 ESP Header 中传输。

手工（Manual）配置 SA 时，需要手工指定 SPI 的取值；
使用 IKE 自动协商（ISAKMP）SA 时，SPI 将随机生成。

另外，手工方式建立的 SA 永不老化，而通过 IKE 协商建立的 SA 具有生存周期，IKE 协商建立的 SA 的生存周期有两种定义方式：

基于时间的生存周期，定义了一个 SA 从建立到失效的时间；
基于流量的生存周期，定义了一个 SA 允许处理的最大流量。

生存周期到达指定的时间或指定的流量，SA 就会失效。SA 失效前，IKE 将为 IPsec 协商建立新的 SA。这样，在旧的 SA 失效前新的 SA 就已经准备好。

在新的 SA 开始协商而没有协商好之前，继续使用旧的 SA 保护通信。
在新的 SA 协商好之后，则立即采用新的 SA 保护通信。

在这里插入图片描述

Internet Key Exchange

安全密钥交换协议（Internet Key Exchange，IKE）建立在由 ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）定义的框架之上，用于安全的完成密钥交换，并提供了身份认证、分发密钥、自动建立 SA 等功能。

在 IPSec 场景中，IKE 为 IPSec 提供了自动协商交换密钥、建立 SA 的服务，能够减少了密钥协商的开销。通过 IKE 建立和维护 SA 的服务，还可以简化了 IPSec 的使用和管理，包括：

因为有了 IKE，IPsec 很多参数（e.g. 密钥）都可以自动建立，降低了手工配置的复杂度。
IKE 协议中的 DH 交换过程，每次的计算和产生的结果都是不相关的。每次 SA 的建立都运行 DH 交换过程，保证了每个 SA 所使用的密钥互不相关。
IPSec 使用 AH 或 ESP 报文头中的序列号实现防重放。此序列号是一个 32bits 的值，此数溢出后，为实现防重放，SA 需要重新建立，这个过程需要 IKE 协议的配合。
对安全通信的各方身份的认证和管理，将影响到 IPSec 的部署。IPSec 的大规模使用，必须有 CA（Certificate Authority，认证中心）或其他集中管理身份数据的机构的参与。
IKE 提供端与端之间动态认证。

IKE 的交换过程

值得注意的是，IKE 不是简单的在网络上传输密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥，并且即使第三者截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。

IKE 使用了两个阶段为 IPsec 进行密钥协商并建立 SA：

通信各方彼此间建立了一个已通过身份认证和安全保护的通道，即：建立一个 ISAKMP SA。第一阶段有主模式（Main Mode）和野蛮模式（Aggressive Mode）两种 IKE 交换方法。
用在第一阶段建立的安全隧道为 IPSec 协商安全服务，即：为 IPsec 协商具体的 SA，建立用于最终的 IP 数据安全传输的 IPsec SA。

在这里插入图片描述

第一阶段主模式的 IKE 协商过程中包含三对消息：

第一对叫 SA 交换，是协商确认有关安全策略的过程；
第二对消息叫密钥交换，交换 Diffie-Hellman 公共值和辅助数据（如：随机数），密钥材料在这个阶段产生；
最后一对消息是 ID 信息和认证数据交换，进行身份认证和对整个第一阶段交换内容的认证。

野蛮模式交换与主模式交换的主要差别在于，野蛮模式不提供身份保护，只交换 3 条消息。在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度；在对身份保护要求较高的场合，则应该使用主模式。

IPSec NAT-Tranversal

IPSec 与 NAT 之间的冲突

IPSec 和 NAT 具有一定的冲突，包括：

AH 传输模式和隧道模式都不支持 NAPT。
ESP 传输模式都不支持 NAPT。
ESP 隧道模式只支持一对一的 NAT，不支持 PAT。

在这里插入图片描述

Transport 模式的冲突：

AH 封装协议的数据完整性校验（Authenticate）范围为整个 IP 报文，NAT 会修改 IP Header 的 Address，所以就会导致接收方 Authenticate 失败。而 PAT 会修改 TCP Header 的 Port，也会导致 Authenticate 失败。
ESP 封装协议的 Authenticate 范围为 ESP Header 和 ESP Tail（尾部）之间。因为 ESP 不校验 IP Header 所以 NAT 行为并不会导致接收方的 Authenticate 失败，但由于 NAT 修改了 IP Header 中的 Address，理论上后面的 TCP checksum 也会随之修改，而 TCP checksum 已经属于 ESP 校验范围之内了，NAT 设备无法进行修改，所以接收端在 TCP 层接收时会导致 checksum 校验失败。

在这里插入图片描述

Tunnel 模式的冲突：

AH 协议的 Tunnel 模式的 Authenticate 范围会包含外层的 New IP Header，因此 NAT 同样会造成接收方 Authenticate 失败。
ESP 协议的 Tunnel 模式经过 NAT 设备后，内层 IP Header 并不会被改变，所以 TCP checksum 也不会改变，接收方也就不会再出现 checksum 失败了。但也存在着缺点：它只能支持一对一的 NAT，即：NAT 设备后面只有一台内网主机。如果考虑 PAT 来补充的话，又回因为 TCP Header 已经被加密而无法实现。

在这里插入图片描述

NAT-T 的封装模式

为了解决上述问题的技术就是 NAT-T，IPSec 的 NAT-T 解决方案是 ESP-UDP-Encapsulate（封装），即：在 ESP Header 前加上一个 New UDP Header，源和目的端口号均是 4500，使得 NAT 设备按照处理一个普通的 UDP 数据包的方式对它处理。这个方法同时适用于 ESP-Transport 和 ESP-Tunnel 模式，以及同时支持 PAT 和 NAT。

UDP-Encapsulated-Transport 模式
UDP-Encapsulated-Tunnel 模式

示例：NAT 设备后有两台内网主机，它们都与 Server 建立 IPSec 连接。

在这里插入图片描述

NAT-T 的协商过程

在这里插入图片描述

IPSec 两端需要在 IKE 完成协商后才能使用 NAT-T。

阶段一：

探测出双方都支持 NAT-T。
探测出双方报文传输路径上存在 NAT 设备。
前 4 个 Msg 都是使用 Sport=Dport=500 进行通信。但当探测到 NAT 设备后，作为 Initiator 再发出第 5 个 Msg 就会将端口切换到 Sport=Dport=4500，Responder 收到该消息后，如果解密成功，后续也会使用新的 4500 端口。注意，RFC3948 规定了 New UDP Header 中的端口要使用和 IKE 协商时相同的端口号，这个端口号在 RFC3947 中规定为 4500。

阶段二：

双方协商 NAT-T 的封装模式，UDP-Encapsulated-Tunnel 还是 UDP-Encapsulated-Transport。
其中，UDP-Encapsulated-Transport 模式还会向对方发送自己的原始 IP 地址，让对方可以据此修正后续 TCP 报文的 checksum。要知道，经过 NAT 设备之后，报文的 IP 地址发生了变化，就会导致接收端校验失败。IPsec 采用的方法是在 IKE 协商时，就将自己原始 IP 地址信息发给对端，这样 Server 在解密出 TCP 报文后，可以根据这个信息修正 checksum。

IPSec Virtual Tunnel Interface

IPSec Virtual Tunnel Interface（VTI，虚拟隧道接口）在操作系统中针对 IPSec Tunnel 模式用于作为一个 Endpoint，同时结合了 IPSec 和 IP Routing 的功能。

本质上 IPSec VTI 是一个三层逻辑接口，它支持动态路由协议，所有路由到 IPSec VTI 的 IP 数据包都将进行 IPSec 保护，同时也可以支持对组播流量的保护。

使用 IPSec VTI l来建立 IPSec 安全连接具有以下优点：

简化配置：通过 Routes 来确定对哪些 IP 数据包需要进行 IPSec 保护。与通过 ACL 指定 IP 数据流范围的方式相比，这种方式简化了用户在部署 IPSec 安全策略时配置上的复杂性，使得 IPSec 的配置不会受到网络规划的影响，增强了网络规划的可扩展性，降低了网络维护成本。
减少开销：在保护远程接入用户流量的组网应用中，在 IPSec VTI 处进行报文封装，与 IPSec over GRE 或者 IPSec over L2TP 方式的隧道封装相比，无需额外为入隧道流量加封装 GRE Header 或者 L2TP Header，减少了报文封装的层次，节省了带宽。
业务应用更灵活：IPsec VTI 在实施过程中明确地区分出 “加密前” 和 “加密后” 两个阶段，用户可以根据不同的组网需求灵活选择其它业务（例如：NAT、QoS）实施的阶段。例如：如果用户希望对 IPSec 封装前的报文应用 QoS，则可以在 IPSec VTI 上应用 QoS 策略；如果希望对 IPSec 封装后的报文应用 QoS，则可以在 Physical Interface 上应用 QoS 策略。

IPSec VTI 的工作原理

发包封装流程：IPSec VTI 对 IP 数据包的封装/解封装发生在 Logical Interface 上。用户流量到达实施 IPSec 配置的设备后，需要 IPSec 处理的报文会被转发到 IPSec VTI 上进行加封装/解封装。IPSec VTI 对 IP 数据包进行加封装的过程如下：

Router 将从入接口接收到的 IP 明文送到转发模块进行处理；
转发模块依据路由查询结果，将 IP 明文发送到 IPSec VTI 进行加封装：原始 IP 报文被封装在一个新的 IP 报文中，新 IP 头中的源地址和目的地址分别为隧道接口的源地址和目的地址。
IPSec VTI 完成对 IP 明文的加封装处理后，将 IP 密文送到转发模块进行处理；
转发模块进行第二次路由查询后，将 IP 密文通过隧道接口的实际物理接口转发出去。

在这里插入图片描述

收包解封装流程：IPSec VTI 对报文进行解封装的过程如下：

Router 将从入接口接收到的 IP 密文送到转发模块进行处理；
转发模块识别到此 IP 密文的目的地为本设备的隧道接口地址且 IP 协议号为 AH 或 ESP 时，会将 IP 密文送到相应的 IPSec VTI 进行解封装：将 IP 密文的外层 IP 头去掉，对内层 IP 报文进行解密处理。
IPSec VTI 完成对 IP 密文的解封装处理之后，将 IP 明文重新送回转发模块处理；
转发模块进行第二次路由查询后，将 IP 明文从隧道的实际物理接口转发出去。

在这里插入图片描述

从上面描述的加封装/解封装过程可见，IPSec VTI 将报文的 IPSec 处理过程区分为两个阶段：“加密前” 和 “加密后”。

需要应用到加密前的明文上的业务（例如：NAT、QoS），可以应用到隧道接口上；
需要应用到加密后的密文上的业务，则可以应用到隧道接口对应的物理接口上。

Linux iptables 与 VTI 的结合

最初往 Linux Kernel 增加 VTI 功能的作者提到：

Virtual tunnel interface is a way to represent policy based IPsec tunnels as virtual interfaces in linux. This is similar to Cisco’s VTI (virtual tunnel interface) and Juniper’s representaion of secure tunnel (st.xx). The advantage of representing an IPsec tunnel as an interface is that it is possible to plug Ipsec tunnels into the routing protocol infrastructure of a router. Therefore it becomes possible to influence the packet path by toggling the link state of the tunnel or based on routing metrics.

这表明了 VTI 在 Linux 中是一种虚拟网络设备。在 Linux 的实现中该设备主要作用是将经过这个设备的网络流量打上标签，IPSec 的策略根据这个标签和相关信息来判断流量该怎么转发。

在 Linux 中，经常使用 iptables 来为各类网络应用打标签，例如：通过 iptables 打标签给 tc 来控制流量，通过 iptables 打标签来给 iproute 来控制路由等做法。所以，通常也可以通过 iptables 给网络流量打上标签，继而实现让其数据包被 IPSec 转发的效果的。

IPSec Virtual Private Network

IPSec 隧道常被作为 Virtual Private Network，有以下应用场景：

Site-to-Site（站点到站点，或者网关到网关）：如企业的多个机构分布在互联网的多个不同的地方，各使用一个应用层网关相互建立 VPN 隧道，企业各分机构内网的用户之间的数据通过这些网关建立的 IPSec 隧道实现安全互联。
End-to-End（端到端，或者 PC 到 PC）：两个位于不同网络的 PC 之间的通信由两个 PC 之间的 IPSec 会话保护，而不是由网关之间的 IPSec 会话保护。这种 IPSec VPN 是通过一些 IPSec VPN 客户端软件，如：Windows、Linux 桌面操作系统中自带的 IPSec VPN 客户功能，Huawei VPN Client 等客户端软件，结合 Window 或 Linux 服务器系统中自带的 IPSec VPN 服务器功能来实现的。
End-to-Site（端到站点，或者 PC 到网关）：两个位于不同网络的 PC 之间的通信由网关和异地 PC 之间的 IPSec 进行保护。在IPSec VPN 客户端方面同样可利用 Windows、Linux 桌面操作系统中自带的 IPSec VPN 客户功能，通常是采用 L2TP over IPSec 方案来部署，即在 L2TP VPN 基础上采用 IPSec 来提供更好的安全保护。

在这里插入图片描述