IPSec-VPN中隧道模式和传输模式区别

IPSecVPN基本原理IPSecVPN是目前VPN技术中点击率非常高的一种技术，同时提供VPN和信息加密两项技术，这一期专栏就来介绍一下IPSecVPN的原理。IPSecVPN应用场景IPSecVPN应用需求出差房工IPSecVPN的应用场景分为3种：Site-to-Site（站点到站点或者网关到网关）：如弯曲评论的3个机构分布在互联网的3个不同的地方，各使用一个商务领航网关相互建立VPN隧道，企业内网（若干PC）之间的数据通过这些网关建立的IPSec隧道实现安全互联。End-to-End（端到端或者PC到PC）：两个PC之间的通信由两个PC之间的IPSec会话保护，而不是网关。End-to-Site（端到站点或者PC到网关）：两个PC之间的通信由网关和异地PC之间的IPSec进行保护。VPN只是IPSec的一种应用方式，IPSec其实是IPSecurity的简称，它的目的是为IP提供高安全性特性，VPN则是在实现这种安全特性的方式下产生的解决方案。IPSec是一个框架性架构，具体由两类协议组成：AH协议（AuthenticationHeader，使用较少）：可以同时提供数据完整性确认、数据来源确认、防重放等安全特性；AH常用摘要算法（单向Hash函数）乂口5和SHA1实现该特性。ESP协议（EncapsulatedSecurityPayload，使用较广）：可以同时提供数据完整性确认、数据加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5或SHA1来实现数据完整性。为何AH使用较少呢？因为AH无法提供数据加密，所有数据在传输时以明文传输，而ESP

提供数据加密；其次AH因为提供数据来源确认（源IP地址一旦改变，AH校验失败），所以无法穿越NAT。当然，IPSec在极端的情况下可以同时使用AH和ESP实现最完整的安全特性，但是此种方案极其少见。IPSec封装模式介绍完IPSecVPN的场景和IPSec协议组成，再来看一下IPSec提供的两种封装模式（传输Transport模式和隧道Tunnel模式）IPSec的两种应用方式一传输模式田头源、目的地址【P田头源、目的地址【P数据

TCP/UDP/1CMPMDS/SHA工摘婆算法IP头

源、目的地址AH认证头摘要IP数据TCP/UDP/ICMP _ EncapsulatedSecurity

Payload

安金封装舞荷IP头

源.目的地址IP数捱TCP/UDP/1CMP源.目的地址IP头

源、目的地址AH认证头摘要IP数据TCP/UDP/ICMP _ EncapsulatedSecurity

Payload

安金封装舞荷IP头

源.目的地址IP数捱TCP/UDP/1CMP源.目的地址头IP头ESP1P数据

加密后密文埴充E5P摘要VDES/1DES/AES加密/MD5/SHA1摘要舞法IP加密后葭文上图是传输模式的封装结构，再来对比一下隧道模式:IPSec的两种应用方式——隧道模式外网IP头外网IP头海，目的地址IE内网IP头源、目的地址||源、目的地址1P病TCP/UDP/1CMP」MD5/占HR1摘要尊注AH认证良外网IP头外网IP头海，目的地址IE内网IP头源、目的地址||源、目的地址1P病TCP/UDP/1CMP」MD5/占HR1摘要尊注AH认证良摘要内网1P头

源.目的地址AuthenticationHeader，

验证头军一IP数据TCP/UDP/ICMP1…,—//fncapsubtedSecurity

Payload

安叁封装转荷内网IP头源.目的地址IP数框TCP/UDP/ICMPDE5/1DES/AES加密,MD5/SHA1摘要算法外网IP头源,目的地址ESP头IP数据 加密后密文填充ESP摘要|Ps«-WkipMd,the.jDocunwcs-FWe即睁c«efD5e.«ip-QpenO..openQfflt^.mgn可以发现传输模式和隧道模式的区别：传输模式在AH、ESP处理前后IP头部保持不变，主要用于End-to-End的应用场景。隧道模式则在AH、ESP处理之后再封装了一个外网IP头，主要用于Site-to-Site的应用场景。从上图我们还可以验证上一节所介绍AH和ESP的差别。下图是对传输模式、隧道模式适用于何种场景的说明。

IPSec膻道模式和传输模式的适用场蹙PC与PC之间IPSec保护PC之间流量可使用传输模式,也可使用隧道模式PC与网关之间IPSec保护PC之间流H只靛使用屣道模式_从这张图的对比可以看出：隧道模式可以适用于任何场景传输模式只能适合PC到PC的场景隧道模式虽然可以适用于任何场景，但是隧道模式需要多一层IP头（通常为20字节长度）开销，所以在PC到PC的场景，建议还是使用传输模式。为了使大家有个更直观的了解，我们看看下图，分析一下为何在Site-to-Site场景中只能使用隧道模式：Internet企业内嘱应方2.17.1.26.24.1.2192.168.1.2【监改会话源192.168.L2目的1<U.L2四配兴趣麻对兴趣就进行加密使用瞳道模式，问题迎刃而解；可以使用传输模式的充要条怦:Internet企业内嘱应方2.17.1.26.24.1.2192.168.1.2【监改会话源192.168.L2目的1<U.L2四配兴趣麻对兴趣就进行加密使用瞳道模式，问题迎刃而解；可以使用传输模式的充要条怦:我黑潦疟｛发起方、畤成方LP地址】如兴趣浦为府议:IP/GRE/TCP/UDP源:6.24.1.2/32目的：2.17.1.2/32朦192.168.1.2目的10.1.1.2L0XU.'源.目的地址都“

是私有地址,因

为私网路由问/题,该数据包在入互联网中植强肆..源192J68.L2目的101.1.2设数据包成功穿越了

互联网，因为目的地址,-是不是嘀应方网关217A.2，所以酹放育并不进行解密,而是直接转发给内网PC /响应方内网PC因为没有进行IPS8协商,所以密文数据无法解密而被PC丢弃如上图所示，如果发起方内网PC发往响应方内网PC的流量满足网关的兴趣流匹配条件，发起方使用传输模式进行封装：IPSec会话建立在发起方、响应方两个网关之间。由于使用传输模式，所以IP头部并不会有任何变化，IP源地址是192.168.1.2,目的地址是10.1.1.2。这个数据包发到互联网后，其命运注定是杯具的，为什么这么讲，就因为其目的地址是10.1.1.2吗？这并不是根源，根源在于互联网并不会维护企业网络的路由，所以丢弃的可能性很大。即使数据包没有在互联网中丢弃，并且幸运地抵达了响应方网关，那么我们指望响应方网关进行解密工作吗？凭什么，的确没什么好的凭据，数据包的目的地址是内网PC的10.1.1.2,所以直接转发了事。最杯具的是响应方内网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方案聚焦发起方响应方确定IPSec会话所使用,•身份确认方式密朗协商方式及刷新周期-Ips《保护的流丽而汽槿流-Ips《保护的流丽而汽槿流I -- 「一^— :AH/ESP使用算法兴趣流传轮模式/隧道模式'IPSec会话发t喘点都为发起方f IPSecSiS'IPSec会话发t喘点都为发起方[IPSec会话响应端融应五发起方、响血所协商出所使用密钥、言法、兴趣流等内容称为发起方安全联盟(SecurityAssociationSA)IPSec除了一些协议原理外，我们更关注的是协议中涉及到方案制定的内容：兴趣流：IPSec是需要消耗资源的保护措施，并非所有流量都需要IPSec进行处理，而需要IPSec进行保护的流量就称为兴趣流，最后协商出来的兴趣流是由发起方和响应方所指定兴趣流的交集，如发起方指定兴趣流为192.168.1.0/24沅0.0.0.0/8，而响应方的兴趣流为10.0.0.0/8已192.168.0.0/16，那么其交集是192.168.1.0/24BA10.0.0.0/8，这就是最后会被IPSec所保护的兴趣流。发起方：Initiator，IPSec会话协商的触发方，IPSec会话通常是由指定兴趣流触发协商，触发的过程通常是将数据包中的源、目的地址、协议以及源、目的端口号与提前指定的IPSec兴趣流匹配模板如ACL进行匹配，如果匹配成功则属于指定兴趣流。指定兴趣流只是用于触发协商，至于是否会被IPSec保护要看是否匹配协商兴趣流，但是在通常实施方案过程中，通常会设计成发起方指定兴趣流属于协商兴趣流。响应方：Responder，IPSec会话协商的接收方，响应方是被动协商，响应方可以指定兴趣流，也可以不指定(完全由发起方指定)。发起方和响应方协商的内容主要包括：双方身份的确认和密钥种子刷新周期、AH/ESP的组合方式及各自使用的算法，还包括兴趣流、封装模式等。SA：发起方、响应方协商的结果就是曝光率很高的SA，SA通常是包括密钥及密钥生存期、算法、封装模式、发起方、响应方地址、兴趣流等内容。我们以最常见的IPSec隧道模式为例，解释一下IPSec的协商过程：发起方Internet企业内网企业内网IPSec隧道模式2响应方2.17.1.2192168.L2源192,168.1.2目的10LL2■=四配兴趣流源192.1S8.1.0/24目的10.0.0.0/8如果该联趣流对成SA发起方Internet企业内网企业内网IPSec隧道模式2响应方2.17.1.2192168.L2源192,168.1.2目的10LL2■=四配兴趣流源192.1S8.1.0/24目的10.0.0.0/8如果该联趣流对成SA已曼存在则无需1KE由商一阶段SA二二二=二二——►兴趣范明文协斶，5A协商条件；■SA不存在IKE一的段安全会话/随道？.磐去多乌学维认♦EA过期■SA不可用，人为原因由赫西对兴趣流进行加密IKE讲标二阶段SA二二〉〈二IKE二阶段安全会话।HHPSm会话/隧道 二二一——A1KE梅商报文——A兴趣潦密文解密对解密后流・进行兴趣流检查源192,168.1.2目的10.1L2上图描述了由兴趣流触发的IPSec协商流程，原生IPSec并无身份确认等协商过程，在方案上存在诸多缺陷，如无法支持发起方地址动态变化情况下的身份确认、密钥动态更新等。伴随IPSec出现的IKE(InternetKeyExchange)协议专门用来弥补这些不足：发起方定义的兴趣流是源192.168.1.0/24目的10.0.0.0/8,所以在接口发送发起方内网PC发给响应方内网PC的数据包，能够得以匹配。满足兴趣流条件，在转发接口上检查SA不存在、过期或不可用，都会进行协商，否则使用当前SA对数据包进行处理。协商的过程通常分为两个阶段，第一阶段是为第二阶段服务，第二阶段是真正的为兴趣流服务的SA，两个阶段协商的侧重有所不同，第一阶段主要确认双方身份的正确性，第二阶段则是为兴趣流创建一个指定的安全套件，其最显著的结果就是第二阶段中的兴趣流在会话中是密文。IPSec中安全性还体现在第二阶段SA永远是单向的：IPSec瞳道模式交企业闯发内网PC192.168.L2响应方发起方Internetf.内网PC10.1.1.2发掘方二、 ；陶应万6.24.1.2 2.17.1.2企业内IV源192.168,1.2IPSec瞳道模式交企业闯发内网PC192.168.L2响应方发起方Internetf.内网PC10.1.1.2发掘方二、 ；陶应万6.24.1.2 2.17.1.2企业内IV源192.168,1.2目的1。1口IKE1办商二附股SA-左靛方一〉响应无二>U二使用单向隧道设计实现更好的安全性解密兴理流检查源10X1.2邨派J巡H兴趣淹进行加密源10A.1.2目的192.16&1.2