|
上网，大家都用natd。不过如果遇到内网中有人使用h.232或sip之类的voip协议，就会出问题。因为上述两种协议无法穿越natd
下面详细说明使用freebsd模块路由器转发的过程，并说明freebsd4与freebsd5在应用中的不同之处。
概述：
主要使用route命令与ipfw中的fwd命令来完成。fwd子句通常用于做透明代理，它的本质是实现下一跳的转发。
问题：内网中有一台机器需要有互联网真实IP地址，它使用h.232协议，只需要访问到互联网中61.1.1.1的主机。拟分配给它的ip地址是219.1.1.3
说明：无论是dnat和snat都是使用修改ip包中地址来实现与互联网互联，这与h.232协议有冲突。具体原因不赘述，总之natd不符合要求。
解决方案：
互联网
|
|-----------------| 219.1.1.1 00:04:3c:ab:dd:ebxl0
| 网关 A|
|-----------------| 192.168.254.254 00:d0:c9:68:16:93 fxp0
|
|-----------------| 192.168.254.250 00:50:04:ba:98:d5 xl1
| 网关 B|
|-----------------| 219.1.1.2 00:10:5a:85:d5:83xl0
|
|-----------------| 219.1.1.3
| 客户机器|
|-----------------|
客户机器需要互联网真实IP地址。网关A是原有互联网网关。网关B是为了实现此项路由转发功能，增加的服务器。
网关A、网关B均为Freebsd。客户机器随意。
方案一：网关A为Freebsd5.3,网关B为Freebsd4
1.网关B的转发
ipfw add 580 fwd 192.168.254.254 ip from 219.1.1.3 to 61.1.1.1
ipfw add 582 fwd 219.1.1.3 ip from 61.1.1.1 to 219.1.1.3
2.网关A的转发
ipfw add 580 fwd 219.234.226.225 ip from 219.1.1.3 to 61.1.1.1
ipfw add 582 fwd 192.168.254.250 ip from 61.1.1.1 to 219.1.1.3
3.在网关A上为客户机器的外部IP做arp代理，代理的mac地址为本机外网网卡mac，使上级路由器将219.1.1.3的包转发到本机。
arp -S 219.1.1.3 00:04:3c:ab:dd:eb pub
可以用netstat -rn | grep 219.1.1.3看到：
219.1.1.300:04:3c:ab:dd:ebUHLS2 00xl0
4.在网关A上为客户机器的外部IP做主机路由
route add -host 219.1.1.3/32 192.168.254.250
可以用netstat -rn | grep 219.1.1.3看到：
219.1.1.3192.168.254.250 UGHS07 fxp0
上述做法的说明：
使用ipfw 的fwd命令进行转发的语法，是容易看懂的。下面说明一下arp代理与主机路由
从客户机出发的访问，通过网关B和网关A即可。
但是从外网回来的IP地址，网关A如何才能接收呢？方法是在网关A上使用arp代理，告诉上级路由器219.1.1.3的包发到网关A上来。
然后在网关A上检查到 route add -host 219.1.1.3/32 192.168.254.250生成的路由，即会把包转发到该机器上。
注意事项：
为何必须同时使用
ipfw add 582 fwd 192.168.254.250 ip from 61.1.1.1 to 219.1.1.3 和
route add -host 219.1.1.3/32 192.168.254.250
按道理说，在网关A上应该可以找到192.168.254.250，那么不需要特意增加路由，即能正确的把包转发到192.168.254.250上。这在freebsd4.x上是正确的。
但是在freebsd5.3中，我发现如果不指定路由表，那么这个包最后会被网卡xl0截获（可能是因为arp代理的原因）。被截获后，网关A发出arp请求，最后无法找到219.1.1.3的mac地址（在本机上，arp代理被忽略）。
使用tcpdump来看，结果如下：
[root@ftp1]/root # tcpdump -i xl0 host 219.1.1.3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
10:43:01.052683 IP 219.1.1.3 > 61.1.1.1: icmp 40: echo request seq 16384
10:43:01.059563 IP 61.1.1.1 > 219.1.1.3: icmp 40: echo reply seq 16384
10:43:01.059606 arp who-has 219.1.1.3 tell ftp1.tgegroup.com
10:43:02.279858 IP 219.1.1.3 > 61.1.1.1: icmp 40: echo request seq 16640
10:43:02.287605 IP 61.1.1.1 > 219.1.1.3: icmp 40: echo reply seq 16640
10:43:02.287635 arp who-has 219.1.1.3 tell ftp1.tgegroup.com
所以，freebsd5的网络实现时，在通过规则检查后，需要目标IP在路由表中的位置。我认为这或许是一个小bug吧。fwd命令并没有得到完美的执行。
方案二：网关A为Freebsd4.10,网关B为Freebsd4.10
1.网关B的转发
ipfw add 580 fwd 192.168.254.254 ip from 219.1.1.3 to 61.1.1.1
ipfw add 582 fwd 219.1.1.3 ip from 61.1.1.1 to 219.1.1.3
2.网关A的转发
ipfw add 580 fwd 219.234.226.225 ip from 219.1.1.3 to 61.1.1.1
ipfw add 582 fwd 192.168.254.250 ip from 61.1.1.1 to 219.1.1.3
不需要做任何其它的工作，转发已经完成。fwd命令在背后做了许多工作，使用时更简单。
可以在网关A上用
tcpdump -i xl1 host 61.1.1.1
tcpdump -i xl1 host 219.1.1.3
观察数据包的走向
可以在网关B上用
tcpdump -i xl0 host 61.1.1.1
tcpdump -i xl0 host 219.1.1.3
观察数据包的走向
关于Freebsd5与Freebsd4表现的推测：
我想是因为freebsd5中改变了ipfw在tcp/ip协议栈中的位置，导致了这种结果。freebsd5中的ipfw2，应该更靠近网络接口层而不是网络层。
OVER
|
