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

李超凡，马凯

（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通道的建立过程和应用效果。仿真实验方案依据实际情况可直接移植到真实的网络环境，也为虚拟仿真平台提供了相应的实践案例，是计算机网络仿真实验的良好应用。