|
阅读：3811回复：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
我难以想象，！ 不可思议。 不太可能。 呵呵。 |
|
|