路由器实现VPN配置.docx
- 文档编号:29232926
- 上传时间:2023-07-21
- 格式:DOCX
- 页数:15
- 大小:24KB
路由器实现VPN配置.docx
《路由器实现VPN配置.docx》由会员分享,可在线阅读,更多相关《路由器实现VPN配置.docx(15页珍藏版)》请在冰豆网上搜索。
路由器实现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协议主要是设计用来通过拨号或专线方式建立点对点连接发送数据。
PPPtt、议将IP,IPX和NETBEU包封装在PP桢内通过点对点的链路发送。
PPP协议主要应用于连接拨号用户和NASPPP拨号会话过程可以分成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-CHA)P
与CHAP相类似,MS-CHA也是一种加密验证机制。
同CHAP-样,使用MS-CHAP时,NAS会向远程客户发送一个含有会话ID和任意生成的挑战字串的挑战口令。
远程客户必须返回用户名以及经过MD4合希算法加密的挑战字串,会话ID和用户口令的MD4合希值。
采用这种方式服务器端将只存储经过哈希算法加密的用户口令而不是明文口令,这样就能够提供进一步的安全保障。
此外,MS-CHA同样支持附加的错误
编码,包括口令过期编码以及允许用户自己修改口令的加密的客户-服务器
(client-server)附加信息。
使用MS-CHAP客户端和NAS双方各自生成一个用于随后数据加密的起始密钥。
MS-CHA使用基于MPPEI勺数据加密,这一点非常重要,可以解释为什么启用基于MPPE勺数据加密时必须进行MS-CHA验证。
在第2阶段PPP链路配置阶段,NAS收集验证数据然后对照自己的数据库或中央验证数据库服务器(位于NT主域控制器或远程验证用户拨入服务器)验证数据的有效性。
阶段3:
PPP回叫控制(callbackcontrol)
微软设计的PPP包括一个可选的回叫控制阶段。
该阶段在完成验证之后使用回叫控制协议(CBCP如果配置使用回叫,那么在验证之后远程客户和NAS之间的连接将会被断开。
然后由NAS使用特定的电话号码回叫远程客户。
这样可以进一步保证拨号网络的安全性。
NAS只支持对位于特定电话号码处的远程客户进行回叫。
阶段4:
调用网络层协议
在以上各阶段完成之后,PPP将调用在链路创建阶段(阶段1选定的各种网络控制协议(NCP).例如,在该阶段IP控制协议(IPCP)可以向拨入用户分配动态地址。
在微软的PPP方案中,考虑到数据压缩和数据加密实现过程相同,所以共同使用压缩控制协议协商数据压缩(使用MPPC和数据加密(使用MPP)
数据传输阶段
一旦完成上述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结合了PPTF和L2F协议。
设计者希望L2TP能够综合PPTF和L2F的优势。
L2TP是一种网络层协议,支持封装的PPP桢在IP,X.25,桢中继或ATM等的网络上进行传送。
当使用IP作为L2TP的数据报传输协议时,可以使用L2TP作为Internet网络上的隧道协议。
L2TP还可以直接在各种WA媒介上使用而不需要使用IP传输层。
草案RFC“第2层隧道协议”对L2TP进行了说明和介绍。
该文档于1998年1月被提交至IETF。
可以在以下网站[url]http:
//www.ietf.org[/url][url]http:
//www.ietf.org[/url]获得草案拷贝。
IP网上的L2TP使用UDF和一系列的L2TP消息对隧道进行维护。
L2TP同样使用UDF将L2TP协议封装的PPP桢通过隧道发送。
可以对封装PPP桢中的负载数据进行加密或压缩。
图8所示为如何在传输之前组装一个L2TP数据包。
PPTP与L2TP
PPTF和L2TP都使用PPP协议对数据进行封装,然后添加附加包头用于数据在互
联网络上的传输。
尽管两个协议非常相似,但是仍存在以下几方面的不同:
1.PPTP要求互联网络为IP网络oL2TP只要求隧道媒介提供面向数据包的点对点的连接。
L2TP可以在IP(使用UDP,桢中继永久虚拟电路(PVCs),X.25虚拟电路(VC®或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传输。
这只是为创建隧道所做的初步准备,并不属于隧道协议。
强制隧道
目前,一些商家提供能够代替拨号客户创建隧道的拨号接入服务器。
这些能够为客户端计算机提供隧道的计算机或网络设备包括支持PPTP协议的前端处理器(FEP,
支持L2TP协议的L2TP接入集线器(LAC或支持IPSec的安全IP网关。
本文将主要以FEP为例进行说明。
为正常的发挥功能,FEP必须安装适当的隧道协议,同时必须能够当客户计算机建立起连接时创建隧道。
以Internet为例,客户机向位于本地ISP的能够提供隧道技术的NAS发出拨号呼叫。
例如,企业可以与某个ISP签定协议,由ISP为企业在全国范围内设置一套FER这些FEP可以通过Internet互联网络创建一条到隧道服务器的隧道,隧道服务
器与企业的专用网络相连。
这样,就可以将不同地方合并成企业网络端的一条单一的
Internet连接。
因为客户只能使用由FEP创建的隧道,所以称为强制隧道。
一旦最初的连接成功,所有客户端的数据流将自动的通过隧道发送。
使用强制隧道,客户端计算机建立单一的PPP连接,当客户拨入NAS寸,一条隧道将被创建,所有的数据流自动通过该隧道路由。
可以配置FEP为所有的拨号客户创建到指定隧道服务器的隧道,也可以配置FEP基于不同的用户名或目的地创建不同的隧道。
自愿隧道技术为每个客户创建独立的隧道。
FEP和隧道服务器之间建立的隧道可以被多个拨号客户共享,而不必为每个客户建立一条新的隧道。
因此,一条隧道中可能会传递多个客户的数据信息,只有在最后一个隧道用户断开连接之后才终止整条隧道。
高级安全功能
虽然Internet为创建VPN提供了极大的方便,但是需要建立强大的安全功能以确保企业内部网络不受到外来攻击,确保通过公共网络传送的企业数据的安全。
对称加密与非对称加密(专用密钥与公用密钥)
对称加密,或专用密钥(也称做常规加密)由通信双方共享一个秘密密钥。
发送方在进行数学运算时使用密钥将明文加密成密文。
接受方使用相同的密钥将密文还原成明文。
RSARC4算法,数据加密标准(DES,国际数据加密算法(IDEA)以及Skipjack加密技术都属于对称加密方式。
非对称加密,或公用密钥,通讯各方使用两个不同的密钥,一个是只有发送方知道的专用密钥,另一个则是对应的公用密钥,任何人都可以获得公用密钥。
专用密钥和公用密钥在加密算法上相互关联,一个用于数据加密,另一个用于数据解密。
公用密钥加密技术允许对信息进行数字签名。
数字签名使用发送发送一方的专用密钥对所发送信息的某一部分进行加密。
接受方收到该信息后,使用发送方的公用密钥解密数字签名,验证发送方身份。
证书
使用对称加密时,发送和接收方都使用共享的加密密钥。
必须在进行加密通讯之前,完成密钥的分布。
使用非对称加密时,发送方使用一个专用密钥加密信息或数字签名,接收方使用公用密钥解密信息。
公用密钥可以自由分布给任何需要接收加密信息或数字签名信息的一方,发送方只要保证专用密钥的安全性即可。
为保证公用密钥的完整性,公用密钥随证书一同发布。
证书(或公用密钥证书)是一种经过证书签发机构(CA数字签名的数据结构。
CA使用自己的专用密钥对证书进行数字签名。
如果接受方知道CA的公用密钥,就可以证明证书是由CA签发,因此包含可靠的信息和有效的公用密钥。
总之,公用密钥证书为验证发送方的身份提供了一种方便,可靠的方法。
IPSec可以选择使用该方式进行端到端的验证。
RAS可以使用公用密钥证书验证用户身份。
扩展验证协议(EAP)
如前文所述,PPP只能提供有限的验证方式。
EAP是由IETF提出的PPP协议的扩展,允许连接使用任意方式对一条PPP连接的有效性进行验证。
EAP支持在一条连接的客户和服务器两端动态加入验证插件模块。
交易层安全协议(EAP-TLS)
EAP-TLS已经作为提议草案提交给IETF,用于建立基于公用密钥证书的强大的验证方式。
使用EAP-TLS客户向拨入服务器发送一份用户方证书,同时,服务器把服务器证书发送给客户。
用户证书向服务器提供了强大的用户识别信息;服务器证书保证用户已经连接到预期的服务器。
用户方证书可以被存放在拨号客户PC中,或存放在外部智能卡。
无论那种方式,如果用户不能提供没有一定形式的用户识别信息(PIN号或用户名和口令),就无法访问证书。
1.4实施过程指导
1.4.1配置IPSecVPN
第一步:
路由器基本配置
R1(config)#
R1(config)#interfacefastEthernet0/0
R1(config-if)#ipaddress101.1.1.1255.255.255.252
R1(config-if)#noshutdown
R1(config-if)#exit
R1(config)#interfaceLoopback0
R1(config-if)#ipaddress10.1.1.1255.255.255.0
R1(config-if)#noshutdown
R1(config-if)#exit
R2(config)#interfacefastEthernet0/0
R2(config-if)#ipaddress101.1.1.2255.255.255.252
R2(config-if)#noshutdown
R2(config-if)#exit
R2(config)#interfaceLoopback0
R2(config-if)#ipaddress10.1.2.1255.255.255.0
R2(config-if)#nosh
R2(config-if)#end
第二步:
配置默认路由
R1(config)#iproute0.0.0.00.0.0.0101.1.1.2
R2(config)#iproute0.0.0.00.0.0.0101.1.1.1
第三步:
配置IPSecVPN
R1(config)#cryptoisakmppolicy10
R1(isakmp-policy)#authenticationpre-share
R1(isakmp-policy)#hashmd5
R1(isakmp-policy)#group2
R1(isakmp-policy)#exit
R1(config)#cryptoisakmpkey0ruijieaddress101.1.1.2
R1(config)#cryptoipsectransform-setvpnah-md5-hmacesp-desesp-md5-hmac
R1(cfg-crypto-trans)#modetunel
R1(config)#cryptomapvpnmap10ipsec-isakmp
R1(config-crypto-map)#setpeer101.1.1.2
R1(config-crypto-map)#settransform-setvpn
R1(config-crypto-map)#matchaddress110R1(config)#cryptomapvpnmap110ipsec-isakmp
R2(config)#cryptoisakmppolicy10
R2(isakmp-policy)#authenticationpre-share
R2(isakmp-policy)#hashmd5
R2(isakmp-policy)#group2
R2(config)#cryptoisakmpkey0ruijieaddress101.1.1.2
R2(config)#cryptoipsectransform-setvpnah-md5-hmacesp-desesp-md5-hmac
R2(cfg-crypto-trans)#modetunel
R2(config)#cryptomapvpnmap10ipsec-isakmp
R2(config-crypto-map)#setpeer101.1.1.1
R2(config-crypto-map)#settransform-setvpn
R2(config-crypto-map)#matchaddress110
第四步:
定义感兴趣数据流及应用VPN
R1(config)#access-listextended110permitip10.1.1.00.0.0.25510.1.2.00.0.0.255
R1(config)#interfaceFastEthernet0/0
R1(config-if)#cryptomapvpnmap
R2(config)#access-listextended110permitip10.1.2.00.0.0.25510.1.1.00.0.0.255
R2(config)#interfaceFastEthernet0/0
R2(config-if)#cryptomapvpnmap
1.4.2验证IPSecVPN
R1#ping
Protocol[ip]:
TargetIPaddress:
10.1.2.1
Repeatcount[5]:
Datagramsize[100]:
Timeoutinseconds[2]:
Extendedcommands[n]:
y
Sourceaddress:
10.1.1.1
TimetoLive[1,64]:
Typeofservice[0,31]:
DataPattern[0xABCD]:
0xabcd
Sending5,100-byteICMPEchoesto10.1.2.1,timeoutis2seconds:
.!
!
!
!
Successrateis80percent(4/5),round-tripmin/avg/max=1/1/1ms
R1#showcryptoipsecsa
Interface:
FastEthernet0/0
Cryptomaptag:
vpnmap,localaddr101.1.1.1mediamtu1500itemtype:
static,seqno:
10,id=32
localident(addr/mask/prot/port):
(10.1.1.0/0.0.0.255/0/0))
remoteident(addr/mask/prot/port):
(10.1.2.0/0.0.0.255/0/0))
PERMIT
#pktsencaps:
4,#pktsencrypt:
4,#pktsdigest8
#pktsdecaps:
4,#pktsdecrypt:
4,#pktsverify8
#senderrors0,#recverrors0
Inbou
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 路由器 实现 VPN 配置