免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 123456sx
打印 上一主题 下一主题

[FreeBSD] 期待高手关注!再发一贴为了说清楚我的问题 [复制链接]

论坛徽章:
0
11 [报告]
发表于 2007-08-10 00:35 |只看该作者
原帖由 feillex 于 2007-8-8 20:48 发表

当用户用网通ip访问电信地址。发出的连接请求是没有问题的,可以到达你的电信ip
问题在于。你的返回的数据包!由于用户属于电信ip地址范围。正好符合你的路由表中,走电信线路的路由条目。返回响应该电信用户请求的的数据包将从电信ip响应用户连接请求
——也就是说,用户对你网通ip发出的请求,却得到来自你的电信ip的回应。这样永远也无法建立三次握手。

我不认为问题在这里。TCP/IP协议的本质就决定了数据包的行走路径不是唯一的,来去从两个不同的路径过都是很正常的事情,不会造成lz的问题。

论坛徽章:
1
寅虎
日期:2013-09-29 23:15:15
12 [报告]
发表于 2007-08-10 08:15 |只看该作者
原帖由 isjfk 于 2007-8-10 00:35 发表

我不认为问题在这里。TCP/IP协议的本质就决定了数据包的行走路径不是唯一的,来去从两个不同的路径过都是很正常的事情,不会造成lz的问题。

我推测因不熟悉技术细节,client(网通线路)通过电信IP访问Server,所发出的包,目的地址是电信IP,而Server返回的包,源地址是网通IP,Client端对这"非法"包如何处理? 估计直接丢弃.

论坛徽章:
0
13 [报告]
发表于 2007-08-10 12:13 |只看该作者
原帖由 isjfk 于 2007-8-10 00:35 发表

我不认为问题在这里。TCP/IP协议的本质就决定了数据包的行走路径不是唯一的,来去从两个不同的路径过都是很正常的事情,不会造成lz的问题。


在tcp/ip协议簇中。
tcp协议是面向连接的。也就是说必须经过三次握手之后才能建立起正常的连接。
而且建立连接后,以后的通讯会一直走这个链路。除非解除连接。再次进行连接。

你所说的这种情况只适合于udp协议。

论坛徽章:
2
丑牛
日期:2013-09-29 09:47:222015七夕节徽章
日期:2015-08-21 11:06:17
14 [报告]
发表于 2007-08-10 13:44 |只看该作者
原帖由 feillex 于 2007-8-8 20:48 发表



其实,原因就在于你上面的话。

根据你的配置。路由表配置为如果目标地址为网通用户则从网通线路发出
如果目标地址为电信用户则从电信线路发出。

当用户用网通ip访问电信地址。发出的连接请求是没有 ...

个人同意这个观点

论坛徽章:
0
15 [报告]
发表于 2007-08-10 16:30 |只看该作者
原帖由 congli 于 2007-8-10 08:15 发表

我推测因不熟悉技术细节,client(网通线路)通过电信IP访问Server,所发出的包,目的地址是电信IP,而Server返回的包,源地址是网通IP,Client端对这"非法"包如何处理? 估计直接丢弃.

技术上的失误是有可能的。不过正常来说,对于电信的路由器来说,网通的IP不应该是“非法”的地址。对于电信的路由器来说,处理这个数据包应该做的是转发到电信和网通互联的接口点,交给网通的路由器去处理就完事。不然的话电信和网通的IP岂不是不能互相访问了?这显然是不应该的,只是比较慢而已。

不过也可能因为某些策略上的原因对这种IP数据包直接丢弃。但一般情况来说这是不应该的。

原帖由 feillex 于 2007-8-10 12:13 发表
在tcp/ip协议簇中。
tcp协议是面向连接的。也就是说必须经过三次握手之后才能建立起正常的连接。
而且建立连接后,以后的通讯会一直走这个链路。除非解除连接。再次进行连接。

你所说的这种情况只适合于udp协议。

不管是TCP还是UDP,最终都要分解封装为IP包进行发送。而IP包是不会管里面放的什么东西的,路由器的转发也以IP包为单位。你甚至可以自已在IP上面做一层私有协议,通过IP进行发送,一样能穿过互联网。

TCP的连接状态是逻辑链路,不存在互联网节点间的物理链路。想想也知道,对于互联网的主干交换机来说,维持数以n亿记的TCP链路状态是不可能的。在互联网发展的早期曾经有支持建立物理链路的协议,不过恐怕早已经被废弃了。根据TCP/IP的原理,TCP数据包也是分解为IP包转发的,所以不存在固定的物理链路。TCP数据包在互联网上传播的途径不是唯一的。

论坛徽章:
0
16 [报告]
发表于 2007-08-10 16:36 |只看该作者
原帖由 congli 于 2007-8-10 08:15 发表

我推测因不熟悉技术细节,client(网通线路)通过电信IP访问Server,所发出的包,目的地址是电信IP,而Server返回的包,源地址是网通IP,Client端对这"非法"包如何处理? 估计直接丢弃.

呵呵,刚才没看明白你的意思。你说的是对的,如果Server返回的数据包源地址填的是服务器另一个接口的IP而不是收到数据包接口的IP,client会直接丢弃。对于TCP来说,这个数据包是非法的

[ 本帖最后由 isjfk 于 2007-8-10 16:38 编辑 ]

论坛徽章:
0
17 [报告]
发表于 2007-08-10 17:18 |只看该作者
一言蔽之:电信的路由器中没有网通的路由,网通的路由器中没有电信的路由,你电信终端的报文到达FB后,好,我FB可以识别,我加源地址是网通的IP给你从电信的线路返回去,你觉得这条报文会不会返回到主机,肯定不会!

论坛徽章:
0
18 [报告]
发表于 2007-08-10 18:28 |只看该作者
关注

论坛徽章:
0
19 [报告]
发表于 2007-08-10 19:46 |只看该作者
原帖由 feillex 于 2007-8-10 19:21 发表

同意。tcp、udp为传输层协议。ip为网络层协议。
传输层协议。需要ip层协议封装进行路由传递。


在这里,混淆了传输层和网络层。tcp链路是由通讯双方(两个通讯主机)来维持的。和路由表没有任何关系。tc ...

你话说的不清不楚,我怎么会往那个方向上理解嘛

其实你说的和 congli 一个意思。不过我对这个还是有疑问。按理来说TCP的连接状态是双方都会保持的。服务器端接收到握手请求时很清楚数据包的来源和目的端口,在构建响应包时就算从另一个端口返回,也不至于会修改IP包的源地址为另一个端口的IP。有时间了我抓包分析一下,反正我手边网卡多~

论坛徽章:
0
20 [报告]
发表于 2007-08-10 20:40 |只看该作者
多谢各位.只是本人问题解决了.不是路由表的问题!!!!
大家谁能对以下做出解释.....
事实证明不像各位说的.路由表不影响来自外网用户的访问....



我的网络环境
电信网通双100M光纤.电信IP219.147.X.X网通IP218.28.X.X
本人做了自动切换的nat说到这里是没有问题的.(文章最后是我的PF.conf 问题部分做了红色显示...)
主要就是pass in  quick on { $ext_if_cnc, $ext_if_ct } proto tcp from any to { $cnc_ip, $ct_ip } port = 80 flags S/SA  keep state \
(source-track rule,max-src-conn 100, max-src-conn-rate 15/3,max-src-states 15,overload <abusive_hosts> flush, src.track 1)
这里的flags S/SA  keep state换成 flags S/SA synproxy state的时候问题就出来了.就是说来自外部网络界面的用户如果使用电信访问我的WEB服务器的网通(也就是说我的IP218.28.X.X),或是网通访问电信(IP219.147.X.X)的时候就不能了.如果我说的还不够明白.这样:
你家用的网通线路上互联网.你可以使用我的IP218.28.X.X正常访问我的web服务器,但根本不能用你家的网通访问我的电信IP219.147.X.X;
电信同上
只要我把 flags S/SA synproxy state改成flags S/SA keep state一切就解决了.现在我还是不知道错在哪里了.....
郁闷 .................郁闷到死!

以下是我的PF.conf
ext_if_cnc="fxp0"
cnc_ip="218.28.X.X/32"
ext_if_ct="rl0"
ct_ip="219.147.X.X/32"
int_if="xl0"
int_net="192.168.0.0/24"
#options
set timeout interval 10
set timeout frag 30
set limit { frags 80000, states 80000 }
set optimization normal
set block-policy return
set loginterface $int_if
set fingerprints /etc/pf.os
set state-policy if-bound
#scrub
scrub on { $int_if, $ext_if_cnc, $ext_if_ct } reassemble tcp no-df random-id
scrub in all
#NAT(net,rdr)
nat on $ext_if_cnc from $int_if:network to any -> ($ext_if_cnc)
nat on $ext_if_ct from $int_if:network to any -> ($ext_if_ct)
rdr on $int_if proto tcp from $int_if:network to any port 21 -> 127.0.0.1 port 8021
pass quick on lo0 all
block drop in quick on $int_if from any to 10.0.0.0/8
block drop in quick on $int_if from any to 172.0.0.0/16
block drop in quick on $int_if from any to 192.168.0.0/16

pass in quick on $int_if proto {udp,icmp} from any to any keep state
pass in quick on $int_if proto tcp from any to any flags S/SA keep state
pass in quick on $int_if proto 4 from any to any keep state
pass in quick on $int_if all keep state

pass out quick on { $int_if , $ext_if_cnc , $ext_if_ct } all keep state
pass in quick on { $ext_if_cnc, $ext_if_ct } proto tcp from any to { $cnc_ip, $ct_ip } port = 22 flags S/SA keep state

table <abusive_hosts> persist  
block in quick from <abusive_hosts>
pass in  quick on { $ext_if_cnc, $ext_if_ct } proto tcp from any to { $cnc_ip, $ct_ip } port = 80 flags S/SA  keep state \
(source-track rule,max-src-conn 100, max-src-conn-rate 15/3,max-src-states 15,overload <abusive_hosts> flush, src.track 1)


block drop in quick on { $ext_if_cnc, $ext_if_ct } all

[ 本帖最后由 123456sx 于 2007-8-10 20:44 编辑 ]
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP