APP下载

IPSec VPN应用场景分析与实验仿真

2022-04-29李超凡马凯

关键词:数据包路由密钥

李超凡,马凯

(1.宿迁市第一人民医院 信息处,江苏 宿迁 223800;2.徐州医科大学 医学信息与工程学院,江苏 徐州 221004)

虚拟专用网络(Virtual Private Network,VPN)是指在运营商的公网资源上建立加密通讯的专用网络[1]。从专线连接发展至穿越公共网络,数据安全和带宽保障仍是主要的考虑因素。企业级的VPN解决方案主要分为:端对端(Site-to-Site)和远程接入(Easy VPN)[2],其中端对端VPN 主要依托的技术包括帧中继协议(Frame Relay)、多协议标签交换虚拟专网技术(Multi-Protocol Label Switching,MPLS)、互联网安全协议(Internet Protocol Security,IPSec);远程接入VPN 主要依托的技术包括点对点隧道协议(Point to Point Tunneling Protocol,PPTP)、第二层隧道协议(Layer 2 Tunneling Protocol,L2TP)、IPSec 协议族和安全套接字协议(Secure Sockets Layer,SSL)。

目前,基于运营商运维的跨域MPLS VPN和基于Web网页认证的SSL VPN是进行VPN接入的主要方式,但是对于企业级的网络运维方案,IPSec VPN 仍是解决站点到站点之间大规模流量通信的主要技术手段。因此,文章基于EVE-NG 虚拟仿真环境,探讨企业网Site-to-Site 架构建立VPN 通道的动态IP 地址、流量放行、地址转换和隧道技术的应用等多种网络拓扑结构。

1 相关技术

1.1 虚拟仿真环境

EVE-NG(Emulated Virtual Environment—Next Generation)是深度定制的Ubuntu 操作系统,融合了Dynamips,基于Linux的互联网操作系统(IOS on Linux,IOL),基于内核的虚拟机(Kernel-based Virtual Machine,KVM)[3],可以直接安装在带有CentOS7操作系统的服务器中,通过用户管理或者创建虚拟化接口的形式,实现B/S 结构的虚拟网络教学平台的仿真环境[4]。用户端使用http/https 访问EVE-NG 服务端地址,通过导入不同设备厂商的镜像文件,搭建各种类型的网络逻辑拓扑进行虚拟仿真实验。

1.2 IPSec框架

IPSec是一种开放标准的框架结构[5],由一组关联协议组成,为IP协议的分组提供加密和认证服务,从数据包传递的角度分为数据层面和控制层面。

1.2.1 数据层面

加密算法:对称加密算法应用同一个密钥进行数据包加解密,明文传输共享密钥,密钥数量指数增长[6]。非对称加密算法运行速度慢,密文较长。因此,IPSec VPN采用非对称密钥进行密钥交换和数字签名,采用对称密钥进行数据包加密,实现安全,速度快,加密后的密文紧凑,无连接服务,支持数字签名和不可否认性。

验证:应用散列函数进行完整性校验,常用散列函数包括MD5(Message Digest Algorithm MD5)和SHA-1(Secure Hash Algorithm 1),散列函数对数据包产生固定大小散列值,单向且避免冲突[7]。

封装协议:认证头(Authentication Header,AH)提供无连接完整性与防重放服务。封装安全载荷(Encapsulate Security Payload,ESP)除了具备AH的功能外,还提供数据源认证、数据加密和有限的传输流机密性。

传输模式:隧道模式(Tunnel Mode)用于通讯站点和加密站点不是同一台设备,需要保护的是多台站点的其中两个站点。传输模式(Transport Mode)用于通讯站点和加密站点是同一台设备,需要保护两个独立站点之间的通信[8]。

1.2.2 控制层面

网络密钥交换协议(Internet Key Exchange,IKE)是由安全关联和秘钥管理协议(ISAKMP)、密钥交换模式(OAKLEY)与共享和秘钥更新技术(SKEME)组成的混合协议[9]。安全关联(Security Association,SA)是对等体两端协商的信息保护策略和密钥,IKE 负责建立与维护IKE SAs 和IPSec SAs,对双方进行认证、交换非对称加密公钥、管理密钥资源与协商数据层面的策略参数。

2 端到端IPSec VPN实验设计与仿真

为探讨端对端IPSec VPN 建立过程中数据层面的流量转发与控制层面的策略协商,仿真实验的逻辑网络拓扑及相应地址规划如图1所示。

图1 IPSec VPN逻辑网络拓扑

在IKE 的协商过程中,存在主模式和快速模式的两种信息交互阶段,如图2 所示,(1)—(4)是明文传递的数据包,(5)—(9)是密文传递的数据包。IKE协商两套信息加密策略,其中主模式阶段通过验证对等体身份并确定会话密钥,快速模式在ISAKMP SA 的保护下,密文协商用于真正保护感兴趣数据流的IPSec SA。各数据包进行交互的作用如下:

图2 IKE协商过程

(1)—(2):用于准确的依据对等体IP地址进行策略提议与回应;

(3)—(4):交换非对称密钥的公钥和随机数,生成非对称密钥和对称密钥[10];

(5)—(6):利用公钥体制对预共享密钥进行加密,验证对等体身份;

(7)—(8):对实际的感兴趣数据流的加密策略的加密协商;

(9):信息确认并生成安全参数索引(Security Parameter Index,SPI)。

2.1 端到端IPSec VPN

依据图1 的拓扑结构,在EVE-NG 中搭建虚拟仿真实验,使用SecureCRT 客户端软件Telnet 设备节点的服务IP地址和端口进行网络配置。VPN Site经创建ISAKMP Policy、设置预共享密钥、转换集策略、抓取感兴趣流,在安全策略(Crypto Map)下匹配,最后在物理接口下调用,完成端到端的IPSec VPN 配置步骤。通过Wireshark网络封包分析软件抓取VPN Site接口的IKE的协商过程如图3所示。由图可知,No.11—19的数据包为IKE协商数据包,使用UDP协议封装,端口号500;No.21—22的数据包是IPSec VPN建立后的通信流量。打开No.11—14的数据包的ISAKMP封装,Payload承载数据包信息,No.15—19的数据包的ISAKMP封装中只存在加密数据的字节数。在No.22的加密数据包中,只存在由ESP封装的SPI和Sequence,SPI是目标对等体在IKE 协商期间随机选择的数字,类似于索引,用于在安全关联数据库(SADB)中查找对应的IPSec SA,Sequence是发送方插入ESP包头的序列号,提供抗重放服务。

图3 Wireshark抓取的IKE协商报文

IPSec VPN 的真实流量转发如图4 所示,其中ID 序号为1 是ISAKMP SA 的加密通道,用于以密文传递预共享密钥验证对等体身份,ID 序号为2001、2002 是IPSec SA 为感兴趣流创建的加密通道,用于真实流量转发,且在站点VPN Site1上,数据包的加解密个数一致,没有丢包现象。

图4 IP加密数据包转发情况

2.2 ISAKMP/IPSec Profile

在IPSec VPN 的建立过程中,多个站点在IKE 协商时,会出现自由组合匹配,导致网络混乱和误差的情况。ISAKMP可以创建多个Keyring并设置预共享密钥与多个ISAKMP Profile进行相应关联,并在Crypto Map中调用,从而映射ISAKMP参数到IPSec隧道,关联第一阶段与第二阶段的协商策略,普遍应用于一个站点和不同站点配置多个IPSec隧道,并且每个站点需要不同第一阶段策略的场合。

对于存在虚拟隧道接口的IPSec VPN架构,与传统端对端方式区别的是:IPSec Profile不再需要访问控制列表(Access-list)抓取感兴趣流和Crypto Map,因为Tunnel已经指明了隧道的源和目的地址,并且通过Tunnel传递的数据都需要进行加密。通过ISAKMP/IPSec Profile的匹配使用,可以有效地解决多站点间进行IKE协商的问题,增强IPSec VPN搭建的逻辑性。

2.3 动态地址的VPN解决方案

依据图1网络拓扑结构,清除VPN Site2的出接口地址,并设置动态主机配置协议(Dynamic Host Configuration Protocol,DHCP)请求,在ISP Cloud开启DHCP地址池,形成一端没有固定IP地址的网络场景。在此种场景下,Dynamic Map&Static Map是唯一的兼容方案,在VPN Site2的设置中,与普通的端对端配置没有任何区别。而在VPN Site1 中,可以用全零代替预共享密钥指定的对等体IP 地址,将转换集指定在Dynamic Map中,并套接在Static Map 中。此类IPSec VPN 架构由于固定IP 地址的站点无法获得对等体IP 地址,所以无法主动发起VPN 流量,必须由对等体获取DHCP 地址池中的IP 地址,然后主动触发VPN 的感兴趣流进行正常通信。

对于两端都没有固定IP地址的场景,可以利用动态域名解析技术(Dynamic Domain Name Server,DDNS)建立数据通道,同时也可以解决上述固定IP地址的站点无法主动发起VPN流量的缺点。

3 网络穿越实验设计与仿真

在逻辑网络拓扑中,VPN Site除了建立加密信息通道外,对于真实工程环境必须启动网络地址转换协议(Network Address Translation,NAT)使得私网地址可以转换为公网地址在运营商网络进行数据包传递。在此种场景下,逻辑网络拓扑结构仍以图1 为例,探讨IPSec VPN 穿越NAT、端口多路复用(Port Address Translation,PAT)及使用隧道技术建立动态路由协议的情况。

3.1 流量放行问题

当VPN Site 启用NAT 协议后,内部私有地址经NAT 映射为VPN Site 的出接口地址进行数据包传递,出现原有IPSec加密通道的目的地不可达现象。在端部存在NAT的情况下,IP数据包的转发遵循:传递方向先进行NAT 地址映射,再进行IP 数据包的加密;接收方向先解密IP 数据包,再进行地址转换。因此,在VPN Site进行通信时,私有地址经NAT地址转换不属于安全策略保护的感兴趣流,造成了数据包不可达。在此类场景下,禁止Access-list 应用在NAT 中的感兴趣流,不允许感兴趣流的私有地址在通信时进行地址转换,解决IPSec通道存在NAT引起的问题。

3.2 Crypto Map对流量的处理

依据上述IPSec 通道中存在NAT 情况下的IP 数据包转发机制,依据图1 逻辑拓扑,VPN Site 均存在内网服务器,设定VPN Site1内部服务器开启Telnet服务,VPN Site2内部服务器开启HTTP 服务,并限制服务器两端的访问,以此探讨在NAT存在的情况下,Crypto Map对访问流量的处理。

在此种场景下,数据加密站点与数据通信站点不是同一台设备,需要考虑的主要因素包含两点:IKE 协商的控制和IPSec通道的流量限制。IPSec通道的策略设置如图5所示,以VPN Site1为例,IKE协商的控制需要在数据加密点,即VPN Site1 外连接口的入方向,放行对等体UDP:500 的IPSec 控制报文和ESP 的IPSec 数据报文;IPSec 通道的流量限制需要在Crypto Map 的入方向,放行对端通信站点的Telnet 服务请求报文和HTTP 服务回复报文,在出方向放行对端通信站点的Telnet 服务回复报文和HTTP 服务请求报文。由图5 可知,扩展访问控制列表均得到有效的匹配,VPN Site内部服务器可以获取相应的Telnet服务和HTTP服务。

图5 IPSec通道的访问控制策略

3.3 NAT-T技术应用

在3.1章节流量放行问题中,已经探讨了对等体两端都启用NAT的情况,而在实际环境中也经常会出现PAT 应用的出口站点与VPN Site 不是同一站点的情况,所以在图1 的逻辑拓扑中,在ISP Cloud 与VPN Site2之间引入一台新的出口设备,VPN Site2作为私有网段的站点,IP 地址沿用192.168.1.0/24网段。在此类场景下,携带公网IP地址的VPN Site1需要与只有私有IP地址的VPN Site2建立IPSec VPN通道,VPN Site2的配置方式与3.1 章节所述一致,而VPN Site1 则需要指定对等体IP 地址为PAT 设备的出口地址。由此,VPN Site2可以遵循先进行PAT 地址转换,再进行IP 数据包加密,与VPN Site1 进行IKE 协商,这与VPN Site1 指定PAT设备为对等体是一致的,然后VPN Site1可以依据状态化的SPI查询本地SADB与VPN Site2进行通信。

在上述情况下,VPN Site1 无法主动对VPN Site2 发起VPN 流量,因为VPN Site1 指定的PAT 设备上没有公网地址与私有地址的转换表项,IKE 协商出现误差。NAT-T 技术(NAT-Traversal)通过在IP 包头和ESP 包头之间插入一个8字节的UDP头部(端口号:4500),从本质上解决ESP协议无法提供转换端口的缺陷[11]。由此,可以在PAT设备上进行IP地址与端口的静态映射,同时映射UDP协议的500和4500端口,以满足图2中IKE的协商过程(图6)。

图6 静态映射地址转换

在图2 的IKE 协商过程中,IPSec 网关在数据包(1)—(2)中交互Vendor ID 表示是否支持NAT-T,数据包(3)—(4)通过NAT-Discovery 负载计算源地址和端口号与目的地址和端口号的Hash 值,若Hash 值不相等,则IPSec通道存在NAT,然后IPSec网关在(5)—(9)数据包增加UDP包头(图7),完成IKE进行NAT穿越的协商过程,并在之后始终封装UDP:4500的包头进行加密通信。

图7 NAT-T技术的IKE协商过程

3.4 GRE/VTI隧道技术应用

在上述端对端IPSec VPN及网络穿越仿真实验中,对于大型企业网的实际网络部署,存在不支持直接加密组播、不支持动态路由协议、不提供服务质量(Quality of Service,QoS)等严重弊端。隧道技术的引入可以有效地解决这一问题,通用路由封装协议(General Routing Encapsulation,GRE)[12]和VTI 技术(Virtual Tunnel Interface)是常用与IPSec 框架组合的隧道类型。GRE 隧道通过在原始IP 数据包增加4 字节的GRE 头部,创建虚拟隧道接口与对端建立动态路由协议的邻居关系,传递私有网段的路由信息,IPSec 进行数据加密。VTI 是IPSec 内嵌的隧道技术,可分为静态的VTI(SVTI)和动态的VTI(DVTI),SVTI 主要用于端对端VPN 类型,DVTI主要用于远程接入VPN类型。

为探讨隧道技术在IPSec VPN 建立的应用情况,沿用3.3 章节的逻辑拓扑结构,SVTI 接口相对于传统的Crypto Map的优势在于可以在隧道口上运用动态路由协议,并且不需要额外的4个字节的GRE头部,降低了发送数据的带宽,所以仿真实验采用SVTI接口建立对等体的动态路由邻居关系和IPSec 加密通道。在VPN Site 启用开放式最短路径优先路由协议(Open Shortest Path First,OSPF),依据各自端部的内网划分路由区域,设置SVTI 的隧道地址为同一网段并宣告进OSPF 域内。应用SVTI 隧道建立的IPSec 加密通道的数据包转发情况如图8所示,加解密数据包的个数随着OSPF进行路由信息更新而不断增长。

图8 应用SVTI隧道的IP加密数据包转发

与GRE 隧道不同的是,SVTI 隧道只有在调用IPSec 加密策略才会启用并建立动态路由邻居关系,而GRE隧道可以随时建立。相较于3.3章节中,因为PAT中没有转换表项需要进行静态映射的情况,动态路由协议有效地解决了这个问题。综上所述,应用隧道技术建立IPSec VPN 在解决大型企业网进行加密通信的业务需求下具有很大的实用价值。

4 结论

EVE-NG 通过导入网络设备厂商的镜像文件,并架构在服务器中实现B/S模式的虚拟仿真环境,因其不占用客户端资源和支持多用户组的强大功能,适用于虚拟网络实践教学平台。文章依托于EVE-NG仿真环境,着重探讨了端对端IPSec VPN、IPSec通道搭建的高级特性、动态地址的VPN解决方案、IPSec网络穿越与隧道技术等多个应用场景,设定多类型VPN 通道建立的业务需求,并提供相应的解决方案。通过Wireshark 和SecureCRT等客户端软件,分析各类型VPN通道的建立过程和应用效果。仿真实验方案依据实际情况可直接移植到真实的网络环境,也为虚拟仿真平台提供了相应的实践案例,是计算机网络仿真实验的良好应用。

猜你喜欢

数据包路由密钥
二维隐蔽时间信道构建的研究*
幻中邂逅之金色密钥
民用飞机飞行模拟机数据包试飞任务优化结合方法研究
密码系统中密钥的状态与保护*
铁路数据网路由汇聚引发的路由迭代问题研究
多点双向路由重发布潜在问题研究
一种基于虚拟分扇的簇间多跳路由算法
路由重分发时需要考虑的问题
C#串口高效可靠的接收方案设计
TPM 2.0密钥迁移协议研究