vpn解决方案

当前位置:当前位置:主页 > 解决方案 > vpn解决方案 > vpn解决方案

VPN解决方案

作者:admin 日期:2014-04-02 17:50 来源:未知

 
大数据
云计算
VPN解决方案
 
1 引言
  目前随着我国网络技术的迅速推广和网络的迅速发展壮大,网络安全问题日益成为人们关心的话题,尤其是我国正在迅速发展中的企业,企业扩大的同时给企业的网络安全带来很大的问题,再加上目前我国网络安全人员严重不足及水平的参差不齐,VPN技术实施方案框架及部署战略问题日益显得重要,对商用vpn可行性研究和对各种VPN的实际部署情况的可行性报告及vpn现场解决方案实施能力是目前一个网络安全人员必不可少的素质之一。
2 VPN技术简介
VPN——虚拟专用网( virtual private network) 是专用网络在公共网络如Internet上的扩展。VPN通过私有 隧道技术在公共网络上仿真一条点到点的专线从而达到安全的数据传输目的。如果要仿真一条专线,为保证传输数据的安全通常还要对数据进行加密处理。在局域网之间进行信息传输时,VPN网关的加密功能能够保证信息在不安全的网络上传输时采用密文形式。这样,即使信息被截取,它的内容也无法被偷窥和篡改.保证通过互联网连接的各个局域网间的信息传输是安全的、机密的。
3 VPN体系架构
广泛的讲,VPN体系机构可以被分成三种常见的情况:站点到站点的VPN、远程访问VPN以及外联网VPN。
3.1 站点到站点的VPN
在这种情况下,同一个机构内部的多个网络站点位于不同的地理位置,这些站点使用VPN连接。每个站点都有多个IP子网,他们形成一个企业的内部互联网络。
3.2 远程访问VPN
在这种情况下,VPN被用来连接一个单的远程网络设备和企业的内联网。这哥单一的网络设备可能是通过电话网访问网络的便携式家算计,或者是通过电缆调制解调器、DSL、以及其它一些连接方式访问网络的远程通信计算机
3.3 外联网VPN
在这种情况下,在某个企业内部的网络资源对于来自其他公司的不同目的的访问时开放的,比如商业事务。这种访问是不同于内联网的。
4 VPN的关键技术
目前VPN主要采用四项技术来保证安全,这四项技术分别是隧道技术(Tunneling)、加解密技术(Encryption & Decryption)、密钥管理技术(Key Management)、使用者与设备身份认证技术(Authentication)。
4.1 隧道技术
VPN是在公网中形成企业专用的链路,为了形成这样的链路,采用了所谓的“隧道”技术。隧道技术是VPN的基本技术,它是分组封装(Capsule)的技术,可以模仿点对点连接技术,依靠Internet服务提供商(ISP)和其他的网络服务提供商(NSP)在公用网中建立自己专用的“隧道”,让数据包通过这条隧道传输。
隧道是一种利用公网设施,在一个网络之上的“网络”传输数据的方法,被传输的数据可以是另一协议的帧。隧道协议用附加的报头封装帧,附加的报头提供了路由信息,因此封装后的包能够通过中间的公网。封装后的包所途经的公网的逻辑路径称为隧道。一旦封装的帧到达了公网上的目的地,帧就会被解除封装并被继续送到最终目的地。
4.1.1 PPTP(Point to Point Tunneling Protocol,点到点隧道协议)
PPTP是VPN的基础。PPTP的封装在数据链路层产生,PPTP协议采用扩展GRE(Generic Routing Encapsulation)头对PPP/SLIP报进行封装。所谓扩展GRE头,即在通常GRE头中,细化并修改了密钥字段的利用,并增加了确认、出现位和确认号字段,从而提供了PPTP的流量控制功能。
4.1.2 L2F(Layer 2 forwording)
L2F可以在多种介质(如ATM、帧中继、IP网)上建立多协议的安全虚拟专用网、它将链路层的协议(如PPP,HDLC等)封装起来传送。因此,网络的链路层完全独立于用户的链路层协议。 4.1.3 L2TP(Layer 2 Tunneling Protocol)
是远程访问型VPN今后的标准协议。它结合了PPTP协议和L2F协议的优点,以便扩展功能。其格式基于L2F,信令基于PPTP。这种协议几乎能实现PPTP和L2F协议能实现的所有服务,并且更加强大、灵活。它定义了利用公共网络设施(如IP网络、ATM、帧中继网络)封装传输链路层PPP帧的方法。
4.1.4 IPSec
是在IP层提供通信安全而提供的一套协议族,是一个开放性的标准框架。IPSec安全协议包括:封装的安全负载ESP(Encapsulation Securiy Payload)和认证报头AH(Authentication Header)、ISAKMP(The Internet Security Association & Key Management Protocol),它对所有链路层上的数据提供安全保护和透明服务。
AH用于通信双方能够验证数据在传输过程中是否被更改并能验证发方的身份,实现访问控制、数据完整性、数据源的认证性和重放根据的保护的功能。
ISAKMP主要用于通信双方协商加密密钥和加密算法,它是基于D-H的密钥交换协议,并且用户的公钥和私钥是由可信任第三方TTP(Trusted Third Party)产生的。
ESP 的基本思想是对整个IP包或更高层协议的数据进行封装,有2种模式:隧道(Tunnel)模式和传输(Transport)模式.在隧道模式下,IPSec把IPv4的整个IP包加密后封装在新的安全IP包的数据段中,并生成一个新的IP包,在传输模式下只是将原IP包中的数据进行加密后再发送出去。
4.1.5 通用路由封装(GRE, Generic Routing Encapsulation)
GRE规定了怎样用一种网络层协议去封装另一种网络层协议的方法。GRE的隧道由两端的源IP地址和目的IP地址来定义。GRE只提供了数据包的封装,它并没有加密功能来防止网络侦听和攻击。所有在实际环境中它常和IPSec一起使用,由IPSec提供用户数据的加密,从而给用户提供更好的安全性。
4.1.6 MPLS协议
MPLS VPN 采用隧道协议为 MPLS技术,利用标签交换,通过LSP(标签交换路径)将私有网络的不同分支联结起来,并结合传统的路由技术,构建一种站点到站点(LAN-to-LAN)的 VPN 技术。它能够比较完善的实现有关QoS服务,因而能满足各种企业互联和应用的需求,使VPN 可以成为专线的替代业务。MPLS VPN 使用双层标签技术实现隧道,内层标签表示分组去往的目标用户站点,外层标签表示分组去往与目标用户站点直连的出口 LER(标签边缘路由器)的 MPLS 域路径。当 IP 分组到达入口 LER,入口 LER 查找 LFIB(标签转发信息数据库)给分组打上双层标签, 封装后的标签分组在MPLS域中沿着 LSP(标签交换路径)路径转发,核心LSR(标签交换路由器)不需要也不知道内层标签的存在,只知交换标签分组的外层标签,当标签分组到达倒数第二跳 LSR 时弹出顶层标签,将只含有内层标签的分组发往出口 LER,出口 LER 弹出内层标签,并查找内层标签关联的 IP 路由,然后按照 IP 包的路由方式到达目的地。
4.2 加解密技术:
加解密技术是数据通信中一项较成熟的技术,VPN可直接利用现有技术。用于VPN上的加密技术由IPSec的ESP (Encapsulationg Security Payload)实现。主要是发送者在发送数据之前对数据加密,当数据到达接收者时由接收者对数据进行解密的处理过程,算法主要种类包括:对称加密(单钥加密)算法、不对称加密(公钥加密)算法等。如DES (Data Encryption Standard)、IDEA (International Data Encryption Algorithm)、RSA(发明者Rivest、Shamir和Adleman名字的首字符)。
对于对称加密算法,通信双方共享一个密钥,发送方使用该密钥将明文加密成密文,接收方使用相同的密钥将密文还原成明文。对称加密算法运算速度快。
不对称加密算法是通信双方各使用两个不同的密钥,一个是只有发送方知道的密钥,另一个则是与之对应的公开密钥,公开密钥不需保密。在通信过程中,发送方用接收方的公开密钥加密消息,并且可以用发送方的秘密密钥对消息的某一部分或全部加密,进行数字签名。接收方收到消息后,用自己的秘密密钥解密消息,并使用发送方的公开密钥解密数字签名,验证发送方身份。
4.3 密钥管理技术:
密钥管理技术的主要任务是如何在公用数据网上安全地传递密钥而不被窃取。现密钥管理技术又分为SKIP与ISAKMP/OAKLEY两种。
SKIP主要是利用Diffie-Hellman的演算法则,在网络上传输密钥;在ISAKMP中,双方都有两把密钥,分别用于公用、私用。
4.4 使用者与设备身份认证技术:
使用者与设备身份认证技术最常用的是用户名/口令或智能卡认证等方式。
5 VPN的部署场景与实施
5.1 IPsec协议集使用及部署情况
5.1.1 LAN TO LAN VPN:共享密钥部署
5.1.2 LAN TO LAN VPN :不对称加密算法部署即CA部署
设计原理:PKI(Pub1ic Key Infrastructure),是一种遵循既定标准的密钥管理平 台,它能为所有网络应用提供加密和数字签名等密码 服务以及所必需的密钥和证书管理体系。在这一体系中,加密密钥与解 密密钥各不相同,发送信 息的人利用接收者的公钥发送加密信息,接收者再利用自己专有的私钥进行解密。这种方式既保证了信息的机密性,又能保证信息具有不可否认性 。PKI利用可信赖的第三方机构一证书机构CA作为密钥管理与验证机构,以签发数字证书方式证 明公钥的效力。此外,所有辅助公开密码系统使用与应用服务的工作均可视为公开密钥基础设施的一部份。把公钥及公钥的拥有者绑定在一起的数字文件即为数字证书,cA利用自己的私钥签名用户证书,而cA的公钥证书则是广为发布的,从而使得用户可以利用公证机关的证书来验证别的用户的证书。
PKI实体包括三个部分,第一部分是PKI用户,即终端用户系统;第二部分指PKI管理实体 ,包 括cA、RA、CRLIssuer;第三部分是PKI的证书及CRL资料库。其中:E E :终端实体 (End Entity),数字证书的月户和证书主体的终端用户系统。CA:证书机构 ( Certification Athority ),PKI系统的核心部件,负责证书管理。RA:注册机构 ( Registration Authority),cA委派的承担某些管理功能的可选系统。CRL:作废证书列表 (Certificate Revocation List),存储所有未过期但已被作废的证书 。CRLIssuer:CRL发布机构,cA委派的承担发布CRL的可选系统。如授权管理基础设施 PMI中的AA(Attribute Authority)可被选作CRL发布机构。公共资料库:存储证书,CRL列表及为终端实体提供证书和CRL列表服务的系统或分布系统的集合。
5.1.3 Remote VPN:EZVPN实现(硬件实现和软件实现)
1,如上图二在 PC 上安装 VPN Client 4.0 客户端软件,将其配置为 Ezvpn 的软件客户端,配置 R2 为 Server,认证方法为本地,当用户成功接入后,为客户端分配一个内网地址(为了测试,地址池网段可以和 R1-R2 同一个网段; ) ,然后从 PC 上 ping 内网中的地址(R1 地址),这时 ping 不通,在R2 上 show crypto ipsec sa 看到只有加密包,没有解密包;因为从 PC 到R1 可以,但是返回的时候就有问题,R1 上面没有回来的路由;
2,PC 到 R1 的流量没问题,但是当流量返回的时候,R1 发现 PC 的地址和自己的地址是在同一个网段,于是就发送 ARP 请求,请求 PC 的MAC 地址,由于 PC 是被逻辑上被放到 R1-R2 之间的网段,不是物理存在的,因此 PC 肯定收不到 ARP 响应; 那么我们可以使用 ARP 代理的方法来解决此问题,即让 R2 代替 PC响应 R1 的 ARP 请求包,但是要想让 R2 代替 PC 响应,那么就要求在 R2上必须有到达 PC 的详细路由,此时我们可以在 R2 上打开反向路由注入(RRI) ,当 R2 给 Client(PC)分配地址以后,自动的在自己的路由表中插入一个 32 位的主机路由,下一跳指向 Client 的公网地址;
3,另外,我们也可以在 R2 连接 R1 的接口上打开/关掉 ARP 代理,来查看效果; NOTE:做完 Remote-Access VPN 后,可以总结一下 L2L 的 RRI 和 RA 的RRI 的不同,以及是分别是如何进行注入的;
4,假设 R2 是公司边界路又器,PC 即要访问公司总部的内部设备(R1) ,又要访问 Internet,那么所有从 PC 出去的包都会被加密,包括去往 Internet 的包;这样就会影响上网的速度和 R2 设备的负载; 我们可以这样做,让 PC 只有去往内网的流量才会通过 Tunnel,去往Internet 的流量不通过 Tunnel;隧道分传就可以实现该功能,在 Server 上配置一个 ACL,该 ACL 必须是扩展 ACL,ACL 中源 IP 地址定义的网段或地址就是需要通过 Tunnel 的流量;当 Client 接入的时候,Server 就会通过 Mode Configure 消息将该 ACL 以及其他参数推送给 Client(PC),那么在 PC 去往 ACL 源 IP 地址定义的网络的时候就会通过 Tunnel 将流量发送出去,其他的都正常转发;提示:不要将 TestPC 网卡的地址改为 172.16.0.0/16 网段范围内的地址 在我们的试验环境中,由于我们是通过远程桌面登录到 TestPC 上去的,所以我们需要做隧道分传,否则的话会使远程桌面断开;因为隧道一旦建立成功,所有的流量都要通过隧道传输; 因此我们可以定义一个列表,来告诉 Client 去往哪些网段的流量才让走隧道;其他的流量都正常转发。
5.1.4 WEB VPN 即SSL VPN
SSL VPN 作为一种全新的技术正在被广泛关注,SSL利用内置在每个 Web 浏览器中的加密和验证功能,并与安全网关相结合,提供安全远程访问企业应用的机制,这样,远程移动用户轻松访问公司内部 B/S和 C/S 应用和其他核心资源。
使用 SSL VPN具有很好的经济性,因为只需要在总部放置一台硬件设备就可以实现所有用户的远程安全访问接入。但是对于 IPSEC VPN来说,每增加一个需要访问的分支,就需要添加一个硬件设备。就使用成本而言,SSL VPN具有更大的优势,由于这是一个即插即用设备,在部署实施以后,一个具有一定 IT 知识的普通工作人员就可以完成日常的管理工作。
SSL VPN 在其易于使用性及安全层级,都比 IPSec VPN 高。我们都知道,由于 Internet 的迅速扩展,针对远程安全登入的需求也日益提升。对于使用者而言,方便安全的解决方案,才能真正符合需求。
SSLVPN 的类型:
一 Clientless SSL VPN
公司内部启用了 http 或 https 的资源,远程用户只需要使用基于 web browser 来访问。浏览带有 Common Internet File System (CIFS)的文件也是可以的。一个好的例子是基于 WEB 的Outlook Access client,Web-enabled applications,file sharing,Outlook Web Access。
• 基于浏览器。
• Microsoft Windows or Linux。
• Web 应用程序,文件共享,Outlook Web Access。
• 网关执行地址或者协议的转换以及内容的解析和重写。
二 Thin-Client SSL VPN (port-forwarding Java applet)
远程用户必须下载一个小的,基于 JAVA的小应用程序。以便能访问到使用静态端口的 TCP应用,UDP 不被支持。包括的例子如:POP3, SMTP, IMAP, SSH, and Telnet。用户需要本地管理员特权,因为对文件的修改是在本地机器中进行。这种 VPN 技术不能让使用动态端口的应用正常工作。如个别的 FTP服务器。
• TCP port 转发
• 使用 Java Applet
• 扩展应用程序支持
• Telnet, e-mail, SSH, Meeting Maker, Sametime Connect
• 支持静态端口的应用程序
不支持 FTP。
• You cannot use thin-client mode for applications such as FTP, where the ports are negotiated dynamically. You can use TCP port forwarding only with static ports.
三 SSL VPN Client (SVC-Tunnel Mode)
在这种技术中,远程工作站需要下载一个小的客户端软件,对公司内部资源的全部安全访问。这个小的客户端软件可以永久地被下载到远程工作站或者安全会话结束后就被删除。远程用户使用的 SSL 隧道在 network(IP)layer 移动数据。因此,隧道模式支持大多数基于IP 的应用。隧道模式支持多种流行的企业应用。
• 工作形式像使用无客户端的 IPsec VPN
• 客户需要下载 Java or ActiveX 程序(大概有 500 kB)
• 支持所有基于 IP流量的应用程序
• 具有管理的可伸缩型
• 本地管理员允许进行安装(就是说有权限安装 Java or ActiveX程序)
5.2 GRE协议部署及使用情况
上图二十二中,有 3 个站点,如果要想实现全网状安全通信的话,那么就要建立 3 个 VPN 连接,如果有 4 个站点,那么就要建立 6 个 VPN 连接,如果还要有站点加入的话,那么就要修改所有站点的配置,同时增加 VPN 建立的连接数,这样就是网络有很差的可扩展性; DMVPN 主要解决的是 Spoke 和 Spoke 之间配置复杂的问题, 同时也提供了很好的扩展性;DMVPN 是 IPSec、mGRE 和 NHRP(下一跳地址解析协议)的综合;在 HUB(R1)和 Spoke(R2 和 R3)之间建立的是永久性的 IPSec VPN;spoke 之间建立的是临时性的 VPN,当 spoke 之间没有流量传送的时候就会自动断开连接;NHRP 协议是一个 client/server 的协议,Client 在设备/接口启动的时候会把它的NBMA地址注册给Server,Server维护一个NHRP数据库, 当Spoke之间建立 VPN 的时候,就会使用 NHRP 协议解析对端的真实 NBMA 地址,然后直接和该地址建 VPN;
5.4 L2TP协议集使用情况部署
L2TP 是 PPTP 和 L2F 的组合, 它定义在 RFC2261 和 RFC3348 中。 L2TP也使用 PPP 来封装用户的数据,因此,允许多协议通过隧道;PPTP 使用MPPE 作为加密,而 L2TP 依赖于更安全的方案:L2TP 的数据包是被 IPSec的 ESP 使用传输模式保护的(GRE over IPsec);因为 L2TP 自身不对数据进行加密;
5.4.1 L2TP 协议介绍
第二层隧道协议(L2TP)是用来整合多协议拨号服务至现有的因特网服务提供商点。PPP 定义了多协议跨越第二层点对点链接的一个封装机制。特别地,用户通过使用众多技术之一(如拨号 POTS、ISDN、ADSL 等)获得第二层连接到网络访问服务器(NAS),然后在此连接上运行 PPP。在这样的配置中,第二层终端点和 PPP会话终点处于相同的物理设备中(如 NAS)。
L2TP 提供了一种远程接入访问控制的手段,其典型的应用场景是:某公司员工通过 PPP 拨入公司本地的网络访问服务器(NAS) ,以此接入公司内部网络,获取 IP 地址并访问相应权限的网络资源;该员工出差到外地,此时他想如同在公司本地一样以内网 IP 地址接入内部网络,操作相应网络资源,他的做法是向当地 ISP 申请 L2TP 服务,首先拨入当地 ISP,请求 ISP与公司 NAS 建立 L2TP 会话,并协商建立 L2TP 隧道,然后 ISP 将他发送的 PPP 数据通道化处理,通过 L2TP 隧道传送到公司 NAS,NAS 就从中取出 PPP 数据进行相应的处理,如此该员工就如同在公司本地那样通过 NAS接入公司内网。
L2TP 扩展了 PPP 模型,允许第二层和 PPP 终点处于不同的由包交换网络相互连接的设备来。通过 L2TP,用户在第二层连接到一个访问集中器 (如调制解调器池、 ADSL DSLAM 等) , 然后这个集中器将单独得的 PPP 帧隧道到 NAS。这样,可以把 PPP 包的实际处理过程与 L2 连接的终点分离开来。 L2TP 使用以下两种信息类型,即控制信息和数据信息。控制信息用于隧道和呼叫的建立、 维持和清除。 数据信息用于封装隧道所携带的 PPP 帧。
控制信息利用 L2TP 中的一个可靠控制通道来确保发送。当发生包丢失时,不转发数据信息。
5.4.2 L2TP 的协议结构
• T ― T 位表示信息类型。若是数据信息,该值为 0;若是控制信息,该值为 1。
• L ― 当设置该字段时,说明 Length 字段存在,表示接收数据包的总长。对于控制信息,必须设置该值。
• X ― X 位为将来扩张预留使用。在导出信息中所有预留位被设置为 0,导入信息中该值忽略。
• S ― 如果设置 S 位,那么 Nr 字段和 Ns 字段都存在。对于控制信息,S 位必须设置。
• O ― 当设置该字段时,表示在有效负载信息中存在 Offset Size 字段。对于控制信息,该字段值设为 0。
• P - 如果 Priority (P)位值为 1,表示该数据信息在其本地排队和传输中将会得到优先处理。
• Ver ― Ver 位的值总为 002。它表示一个版本 1 L2TP 信息。
• Length ― 信息总长,包括头、信息类型 AVP 以及另外的与特定控制信
息类型相关的 AVPs。 • Tunnel ID ― 识别控制信息应用的 Tunnel。如果对等结构还没有接收到分配的 Tunnel ID,那么 Tunnel ID 必须设置为 0。一旦接收到分配的 Tunnel ID,所有更远的数据包必须和 Tunnel ID 一起被发送。
• Call ID ― 识别控制信息应用的 Tunnel 中的用户会话。如果控制信息
在 Tunnel 中不应用单用户会话(例如,一个 Stop-Control-Connection-Notification 信息),Call ID 必须设置为 0。
• Nr ― 期望在下一个控制信息中接收到的序列号。
• Ns ― 数据或控制信息的序列号。
• Offset Size & Pad ― 该字段规定通过 L2F 协议头的字节数,协议头是有效负载数据起始位置。Offset Padding 中的实际数据并没有定义。如果 Offset 字段当前存在,那么 L2TP 头 Offset Padding 的最后八位字节后结束。
L2TP 分为两种模式:自发隧道模式和强制隧道模式。
5.4.3 L2TP 自发模式试验
5.5 MPLS协议使用及部署情况
MPLS VPN 采用隧道协议为 MPLS技术,利用标签交换,通过LSP(标签交换路径)将私有网络的不同分支联结起来,并结合传统的路由技术,构建一种站点到站点(LAN-to-LAN)的 VPN 技术。它能够比较完善的实现有关QoS服务,因而能满足各种企业互联和应用的需求,使VPN 可以成为专线的替代业务。MPLS VPN 使用双层标签技术实现隧道,内层标签表示分组去往的目标用户站点,外层标签表示分组去往与目标用户站点直连的出口 LER(标签边缘路由器)的 MPLS 域路径。当 IP 分组到达入口 LER,入口 LER 查找 LFIB(标签转发信息数据库)给分组打上双层标签, 封装后的标签分组在MPLS域中沿着 LSP(标签交换路径)路径转发,核心LSR(标签交换路由器)不需要也不知道内层标签的存在,只知交换标签分组的外层标签,当标签分组到达倒数第二跳 LSR 时弹出顶层标签,将只含有内层标签的分组发往出口 LER,出口 LER 弹出内层标签,并查找内层标签关联的 IP 路由,然后按照 IP 包的路由方式到达目的地。
MPLS VPN 网络通常由 CE、PE、P三类设备组成,其中CE 为用户边缘路由器,为用户提供到 PE 路由器的连接,一般不需要支持 MPLS 协议;PE 为提供商边缘路由器,它根据存放路由信息将来自CE 路由器或 LSP的 VPN 数据处理后进行转发, 同时负责和其他PE路由器交换路由信息;P 为提供商核心路由器,它根据分组的外层标签对 VPN 数据进行透明转发,P 路由器只维护到 PE 路由器的路由信息而不维护 VPN 相关的路由信息,PE 和P 都需要支持 MPLS 协议。
6 下一代VPN技术展望
6.1 VoIP VPN
许多大型公司及中小型企业都采用基于IP的VPN,来传送大量的数据业务。但企业中的话音却是通过另外租用线路来传送,这种数据与话音业务分别传送的方式成本很高。因此,话音以数据方式传输一直是业界最为关注的技术之一。
一些通信公司如Cisco等,提出了VoIP VPN的解决方案,即利用VoIP技术使企业可以利用IP VPN来传送话音业务,允许话音传送就行一种数据业务一样通过IP网络。
Cisco推出了一种能够传输话音和视频业务的IPSec VPN。该方案基于VPN路由器,通过使用服务类型字段对话音和视频流量作标记,将其显示为IPSec报头的一部分发向网络,使其享有更高的优先级,这样企业可利用IP电话建立起自己的远程家庭办公网络系统。该系统除具备IP PBX的全部特性外,还有一条安全数据链路作备份。
VoIP VPN使企业不必分别为话音和数据建立网络,大大节省了企业开销,是一项具有广泛发展前景的技术。
由于目前该方案尚在研究提案中,尚不给出配置案例及分析。
6.2 基于VPN 的安全多播
多播应用是当今互联网技术发展的热点,多播数据传输的安全性和可靠性已成为多播技术发展亟待解决的两个问题。因此有人提出了基于VPN的安全多播技术, 它由安全多播网关和安全多播主机组成,充分利用现有的基于IPSec的VPN系统的体系结构来实现多播数据的安全传输,实现简单,结构灵活,与IPSec兼容。
基于VPN安全多播系统的安全多播网关中有一个网关充当多播组的控制器, 一个网关充当多播组的备份控制器. 组控制器对整个多播组的安全策略进行管理, 备份控制器在主控制器失效时充当多播组的主控制器。多播报文在安全多播网关之间采用隧道进行传输, 在多播安全网关和多播安全主机之间采用多播传输.
基于VPN的安全多播系统提高了多播数据传输时的安全性和可靠性。
6.2.1 下一代VPN部署配置实例--GETVPN
IETF 标准化文档 RFC 3547 中的组解释域 Group Domain of Interpretation (GDOI)是GETVPN 的最主要的部分。
GET VPN 技术是公有开放标准和 Cisco 私有技术的结合产物,该技术发挥了底层 MPLS 和共享网络的优势。
GET VPN 具有以下几个优势:
为任意节点间瞬时大范围的 IP 通信提供了安全范本。只需利用基础的 IP 路由结构,而不需要在基础结构上构建另一层路由结构。 与传统的IPSec隧道技术相比,GET VPN 技术提供了与组播技术的无缝结合。
通过使用加密和封装技术保护了源地址和目的地址之间的通信,同时也可以很好的QOS 等技术协同工作。
GDOI组密钥管理协议为一组设备提供了加密密钥和策略的集合。在GET VPN的网络中,GDOI分配一个公钥到组内的其他VPN网关,来确保通信的安全性。组中的所有VPN网关使用一种叫做rekey的方法来定期的更新密钥。
GDOI协议受阶段1的IKE SA保护。所有的VPN网关必须使用IKE进行认证。并且支持所有的IKE认证方法(PSK,PKI)。当VPN网关被认证和通过IKE SA获得密钥后,IKE SA条目超时后,GDOI通过灵活有效的方法更新组成员。 GDOI包含两种不同的加密密钥,其中名为KEK的密钥用来保护GET VPN的控制层面,另外一种名为TEK的密钥用来加密数据流。
IP tunnel header preservation:
传统意义上的IPSEC,隧道端点的地址被作为新的IP包的源和目的。数据包使用加密端的物理接口地址作为源地址,使用解密端的物理接口地址作为目的地址在IP网络上进行路由(隧道模式)。在GET VPN解决方案中,IPSEC保护的数据包将原数据包中的源地址和目的地址复制一份作为整个IP包头中的地址。(如下图)
图五十八 GET VPN数据包结构带来的最大优越性表现在可以使用底层的网络对GET VPN的数据包进行路由,分支机构中的高可用性技术可以和GET VPN解决方案无缝结合(如双接入点双链路等),不在需要在IPSec层面上实施高可用性的技术(如双HUB点,状态型高可用性IPSEC技术等)。
Key servers (KSs) 通常情况下IOS设备作为一个Key Server负责创建和维护GET VPN的控制层面。所有的加密策略包括:感兴趣流,加密协议,SA,rekey间隔等等,都需要在KS上进行统一的定义并在组成员想KS注册的时候将策略推送给组成员。
GET VPN是通过KS使用IKE第一阶段来认证组成员,组成员在认证通过后将key和加密策略下载到组成员本地。KS同时负责Key的刷新和分发。 和传统的IPSEC解决方案不同的是,GET VPN的感兴趣流是通过ACL方式定义在KS上,无论GMs是否和KS属于同一个子网内,该ACL都可以被下载到GMs路由器上。在定义感兴趣流的ACL时,建议将GM成员的网络汇总为尽可能的少的条目。例如如果组成员的网络都位于10.0.0.0/8的网络中(10.1.1.0/24,10.1.2.0/24等),最好将感兴趣流定义为permit 10.0.0.0/8 to 10.0.0.0/8”,而不是10.1.1.0/24 to 10.1.2.0/24。非对称的策略将导致ACL条目数量过于庞大,在这种情况下,为大多数组成员定义一个聚合策略是比较理想的策略实现方式。最少条目的聚合策略是permit ip any any,该策略加密GMs之间通信的流量,因此很多时候,我们需要定义排除的列表(使用Deny选项)使某些不需要与其他组成员通讯的数据不进行加密传输。
GMs:前面已经提到,加密策略主要定义在KS上,当组成员向KS注册时下载这些策略到GM成员的本地,而作为组成员来说,只需要定义IKE的第一阶段和GDOI组信息。基于这些下载的加密策略,GM成员决定哪些流量将被加密和被解密,以及使用什么样的key等。但是,在某些情况下,GM成员可以配置本地的策略来覆盖通过KS得到的策略。例如,在组中的几个成员间运行了路由协议,而这些参加路由协议的流量必须避开加密策略,这个时候我们需要在这些组成员上定义一些策略条目来避开全局的策略。
Group SA:和传统的IPSEC解决方案不同的是,GET VPN使用组SA的概念。所有GET VPN组内成员间的互相通信使用统一的加密策略和一条公共的SA。有了这些公共的策略,组成员间将不必再协商IPSEC隧道,这减少了路由器的资源消耗。
Rekey Process :以上我们提到,KS不仅仅负责创建加密策略和key,同时也负责更新和分发新key到组成员。当已存在的key超时后,KS将分发新的key到组成员,这个过程就被称为rekey进程。GET VPN支持两种类型的Rekey消息:单播和组播。
如果组成员不能从KS处收到rekey消息(例如KS服务器down或者网络中断),GM将在已存在的IPSEC SA超时前60秒尝试向KS进行注册。如果注册成功,则组成员通过重注册过程收到新的SA并且流量不会产生中断。如果注册不成功,则组成员会每间隔10秒尝试向KS重试三次,如果依然不成功则在已存在的IPSEC SA超时前20秒时,尝试向其他已定义的KS注册。
Unicast Rekey :在单播Rekey的过程中,KS生成一个rekey消息并且将这个消息复制发送给每一个组成员。
当组成员收到该消息后,返回一个ACK消息给KS。该机制不仅能确定在KS上注册的活跃组成员是正确的,同时也能确定rekey消息只发送给了活跃的组成员。
KS在网络出现短暂中断的时候,会对Rekey数据包进行重传。如果GM在KS发出的三次rekey的过程中不能响应,则KS会将该GM从活跃的GM数据库中移除,并停止向该GM发送rekey消息。
Multicast Rekey :在组播Rekey的过程中,KS创建一个rekey消息并发送该消息到预先配置好的组播组地址。
每一个加入这个组播组的GM,在向KS注册的时候都会受到这个rekey消息的拷贝。
和单播rekey过程不同的是,组播rekey没有ACK的机制。KS不会维护一个活跃的GM数据库。和单播rekey过程相同的是,KS会对Rekey数据包进行重传,已防止短暂的网络中断。 为了使用组播方式的rekey,必须在核心的网络上打开组播功能。
COOP KSs :KS在整个GET VPN中扮演着最重要的角色,KS维护着整个GET VPN的控制层面。因此,仅有一台KS时有可能会在VPN网络中造成单点故障。GET VPN支持多个KS服务器,称之为COOP KSs,用来确保如果主KS失效或者不可达的时侯,GET VPN的控制层面可以使主KS失效时无缝切换到其他的KS。
一个组成员可以配置多个活跃KS服务器,GM会对这个列表进行递归查询。 COOP协议配置在每一个GDOI的基本组内,一个KS可以配置多个GDOI组用来维护多个KSs所关联的不同的COOP列表。 当COOP KSs启动后,所有的KSs都被假设为处于备用状态并开始选举主KS。优先级最高的KS被选举为主KS,同时其他的KS都被置于备用状态。主KS用来创建和分发组策略到所有的GM,并且和其他的COOP KSs进行周期性的同步。
COOP KSs之间交换一种单向的消息通告(从主KS到备用KS)。如果一个备用的KS在一段时间内不能收到主KS发送来的消息,备用的KS将尝试联系主KS并请求更新消息。如果主KS没有响应,则COOP KSs间重新开始选举,直到一个新的主KS被选举出来。
建议在Coop KS内部配置DPD特性,该特性可以使主KS跟踪和显示其他的备用KS的状态。但是需要注意的是在GM和KS之间该功能不是必须的同时也不支持该功能。
Time Based Anti-Replay :在传统的IPSEC vpn解决方案中,防止回放攻击的能力可以防止第三方恶意攻击对IPSEC站点间IPSEC包进行抓包并回放从而造成的DOS攻击。传统的IPSEC VPN解决方案使用基于滑动窗口的计数器:发送者发送使用连续数值的数据包,接收者视同滑动窗口来确定这个包是否是被允许。
我们使用一种新的方法称为基于时间的反回放攻击来保护网络不受第三人的攻击。TBAR在KS上维护一个虚构的时间,所带来的其中一个优点就是不需要在GET VPN的设备间使用NTP来同步时间。主KS为整个组建立并维护一个虚构的时间。主KS会在GM进行rekey更新的时候与GM成员进行虚构时间的同步。每一个GM成员都在数据包内包含一个虚构的时间戳。接收数据包的VPN网关会将数据包内的时间戳和自身与KS同步得到的时间戳进行比较,如果数据包内的时间戳比较晚,则丢弃该数据包。
虽然发展前景比较乐观,不过MPLS VPN 技术要想有更大的发展,目前QOS问题还有待进一提高,安全问题需加强,另外需要进一步提高标准化程度,解决多厂家设备的互通性问题。相信经过 MPLS VPN 技术的不断完善和发展,未来必将和IP网络达到完美结合,为用户提供更加满意的服务和更加丰富的业务,成为VPN 技术的主流。