路由器实现VPN配置.docx

路由器实现VPN配置.docx

《路由器实现VPN配置.docx》由会员分享，可在线阅读，更多相关《路由器实现VPN配置.docx（11页珍藏版）》请在冰豆网上搜索。

路由器实现VPN配置

M12-3使用路由器实现VPN功能

1.1教学目的与要求

1.1.1教学目的

主要要求学生通过该能力模块的学习,能够熟练掌握使用路由器安装与配置VPN的能力。

1.1.2教学要求

1.教学重点

✧使用路由器构建站点到站点的IPSecVPN

2.教学难点

✧理解IPSecVPN

1.2本能力单元涉及的知识组织

1.2.1本能力单元涉及的主要知识点

1、使用路由器构建IPSecVPN

1.2.2本能力单元需要解决的问题

1、按照项目的需求，重点理解虚拟专用网的定义；

2、按照项目的需求，熟练掌握使用路由器配置VPN；

1.3核心技术和知识的理解

1.3.1虚拟专用网

点对点协议

因为第2层隧道协议在很大程度上依靠PPP协议的各种特性，因此有必要对PPP协议进行深入的探讨。

PPP协议主要是设计用来通过拨号或专线方式建立点对点连接发送数据。

PPP协议将IP，IPX和NETBEUI包封装在PP桢内通过点对点的链路发送。

PPP协议主要应用于连接拨号用户和NAS。

PPP拨号会话过程可以分成4个不同的阶段。

分别如下：

阶段1：

创建PPP链路

PPP使用链路控制协议（LCP）创建，维护或终止一次物理连接。

在LCP阶段的初期，将对基本的通讯方式进行选择。

应当注意在链路创建阶段，只是对验证协议进行选择，用户验证将在第2阶段实现。

同样，在LCP阶段还将确定链路对等双方是否要对使用数据压缩或加密进行协商。

实际对数据压缩/加密算法和其它细节的选择将在第4阶段实现。

阶段2：

用户验证

在第2阶段，客户会PC将用户的身份明发给远端的接入服务器。

该阶段使用一种安全验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。

大多数的PPP方案只提供了有限的验证方式，包括口令验证协议（PAP），挑战握手验证协议（CHAP）和微软挑战握手验证协议（MSCHAP）。

1.口令验证协议（PAP）

PAP是一种简单的明文验证方式。

NAS要求用户提供用户名和口令，PAP以明文方式返回用户信息。

很明显，这种验证方式的安全性较差，第三方可以很容易的获取被传送的用户名和口令，并利用这些信息与NAS建立连接获取NAS提供的所有资源。

所以，一旦用户密码被第三方窃取，PAP无法提供避免受到第三方攻击的保障措施。

2.挑战-握手验证协议（CHAP）

CHAP是一种加密的验证方式，能够避免建立连接时传送用户的真实密码。

NAS向远程用户发送一个挑战口令（challenge），其中包括会话ID和一个任意生成的挑战字串（arbitrarychallengestring）。

远程客户必须使用MD5单向哈希算法（one-wayhashingalgorithm）返回用户名和加密的挑战口令，会话ID以及用户口令，其中用户名以非哈希方式发送。

CHAP对PAP进行了改进，不再直接通过链路发送明文口令，而是使用挑战口令以哈希算法对口令进行加密。

因为服务器端存有客户的明文口令，所以服务器可以重复客户端进行的操作，并将结果与用户返回的口令进行对照。

CHAP为每一次验证任意生成一个挑战字串来防止受到再现攻击（replayattack）.在整个连接过程中，CHAP将不定时的向客户端重复发送挑战口令，从而避免第3方冒充远程客户（remoteclientimpersonation）进行攻击。

3.微软挑战-握手验证协议（MS-CHAP）

与CHAP相类似，MS-CHAP也是一种加密验证机制。

同CHAP一样，使用MS-CHAP时，NAS会向远程客户发送一个含有会话ID和任意生成的挑战字串的挑战口令。

远程客户必须返回用户名以及经过MD4哈希算法加密的挑战字串，会话ID和用户口令的MD4哈希值。

采用这种方式服务器端将只存储经过哈希算法加密的用户口令而不是明文口令，这样就能够提供进一步的安全保障。

此外，MS-CHAP同样支持附加的错误编码，包括口令过期编码以及允许用户自己修改口令的加密的客户-服务器（client-server）附加信息。

使用MS-CHAP，客户端和NAS双方各自生成一个用于随后数据加密的起始密钥。

MS-CHAP使用基于MPPE的数据加密，这一点非常重要，可以解释为什么启用基于MPPE的数据加密时必须进行MS-CHAP验证。

在第2阶段PPP链路配置阶段，NAS收集验证数据然后对照自己的数据库或中央验证数据库服务器（位于NT主域控制器或远程验证用户拨入服务器）验证数据的有效性。

阶段3：

PPP回叫控制（callbackcontrol）

微软设计的PPP包括一个可选的回叫控制阶段。

该阶段在完成验证之后使用回叫控制协议（CBCP）如果配置使用回叫，那么在验证之后远程客户和NAS之间的连接将会被断开。

然后由NAS使用特定的电话号码回叫远程客户。

这样可以进一步保证拨号网络的安全性。

NAS只支持对位于特定电话号码处的远程客户进行回叫。

阶段4：

调用网络层协议

在以上各阶段完成之后，PPP将调用在链路创建阶段（阶段1）选定的各种网络控制协议（NCP）.例如，在该阶段IP控制协议（IPCP）可以向拨入用户分配动态地址。

在微软的PPP方案中，考虑到数据压缩和数据加密实现过程相同，所以共同使用压缩控制协议协商数据压缩（使用MPPC）和数据加密（使用MPPE）。

数据传输阶段

一旦完成上述4阶段的协商，PPP就开始在连接对等双方之间转发数据。

每个被传送的数据报都被封装在PPP包头内，该包头将会在到达接收方之后被去除。

如果在阶段1选择使用数据压缩并且在阶段4完成了协商，数据将会在被传送之间进行压缩。

类似的，如果如果已经选择使用数据加密并完成了协商，数据（或被压缩数据）将会在传送之前进行加密。

点对点隧道协议（PPTP）

PPTP是一个第2层的协议，将PPP数据桢封装在IP数据报内通过IP网络，如Internet传送。

PPTP还可用于专用局域网络之间的连接。

RFC草案“点对点隧道协议”对PPTP协议进行了说明和介绍。

该草案由PPTP论坛的成员公司，包括微软，Ascend，3Com，和ECI等公司在1996年6月提交至IETF。

可在如下站点[url]http:

//www.ietf.org[/url][url]http:

//www.ietf.org[/url]参看草案的在线拷贝.PPTP使用一个TCP连接对隧道进行维护，使用通用路由封装（GRE）技术把数据封装成PPP数据桢通过隧道传送。

可以对封装PPP桢中的负载数据进行加密或压缩。

图7所示为如何在数据传递之前组装一个PPTP数据包。

第2层转发（L2F）

L2F是Cisco公司提出隧道技术，作为一种传输协议L2F支持拨号接入服务器将拨号数据流封装在PPP桢内通过广域网链路传送到L2F服务器（路由器）。

L2F服务器把数据包解包之重新注入（inject）网络。

与PPTP和L2TP不同，L2F没有确定的客户方。

应当注意L2F只在强制隧道中有效。

（自愿和强制隧道的介绍参看“隧道类型”）。

第2层隧道协议（L2TP）

L2TP结合了PPTP和L2F协议。

设计者希望L2TP能够综合PPTP和L2F的优势。

L2TP是一种网络层协议，支持封装的PPP桢在IP，X.25，桢中继或ATM等的网络上进行传送。

当使用IP作为L2TP的数据报传输协议时，可以使用L2TP作为Internet网络上的隧道协议。

L2TP还可以直接在各种WAN媒介上使用而不需要使用IP传输层。

草案RFC“第2层隧道协议”对L2TP进行了说明和介绍。

该文档于1998年1月被提交至IETF。

可以在以下网站[url]http:

//www.ietf.org[/url][url]http:

//www.ietf.org[/url]获得草案拷贝。

IP网上的L2TP使用UDP和一系列的L2TP消息对隧道进行维护。

L2TP同样使用UDP将L2TP协议封装的PPP桢通过隧道发送。

可以对封装PPP桢中的负载数据进行加密或压缩。

图8所示为如何在传输之前组装一个L2TP数据包。

PPTP与L2TP

PPTP和L2TP都使用PPP协议对数据进行封装，然后添加附加包头用于数据在互联网络上的传输。

尽管两个协议非常相似，但是仍存在以下几方面的不同：

1.PPTP要求互联网络为IP网络。

L2TP只要求隧道媒介提供面向数据包的点对点的连接。

L2TP可以在IP（使用UDP），桢中继永久虚拟电路（PVCs）,X.25虚拟电路（VCs）或ATMVCs网络上使用。

2.PPTP只能在两端点间建立单一隧道。

L2TP支持在两端点间使用多隧道。

使用L2TP，用户可以针对不同的服务质量创建不同的隧道。

3.L2TP可以提供包头压缩。

当压缩包头时，系统开销（overhead）占用4个字节，而PPTP协议下要占用6个字节。

4.L2TP可以提供隧道验证，而PPTP则不支持隧道验证。

但是当L2TP或PPTP与IPSEC共同使用时，可以由IPSEC提供隧道验证，不需要在第2层协议上验证隧道。

IPSec隧道模式

IPSEC是第3层的协议标准，支持IP网络上数据的安全传输。

本文将在“高级安全”一部分中对IPSEC进行详细的总体介绍，此处仅结合隧道协议讨论IPSEC协议的一个方面。

除了对IP数据流的加密机制进行了规定之外，IPSEC还制定了IPoverIP隧道模式的数据包格式，一般被称作IPSEC隧道模式。

一个IPSEC隧道由一个隧道客户和隧道服务器组成，两端都配置使用IPSEC隧道技术，采用协商加密机制。

为实现在专用或公共IP网络上的安全传输，IPSEC隧道模式使用的安全方式封装和加密整个IP包。

然后对加密的负载再次封装在明文IP包头内通过网络发送到隧道服务器端。

隧道服务器对收到的数据报进行处理，在去除明文IP包头，对内容进行解密之后，获的最初的负载IP包。

负载IP包在经过正常处理之后被路由到位于目标网络的目的地。

IPSEC隧道模式具有以下功能和局限：

1.只能支持IP数据流

2.工作在IP栈（IPstack）的底层，因此，应用程序和高层协议可以继承IPSEC的行为。

3.由一个安全策略（一整套过滤机制）进行控制。

安全策略按照优先级的先后顺序创建可供使用的加密和隧道机制以及验证方式。

当需要建立通讯时，双方机器执行相互验证，然后协商使用何种加密方式。

此后的所有数据流都将使用双方协商的加密机制进行加密，然后封装在隧道包头内。

隧道类型

1.自愿隧道（Voluntarytunnel）

用户或客户端计算机可以通过发送VPN请求配置和创建一条自愿隧道。

此时，用户端计算机作为隧道客户方成为隧道的一个端点。

2.强制隧道（Compulsorytunnel）

由支持VPN的拨号接入服务器配置和创建一条强制隧道。

此时，用户端的计算机不作为隧道端点，而是由位于客户计算机和隧道服务器之间的远程接入服务器作为隧道客户端，成为隧道的一个端点。

目前，自愿隧道是最普遍使用的隧道类型。

以下，将对上述两种隧道类型进行详细介绍。

自愿隧道

当一台工作站或路由器使用隧道客户软件创建到目标隧道服务器的虚拟连接时建立自愿隧道。

为实现这一目的，客户端计算机必须安装适当的隧道协议。

自愿隧道需要有一条IP连接（通过局域网或拨号线路）。

使用拨号方式时，客户端必须在建立隧道之前创建与公共互联网络的拨号连接。

一个最典型的例子是Internet拨号用户必须在创建Internet隧道之前拨通本地ISP取得与Internet的连接。

对企业内部网络来说，客户机已经具有同企业网络的连接，由企业网络为封装负载数据提供到目标隧道服务器路由。

大多数人误认为VPN只能使用拨号连接。

其实，VPN只要求支持IP的互联网络。

一些客户机（如家用PC）可以通过使用拨号方式连接Internet建立IP传输。

这只是为创建隧道所做的初步准备，并不属于隧道协议。

强制隧道

目前，一些商家提供能够代替拨号客户创建隧道的拨号接入服务器。

这些能够为客户端计算机提供隧道的计