jianxin007 发表于 2006-11-22 20:54:05

楼主哥们,我猜想,你想实现的是多操作员同时操作总公司的ERP之类的软件的功能吧?
既然ROS现在用起来有些问题,我推荐你使用我所设想的解决方法。
如图

jianxin007 发表于 2006-11-22 21:02:27

135.40.26.121这台客户端现在直接暴露在公网上了,暂时就用天网之类的防火墙来解决一下吧。等问题解决了,你可以把ROS再放到135.40.26.121前面。
CITRIX终端服务器可以很完美的解决多操作员同时连接数据服务器的问题。同时,系统易于维护。
在服务器端看来,是单IP多操作员在连接它。

jack_i5 发表于 2006-11-22 21:08:38

原帖由 seignior 于 2006-11-22 20:24 发表
比预期的要复杂......
135.40.26.1归不归你管?看样子你应该不只一个公网ip的说,根据掩码,你应该有整整254个ip可用。

无论是微波还是光纤,这部分你都无需理会,你只要把他理解成一个通路即可。

1、135.40.26.1不归我管。
2、从掩码看,我的确有254个可用地址。但实际的情况是,其他分公司瓜分了那剩下的252个地址。
3、下午,我咨询了我的一个朋友,被告知,像我这样来伪造地址,会造成整个网络的瘫痪。这类似于GRE攻击。不知道真的假的?

seignior 发表于 2006-11-22 21:32:34

无解了,终于明白你一直强调“只有一个公网IP”是什么意思了,原来说的是“只有一个被信任的ip”...........

我是没办法了,之前说的全部作废,但jianxin007的方案可行,实际上不需要弄得他那么复杂,完全无需中间的ros,直接把121那机器绑多一个内网ip即可,其他客户机直接登陆上121(其实未必使用citrix,看你自己懂操作什么了,反正就是其他客户机直接当一个终端一样登陆上121即可)操作。

至少在你的描述里,构不成gre攻击,nat是边缘的、单向的。

jack_i5 发表于 2006-11-22 21:42:36

原帖由 seignior 于 2006-11-22 21:32 发表
无解了,终于明白你一直强调“只有一个公网IP”是什么意思了,原来说的是“只有一个被信任的ip”...........

我是没办法了,之前说的全部作废,但jianxin007的方案可行,实际上不需要弄得他那么复杂,完全无 ...

这么就放弃ros了?我总觉得问题应该可以借助ros解决的,只是我现在还没办法

jianxin007 发表于 2006-11-22 21:47:45

先把业务恢复再想别的方法吧,缓一缓~~~~~~~~~~如果没有CITRIX服务端,我可以提供METAFRAME CITRIX XP,FOR WIN2000和FOR WIN2003都有(D版)。

jack_i5 发表于 2006-11-22 21:55:32

原帖由 jianxin007 于 2006-11-22 21:47 发表
先把业务恢复再想别的方法吧,缓一缓~~~~~~~~~~如果没有CITRIX服务端,我可以提供METAFRAME CITRIX XP,FOR WIN2000和FOR WIN2003都有(D版)。


谢谢
我已经给你发了站内短消息,查收

analyst 发表于 2006-11-22 22:16:56

我觉得不少人忽略了一个控制与反控制的问题。

个人认为解决问题的方法还是需要模拟一个这样环境来研究究竟提交&反馈了哪些数据。

jack_i5 发表于 2006-11-22 22:20:34

原帖由 analyst 于 2006-11-22 22:16 发表
我觉得不少人忽略了一个控制与反控制的问题。

个人认为解决问题的方法还是需要模拟一个这样环境来研究究竟提交&反馈了哪些数据。

老A    研究数据封包是一条思路...但,这样做代价太大。

seignior 发表于 2006-11-22 23:04:03

analyst应该没接触过spa吧,根据不同的供应商,验证的东西都不同,但就我之前看到的,绝对包括ip之类的信息(他会主动拆封包),达不到他条件的就拒绝(N多条件,杀毒软件没升级都归他管,数据在spa客户端提供)。 过nat就已经无法达到要求了(spa信息验证不正确)。

心想事成 发表于 2006-11-22 23:22:40

spa是不是检测到你使用共享了?
用我做的反尖兵coyote试试

jack_i5 发表于 2006-11-22 23:32:16

原帖由 seignior 于 2006-11-22 23:04 发表
analyst应该没接触过spa吧,根据不同的供应商,验证的东西都不同,但就我之前看到的,绝对包括ip之类的信息(他会主动拆封包),达不到他条件的就拒绝(N多条件,杀毒软件没升级都归他管,数据在spa客户端提供)。...

白皮书上说“对数据做深度检测”。估计这一条就够人琢磨了。鬼知道他验证哪些信息!

seignior 发表于 2006-11-23 00:19:16

原帖由 想得太美 于 2006-11-22 23:22 发表
spa是不是检测到你使用共享了?
用我做的反尖兵coyote试试


不是,是在客户端要装spa客户端软件,连接的时候,spa会根据客户机的实际情况附加数据进数据包里,spa类似一个网桥之类的东西会验证spa客户端附加的报文,如果某些数据不完整,就扔到升级服务器处理(例如杀毒软件没升级,系统sp没打之类),此时只能和指定的升级服务器通讯,直到完全通过为止才能和其他机器通讯。如果校验完全不正确(例如根本没有装spa客户端或者校验错),就直接把该报文仍到非信任列表里面,结果就是完全不能通讯(在局域网里)。简单地说就是一个内网安全软件。


他内网的spa客户端已经在附加的报文里说明了自己是“192.168.0.x”(假设),这个时候spa客户端的附加数据和报文头的ip数据是正确的,但他经过nat之后,报文头被改变成nat的ip,结果就是在spa服务器那里校验不正确了(报文头的ip和spa附加的ip不吻合)。

[ 本帖最后由 seignior 于 2006-11-23 00:27 编辑 ]

naboo 发表于 2006-11-23 08:44:59

终于知道情况了,已经没有办法了!

jack_i5 发表于 2006-11-23 11:04:19

原帖由 seignior 于 2006-11-23 00:19 发表



不是,是在客户端要装spa客户端软件,连接的时候,spa会根据客户机的实际情况附加数据进数据包里,spa类似一个网桥之类的东西会验证spa客户端附加的报文,如果某些数据不完整,就扔到升级服务器处理(例如 ...

-----------------------------------------
RE: seignior
按照SPA白皮书上说,我结合你的回答理解如下:
1、SPA客户端在最先发起连接SPA服务器时的数据封包一定是正确的。我们假定叫它A封包,A包中包含了所有的合法信息和SPA附加的校验数据,注意:虽然此时的A包可以称为合法,但内含的IP头却是虚假的,是我为了骗过SPA自动分组而伪造的一个仿真地址。

->>>2、继续,当A经过NAT之后,A包被重新封装,我们叫它B包,B包此时的IP头是135.40.26.121,是一个真正意义上的合法地址,但A与B包相比,B却缺少了SPA客户端的验证信息。理论上讲,对于SPA服务器而言,B包是一个非法的数据包,因为缺少必要的SPA完整性信息,B包会被拒绝。先这样假设一下。

->>>3、再继续,当B包按照A包中的目标地址将它送达SPA服务器之后呢?是B包被拆解,直接将A交给SPA服务器呢?还是直接用B包和SPA服务器通讯?这里我就不是很明白。

->>> 前面讲的,我曾经成功的让两机通过ROS合法使用了15分钟。我就一直在想,为什么会成功15分钟?难道是SPA服务器一次轮询的时间间隔就是15分钟?还是有别的什么含义?
白皮书的最后提到了SPA通讯所使用的端口。分别是:SPA客户端(发起)--->SPA服务器    TCP   80
SPA服务器(发起)--->SPA客户端      UDP39999
假如我在forward上放行80,drop 39999,是不是可以理解为强制不准SPA服务器探测我的ROS呢?由此就可以理解为什么正常使用15分钟之后被断开了。因为ROS无法应答SPA服务器的质询!15分钟之后自然会被断开!

--------------------
有如下一些关于ROS的操作疑问
1、能否将外网的某个IP和端口映射到ROS内部?本案中,如果将SPA服务器下行的UDP 39999映射到ROS内部,会发生什么情况?
2、DROP的实际动作是什么?它会返回一个包给源地址吗?我们能不能让一个数据包在ROS这里“石沉大海”?也就是说,我想彻底让ROS在SPA服务器那里“隐身”。


[ 本帖最后由 jack_i5 于 2006-11-23 11:08 编辑 ]
页: 1 2 [3] 4
查看完整版本: Symantec Sygate Enterprise Protection网络环境下,ROS不能用了!