IPSecVPN基础(1)3300字.docx

    IPSecVPN基础(1)3300字    IPSec VPN基本原理(1)IPSec VPN是目前VPN技术中点击率非常高的一种技术，同时提供VPN和信息加密两项技术，这一期专栏就来介绍一下IPSec VPN的原理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.23. 这个数据包发到互联网后，其命运注定是杯具的，为什么这么讲，就因为其目的地址是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个字母的排列组合，但其所涉及的协议功能众多、方案又极其灵活，本期主要介绍IPSec的基本原理，在后续专栏还会继续介绍IPSec的其它方面知识。

第二篇：通过 NAT 使用 IPSec 4500字与通过 NAT 使用 IPSec 相关的问题与通过 NAT 使用 IPSec 相关的问题如下：NAT 无法更新上层校验和 ?TCP 和 UDP 报头包含一个校验和，它整合了源和目标 IP 地址和端口号的值 当 NAT 改变了某个包的 IP 地址和（或）端口号时，它通常要更新 TCP 或 UDP 校验和 当 TCP 或 UDP 校验和使用了 ESP 来加密时，它就无法更新这个校验和 由于地址或端口已经被 NAT 更改，目的地的校验和检验就会失败 虽然 UDP 校验和是可选的，但是 TCP 校验和却是必需的NAT 无法多路传输 IPSec 数据流 ?ESP 保护的 IPSec 流量没有包含可见的 TCP 或 UDP 报头 ESP 报头位于 IP 报头和加密的 TCP 或 UDP 报头之间，并且使用 IP 协议号 50 因此，TCP 或 UDP 端口号就无法将流量多路传输到不同的专用网主机 ESP 报头包含一个名为 Security Parameters Index（安全参数索引，SPI）的字段 SPI 与明文（plaintext）IP报头中的目标 IP 地址和 IPSec 安全协议（ESP 或 AH）结合起来用于识别 IPSec 安全关联（SA）。

对于到 NAT 的传入流量，目标 IP 地址必须映射到一个专用 IP 地址 对于 NAT 专用端的多个 IPSec 对话方，多个 IPSec ESP 数据流的传入流量的目标 IP 地址是同一个地址 为了将一个 IPSec ESP 数据流与另一个区分开，目标 IP 地址和 SPI 必须得到跟踪并映射到某个专用目标 IP 地址和 SPI由于 SPI 是一个 32 位的数字，多个专用网客户端使用相同 SPI 值的概率很低 问题在于，您很难确定哪个传出 SPI 值对应于哪个传入 SPI 值NAT 无法映射 SPI，因为ESP尾部包含一个消息验证散列码（hashed message authentication code，HMAC），它检验 ESP 协议数据单元（PDU）的完整性（ESP PDU 包含 ESP 报头、ESP 有效载荷和 ESP 尾部），SPI 无法在 HMAC 值失效之前改变无法改变 IKE UDP 端口号 ?IPSec 的某些实现同时使用 UDP 端口 500 来作为源和目标 UDP 端口号 然而，对于一个位于 NAT 之后的 IPSec 对话方，NAT 会改变初始 IKE 主模式包的源地址。

根据具体的实现方式，来自 500 之外的其他端口的 IKE 流量可能会被丢弃IKE UDP 端口映射的 NAT 超时可能导致问题 ?NAT 中的 UDP 映射通常会很快被删除 发起者的 IKE 流量在 NAT 中创建了一个 UDP 端口映射，它在初始主模式和快速模式 IKE 协商期间使用 然而，如果响应者随后向发起者发送 IKE 消息却没有提供 UDP 端口映射，那么这些消息将被 NAT 丢弃Identification IKE 有效载荷包含嵌入的 IP 地址 ?对于主模式和快速模式协商，每个 IPSec 对话方发送一个 Identification IKE 有效载荷，其中包括发送对话方的嵌入 IP 地址 由于发送节点的源地址已经被 NAT 改变，该嵌入地址和 IKE 包中的 IP 地址不匹配 验证 Identification IKE 有效载荷的 IP 地址的 IPSec 对话方将丢弃该包，并放弃 IKE协商 返回页首对 IPSec 的 NAT-T 修改概述NAT-T 对 IPSec 的修改如下：ESP 的 UDP 封装 ?UDP 报头置于外层 IP 报头和 ESP 报头之间，用于封装 ESP PDU。

用于 UDP 封装的 ESP 流量的端口和用于 IKE 的端口相同修 改过的 IKE 报头格式IPSec。