公海彩船·6600(中国游)官方网站

中文

登录

产品

< 返回主菜单

产品

解决公海彩船·6600官网

< 返回主菜单

解决公海彩船·6600官网中心

行业

服务支持

合作伙伴

关于公海彩船·6600

投资者关系

返回主菜单

选择区域/语言

首页
技术博文
互联网
站点间IPSec VPN网络技术深度解析

站点间IPSec VPN网络技术深度解析

【IPSec VPN】本文首先通过梳理IPSec VPN中各技术的用途及之间的关联关系帮助大家理解技术原理，其次为大家介绍IPSec VPN的一些高级功能，最后为大家分享典型实践场景和故障排查方法。

发布时间：2020-07-01
点击量：
点赞：

分享至

我想评论

本文作者：田思杨

公海彩船·6600网络技术服务部互联网服务中心

前言

在上一篇《VPN技术浅谈之如何部署远程办公网络》中，作者为大家分享了端到站点VPN技术，该技术主要使用在远程办公人员和企业网络互通场景，而站点到站点VPN技术常用于总部与分支之间的网络互通，通过利用组织已有的互联网出口，使用VPN技术虚拟出一条“专线”，将企业的分支机构和总部连接起来，组成一个大的局域网。站点到站点VPN主要包括IPSec VPN、L2TP VPN、L2TP over IPSec VPN、GRE VPN、GRE over IPSec VPN、SSL VPN等。IPSec VPN技术因其具有安全性高、成本低、部署灵活、扩展性好等优点，已成为企业站点间VPN部署的第一技术选择。

IPSec VPN不是一个单独的协议，而是由一组协议组成，因其包含的技术多、技术间关联关系多，很多朋友无法把IPSec VPN技术理解透。本文首先通过梳理IPSec VPN中各技术的用途及之间的关联关系帮助大家理解技术原理，其次为大家介绍IPSec VPN的一些高级功能，最后为大家分享典型实践场景和故障排查方法。希望本文能够帮助各位读者把IPSec VPN技术学透、用明白，耐心读完这篇文章相信你会有不一样的收获。

公海彩船·6600支持IPSec VPN的设备有很多种，不同设备对各IPSec VPN技术的支持情况略有差异，本文以公海彩船·6600网关设备为例给大家讲解，如读者使用其他设备欢迎联系公海彩船·6600工程师或到公海彩船·6600官网查询，感谢。

图1：常见企业VPN接入拓扑模型

IPSec VPN基础参数

IPSec中通信双方建立的连接叫做安全关联（IPSec SA），双方通过参数协商完成IPSec SA建立后，通过IPSec SA传输加密的数据报文进行通信。所以两个对等体间要想通过IPSec VPN通信，首先要建立IPSec SA。在进行IPSec SA建立时对等体间要进行IPSec SA参数协商，两端参数相同时才会建立成功。

图2：IPSec VPN基础参数

IPSec SA生成方式

手动指定生成IPSec SA

对等体通过手动指定IPSec SA协商参数生成IPSec SA，IPSec SA建立后没有生存周期限制，永不过期，除非手工删除，因此存在安全隐患。一般推荐在对等体数量较少且无法通过IKE协商建立IPSec SA场景下使用。

IKE协商生成IPSec SA

IKE用于动态建立并实时维护IPSec SA。IKE通过两个阶段来建立IPSec SA，第一阶段首先要协商建立IKE SA，第二阶段通过IKE SA协商建立IPSec SA。

IKE协商生成IPSec SA比手动指定生成IPSec SA存在以下优势：

适用场景丰富：手动指定方式必须对等体两端都有固定的公网IP地址，如一端对等体公网IP地址不固定必须使用IKE协商方式；
降低配置复杂度：手动指定方式需要手动配置SPI、密钥等信息，在对等体较多的场景配置量较大而不便于维护，IKE协商方式会通过IKE SA来生成和维护这些信息，降低配置复杂度及维护成本；
提高安全性：手动指定方式建立的IPSec SA密钥是静态的，建立后永不过期，IKE协商方式会通过IKE SA生成密钥，并且生命周期到期后进行老化重新生成，提高了安全性。

小提示：IKE协议目前有两个版本IKEv1与IKEv2，IKEv1目前较为常用，IKEv2与IKEv1配置思路相同，但协商过程与IKEv1有所区别，本文不进行讲解，本文中出现的IKE协议均代表IKEv1。

IKE SA协商模式

在IKE第一阶段有两种协商模式可协商建立IKE SA，主模式或者野蛮模式。主模式使用6个报文完成IKE SA建立，而野蛮模式使用3个报文完成IKE SA建立，与主模式相比野蛮模式减少交互报文数量从而加快了协商速度，但因对身份信息和认证信息采用明文交互，没有加密保护，因此不安全，作者不推荐使用。

野蛮模式早期设计主要为解决一端对等体公网IP地址不固定或没有公网IP地址的场景下主模式无法协商建立的问题，目前该问题可以通过“动态隧道”的方法更好地解决，所以推荐使用主模式。野蛮模式仅在公海彩船·6600设备与非公海彩船·6600设备建立IPSec使用主模式无法建立成功下使用，其他场景下不推荐使用。

小提示：主模式和野蛮模式报文交互详细流程参考本文《IKE报文交互知识点回顾》小节。

IKE SA加密方式

IKE SA使用对称加密算法对数据进行加密和解密，保证数据的安全性。常用的对称加密算法有DES、3DES、AES等，这三个加密算法的安全性由高到低依次是：AES、3DES、DES，安全性高的加密算法实现机制复杂，运算速度慢。

图3：IKE SA常用的对称加密算法

IKE SA验证方式

IKE SA使用验证算法对报文完整性及来源合法性进行验证，常用的验证方式有MD5-HMAC、SHA1-HMAC等，是HASH算法和HMAC两种技术的结合。

HASH算法实现对报文进行完整性校验，常见的HASH算法有MD5、SHA1等，MD5算法的计算速度比SHA1算法快，而SHA1算法的安全强度比MD5算法高。

图4：IKE SA常用的HASH算法

HMAC(Hash-based Message Authentication Code)是一种基于HASH算法和密钥进行消息认证的方法，实现对报文来源的合法性进行验证，可以与任何HASH算法捆绑使用。

IKE SA密钥生成方式

DH（Diffie-Hellman）是一种非对称密钥算法，双方可通过仅交换一些数据，即可计算出双方的密钥，并且第三方捕获了其中的数据也无法计算得出密钥。DH产生的密钥用于数据报文加密及HMAC计算中。对等体两端DH组长度需指定为相同，常用的DH组长度有768bit（DH1）、1024bit（DH2）、1536bit（DH5）。

IKE SA认证方式

在IKE对等体之间在进行身份认证时支持通过预共享密钥认证和数字证书认证两种方式来确认对方身份的合法性。预共享密钥认证配置比较简单，是目前比较常用的认证方式。数字证书认证相对复杂但安全性较高，对安全性有较高要求的场景建议使用数字证书认证。

IKE SA身份标识

在IKE SA协商中对等体双方需要使用相同类型的身份标识，常用的身份标识类型有4种，IP地址、FQDN、USER-FQDN、证书DN。数字证书认证通常采用证书DN作为本地身份标识。预共享密钥认证默认采用IP地址作为本地身份标识，通常使用采用IP地址作为本地身份标识即可，若遇到以下两种场景推荐手动修改使用FQDN或USER-FQDN：

如果对等体的IP地址为域名形式，则必须使用FQDN或USER-FQDN；
对等体较多的场景下，建议采用FQDN或USER-FQDN，便于区分每个对等体对应是哪个分支。

小提示：身份标识类型与协商模式无关，任何身份标识在主模式或野蛮模式下均可使用，比如主模式使用FQDN作为身份标识或野蛮模式使用IP作为身份标识都可正常完成IKE SA协商，只要对等体两端使用相同类型身份标识即可。

IKE SA生命周期

由于IPSec SA协商是建立在IKE SA基础上的，因此为节省协商IPSec SA的时间，一般IKE SA生命周期（60秒到86400秒，缺省86400秒）比IPSec SA生命周期设置的长。当在进行IKE SA协商时，两端对等体设置的IKE SA生命周期不同不会造成IKE SA协商失败，而使用发送方设置的IKE SA生命周期。

IPSec SA安全协议

AH和ESP是IPSec的两种安全协议，用于实现IPSec在身份认证和数据加密的安全机制。

AH协议（Authentication Header，协议号51），主要提供数据完整性确认、数据来源确认、防重放等安全特性。AH通常使用MD5-HMAC、SHA-HMAC等验证算法实现数据完整性；
ESP协议（Encapsulating Security Payload，协议号50），主要提供数据完整性确认、数据加密、数据来源确认、防重放等安全特性。ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5-HMAC、SHA-HMAC等验证算法实现数据完整性。ESP协议相比AH协议多了支持数据加密、支持NAT穿越（NAT-T）这两大优势，是目前IPSec VPN较为常用的安全协议。

IPSec SA封装模式

封装模式用于指定安全协议的封装位置，有传输模式和隧道模式两种：

传输（Transport）模式下，AH头或ESP头插入IP头和传输层协议之间，不改变原始报文头，IPSec隧道的源和目的地址就是最终通信双方的源和目的地址，所以只能保护两个IPSec对等体之间相互通信。一般常用在使用GRE over IPSec或L2TP over IPSec协议的场景中，使用IPSec隧道保护GRE或L2TP对等体；

隧道（Tunnel）模式下，AH头或ESP头插在原始IP头之前，并且新生成一个IP头放在ESP头或AH头之前，所以可以保护两个IPSec对等体背后两个网络之间进行通信。一般常用在站点间网络互通的场景，是较常用的封装模式。

图5：AH协议两种封装模式下报文封装

图6：ESP协议两种封装模式下报文封装

IPSec SA加密方式

IPSec SA支持使用的加密方式与IKE SA相同，参考本文《IKE SA加密方式》小节。

IPSec SA验证方式

IPSec SA支持使用的验证方式与IKE SA相同，参考本文《IKE SA验证方式》小节。

IPSec SA生命周期

为了确保安全，IPSec SA将在经过一定时间（0或者120秒到86400秒，缺省3600秒）或达到一定通信量（0或2560KB到536870912KB，缺省4608000KB）之后超时，重新协商，并使用新的密钥。新IPSec SA在生命周期超时前30秒，或经由这条隧道的数据通信量距生命周期还有256KB时开始进行协商（根据哪个先发生）。

当在进行IPSec SA协商时，两端对等体设置的IPSec SA生命周期不同不会造成IPSec SA协商失败，而使用发起方设置的IPSec SA生命周期。

IPSec VPN高级功能

图7：IPSec VPN高级功能

IPSec隧道自动建立（Set Autoup）

在默认情况下IPSec VPN配置完后，IPSec隧道是由数据流量触发后再协商建立的。配置IPSec隧道自动建立（Set Autoup）功能后，不管是否有数据流量触发，只要完成IPSec VPN配置后，设备会自行触发IPSec隧道建立。

IPSec链路探测（DPD/Track）

DPD探测

在默认情况下两端设备建立IPSec隧道后，当一端设备出现问题后另一端是无感知的，另一端设备会继续通过IPSec隧道发送数据给故障设备导致数据通信中断。此时需要等待IPSec隧道超时后故障IPSec隧道才会中断（IPSec隧道默认超时时间为一小时）。

DPD探测是通过发送IKE报文确认对端设备IKE SA状态是否正常的一种探测机制，当探测到对端IKE状态异常时，会清除对应的IKE SA和IPSec SA。

DPD探测有两种工作模式：

按需探测模式（On-demand），在超过配置的探测时间且当有数据报文发送时，设备会发送DPD消息探测对端设备是否正常，当发送5次DPD信息都没有收到对端设备回包会认为对端IKE SA状态异常；
周期探测模式（Periodic），设备会根据配置的探测时间周期性主动发送 DPD 消息探测对端设备是否正常，当发送5次DPD信息都没有收到对端设备回包会认为对端IKE SA状态异常。

综上按需探测模式比周期探测模式会发送更少的DPD信息只在数据报文发送前检测，节约设备资源及网络带宽资源，但探测到对端设备故障的时间会比周期探测模式长，读者根据自身业务需求使用合适模式进行DPD探测即可。

Track探测

DPD探测通过交互IKE报文可以探测到对端设备IKE SA状态是否正常，对于IKE SA状态正常而IPSec SA异常的情况DPD探测就无能为力了，这种情况同样会导致IPSec业务中断。Track探测通过定期发送ICMP或UDP报文探测IPSec实际业务是否正常，当Track探测到IPSec业务不通时会清除对应的IPSec SA进行重新协商。一般建议同时配置DPD探测和Track探测。

NAT穿越（NAT-T）

设备默认开启NAT穿越（NAT-T）功能，用于解决当建立IPSec VPN的两台设备间存在NAT设备ESP报文无法通过的问题。ESP报头封装在IP层之上IP协议号50所以无法通过NAT设备, NAT-T通过在ESP报文之上封装4500端口的UDP报头解决该问题。

图8：NAT-T在ESP报文之上封装4500端口的UDP报头

在IKE协商的第一阶段（主模式第1、2个报文、野蛮模式第1个报文）支持NAT-T的设备在发送IKE报文中会携带一个检测NAT-T能力的Vendor ID的载荷，当两端设备都携带这个字段就会进行NAT-T协商。当检测双方都支持NAT-T随后（主模式第3、4个报文、野蛮模式第2个报文）会携带一个NAT-D的载荷，NAT-D载荷中包含自己IP地址和端口的HASH值，对端设备收到这个值后会与收到的实际IP地址和端口的Hash值做对比，如果相同说明中间未经过NAT设备，否则说明中间经过NAT设备。如果NAT-T检测到中间经过NAT设备，设备会在下一个报文（主模式第5、6报文、野蛮模式第3个报文）开始插入一个4500端口的UDP报头，至此NAT-T工作结束。

动态隧道（Crypto Dynamic-map）

一般情况下，两端设备都有公网IP地址，配置时两端使用静态隧道的方式相互指定对端公网IP地址进行IPSec隧道建立。实际中也会遇到一端有公网IP地址而另一端没有固定公网IP地址或者没有公网IP地址的情况，这种情况两端都使用静态隧道的方式就无法建立IPSec隧道。使用动态隧道配置时无需指定对端IP地址、身份、感兴趣流等，有公网IP地址的一端使用动态隧道可解决另一端没有固定公网IP地址或者没有公网IP地址的问题。此外，如果本端需要建立大量IPSec VPN的对等体也可以使动态隧道，减少配置量。

反向路由注入（RRI）

在完成IPSec配置后我们要配置去往对端网段的静态路由，如果感兴趣流网段较多人为手动配置及维护这些路由有些不便。开启反向路由注入功能，当IPSec隧道建立完成后会自动产生相应的静态路由（目的地址是对端感兴趣流地址，下一跳是对端公网IP地址）注入到路由表中，当IPSec隧道断开后对应的路由也会消失。反向路由会结合IPSec隧道的建立信息自动生成对端网段路由，这样便能动态地完成路由的添加与删除，避免大量人为配置。此外，在设备存在多出口场景，还可以通过反向路由注入进行多出口上IPSec隧道的切换。

使用动态路由协议（GRE over IPSec/L2TP over IPSec）

在IPSec网络中只能通过静态路由配置到对端网段的路由，IPSec对等体之间无法使用动态路由协议进行路由学习，反向路由注入可以一定程度上解决感兴趣流网段较多、静态路由维护成本高的问题，如果希望使用动态路由协议进一步降低路由维护成本，可以使用GRE over IPSec VPN或者L2TP over IPSec VPN，使用GRE或者L2TP建立VPN隧道，然后再使用IPSec隧道保护这个VPN隧道，此时既保证了数据安全又可在VPN隧道两端使用动态路由协议。

IPSec VPN典型场景

单总部单分支场景

场景Ⅰ

图9：IPSec VPN典型场景Ⅰ配置表

场景Ⅱ

图10：IPSec VPN典型场景Ⅱ配置表

场景Ⅲ

图11：IPSec VPN典型场景Ⅲ配置表

场景Ⅳ

图12：IPSec VPN典型场景Ⅳ配置表

场景Ⅴ

图13：IPSec VPN典型场景Ⅴ配置表

场景Ⅵ

图14：IPSec VPN典型场景Ⅵ配置表

多总部多分支场景

场景Ⅶ

图15：IPSec VPN典型场景Ⅶ配置图

场景Ⅷ

图16：IPSec VPN典型场景Ⅷ配置表

在多总部多分支场景下，除以上两种单出口情况外，多出口的情况也较为常见。部署时将以上两种多总部多分支场景与单总部单分支场景下多出口的情况结合使用即可，本章不在赘述。

IPSec VPN故障排查

IPSec VPN使用时难免会遇到隧道建立失败的情况。一般IPSec VPN故障可分为三类：IKE SA建立失败；IPSec SA建立失败；IPSec SA建立成功但数据不通。在遇到IPSec VPN故障时读者可查看发起方和接收方状态并对比如下IPSec对等体状态解析图确认属于哪类故障，然后根据每类故障常见原因进行排查。

图17：查看IPSec对等体状态

18：IPSec对等体状态解析

IKE报文交互知识点回顾

在分析每类故障常见发生原因前，作者首先带大家回顾下IKE报文交互情况，只有知道了每个报文在交互什么内容，在遇到IPSec建立停留在某一阶段时，我们才知道排查的方向。IKE通过两个阶段来建立IPSec SA，第一阶段采用主模式或者野蛮模式建立IKE SA，第二阶段采用快速模式建立IPSec SA。

IKE第一阶段（主模式）：

第1-2个报文携带IKE策略，进行IKE策略协商，IKE策略包含：加密算法、HASH算法、DH组、验证方式、IKE SA生命周期，
第3-4个报文携带DH算法需要的材料，进行DH算法计算生成密钥，
第5-6个报文携带身份信息及认证信息，进行对等体间的认证，完成IKE SA建立。需要注意的是从第5个报文开始有两处变化，第一点是报文开始被加密保护，第二点是如果存在NAT穿越的情况UDP端口号将从500变为4500

图19：主模式报文交互流程及对等体状态

IKE第一阶段（野蛮模式）：

第1个报文发送方发送IKE策略、DH算法需要的材料、身份信息，IKE策略包含：加密算法、HASH算法、DH组、验证方式、IKE SA生命周期；
第2个报文接收方回应匹配的IKE策略，发送DH算法需要的材料、身份信息、认证信息；
第3个报文发送方发送认证信息完成认证，完成IKE SA建立。如果存在NAT穿越的情况从该报文开始UDP端口号从500变为4500。

图20：野蛮模式报文交互流程及对等体状态

IKE第二阶段：

第1个报文发送方发送IPSec转换集、感兴趣流，进行IPSec参数协商，IPSec转换集包含：封装模式、安全协议、加密算法、HASH算法、IPSec SA生命周期。另外如果开启PFS还会携带DH算法需要的材料，进行DH算法计算生成新的密钥；
第2个报文接收方回应匹配的IPSec策略、感兴趣流及DH算法需要的材料(如果开启PFS)；
第3个报文发送方进行结果确认，双方完成IPSec SA建立。

小提示：PFS（Perfect Forward Secrecy）是一种安全机制，默认情况下IPSec SA会直接使用IKE SA通过DH算法生成的密钥，开启PFS机制后，IPSec SA在协商时会在额外进行一次DH密钥交换算法，使IPSec SA使用的密钥与IKE SA使用的密钥不同，提高安全性。

IKE SA建立失败故障原因分析

图21：IKE第一阶段IKE SA建立失败原因

IPSec SA建立失败故障原因分析

图22：IKE第二阶段IPSec SA建立失败原因

IPSec SA建立成功但数据不通故障原因分析

图23：IPSec SA建立成功但数据不通原因

写在最后

本文结合理论与实践对IPSec VPN技术的基础参数、高级功能、典型实践场景及故障排查方法进行了深入解析。除了IPSec VPN技术外L2TP over IPSec VPN、GRE over IPSec VPN等VPN技术也在一些企业站点间使用，读者可结合本文思路自行进行研究。

相关推荐：

VPN技术浅谈之如何部署远程办公网络
企业办公网接入认证技术详解
居安思危，主动革新 ——浅析园区办公网络的建设

相关标签：

点赞

<< IT小张：618别人剁手我剁“框”！

IT小张：一台交换机和“隐秘的角落”不得不说的关系 >>

客户评论

暂无评论

我要评论

您的姓名

您的手机号*

您的邮箱

公司名称

您的评论*

我已仔细阅读并同意隐私声明

验证码*

提交评论

更多技术博文

任何需要，请联系我们

与售前顾问交谈

填写项目需求表单

售前咨询
售后服务
意见反馈

返回顶部

收起

文档AI助手

文档评价

该资料是否解决了您的问题？

您对当前页面的满意度如何？

不咋滴

非常好

您满意的原因是（多�。�？

您对文档是否还有其它的问题或建议？

为尽快解决问题，请您留下联系方式以便回复

邮箱

手机号

感谢您的反�。�

请选择服务项目

售前咨询

售后服务

意见反馈

更多联系方式

【网站地图】【sitemap】