|
 | 作者: xiean [xiean]
 论坛用户 |
登录 |
| [讨论]关于NAT无法在源与目标同网段情况下内进行地址转换的(FreeBSD/IPFILTER) 发起人：邪・安 警告：任何公司及个人不得就此帖灌水！对于灌水的概念在本帖中定义为：不具有任何参考意义的回帖及字数少于20字节的回帖！ 对于NAT同网段下的处理问题，我相信很多人都遇到过，至少我和NetDemon就为此烦恼不已，于是我想以此话题与大家共同讨论，以得出可行的解决方案。 以下是TCP的试验，选FTP的原因是98用20CN Mini FTP开服务简单 试验环境（一）： ================ NAT Host： --OS：FreeBSD 4.8-RELEASE --NAT：IPFILTER --Interface: ----rl1:Realtek 8139 10/100M (IP 192.168.0.1/24, 192.168.10.1/24) A Host: --OS: Windows 2003 --Interface: Realtek 8139 10/100M (IP 192.168.0.3/24) --Gateway: 192.168.0.1 B Host: --OS: Windows 98 --Interface: Realtek 8139 10/100M (IP 192.168.10.2/24) --Gateway: 192.168.10.1 --Service: FTP --Port: 21 NAT方式： --所有对于rl1设备上192.168.10.1.2021的请求，全部NAT到192.168.10.2.21 测试 A <-> NAT <-> B 正常，以下帖上 A <-> NAT <-> B 信息 A信息： <- ftp 回显 -> ftp> open 192.168.10.1 2021 Connected to 192.168.10.1. 220 你Y又来了!!! User (192.168.10.1:(none)): <- netstat -na 结果 -> TCP 192.168.0.3:2806 192.168.10.1:2021 ESTABLISHED B信息： <- netstat -na 结果 -> TCP 192.168.10.2:21 192.168.0.3:2806 ESTABLISHED NAT信息： <- tcpdump -i rl1 net 192.168.10.0 mask 255.255.255.0 -> 00:58:40.910394 192.168.0.3.2806 > 192.168.10.1.servexec: S 2468326625:2468326625(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 00:58:40.910673 192.168.0.3.2806 > 192.168.10.2.ftp: S 2468326625:2468326625(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 00:58:40.911580 192.168.10.2.ftp > 192.168.0.3.2806: S 8951609:8951609(0) ack 2468326626 win 8760 <mss 1460,nop,nop,sackOK> (DF) 00:58:40.911633 192.168.10.1.servexec > 192.168.0.3.2806: S 8951609:8951609(0) ack 2468326626 win 8760 <mss 1460,nop,nop,sackOK> (DF) 00:58:40.912125 192.168.0.3.2806 > 192.168.10.1.servexec: . ack 1 win 17520 (DF) 00:58:40.912170 192.168.0.3.2806 > 192.168.10.2.ftp: . ack 1 win 17520 (DF) 00:58:40.925376 192.168.10.2.ftp > 192.168.0.3.2806: P 1:19(18) ack 1 win 8760 (DF) 00:58:40.925402 192.168.10.1.servexec > 192.168.0.3.2806: P 1:19(18) ack 1 win 8760 (DF) 00:58:41.087115 192.168.0.3.2806 > 192.168.10.1.servexec: . ack 19 win 17502 (DF) 00:58:41.087141 192.168.0.3.2806 > 192.168.10.2.ftp: . ack 19 win 17502 (DF) 试验环境（二）： ================ NAT Host： --OS：FreeBSD 4.8-RELEASE --NAT：IPFILTER --Interface: ----rl1:Realtek 8139 10/100M (IP 192.168.10.1/24) A Host: --OS: Windows 2003 --Interface: Realtek 8139 10/100M (IP 192.168.10.3/24) --Gateway: 192.168.10.1 B Host: --OS: Windows 98 --Interface: Realtek 8139 10/100M (IP 192.168.10.2/24) --Gateway: 192.168.10.1 --Service: FTP --Port: 21 NAT方式： --所有对于rl1设备上192.168.10.1.2021的请求，全部NAT到192.168.10.2.21 测试 A <-> NAT <-> B 超时，以下帖上 A <-> NAT <-> B 信息 A信息： <- ftp 回显 -> ftp> open 192.168.10.1 2021 > ftp: connect :连接超时 <- netstat -na 结果 -> TCP 192.168.10.3:2808 192.168.10.1:2021 SYN_SENT B信息： <- netstat -na 结果 -> 无对应记录 NAT信息： <- tcpdump -i rl1 net 192.168.10.0 mask 255.255.255.0 -> 01:07:59.638032 192.168.10.3.2808 > 192.168.10.1.servexec: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:07:59.638263 192.168.10.3.2808 > 192.168.10.2.ftp: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:07:59.638343 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 (DF) 01:08:02.576505 192.168.10.3.2808 > 192.168.10.1.servexec: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:08:02.576684 192.168.10.3.2808 > 192.168.10.2.ftp: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:08:02.576777 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 (DF) 01:08:08.569116 192.168.10.3.2808 > 192.168.10.1.servexec: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:08:08.569295 192.168.10.3.2808 > 192.168.10.2.ftp: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:08:08.569377 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 (DF) 以下不断重复如下类似信息 01:08:08.569116 192.168.10.3.2808 > 192.168.10.1.servexec: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:08:08.569295 192.168.10.3.2808 > 192.168.10.2.ftp: S 2303804337:2303804337(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 01:08:08.569377 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 (DF) 根据试验二，可以看出A发送到NAT.2021的SYN请求，被NAT转发到B.21，同时重定向连接为A到B。这时问题产生了，A先向NAT发送过SYN请求，并等待NAT回应，NAT转发A的SYN到B，但并没有改变包中的源地址项，于是此时B接收到来自NAT的SYN，并按包中的源地址返回ACK应答，由于B返回A不需要经过Gateway也就是NAT，所以B对SYN做出的回应ACK将直接返回给A，而不再经过NAT的Gateway。对于A来说，该ACK是不合法的数据包，直接丢弃，并且A依然不断在向NAT重复发送连接请求直到Timeout，所以连接一直无法建立。 如果发生在 WAN <-> NAT <-> LAN 下，所有由NAT发出到WAN的包，在LAN是私有地址的情况下，都将对其进行封装成NAT的公网地址，再与公网进行连接，并对分配的端口与发出请求的内网地址和端口在记录中建立对应关系，如果收到来自公网对这个端口的返回包，则再由NAT转发到发出原始请求的内网主机。从公网主动访问NAT主机特定端口，并且NAT主机对此端口往内网转发的情况大同小异，我就不再多说。（由于对这种NAT方式捉包，需要一定的环境，我不太方便进行互联网和内网之间的NAT试验，有兴趣的朋友可以试验一下，把结果拿出来共享^_^） 邪・安小结： ============ 在以上情况下，当NAT两边的主机如果在同类型网段下（公网类型或私网类型），NAT并不对数据包地址进行伪装，而仅仅是对包的目标地址重定向；只有在NAT两边主机在不同类型网段下（常见情况就是WAN <-> NAT <-> LAN）NAT才会对数据包私有地址进行伪装。而当NAT两边主机在同类型网段及同一网段（同一网段是指A到B并不通过任何路由或网关）下，这种处理方式显然出现问题，主要原因就是NAT没有对数据包地址进行伪装，使得目标主机的ACK返回包直接发到源主机，造成握手错误，连接超时断开。 结论，NAT对同类型网段不进行地址伪装是因为这样处理效率明显高于地址伪装。 如此，我想请问，有没有方法使NAT强制所有包进行地址伪装？是不是所有的或大部分的NAT软件都是如此？ 注：邪某深知自己能力不足，以上小结如果有错误，请指正，不要见笑哈 ^_^ [此贴被 邪・安(xiean) 在 08月30日05时42分 编辑过] |
| 地主 发表时间: 08/30 02:02 |
 | 回复: NetDemon [netdemon]  ADMIN |
登录 |
|
这个问题在我看来，结论并非如此： 在第一种能够正常工作的情况中，我们看到这样的通信 （我简化一下，而且因为/etc/services中2021被标记为servexec,因此这里的servexec事实上是2021，而ftp正是21） 192.168.0.3.2806 > 192.168.10.1.2021 192.168.0.3.2806 > 192.168.10.2.ftp 192.168.10.2.ftp > 192.168.0.3.2806 192.168.10.1.2021 > 192.168.0.3.2806 那么其工作状态是这样的，首先 192.168.0.3.2806 > 192.168.10.1.2021 由于2021是重定向到192.168.10.2的21的，因此发生了第二个数据，（natd此时keep此syn的状态）。 192.168.0.3.2806 > 192.168.10.2.ftp 192.168.10.2受到了这个SYN，回送给192.168.0.3.2806，又产生了第三个 192.168.10.2.ftp > 192.168.0.3.2806 此时natd在syn表中的查找，有对应的syn，因此对192.168.0.3.2806发出syn,于是有了这个包 192.168.10.1.2021 > 192.168.0.3.2806 至此，返回成功。下面的是tcp连接中必要的ack等东西，反正通过同样的方式，每个包都能正确地返回，最终完成3次握手完成连接。 但在二种不能工作的测试中，我们可以看到他的第三步是不同的，而且不会有第四步 192.168.10.3.2808 > 192.168.10.1.2021 192.168.10.3.2808 > 192.168.10.2.ftp 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 192.168.10.3.2808 > 192.168.10.1.2021 前面两种是完全相同的，首先 192.168.10.3.2806 > 192.168.10.1.2021 由于2021是重定向到192.168.10.2的21的，因此发生了第二个数据，（natd此时keep此syn的状态）。 192.168.10.3.2806 > 192.168.10.2.ftp 192.168.10.2受到了这个SYN，回送给192.168.10.3.2806，本来会产生了第三个192.168.10.2.ftp > 192.168.10.3.2806 ,但这里没有，为什么呢？？？？？就算192.168.10.2与192.168.10.3是同一个IP段，那么他受到这个SYN之后，他还是要回应的阿？？？这是我的一个疑问！！！在我看来，这个包根本就没有通过运行着tcpdump的192.168.10.1(他直接回送给10.3了，因为同一个网段，他没必要经过网关，因此在0.1上运行的tcpdump捕捉不到的）而natd也是明显的知道这一点的，因为他对192.168.10.3发出了这个包 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 他企图通过icmp重定向告诉192.168.10.3 "redirect 192.168.10.1 to host 192.168.10.2" ---把对我的连接改为直接连接192.168.10.2。可192.168.10.3就是不管，他还是固执的 192.168.10.3.2808 > 192.168.10.1.2021。 nat还是告诉他直接连接10.2,他还是不听，继续连接，直到timeout 因为现在几乎所有的操作系统基于安全方面的考虑，都不支持icmp redirect ，因此问题发生在natd的通知客户的的方式上面，但因为tcp/ip的初期构造并不太理想，因此，目前并没有良好的解决方案来解决这个redirect问题，而natd他又必须遵从相关的rfc规定。或者我们可以尝试改变natd这个方式，可同时，不按照rfc的规定又有可能导致其他的问题的出现。 除非象M$这种有可能重新订立一个协议并让他为多数的人接受外，我们自己尝试更改这样的东西肯定面对的只有一个墙壁 由此可见，导致这个问题发上的并不在于natd的软件身上，而是在于tcp/ip协议或操作系统本身，如果在192.168.10.2收到请求后，不是因为同一个网段而直接回应的话，不会发生这个情况，但实际上，他是一定会根据协议对这个IP回应而不是对网关回应的。 分析依然自己觉得不大理想，也许是错误的理解，如有人指出并大胆耻笑，在下感激不尽 :) [此贴被 NetDemon(netdemon) 在 08月30日04时21分 编辑过] |
| B1层 发表时间: 08/30 03:59 |
| 回复: xiean [xiean] 论坛用户 |
登录 |
|
看到ND的回帖后，我才发现我刚才试验二忘了最重要的事，就是我没有在A上sniffer数据包，我刚才所说的B直接回给A是理论上的猜测，先在此道歉。 我复原试验二，并增加在A上截取来自B的数据包取得如下信息 NAT 主机 tcpdump 信息: 04:36:04.345918 192.168.10.3.3298 > 192.168.10.1.servexec: S 4224915816:4224915816(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 04:36:04.346164 192.168.10.3.3298 > 192.168.10.2.ftp: S 4224915816:4224915816(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 04:36:04.346234 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 (DF) ........（信息重复省略，只取第一个包） A主机截图：  如上信息说明，A(192.168.10.3)收到来自B(192.168.10.2)的回应，我们只看第一个包，在 NAT 的信息里，这个包 192.168.10.3.3298 > 192.168.10.2.ftp: S 4224915816:4224915816 这条信息告诉我门，此时10.3.3298对10.1.2021的请求已被重定向10.3.3298到10.2.21，这是一条SYN包，SYN号为4224915816，希望回复所用的SYN为4224915816 我们再看A主机截图，取第一个包，我们所看到信息有 包源与目的地址 192.168.10.2.21 -> 192.168.10.3.3298 ACK 回应码为 4224915816 + 1 = 4224915817，这是标准的握手回应 其它两个包也依然如此，由此可见，B的确回应A的请求了，但该回应包并没有经过 NAT/Gateway，所以在NAT主机上，我们无法截取该包。但由于A是向NAT发出的SYN，所以一直在等待NAT的回应，虽然B的ACK正确，但由于ACK包的源地址并非NAT主机地址(10.1)，所以直接丢弃该包，造成连接超时。 我认为最终问题是，如何能强制NAT进行地址转换？ [此贴被 邪・安(xiean) 在 08月30日05时16分 编辑过] |
| B2层 发表时间: 08/30 04:59 |
| 回复: NetDemon [netdemon] ADMIN |
登录 |
|
NAT是有回应的，他首先知道了B会直接回应A，因此他对A发出 192.168.10.1 > 192.168.10.3: icmp: redirect 192.168.10.1 to host 192.168.10.2 让他直接和B取得联系，可A就是不管啊，因此他也没有办法了。 你不能让nat伪造，我说了，因为这样不符合协议标准，任何一个natd都不会这么做，除非M$才够种这么做 |
| B3层 发表时间: 08/30 05:07 |
| 回复: xiean [xiean] 论坛用户 |
登录 |
|
我不赞同ND“因为这样不符合协议标准，任何一个natd都不会这么做”的观点。 说说我的想法(TCP协议) ----EG-1: 公网对私网通过NAT访问私网服务21（标准的防火墙NAT） A为公网主机，NAT代表NAT服务主机，B代表私网主机，其连接图如下 A <-> NAT <-> B 假设IP为 A:200.200.200.101/NAT-interface:100.100.100.101/B:192.168.0.2 1) A 发送21连接请求到 NAT 200.200.200.101.2587 -> 100.100.100.101.21 2) NAT获取该包，发现有redirect规则，此时对A的请求keep，并对B发送连接请求 100.100.100.101.7894 -> 192.168.0.2.21 3) B返回连接确认包给NAT 192.168.0.2.21 -> 100.100.100.101.7894 4) NAT对此回复包进行伪装并回复给A 100.100.100.101.21 -> 200.200.200.101.2587 这是TCP前两次握手的过程 SYN/SYN+ACK，后面的通讯大同小异 ----EG-2: 同网段通过NAT访问服务21（上述试验二中我想的成功方式的假设） A，B同为私网主机，NAT代表NAT服务主机，其连接图如下 A <-> NAT <-> B 假设IP为 A:192.168.0.3/NAT-interface:192.168.0.1/B:192.168.0.2 1) A 发送21连接请求到 NAT 192.168.0.3.2587 -> 192.168.0.1.21 2) NAT获取该包，发现有redirect规则，此时对A的请求keep，并对B发送连接请求 192.168.0.1.7894 -> 192.168.0.2.21 3) B返回连接确认包给NAT 192.168.0.2.21 -> 192.168.0.1.7894 4) NAT对此回复包进行伪装并回复给A 192.168.0.1.21 -> 192.168.0.3.2587 但实际情况并非如我假设，实际情况是在 2) 中，NAT发现redirect规则，也发现A和B处于同一网段，就把该包直接重定向成A和B的连接发送给B，并回应A一个包通知该转向，但A似乎并没有处理该包，以至于B回复A包的信息被丢弃。 在如此情况下，我认为应该可以通过一些设置来让 NAT 对每个有redirect规则都强制进行IP Masquerade。而我认为这种强制方式并不违反协议标准，在最坏的情况下，也应该只是让NAT主机所要处理的数据量加大而已。 不知道我的想法是否正确，我们急需第三方的专业人士参与讨论，您还犹豫什么？加入我们的讨论吧，记住，严禁水帖！ |
| B4层 发表时间: 08/30 05:58 |
| 回复: xiean [xiean] 论坛用户 |
登录 |
|
还有补充，就是NAT并不是只对同网段如此处理，我认为NAT是通过判断A和B之间是否可以直接通讯来选择伪装或重定向这两种方式中的一种来进行地址转换。如果A和B之间无法直接通讯（A和B之间无任何可选择的路由或公网/私网地址限制），则NAT使用IP伪装来保持A和B的连接（如楼上的----EG-1: 公网对私网通过NAT访问私网服务21）；如果A和B之间可以直接通讯（A和B之间有路由），那么NAT将直接重定向A的包为A到B的包，并通知A重定向。在试验一中，其实使用的是第二种，即重定向（如试验一，因为试验一中A和B是可以直接通讯的，路由为NAT主机，所以成功）。可是在试验二中，NAT依然采用重定向方式，但是A对于重定向请求却没有处理？？看记录里，NAT把A的包转到B是优先于NAT通知A，这会是原因所在吗？延迟？不可能吧，我肯定是乱想，TCP/IP协议的问题可不是凭我这猪就能找出来的。。。*^_^* |
| B5层 发表时间: 08/30 06:24 |
| 回复: xiean [xiean] 论坛用户 |
登录 |
|
ND回复中的“因为现在几乎所有的操作系统基于安全方面的考虑，都不支持icmp redirect ，因此问题发生在natd的通知客户的的方式上面”我在想法上也有出入 如我楼上所想，试验一中，A对icmp redirect是有处理的，从tcpdump 的捉取记录中我们可以看出，包的源地址和目的地址是A和B直接通讯，如果是伪装方式的话，那么应该是记录下A和NAT及NAT和B的通讯，因为tcpdump的sniffer数据并非经NAT处理，所以不会出现这种NAT里的逻辑表达方式，而是应该是原始的包数据，因为需要经过NAT所在的路由，所以被tcpdump给sniffer。 而试验一中NAT发给A的icmp redirect请求是通过192.168.0.1发送的，所以在 tcpdump -i rl1 net 192.168.10.0 mask 255.255.255.0 命令下，是无法捉到这个icmp redirect请求，并非表示NAT没有向A发送icmp redirect，今天太累了，改天再捉～ 所以我认为A对icmp redirect请求是有处理的。 [此贴被 邪・安(xiean) 在 08月30日06时07分 编辑过] |
| B6层 发表时间: 08/30 06:36 |
 | 回复: group [group] 论坛用户 |
登录 |
|
192.168.0.203:8080(JSP WEB) 192.168.0.1 \ NAT Server 218.19.72.23 / 218.19.72.23:100->192.168.0.203:8080 测试结果：在192.168.0.1上，用192.168.0.203:8080及218.19.72.23:100访问，都正常 OS: win 2000 server NAT: CCProxy |
| B7层 发表时间: 08/30 15:23 |
| 回复: group [group] 论坛用户 |
登录 |
|
另一个例子，机房一堆服务器 192.168.0.x的内网 一个netscreen防火墙 内网的主机都没有IP地址，全部靠在netscreen上做NAT 一切正常，包括ping |
| B8层 发表时间: 08/30 15:25 |
| 回复: NetDemon [netdemon] ADMIN |
登录 |
|
到后来，你好象自相矛盾了，因为你最终的结论是 （一）和（二）是一抹一样的处理方式，而（一）也是用icmp rdr处理了的，然后既然A对icmp redirect请求是有处理的,为何没有看到他的反应？他继续对着NAT发，而不是对着B发？ 非常明显，这个问题要讨论下去还需要相当多的实际数据来支持，因为你自己也一次又一次的证实了你tcpdump出来的非完整性，不是丢这就是丢那的，而我的分析完全是根据你的tcpdump来做的。 现在我们不要考虑这个对WAN的封装问题，是要用实际数据证明1和2的关键区别，找出问题的所在来看看有没有办法解决，不要因为我的不同观点而把论题转移为来推翻我的说法 TO 晓岚：在Win下多数同类功能软件都是可以这样的。包括它自身的远程和路由功能中的NAT我记得也是可以的 |
| B9层 发表时间: 08/30 16:24 |
| 回复: xiean [xiean] 论坛用户 |
登录 |
|
嗯，我在A机上装上PortTunnel，并设置80转发到BSD主机，并从B机上访问，同网段正常，图示 B(98) <-> Windows2003(PortTunnel) <-> FreeBSD 完全成常，加上以上 晓澜 的例子，我认为这个问题和协议无关，所以我认为在BSD上的IPFW+NATD及IPFILTER肯定有办法设置以达到要求 |
| B10层 发表时间: 08/30 16:25 |
| 回复: NetDemon [netdemon] ADMIN |
登录 |
|
我倒是觉得这是和操作系统有关，我刚刚看了Nat的源代码 每一个进入的包，他都已SOCK_RAW的方式接受了，然后再自己解码辨别类型再发出去的，是所有的包都经过他处理的，也没有判断源地址个目标地址的类型而发出icmp rdr的。因为有可能 tcpdump中的icmp rdr 事实上是内核做的，和NAT无关 |
| B11层 发表时间: 08/30 16:50 |
| 回复: TomyChen [quest] 版主 |
登录 |
|
道理跟IPSec差不多 A<----IPSec---->B A->B两端不可能，也绝对不可以是同一网段，即使是VPN Gateway后面的client也不能跟另外一端属于同一网段。 不明白的是为什么ND说跟操作系统有关系 [quote] 我倒是觉得这是和操作系统有关，我刚刚看了Nat的源代码 每一个进入的包，他都已SOCK_RAW的方式接受了，然后再自己解码辨别类型再发出去的，是所有的包都经过他处理的，也没有判断源地址个目标地址的类型而发出icmp rdr的。因为有可能 tcpdump中的icmp rdr 事实上是内核做的，和NAT无关 [quote] 做为转发，当然要用SOCK_RAW方式来接受啦，问题是，在这里问题根源就是这个地址转发中间，是否成功了？ |
| B12层 发表时间: 08/30 19:37 |
| 回复: NetDemon [netdemon] ADMIN |
登录 |
|
我似乎已经可以得出结论，这确实是和操作系统的处理方式有关，而和NATD软件无关 我们做了如下试验： 由远程的xiean透过一台ipfw+natd 的freebsd 对netdemon位于内部网的电脑作出ftp连接，试验环境如下： NAT Host 外网界面：dc0 ip:211.161.57.4 内网界面：rl0 ip:192.168.0.1 转发规则：redirect_port tcp 192.168.0.2:21 211.161.57.4:2121 （所有对211.161.57.4:2121 的tcp 连接 转到 192.168.0.2:21） Netdemon Host ip :192.168.0.2 Xiean Host ip :61.183.214.27 从这个通信的数据流经界面来看， xiean <==> dc0 是相同的 rl0 <==> netdemon 也是相同的， 因此，用tcpdump dump dc0 和 rl0的数据，就可以体现出natd的处理过程 下面是tcpdump的数据 dc0 03:28:23.334447 61.183.214.27.11711 > 211.161.57.4.2121: S 969481080:969481080(0) win 16384 <mss 1452,nop,nop,sackOK> (DF) 03:28:23.335376 211.161.57.4.2121 > 61.183.214.27.11711: S 4235342954:4235342954(0) ack 969481081 win 64240 <mss 1460,nop,nop,sackOK> (DF) 03:28:23.492963 61.183.214.27.11711 > 211.161.57.4.2121: . ack 1 win 17424 (DF) 03:28:23.496121 211.161.57.4.2121 > 61.183.214.27.11711: P 1:19(18) ack 1 win 64240 (DF) 03:28:23.796363 61.183.214.27.11711 > 211.161.57.4.2121: . ack 19 win 17406 (DF) rl0 03:40:45.116741 61.183.214.27.11744 > 192.168.0.2.ftp: S 4214957440:4214957440(0) win 16384 <mss 1452,nop,nop,sackOK> (DF) 03:40:45.116852 192.168.0.2.ftp > 61.183.214.27.11744: S 109983982:109983982(0) ack 4214957441 win 64240 <mss 1460,nop,nop,sackOK> (DF) 03:40:45.269186 61.183.214.27.11744 > 192.168.0.2.ftp: . ack 1 win 17424 (DF) 03:40:45.270626 192.168.0.2.ftp > 61.183.214.27.11744: P 1:19(18) ack 1 win 64240 (DF) 03:40:45.602616 61.183.214.27.11744 > 192.168.0.2.ftp: . ack 19 win 17406 (DF) 因为这是两次分两次dump,是两次连接，因此xiean的端口分别是11744和11711， 事实上我们是可以把所有的11744替换为11711来看待。 由这个数据看来，natd所作的非常清晰，非常简单，他根据转发的条件把dc0上的211.161.57.4.2121变换为192.168.0.2.21由内核从rl0上发送出去。再把由内核从rl0上交回来的192.168.0.2.21 变换为211.161.57.4.2121 由内核从dc0上返回去，始终没有改变原地址和端口61.183.214.27.11711。是始终没有出现过rl0的ip 192.168.0.1 在我继续证明为什么内网不成功，不会有这样的数据通路的之前。我们先明确一下这个东西，就是，什么是"自己"? 对于内核来说，192.168.0.1 、211.161.57.4 都是他自己。这两个对他来说是毫无区别，一视同仁的。但对于nat来说，192.168.0.1 对他毫无意义，他认为211.161.57.4是他自己，他只会在这个ip上做出端口映像，只监护这个界面上的数据。对于ipfw/natd来说，这个数据是又ipfw交给他的。对于ipfilter来说，这是通过，nat规则决定的，虽然ipfilter可以在不同的界面转来转去的，但始终，对于每一个制定的转发条件，他只对那个界面作出端口映像。如rdr dc0 211.161.57.4 port 2121 -> 192.168.0.2 port ftp,他依然只认为dc0上的211.161.57.4为他自己。 那么从内网的192.168.0.3连接211.161.57.4：2121 的时候，这个数据首先到达的是rl0，再到内核。而对于内核来说211.161.57.4就是他自己，他根本就不需要把这个数据体现到dc0上去，因此natd根本没发在dc0上得到这个数据然后转发，这点从ipfwd的规则中明显看出来，divert natd ip from any to any via dc0 。只有via dc0 的才会交给natd. 因此，由内网的rl0来的数据，绝对是不会处理了。ftp 211.161.57.4:2121就是和ftp 192.168.0.1:2121一样的效果。在这台机器本身上ftp 211.161.57.4:2121 就是和ftp 127.0.0.1一样的效果。而对于natd来说，只有由dc0来的并且目标地址为211.161.57.4:2121，他才会转发。当然，就会不成功了。 SO....... 如果把 divert natd ip from any to any via rl0 divert natd ip from any to any via lo0 加进去，会有什么后果呢？是不是就行了？明天再做实验 |
| B13层 发表时间: 09/01 14:45 |
| 回复: NetDemon [netdemon] ADMIN |
登录 |
|
事实上也不存在他强不强制的问题，他也没有智能化的监测什么同不同网段的东西，只要符合他规则的，他就转，这就是NAT。不存在所谓“通过一些设置来让 NAT 对每个有redirect规则都强制进行IP Masquerade”，因为她本来就确实已经对每个有redirect规则都进行IP Masquerade。 如果以xiean的理解，A<==>NAT ,NAT做处理，然后 NAT <==>B ,好像是吧A和B隔断了那样，那不是占不占用资源的问题了，这已经不是NAT的概念了，而类似于代理服务器的概念了。 显然CCProxy已经从名字上告诉我们，我是Proxy ，不是NAT。 [此贴被 NetDemon(netdemon) 在 09月01日15时10分 编辑过] |
| B14层 发表时间: 09/01 15:02 |
| 回复: NetDemon [netdemon] ADMIN |
登录 |
|
邪安同志，哈哈，我找到了最权威的答案，ipf的作者说的，现在建议你去看一下克鲁斯去年拍的那个电影《不可能的任务》解解闷气吧 Q: I'm using rdr for a webserver behind IPF and the world can see it just fine, but the internal machines can't surf to it via the external IP address. A: For the purposes of explaining this, lets take the following example: (internet)--->(if0[OS]if1)----|----(httpd on 192.168.0.2) | |----(browser on 192.168.0.3) if0 is some.isp.ip.addr if1 is 192.168.0.1 I have a rdr on the external interface, written as: rdr if0 0.0.0.0/0 port 80 -> 192.168.0.2 port 80 Now, IPFilter's rdr function does not natively support "bouncing" the connection (i.e. a packet coming in and leaving the same interface). The redirection happens only to packets coming in on the external interface. If you want to surf to 192.168.0.2 from the browser on 192.168.0.3, you can either do so directly via http://192.168.0.2/ (or by a CNAME in your DNS), or by using a "bounce" utility on the firewall to reflect inbound packets on if1 towards 192.168.0.2. By nature neither the OS nor ipf will do this for you. If you search the ipf archives you will find some bounce utilities. The golden RDR rule: rdr works *only* when the packet traverses the firewall (i.e. in one interface and out on another interface). [此贴被 NetDemon(netdemon) 在 09月02日06时38分 编辑过] |
| B15层 发表时间: 09/02 06:17 |
| 回复: xiean [xiean] 论坛用户 |
登录 |
|
郁闷ing。。。果然。。。。。。ipfilter 不支持。。。。 If you want to surf to 192.168.0.2 from the browser on 192.168.0.3, you can either do so directly via http://192.168.0.2/ (or by a CNAME in your DNS), 要晕啊～～～，不过设DNS也可以。。。就是内网把bsd当成dns。。。这样也成。。。哎。。。只有这样了哈 我在看 Mission impossilbe II... |
| B16层 发表时间: 09/02 13:42 |
|
20CN网络安全小组版权所有
Copyright © 2000-2010 20CN Security Group. All Rights Reserved.
论坛程序编写：NetDemon
粤ICP备05087286号
论坛: 系统集成
标题: [讨论]关于NAT无法在源与目标同网段情况下内进行地址转换