IPSEC
是一套比较完整成体系的
×××
技术,它规定了一系列的协议标准。如果不深入探究
IPSEC
的过于详细的内容,我们对于
IPSEC
大致按照以下几个方面理解。
1. 为什么要导入 IPSEC 协议
导入 IPSEC 协议,原因有 2 个,一个是原来的 TCP/IP 体系中间,没有包括基于安全的设计,任何人,只要能够搭入线路,即可分析所有的通讯数据。 IPSEC 引进了完整的安全机制,包括加密、认证和数据防篡改功能。
1. 为什么要导入 IPSEC 协议
导入 IPSEC 协议,原因有 2 个,一个是原来的 TCP/IP 体系中间,没有包括基于安全的设计,任何人,只要能够搭入线路,即可分析所有的通讯数据。 IPSEC 引进了完整的安全机制,包括加密、认证和数据防篡改功能。
另外一个原因,是因为
Internet
迅速发展,接入越来越方便,很多客户希望能够利用这种上网的带宽,实现异地网络的的互连通。
IPSEC
协议通过包封装技术,能够利用
Internet
可路由的地址,封装内部网络的
IP
地址,实现异地网络的互通。
2.
包封装协议
设想现实一种通讯方式。假定发信和收信需要有×××(成年人才有),儿童没有×××,不能发信收信。有 2 个儿童,小张和小李,他们的老爸是老张和老李。现在小张和小李要写信互通,怎么办?
设想现实一种通讯方式。假定发信和收信需要有×××(成年人才有),儿童没有×××,不能发信收信。有 2 个儿童,小张和小李,他们的老爸是老张和老李。现在小张和小李要写信互通,怎么办?
一种合理的实现方式是:小张写好一封信,封皮写上
"
小张
-->
小李
",
然后给他爸爸,老张写一个信封,写上
“
老张
-->
老李
”
,把前面的那封信套在里面,发给老李,老李收到信以后,打开,发现这封信是给儿子的,就转给小李了。小李回信也一样,通过他父亲的名义发回给小张。
这种通讯实现方式要依赖以下几个因素:
* 老李和老张可以收信发信
* 小张发信,把信件交给老张。
* 老张收到儿子的来信以后,能够正确的处理(写好另外一个信封),并且重新包装过的信封能够正确送出去。
* 另外一端,老李收到信拆开以后,能够正确地交割小李。
* 反过来的流程一样。
把信封的收发人改成 Internet 上的 IP 地址,把信件的内容改成 IP 的数据,这个模型就是 IPsec 的包封装模型。小张小李就是内部私网的 IP 主机,他们的老爸就是 ××× 网关,本来不能通讯的两个异地的局域网,通过出口处的 IP 地址封装,就可以实现局域网对局域网的通讯。
这种通讯实现方式要依赖以下几个因素:
* 老李和老张可以收信发信
* 小张发信,把信件交给老张。
* 老张收到儿子的来信以后,能够正确的处理(写好另外一个信封),并且重新包装过的信封能够正确送出去。
* 另外一端,老李收到信拆开以后,能够正确地交割小李。
* 反过来的流程一样。
把信封的收发人改成 Internet 上的 IP 地址,把信件的内容改成 IP 的数据,这个模型就是 IPsec 的包封装模型。小张小李就是内部私网的 IP 主机,他们的老爸就是 ××× 网关,本来不能通讯的两个异地的局域网,通过出口处的 IP 地址封装,就可以实现局域网对局域网的通讯。
引进这种包封装协议,实在是有点不得已。理想的组网方式,当然是全路由方式。任意节点之间可达(就像理想的现实通讯方式是任何人之间都可以直接写信互通一样)。
Internet
协议最初设计的时候,
IP
地址是
32
位,当时是很足够了,没有人能够预料到将来
Internet
能够发展到现在的规模(相同的例子发生在电信短消息上面,由于
160
字节的限制,很大地制约了短消息的发展)。按照
2
的
32
次方计算,理论上最多能够容纳
40
亿个左右
IP
地址。这些
IP
地址的利用是很不充分的,另外大约有
70
%左右的
IP
地址被美国分配掉了(谁让人家发明并且管理
Internet
呢?)所以对于中国来说,可供分配的
IP
地址资源非常有限。
既然
IP
地址有限,又要实现异地
lan-lan
通讯,包封包,自然是最好的方式了。
3.
安全协议(加密)
依然参照上述的通讯模型。
假定老张给老李的信件要通过邮政系统传递,而中间途径有很多好事之徒,很想偷看小张和小李(小张小李作生意,通的是买卖信息)通讯,或者破坏其好事。
解决这个问题,就要引进安全措施。安全可以让小李和小张自己来完成,文字用暗号来表示,也可以让他们的老爸代劳完成,写好信,交给老爸,告诉他传出去之前重新用暗号写一下。
依然参照上述的通讯模型。
假定老张给老李的信件要通过邮政系统传递,而中间途径有很多好事之徒,很想偷看小张和小李(小张小李作生意,通的是买卖信息)通讯,或者破坏其好事。
解决这个问题,就要引进安全措施。安全可以让小李和小张自己来完成,文字用暗号来表示,也可以让他们的老爸代劳完成,写好信,交给老爸,告诉他传出去之前重新用暗号写一下。
IPSEC
协议的加密技术和这个方式是一样的,既然能够把数据封装,自然也可以把数据变换,只要到达目的地的时候,能够把数据恢复成原来的样子就可以了。这个加密工作在
Internet
出口的
×××
网关上完成。
4.
安全协议(数据认证)
还是以上述通讯模型为例,仅仅有加密是不够的。
把数据加密,对应这个模型中间,是把信件的文字用暗号表示。
还是以上述通讯模型为例,仅仅有加密是不够的。
把数据加密,对应这个模型中间,是把信件的文字用暗号表示。
好事之徒无法破解信件,但是可以伪造一封信,或者胡乱把信件改一通。这样,信件到达目的地以后,内容就面目全非了,而且收信一方不知道这封信是被修改过的。
为了防止这种结果,就要引入
数据防篡改
机制。万一数据被非法修改,能够很快识别出来。这在现实通讯中间可以采用类似这样的算法,计算信件特征(比如统计这封信件的笔划、有多少字),然后把这些特征用暗号标识在信件后面。收信人会检验这个信件特征,由于信件改变,特征也会变。所以,如果修改人没有暗号,改了以后,数据特征值就不匹配了。收信人可以看出来。
实际的
IPSEC
通讯的数据认证也是这样的,使用
md5
算法计算包文特征,报文还原以后,就会检查这个特征码,看看是否匹配。证明数据传输过程是否被篡改。
5.
安全协议(身份认证)
还是假定小张小李通讯模型。
由于老张和老李不在一个地方,他们互相不能见面,为了保证他们儿子通讯的安全。老张和老李必须要相互确认对方是否可信。这就是身份认证问题。
还是假定小张小李通讯模型。
由于老张和老李不在一个地方,他们互相不能见面,为了保证他们儿子通讯的安全。老张和老李必须要相互确认对方是否可信。这就是身份认证问题。
假定老李老张以前见过面,他们事先就约定了通讯暗号,比如
1234567890
对应
abcdefghij
,
那么写个
255
,对应就是一个
bee
。
常见的
×××
身份认证可以包括预共享密钥,通讯双方实现约定加密解密的密码,直接通讯就可以了。能够通讯就是朋友,不能通讯就是坏人,区分很简单。
其他复杂的身份认证机制包括证书(电子证书比如
x509
之类的),比较罗里罗嗦,这里就不具体展开了,怕有兄弟看了打瞌睡。如果需要,可以找我要更具体的技术白皮书以及相关的身份认证文档。
如果有身份认证机制,密钥的经常更换就成为了可能。
6.
其他
解决了上述的几个问题,基本可以保证 ××× 通讯模型能够建立起来了。
但是并不完美,这是最简单的 ××× 。即通过对端两个静态的 IP 地址,实现异地网络的互联。美国的很多 ××× 设备就作到这一级,因为美国 IP 地址充裕,分配静态 IP 地址没有问题。苦的是我等中国客户, 2 端都需要静态 IP 地址,相当于 2 根 Internet 专线接入。
××× 要在中国用起来,还要解决一堆的相关问题。。
解决了上述的几个问题,基本可以保证 ××× 通讯模型能够建立起来了。
但是并不完美,这是最简单的 ××× 。即通过对端两个静态的 IP 地址,实现异地网络的互联。美国的很多 ××× 设备就作到这一级,因为美国 IP 地址充裕,分配静态 IP 地址没有问题。苦的是我等中国客户, 2 端都需要静态 IP 地址,相当于 2 根 Internet 专线接入。
××× 要在中国用起来,还要解决一堆的相关问题。。
IPSEC
通过包封装包的方法,通过
Internet
建立了一个通讯的隧道,通过这个通讯的隧道,就可以建立起网络的连接。但是这个模型并非完美,仍然有很多问题需要解决。
在讲述其他问题以前,我们对
×××
定义几个概念。
×××
节点:一个
×××
节点,可能是一台
×××
网关,也可能是一个客户端软件。在
×××
组网中间,属于组网的一个通讯节点。它应该能够连接
Internet
,有可能是直接连接,比如
adsl
、电话拨号等等,也可能是通过
nat
方式,例如:小区宽带、
cdma
上网、铁通线路等等。
×××
隧道:在两个
***
节点之间建立的一个虚拟链路通道。两个设备内部的网络,能够通过这个虚拟的数据链路到达对方。与此相关的信息是当时两个
×××
节点的
IP
地址,隧道名称、双方的密钥。
隧道路由:一个设备可能和很多设备建立隧道,那么就存在一个隧道选择的问题,即到什么目的地,走哪一个隧道?
用前面的通讯模型来说,老李老张就是隧道节点,他们通过邮政系统建立的密码通讯关系,就是一个数据隧道,小张和小李把信发给他们老爸的时候,他们老爸要作出抉择,这封信怎么封装,封装以后送给谁。假如还有一个老王和他们的儿子,也要通讯,这时候隧道路由就比较好理解了。送给小王的数据,就封装给老王,送给小李的数据,就封装发给老李。如果节点非常多,那么这个隧道路由就会比较复杂。
理解了以上的问题,我们就知道,
ipsec
要解决的问题其实,可以分为以下几个步骤:
l 找到对方 *** 节点设备,如果对方是动态 IP 地址,那么必须能够通过一种有效途径能够及时发现对方 IP 地址的变化。按照通讯模型,就是老李老张如果经常搬家的话,必须有一个有效的机制,能够及时发现老李老张地址的变化。
l 建立隧道,建立隧道说起来简单,作起来不容易。如果两个设备都有合法的公网 IP ,那么建立一个隧道是比较容易的。如果一方在 nat 之后,那就比较罗嗦了。一般通过内部的 *** 节点发起一个 udp 连接,再封装一次 ipsec ,送到对方,因为 udp 可以通过防火墙进行记忆,因此通过 udp 再封装的 ipsec 包,可以通过防火墙来回传递。
l 建立隧道以后,就确定隧道路由,即到哪里去,走哪个隧道。很多 ××× 隧道配置的时候,就定义了保护网络,这样,隧道路由就根据保护的网络关系来决定。但是这丧失了一定的灵活性。
l 找到对方 *** 节点设备,如果对方是动态 IP 地址,那么必须能够通过一种有效途径能够及时发现对方 IP 地址的变化。按照通讯模型,就是老李老张如果经常搬家的话,必须有一个有效的机制,能够及时发现老李老张地址的变化。
l 建立隧道,建立隧道说起来简单,作起来不容易。如果两个设备都有合法的公网 IP ,那么建立一个隧道是比较容易的。如果一方在 nat 之后,那就比较罗嗦了。一般通过内部的 *** 节点发起一个 udp 连接,再封装一次 ipsec ,送到对方,因为 udp 可以通过防火墙进行记忆,因此通过 udp 再封装的 ipsec 包,可以通过防火墙来回传递。
l 建立隧道以后,就确定隧道路由,即到哪里去,走哪个隧道。很多 ××× 隧道配置的时候,就定义了保护网络,这样,隧道路由就根据保护的网络关系来决定。但是这丧失了一定的灵活性。
所有的
ipsec ×××
展开来讲,实现的无非就是以上几个要点,具体各家公司,各有各的做法。但是可以肯定,目前在市场销售的
×××
,肯定都已经解决了以上的问题。
第一个问题
怎样找到
***
节点设备。
假如设备都是动态拨号方式的话,那么一定需要一个合适的静态的第三方来进行解析。相当于两个总是不停搬家的人,要合适找到对方,一定需要一个大家都认识的朋友,这个朋友不搬家,两个人都能够联系上他。
静态的第三方,常见的有
3
种实现方式:
通过网页,这是深信服公司发明的一种技术,通过
Web
页解析
ip
地址。大家可以登录一下
[url]http://www.123cha.com/[/url]
,就可以查找到当前的
IP
地址。因此,动态的设备,可以通过这种方式,把自己当前的
IP
地址提交上去。其他设备可以通过网页再查询回来。这样,设备之间就可以互相通过这个网页找到。因为网页是相对固定的,所以这种方式能够很有效地解决这个问题。这种方式能够有效地分散集中认证的风险,而且很容易实现备份,属于比较巧妙的一种解决方案。当然,对于
Web
页可能存在比较多的***,因此,要注意安全防范。
通过一个集中的服务器,实现统一解析,然后给用户进行分组。每个
***
设备只能看到同组的其他设备,不能跨组访问。也可以通过目录服务器实现。这种方式适合集中式的
×××
,在企业总部部署服务器,实现全局设备的统一认证和管理。它不太适合零散用户的认证,因为存在一个信任问题,客户会置疑管理服务器如果出现了问题,有可能其他设备就能够连接到自己的
***
域里面。这种大型的集中
***
管理软件,在很多国内外的
***
厂商都有专门的设备或软件,它除了能够进行动态
IP
地址解析,还能够实现在线认证等等功能。如果管理中心比较职能的话,可以集中制订通讯策略,下面的
***
设备配置参数比较少。
还有一种方式,是
DDNS
,即动态域名。动态域名是一种相对比较平衡的技术。
***
设备拨号以后,把自己当前的
IP
地址注册给一级域名服务器,并且更新自己的二级域名
IP
地址,
internet
其他用户,通过这个二级域名就可以查找到它。例如:动态域名服务器的名称是
99ip.net
,是
abc. 99ip.net
,则
***
设备通过一个软件,提交给服务器,把
abc.99ip.net
,漂移成当前的
IP
地址。但是,有时也会遇到
dns
缓存问题。
***
厂家如果自身提供
ddns
服务的话,就可以通过内部协议,把查询速度加快,并且避免
dns
缓冲带来的问题。
以上讲述了三种动态
IP
地址的解析方法,国内一般厂家提供的无外乎这几种方法。如果再有比较偏门的技术,也许就不是主流技术了。
解决了动态
IP
地址问题,按照之前的通讯模型,不考虑
×××
设备很多的情况,就可以组网。因此,一旦这种技术被越来越多的厂家掌握,基于
IPsec ***
设备和软件是一定会价格下降的。
It
技术从朝阳变成夕阳就是转眼之间的事情。
第二个问题
隧道如何建立
解决了 Ip 地址动态寻址的问题,现在来说一下 Nat 穿越的问题。我们知道, Udp 和 TCP 是可以穿越防火墙的。直接的 IPsec 封装,不能穿越防火墙,因为防火墙需要更改端口信息,这样回来的数据包,才能转到正确的内部主机。用 UDP 显然比较合适,因为使用 tcp 的话,不仅三次握手占据时间很长,而且还有来回的确认。而实际上,这些工作属于 ipsec 内部封装的报文要干的事情,放在这里完成是不合适的。因此,用 udp 来封装 ipsec 报文,以穿越 nat ,几乎是唯一可以选择的方案。
解决了 Ip 地址动态寻址的问题,现在来说一下 Nat 穿越的问题。我们知道, Udp 和 TCP 是可以穿越防火墙的。直接的 IPsec 封装,不能穿越防火墙,因为防火墙需要更改端口信息,这样回来的数据包,才能转到正确的内部主机。用 UDP 显然比较合适,因为使用 tcp 的话,不仅三次握手占据时间很长,而且还有来回的确认。而实际上,这些工作属于 ipsec 内部封装的报文要干的事情,放在这里完成是不合适的。因此,用 udp 来封装 ipsec 报文,以穿越 nat ,几乎是唯一可以选择的方案。
用
udp
穿越
nat
防火墙,这只解决了问题的一半,因为这要求至少有一方处于
Internet
公网上面。有可路由的
IP
地址。而有时会发生两个
***
节点都在
nat
之后的情景,这只能通过第三方转发来完成。即两个设备都可以与第三方设备互通,第三方设备为双方进行转发。这个可以通过之前的模型解析,老张老李不能直接通讯,他们都可以与老王通讯,老王就可以在中间进行转发。凡是小李小张的通讯,交给他们老爸以后,老王最后再进行转交。这是隧道路由的概念就很清晰了,不能一个隧道直接到达,可以在几个隧道之间转发。
所以,
IPsec ***
并不神秘。所有核心的工作无非就是围绕以下几个方面展开:
l 如何找到与本 ××× 节点相关的其他节点。
l 协商出一个可以通讯的隧道。如果是 nat 之后,应该怎么处理。
l 建立隧道路由表,确定不同的目标地址,走不同的隧道。
l 如何找到与本 ××× 节点相关的其他节点。
l 协商出一个可以通讯的隧道。如果是 nat 之后,应该怎么处理。
l 建立隧道路由表,确定不同的目标地址,走不同的隧道。
假定以上的问题都得到了解决,通过某种方式,动态
IP
地址的
×××
节点可以相互找到对方,并且能够建立隧道,因此也能够实现隧道路由通讯。是不是一个完整的
×××
就能够实现了呢??
答案仍然是否,解决了以上问题,并不代表一个很好用的
×××
产品,仍然有其他很多问题。之后的问题是围绕着复杂性展开的,简单的原理实现之后,剩下的工作就是要解决掉全部相关的边缘问题。才能够实现一个好用的东西。能够用是一回事,好用是另外一回事。