内容纲要

IPSec VPN 是目前 VPN 技术中应用比较高的一种技术,同时提供 VPN 和信息加密两项技术。

IPSec VPN 协议简介

IPSec(IP Security) 协议族是 IETF 制定的一系列协议,它为 IP 数据报提供了高质量的、可互操作的、基于密码学的安全性。

特定的通信方之间在 IP 层通过加密与数据源验证等方式,来保证数据报在网络上传输时的私有性、完整性、真实性和防重放。具体介绍如下:
私有性 (Confidentiality)
指对用户数据进行加密保护,用密文的形式传送。

完整性 (Data integrity)
指对接收的数据进行验证,以判定报文是否被篡改。

真实性 (Data authentication)
指验证数据源,以保证数据来自真实的发送者。

防重放 (Anti-replay)
指防止恶意用户通过重复发送捕获到的数据包所进行的攻击,即接收方会拒绝旧的或重复的数据包。

IPSec 通过 AH(Authentication Header) 和 ESP(Encapsulating Security Payload) 两个安全协议实现了上述目标。为简化 IPSec 的使用和管理,IPSec 还可以通过 IKE(Internet Key Exchange) 进行自动协商交换密钥、建立和维护安全联盟的服务。具体介绍如下:

AH 协议
AH 是报文头验证协议,主要提供的功能有数据源验证、数据完整性校验和防报文重放功能。然而,AH 并不加密所保护的数据报。

ESP 协议
ESP 是封装安全载荷协议。它除提供 AH 协议的所有功能外 (但其数据完整性校验不包括 IP 报文头),还可提供对 IP 报文的加密功能。

AH 和 ESP 可以单独使用,也可以同时使用。对于 AH 和 ESP,都有两种封装模式:传输模式和隧道模式。详细介绍请参见 “IPSec 协议的封装模式”。

IKE 协议
IKE 协议用于自动协商 AH 和 ESP 所使用的密码算法,并将算法所需的必备密钥放到恰当位置。

IKE 协商并不是必须的,IPSec 所使用的策略和算法等也可以手工方式进行协商。关于两种协商方式的比较,请参见 “IKE 的协商模式”。

IKEv2 协议
IKEv2 协议作为 IKE 协议的继任者,在延续 IKE 基本功能的同时,简化了协议的复杂性,提高了协议效率和加强了协议扩展性。

IPSec VPN 的应用场景分为 3 种:
1.Site-to-Site(站点到站点或者网关到网关):如弯曲评论的 3 个机构分布在互联网的 3 个不同的地方,各使用一个商务领航网关相互建立 VPN 隧道,企业内网 (若干 PC) 之间的数据通过这些网关建立的 IPSec 隧道实现安全互联。

2.End-to-End(端到端或者 PC 到 PC): 两个 PC 之间的通信由两个 PC 之间的 IPSec 会话保护,而不是网关。

3.End-to-Site(端到站点或者 PC 到网关):两个 PC 之间的通信由网关和异地 PC 之间的 IPSec 进行保护。

VPN 只是 IPSec 的一种应用方式,IPSec 其实是 IP Security 的简称,它的目的是为 IP 提供高安全性特性,VPN 则是在实现这种安全特性的方式下产生的解决方案。IPSec 是一个框架性架构,具体由两类协议组成:

1.AH 协议 (Authentication Header,使用较少):可以同时提供数据完整性确认、数据来源确认、防重放等安全特性;AH 常用摘要算法 (单向 Hash 函数)MD5 和 SHA1 实现该特性。

2.ESP 协议 (Encapsulated Security Payload,使用较广):可以同时提供数据完整性确认、数据加密、防重放等安全特性;ESP 通常使用 DES、3DES、AES 等加密算法实现数据加密,使用 MD5 或 SHA1 来实现数据完整性。

为何 AH 使用较少呢?因为 AH 无法提供数据加密,所有数据在传输时以明文传输,而 ESP 提供数据加密;其次 AH 因为提供数据来源确认 (源 IP 地址一旦改变,AH 校验失败),所以无法穿越 NAT。当然,IPSec 在极端的情况下可以同时使用 AH 和 ESP 实现最完整的安全特性,但是此种方案极其少见。

IPSec 封装模式

介绍完 IPSec VPN 的场景和 IPSec 协议组成,再来看一下 IPSec 提供的两种封装模式 (传输 Transport 模式和隧道 Tunnel 模式)

上图是传输模式的封装结构,再来对比一下隧道模式:

可以发现传输模式和隧道模式的区别:

1. 传输模式在 AH、ESP 处理前后 IP 头部保持不变,主要用于 End-to-End 的应用场景。

2. 隧道模式则在 AH、ESP 处理之后再封装了一个外网 IP 头,主要用于 Site-to-Site 的应用场景。

从上图我们还可以验证上一节所介绍 AH 和 ESP 的差别。下图是对传输模式、隧道模式适用于何种场景的说明

从这张图的对比可以看出:
1. 隧道模式可以适用于任何场景

2. 传输模式只能适合 PC 到 PC 的场景

隧道模式虽然可以适用于任何场景,但是隧道模式需要多一层 IP 头 (通常为 20 字节长度) 开销,所以在 PC 到 PC 的场景,建议还是使用传输模式。

为了使大家有个更直观的了解,我们看看下图,分析一下为何在 Site-to-Site 场景中只能使用隧道模式:

如上图所示,如果发起方内网 PC 发往响应方内网 PC 的流量满足网关的兴趣流匹配条件,发起方使用传输模式进行封装:

1.IPSec 会话建立在发起方、响应方两个网关之间。

2. 由于使用传输模式,所以 IP 头部并不会有任何变化,IP 源地址是 192.168.1.2,目的地址是 10.1.1.2。

3. 这个数据包发到互联网后,其命运注定是杯具的,为什么这么讲,就因为其目的地址是 10.1.1.2 吗?这并不是根源,根源在于互联网并不会维护企业网络的路由,所以丢弃的可能性很大。

4. 即使数据包没有在互联网中丢弃,并且幸运地抵达了响应方网关,那么我们指望响应方网关进行解密工作吗?凭什么,的确没什么好的凭据,数据包的目的地址是内网 PC 的 10.1.1.2,所以直接转发了事。

5. 最杯具的是响应方内网 PC 收到数据包了,因为没有参与 IPSec 会话的协商会议,没有对应的 SA,这个数据包无法解密,而被丢弃。

我们利用这个反证法,巧妙地解释了在 Site-to-Site 情况下不能使用传输模式的原因。并且提出了使用传输模式的充要条件:兴趣流必须完全在发起方、响应方 IP 地址范围内的流量。比如在图中,发起方 IP 地址为 6.24.1.2,响应方 IP 地址为 2.17.1.2,那么兴趣流可以是源 6.24.1.2/32、目的是 2.17.1.2/32,协议可以是任意的,倘若数据包的源、目的 IP 地址稍有不同,对不起,请使用隧道模式。

IPSec 协商

IPSec 除了一些协议原理外,我们更关注的是协议中涉及到方案制定的内容:

1. 兴趣流:IPSec 是需要消耗资源的保护措施,并非所有流量都需要 IPSec 进行处理,而需要 IPSec 进行保护的流量就称为兴趣流,最后协商出来的兴趣流是由发起方和响应方所指定兴趣流的交集,如发起方指定兴趣流为 192.168.1.0/24à10.0.0.0/8,而响应方的兴趣流为 10.0.0.0/8à192.168.0.0/16,那么其交集是 192.168.1.0/24?à10.0.0.0/8,这就是最后会被 IPSec 所保护的兴趣流。

2. 发起方:Initiator,IPSec 会话协商的触发方,IPSec 会话通常是由指定兴趣流触发协商,触发的过程通常是将数据包中的源、目的地址、协议以及源、目的端口号与提前指定的 IPSec 兴趣流匹配模板如 ACL 进行匹配,如果匹配成功则属于指定兴趣流。指定兴趣流只是用于触发协商,至于是否会被 IPSec 保护要看是否匹配协商兴趣流,但是在通常实施方案过程中,通常会设计成发起方指定兴趣流属于协商兴趣流。

3. 响应方:Responder,IPSec 会话协商的接收方,响应方是被动协商,响应方可以指定兴趣流,也可以不指定 (完全由发起方指定)。

4. 发起方和响应方协商的内容主要包括:双方身份的确认和密钥种子刷新周期、AH/ESP 的组合方式及各自使用的算法,还包括兴趣流、封装模式等。

5.SA:发起方、响应方协商的结果就是曝光率很高的 SA,SA 通常是包括密钥及密钥生存期、算法、封装模式、发起方、响应方地址、兴趣流等内容。

我们以最常见的 IPSec 隧道模式为例,解释一下 IPSec 的协商过程:

上图描述了由兴趣流触发的 IPSec 协商流程,原生 IPSec 并无身份确认等协商过程,在方案上存在诸多缺陷,如无法支持发起方地址动态变化情况下的身份确认、密钥动态更新等。伴随 IPSec 出现的 IKE(Internet Key Exchange) 协议专门用来弥补这些不足:

1. 发起方定义的兴趣流是源 192.168.1.0/24 目的 10.0.0.0/8,所以在接口发送发起方内网 PC 发给响应方内网 PC 的数据包,能够得以匹配。

2. 满足兴趣流条件,在转发接口上检查 SA 不存在、过期或不可用,都会进行协商,否则使用当前 SA 对数据包进行处理。

3. 协商的过程通常分为两个阶段,第一阶段是为第二阶段服务,第二阶段是真正的为兴趣流服务的 SA,两个阶段协商的侧重有所不同,第一阶段主要确认双方身份的正确性,第二阶段则是为兴趣流创建一个指定的安全套件,其最显著的结果就是第二阶段中的兴趣流在会话中是密文。

IPSec 中安全性还体现在第二阶段 SA 永远是单向的:

从上图可以发现,在协商第二阶段 SA 时,SA 是分方向性的,发起方到响应方所用 SA 和响应放到发起方 SA 是单独协商的,这样做的好处在于即使某个方向的 SA 被破解并不会波及到另一个方向的 SA。这种设计类似于双向车道设计。

IPSec 虽然只是 5 个字母的排列组合,但其所涉及的协议功能众多、方案又极其灵活。

发表评论

电子邮件地址不会被公开。 必填项已用*标注