阅读:3746回复:8
关于ipsec vpn的思考
既然谈到ipsec,虽然我目前已经不对此太感兴趣了――为mm做核心
木马做得我每天都在想木马的事情;),但是还是保持跟踪着发展方 向。顺便就多说两句。 freeswan的pluto支持的许多地方不尽如人意,例如nat穿越 就是一个大问题,所有的补丁都不完全解决问题,一个问题 是无法解决nat内部server,另一个问题是无法解决负载均衡 的nat的问题。为了解决这些垃圾问题,pluto代码我真是差点 改到吐血――而为了支持双nat对穿,没有manager又不行,这 有没有标准,我又不希望失去基本的兼容性。我不知道是否有 人和我一样郁闷过,对于负载均衡的nat,要处理那种floating port(4500)的情况很有点费劲。我又要发牢骚了,如果不是因为 所谓的ike-friend nat的出现,也不至于说需要有一个floating port 前面说的是1.9x版本。 下面说说新出来的2.0版本。 2.0版本极大的强化了dnssec的支持,但是同时在我看来―― 有点偏离主题了,因为目前为止支持dnssec的只有freeswan。 而通过dnssec还只是一个draft,目前我看不到变成rfc 的希望。 令人失望的是,freeswan从来不考虑真正的需要,例如一个 能够工作的policy manage server,更好地解决nat的问题。 还有一个问题很基本,就是全动态ip的问题――没有manager 是不可能的。 关于nat-t,draft都到0.5了,我认为成为rfc的可能性比较 大了。特别是注意到这个draft是ms和cisco联手推出的。 netscreen支持的只是0.1――到去年11月为止――那时候 最新的是0.3。这反应出大公司的反应能力比较慢,同时证明 这一点的是,chkpoint那时候还不支持全动态ip的策略,即 便有manager的情况下。同样,那时候chkpoint也对nat支持 得不太好。我认为这应该是国内有自主开发实力――而不是 只能在freeswan上做个界面的那种的厂商的机会。 考虑到国内nat部署如此普及,这个问题解决不好,我认为 是影响vpn部署的一个重大因素。而幸运的是,国外并没有 这么多的nat,那里ip并不缺乏,所以他们并不特别重视这个 问题。这是一个重大的突破点。 可惜得是,国内大多数厂商都只能基于freeswan改来改去。 自己连读懂freeswan的能力都不具备,更不用说修改,移植 了。 关于policy manger,各种复杂不复杂的draft不少了,但是 我认为不会有一个成为标准。 两方面的考虑:一方面是目前 作为vpn巨鄂的chkpoint,netscreen都推出了自己的manager, 虽然似乎在国内用得很少――同时更让我觉得有趣的是,国内 部署vpn,几乎都用preshared key认证dh,即便他们买的是 netscreen/chkpoint。这些东西都是undocument。我去年11月 的安全展会上要求netscreen公开他们的manager协议。那些 老外觉得不可思议,认为要求过分。就是说,这帮人并没有 意识到这是重要的。而且他们似乎并不认为不同厂商的产品 互联是重要的。 另一方面,我认为ipsec本身的许多问题让他们不会急于制定 这样的标准。现在还有ipsec 的mib库没有制定标准,还有 nat-t的问题,等等等等。 此外,关于x509,我认为倒不是目前最重要的问题,我认为 国内要真的部署pki,还有一段路要走。而且对于大多数企业 来说,即便是大企业,pki也是一种消费不起的奢侈。 最后,但是并非不重要,我想谈论一个问题是vpn和firewall 配合的问题。让我吐血的是,居然有很多厂商都不重视。 netsrceen和chkpoint不重视也就罢了,因为他们的fw和vpn 都是一体的,而且也许他们够牛,能够让他们的用户撤掉 以前买的fw。 目前ieee小组似乎有追求完美的倾向,不过考虑到以前的 那些垃圾协议给大家造成了多少伤害我就认为慎重一点的确 是必要的,那些垃圾协议包括ftp,nat等等等等,不一而足。 想必任何一个实现过nat的兄弟都对ftp的支持感到过郁闷吧? 这种协议还多的是。ftp不过是最有名的一种而已。nat没有 具体的标准,结果实现只取决于创意,我知道的nat实现 就有n多种,如果结合具体的os上的实现,更是五花八门, sygate和wingate的nat实现就截然不同。至于syagate和 linux2.2地实现也不同,linux2.2和2.4的又不同。我常常 除了需要分析这种nat到底是何种转换格式之外,还要分析 这个nat到底实现在核心哪个部分。 ========================================================= 以上是我近些年对vpn技术和市场的跟踪,实现和观察,以及 思考。 就我个人而言,我最关心的问题是连通性――不管什么nat 都能连通;其次是兼容性――要能够和不同厂商的产品互联, 当然,那些基于manager的功能不可能指望,但是至少在 没有nat,双静态ip的情况下应该能够完美的互联起来――其实 我觉得1静态+1动态应该也能互联。甚至1静态+1动态nat应该 也能够互联,或者说至少应该跟大部分国外真正实现ike的 厂商的产品互联。 国内玩假的ipsec得太多了,我举出一个例子来吧:天融信 作为一个这么大的安全公司,居然玩假的ipsec,让我失望ing。 有些玩真的却只是简单的freeswan,还是让我失望ing。 哼哼,倚天不出,谁与争锋!!! |
|
|
沙发#
发布于:2003-05-27 13:29
――――――――――――――――――――――――――――――――
令人遗憾,我特意新开了一个帖子的主题,但是大家还是在这里面 re。 这里来往的几个也许都对ipsec vpn感到关注,也许还能深入的谈谈 老mo把这个话题转过去吧,或者做个链接什么的。就是关于ipsec vpn的讨论。 ―――――――――――――――――――――――――――――――――― 怎么说呢? 我只能说,你对大家的想法理解的还不深。 你把题目改成“关于。。。。的源码” 这立刻就变成一个热贴了。。 ;) “关于。。。。的思考”感兴趣的人会少一点吧? |
|
|
板凳#
发布于:2003-05-27 13:38
――――――――――――――――――――――――――――――――――――――
看来你需要找本人月神话来看看 还在迷信蠢驴编程? ―――――――――――――――――――――――――――――――――――― 就在前些天,我的一个同学做博士开题报告,也把你说的那个什么神话,当作参考书列上去了。刚好老师也没读过,因此被质疑。我也没读过这书,所以在下面窃笑:看来他要被抓住了。。。 既然你说要看,看来是得看看啦。 |
|
|
地板#
发布于:2003-06-02 15:04
我想不是大家不想更多的考虑VPN的技术.这里面还有一个时间精力的问题。在公司不同于在学校好研究所,一般的公司(还没有走到技术研究-》开发-》推广-》维护这样一个良性循环的公司)那个不是时间紧任务急?而且市场的需求千奇百怪,应接不暇。对于技术本身的关注往往会排在实现实现或者说能够应用之后。
我还没有怎么研究过check point的VPN,不过通过一个第三方服务器来解决nat的问题这个应该是解决nat的一个通用的思路,似乎也是唯一的解决方法。 在目前的阶段,VPN的互通的需求似乎还不是很迫切,而且要做到互通也是在大家都按照标准的方式来做,不然互通几乎是不可能的(那样要浪费掉太多的精力)。 现在似乎是安全这块的门槛低了,大家都进入了,一哄而上,就象ERP一样,那里都有ERP。 老胡现在有MM了,有追求了吧,呵呵。祝你好运! |
|
|
地下室#
发布于:2003-06-11 09:33
对于freeswan的实现,我看过一些,后来的出的补丁中已经跟进了NAT的支持,但在实现上的确仍然不是很完美。
我认同斑竹的话,想不到在这里会有那么多研究IPSEC的高手,真的感到很欣慰!!!虽然IPSEC本身还有如此大的缺陷,而我们似乎也很难看到部署IPSEC会给我们带来的希望。 我freeswan的IPSEC实现不是很了解,至少,在核心是这样的,但是,我却在windows上实现了IPSEC的核心,不论在98和2000中,这个实现都显得如此的复杂,当然如果你做的不是产品,而只是一些研究那么就另当别论,而这其中,现阶段,还不支持NAT,也就是说在国内的环境中并没有实际部署的优势。 我很赞同斑竹的意见,任何产品,保持最大的兼容性应该是最为重要的,我在做这个客户端的时候,能够深刻的体会到这一点,我们的公司不大,没有NS和Checkpoint那么牛,人家可以不重视和我们连,而我们却一定要保持和它的兼容。 使用NDIS的IM实现这个东西,性能上倒是不差的,同等条件下,甚至超过了VPN网关!也许,我们在windows上开发IPSEC的人都应该注意到这一点,因为我们可以将这个产品部署在以PC作为网关的小型公司作为他们的网关,当然,这首先要求我们必须要有足够强大的兼容性和NAT实现。 下一步,我将实现和FW的合成,这个东西本来就牵涉到一些很严重的问题,在网关上,ACL的实现体现了这种复杂性并且导致了这种复杂性,在这个上面我还没有体会。 考虑到以后的开发,你必须设计一个良好的系统,至少必须具备较强的可扩展性,这导致了系统的复杂性,不过,总是比freeswan要好,那套代码,看起来和改起来都是那么的让人头大。。。。。 最后给斑竹提个小小的要求,希望斑竹能够每周有一个固定时间前来这个版面,讨论现在的新的技术,我们不能总是做技术跟进,我们需要一个高瞻远瞩的人,看到一个超越的机会 |
|
5楼#
发布于:2003-06-12 15:23
对于freeswan的实现,我看过一些,后来的出的补丁中已经跟进了NAT的支持,但在实现上的确仍然不是很完美。 你的客户端是如何实现的?结构怎么样?你们的网关呢??? 客户端的整个IPSEC都是做在一个驱动里面还是分开的? 98下呢?你移植了passthru???我到是觉得在98下移植passthru并不是必须的,也未必是最好的选则,除非你要不断的iocalldriver。 freeswan的代码看着确实头大,我是不喜欢看他的代码,不过他那里面的一些技巧还是不错的。 你们要把客户端结合FW??我不认为这是一个好的方式。fw如果只做一个端口和协议的过滤我认为没有任何意义。 |
|
|
6楼#
发布于:2003-06-16 09:10
[quote]对于freeswan的实现,我看过一些,后来的出的补丁中已经跟进了NAT的支持,但在实现上的确仍然不是很完美。 你的客户端是如何实现的?结构怎么样?你们的网关呢??? 客户端的整个IPSEC都是做在一个驱动里面还是分开的? 98下呢?你移植了passthru???我到是觉得在98下移植passthru并不是必须的,也未必是最好的选则,除非你要不断的iocalldriver。 freeswan的代码看着确实头大,我是不喜欢看他的代码,不过他那里面的一些技巧还是不错的。 你们要把客户端结合FW??我不认为这是一个好的方式。fw如果只做一个端口和协议的过滤我认为没有任何意义。 [/quote] 我是在公司做事情的,有些东西是不太方便说的,我们的确有自己的网关,这并没有什么。我谈谈windows下的IPSEC的问题,我们的软件在驱动上,不管是98还是2000都没有移植过passthru,都是自己的代码,但应该说在实现上就是在中间层,这个没有隐瞒的必要,我们没有safenet那么好,可以得到MS的TCP/IP堆栈的代码, 我们只能是做在中间层。 还有,我们的IPSEC功能都实现在驱动层次,这个也没有必要隐瞒,没有使用共享内存,其实我想过使用HU斑竹所提出 的使用LIB的方法,但最终没有这样做,应该 说Ioctl是比较多的,不过这个也没有什么关系啊。。 说到FW,我倒是觉得做在一起有好处,这是中国人的习惯问题,当然希望用最少的钱解决做多的事情! 当然,如果只是处理包过滤,难度不会很大, 但是,我已经说了,希望能够把它实现为一个 网关级的东西,因此这个方案还是比较复杂的 |
|
7楼#
发布于:2003-06-21 02:27
我们的产品就是在FREESWAN基础上开发的。我觉得主要问题还是在於标准。各位不妨加入到ipsec@lists.tislabs.com <ipsec@lists.tislabs.com>,上面有不少对新标
准(如IKEv2, NAT等)的讨论,大家不妨提出自己的看法。 |
|
8楼#
发布于:2003-07-02 18:43
我难以想象,! 不可思议。 不太可能。 呵呵。 |
|
|