基于 IP Filter 的NAT透析

基于 IP Filter 的NAT透析

 

摘 要：

　　本文依托cnfug开发的Floppy Firewall为平台，以嗅探器抓包分析结合相应的路由转发规分析IPFilter对数据报进行转发和NAT的机理，最终针对实际案例的需求提出解决方案。

一、前言

　　如今很多企事业单位拥有自己的LAN，介入互联网的方案比较流行的方案是选用如图1-1的拓扑结构来构建网络。防火墙服务器充当过滤和转发数据报的中间代理，专用服务器安置在防火墙后面避免受到攻击。这类防火墙有硬件和软件之分，对于一个普通小型局域网来说，软件防火墙已经可以满足需求，而软件防火墙领域几乎是IPfw和IP Filter的天下，它们的功能非常强大，安装也非常容易，考验防火墙管理员的主要是如何配置防火墙的rules，现在在网上可以很容易地找到如何配置rules的文献，但是很少有介绍其工作机理的资料，本文将以一个基于IP Filter防火墙的实际案例来分析这些rules的工作机理，并将其运用到实际案例中解决特殊的需求问题。


　　　　　　　　　　　　图1-1 常用的拓扑结构

二、案例需求

　　本文所举案例为一实验室的局域网的防火墙配置。该实验室局域网拥有30台客户机，它们通过3个HUB连接在一起，通过一台安装有FreeBSD的服务器用IPFW共享一个固定IP连接Internet，该服务器除了充当局域网的防火墙之外，在其上面还运行了几乎所有FreeBSD能够提供的大众化服务，如WEB、TOMCAT、JAVA、FTP、SMABA、MAIL、DNS、TELNET等（详情请参考cnfug期刊第八期的《用FreeBSD构建家庭网络世界》和第九期的《基于FreeBSD操作系统的安全电子邮件系统架设》），随着使用人数的增多，该服务器慢慢有些不堪重负，经常可以看到在后台运行的NATD服务占用了约50％的CPU时间，尤其是TOMCAT服务启动并调用JDK之后占用的内存高达106M之巨，在高峰期客户端的上网速度有明显变慢。为了缓解服务器的压力，我采用了前面介绍的现今比较流行的方案，把防火墙和专用服务器的功能分开，防火墙采用了由cnfug开发的基于FreeBSD的Floppy Firewall系统。如此，一来可以节约硬件成本，因为所有配件下来不到150元；二来可以方便日后的维护，因为一旦配置好防火墙之后，再也不怕断电等会导致硬盘版操作系统数据丢失的意外事故，也方便系统的备份（仅仅备份一张软盘镜像而已）；三来可以对在防火墙后的专用服务器提供一道安全屏障，这点是显而易见的，虽然对于我们来说网络安全并不是太重要。

　　这套由cnfug开发的软盘版的FreeBSD防火墙使用的是4.9版本的FreeBSD，防火墙使用的是IP FilterV3.4.20，改造后的网络的整体拓扑结构如图2-1所示。


　　　　　　本案例的需求主要有四点：

　　1、 子网192.168.0.0/24中的所有电脑可以借助网关(防火墙)192.168.0.1透明地访问互联网。（注：192.168.0.0/24这种格式在IP Filter 的rules中大量使用，其中/24＝3×8表示三个字节的子网掩码255.255.255.0，掩盖一个C类网段，在这里表示IP地址前三段等于192.168.0的所有电脑。同理，/16表示一个B类网，/32唯一标识一台主机。）

　　2、 外网的客户机可以透明地可以访问IP地址为192.168.0.251的多功能服务器（Web、Email、Ftp服务）和IP地址为192.168.0.2的文件兼打印服务器。

　　3、 内网客户机可以和外网客户机一样通过访问外网IP202.115.65.225来访问内网的web、email等服务器。

　　4、 内网的客户机可以访问远程的Ftp服务器同时外网的客户端也可访问内网的Ftp服务器。（由于Ftp协议的特殊性在此专门提出） 从图2-1看到，防火墙的两块8139网卡rl1和rl0分别连接Internet和局域网的交换机，外网卡IP地址为202.115.65.225内网卡IP地址为192.168.0.1。由于内核中IPf的缺省设置为block all，即过滤所有的包，在该情况下，防火墙的两块网卡不能和外界有任何数据交换，ping任何地址都提示“ping:sendto: no route to host”，所以必须人工配置IPf规则，如下命令可完成让所有数据报自由进出防火墙的两块网卡：

#cat << end > ipf.conf //红色的字表示是系统提示符
>pass in all //允许任何包从任何网卡进
>pass out all //允许任何包从任何网卡出
>end //保存
#ipf –f ipf.conf //执行ipf.conf文件中的过滤规则
#sysctl –w net.inet.ip.forwarding =1 //打开内核的ip转发

　　现在防火墙没有任何过滤规则，可以允许所有的数据报自由进出自己的两块网卡，但是它还不知道如何把到达其上的数据报转发，下面我将详细介绍怎么让它按照我们的需求转发数据报，这也是本文的重点所在。（注：本文主要目的是介绍IP filter防火墙软件对数据报转发机理，也就是路由功能，对于如何对数据报进行过滤不是本文的内容，请参考IPf的相关文献。）

三、IP Filter NAT机理分析

　　IP Filter的功能主要包括过滤和路由两部分，所以该防火墙软件包有两个主要工具－IPf和IPnat。IPf可以实现数据报过滤，上一节就用到了IPf命令来使pass in/our all过滤规则生效， 路由功能则由IPnat来实现，IPnat命令用来读取并执行用户设定的路由规则。

3.1 用map指令来共享IP地址

　　为了让192.168.0.0/24（24=3×8即三个字节的子网）的电脑可以共享一个外网IP来访问互联网，用一条最基本的两条rules就可以实现，如下所示：

map rl1 192.168.0.0/24 -> 202.115.65.225/32 portmap tcp/udp 10000:39999
map rl1 192.168.0.0/24 -> 202.115.65.225/32

　　这两条rules从字面上很好解释，即在网卡rl1上把192.168.0.*(/24表示3字节的子网掩码，标识一个C类网段的所有IP地址)网段的所有IP地址和IP地址202.115.65.225（/32表示4字节的子网掩码，唯一标识一个IP地址）进行单向映射，portmap的用处是告诉防火墙把内网客户机的端口进行临时存储时的映射范围为10000-39999，具体原理在下面将详述。


　　　　　　　　　　图3-1 内网用户访问外网WEB服务器的映射过程

　　从图3-1中，内网中IP地址为192.168.0.3的PC客户机欲访问外网的IP地址为202.108.249.134的web服务器，连接过程如下：

　　①建立连接阶段（SYN第一次握手）：客户机先建立一个随机的TCP端口1413准备和web服务器的80端口连接，但由于它们不在同一个网段，所以请求连接的SYN数据报被发送到了和客户机在同一个网段的网关服务器，在这里网关服务器就是我们的防火墙兼路由器，所以数据报在数据链路层会先发送至我们的防火墙的内网卡，从下面捕获的数据报中可以看到，数据报的以太帧的目的地址是网关的MAC地址。网关即防火墙收到该数据报之后解开IP报取出目的IP地址，发现目的地址是外网IP所以在内部就转发到外网卡rl1，rl1会按照IPnat设置的转发规则，把在192.168.0.*发来的数据报接受下来，然后改变IP头中的源地址为它的IP地址（202.115.65.225），map指令会把内部客户端的IP和端口号暂时保存在一个临时路由表中以便接受到返回的数据报时可以正确地交付给客户端，客户机的端口号并不是直接保存起来，而是防火墙先在portmap的范围内找到一个端口和其一一对应起来保存，前面的设置portmap的范围为10000:39999的原因主要是因为这个范围的端口一般不会被防火墙上本身自己的监听端口相同，如果端口冲突的话会导致严重问题，这种暂存功能在防火墙过滤中也经常被使用，Ipf规则中的keep state就是用来在屏蔽外网数据进入的状态下把内网的请求端口号临时保存到一张路由表中以便返回数据报可以顺利被接收。


　　　　　　　　　图3-2 嗅探器捕获的内网访问外网web服务器的数据报

　　②对方确认阶段（SNY ACK第二次握手）：外网WEB服务器接收到了以202.115.65.225为源地址的连接请求，所以它会自动发会一个SYN连接请求并捎带一个ACK确认数据报，这个数据报将被防火墙外网卡rl1接收，防火墙收到后分析IP包的端口号并从临时路由表中计算出该数据报应该转发到哪一个客户机，当然在我们的例子中它会把该数据报发还给192.168.0.3的客户机，正如图3-2②所示。

　　③连接的最后确认（ACK 第三次握手）：内网客户机收到WEB服务器的ACK＋SYN数据报后认为连接已经成功了，然后发送最后一个确认数据报给对方，防火墙对该数据报的处理步骤同①。

　　④发送HTTP连接请求：客户机发送的第一个携带HTTP数据的包从这里开始，第一个数据报是HTTP连接请求。

　　⑤WEB服务器回复数据报：WEB服务器顺利接收到HTTP请求马上给予回复的数据报，数据报如果标号是200则表示HTTP连接正常，接下来就可以把对方请求的WEB页传给客户机。

　　完成了上面的5个过程，一个对用户透明的HTTP连接就建立了起来，对于客户端的用户来说，好像是直接连接到WEB服务器上去的，这都有赖于IPnat的功劳。

3.2用rdr指令实现NAT转换

　　为了让外网的客户机可以通过IP 202.115.65.225访问到位于内网中的web、mail、Ftp服务器，IPnat的rule相应的设置为：

rdr rl1 202.115.65.225/32 port 80 -> 192.168.0.221 port 80
rdr rl1 202.115.65.225/32 port 21 -> 192.168.0.251 port 21
rdr rl1 202.115.65.225/32 port 25 -> 192.168.0.251 port 25
rdr rl1 202.115.65.225/32 port 110 -> 192.168.0.251 port 110

　　这条规则从字面上也很好解释，rdr是rewrites destination addresses的意思，其功能是把防火墙上接收到的数据报改变目的地址（转发）到另外的一台或多台主机上，上面的指令可以解释为，把rl1（外网卡）上接收到的数据报按照指定的端口转发到指定的位于内网的服务器上，80、21、25、110分别代表web、Ftp、smtp和pop3服务，所以这四条指令会把外网对防火墙的web、Ftp和mail请求转发到IP为192.168.0.251内网服务器上，下面以web服务为例来分析其工作流程。

　　如图3-3所示，IP地址为202.115.65.38的客户端欲用IP地址202.115.65.225访问位于局域网内部的IP地址为192.168.0.221的WEB服务器，连接过程如下：


　　　　　　　　图3-3 外网客户访问内网WEB服务器的过程


　　　　　　　　　图3-4 从外网客户机上捕获的数据报

　　①发起连接阶段（SYN）：客户机202.115.65.38建立临时端口1123发起对202.115.65.225的80（http）端口的连接请求。该连接请求被传送到了防火墙的外网卡rl1上，按照前面设置的IPnat的规则，防火墙会把在rl1上对80端口的请求数据报要改变其目的地址为192.168.0.221后转发给目的主机。

　　②服务器确认阶段（SYN ACK第二次握手）：对于位于内网的web服务器来说，虽然它收到的HTTP连接请求是防火墙转发给它的，但是转发过程没有改动IP数据包的头信息，仅仅改动了数据链路层的地址信息，所以它以为请求是直接从202.115.65.38上发出的，因此它会立刻给202.115.65.38发确认数据报，这个过程其实等于202.115.65.38是外网服务器，192.168.0.221是内网客户端，数据报的转发过程和我们上一节讨论的map机制完全一样，数据报会透明地被转发到202.115.65.38，只不过数据报的源IP地址被防火墙改为了202.115.65.225，如果没有设置前面的map规则，数据包将无法回送，连接会失败告终。从图3-4的第2步我们可以清晰看到外网客户端接收到了返回的确认数据报。

　　③连接的最后确认（ACK 第三次握手）：外网客户端回送确认数据报给内网web服务器，这个过程和第一步类似不再详述。

　　④－⑤是HTTP连接建立，和上一节类似。

3.3用bimap指令实现NAT转换

　　bimap指令可以说是map指令的增强版，map实现的是单向映向，而bimap能够实现双向的同时映向，它其实实现了rdr＋map的功能，其主要应用到你想把所有的外部请求都转换到内网的一台服务器上或几台运行相同服务的负载均衡服务器群上。比如上面提到的案例中的192.168.0.251是一个身兼多职的综合服务器，设置如下bimap规则后对外部来说202.115.65.225就等同于192.168.0.251，对202.115.65.225的web、mail、DNS、telnet等等访问会一股脑地发给192.168.0.251，用rdr来实现同样的效果则必须每个服务作一个转换。

bimap rl1 192.168.0.251/32 -> 202.115.65.225/32
bimap rl1 202.115.65.225/32 -> 192.168.0.251/32

　　在我的试验中，上面两个规则都能达到同样的效果，这也充分的说明了该指令执行的是双向的映射。虽然bimap使用起来如此简单，但是bimap并没有被广泛使用，原因非常简单，因为它只能把外部数据报转到内网的一台主机上（负载均衡服务器群组其实相当于一台服务器），如果想把web、Ftp、email服务器分别让两台以上的主机充当用bimap将无法做到，所以rdr被广泛推崇和采纳。

　　由于前面已经比较详尽的分别分析了rdr和map的工作机理，对于bimap来说就是rdr和map的组合，所以本文将不做详细介绍。

四、案例需求的实现

4.1需求一的实现

　　案例的需求一是让子网192.168.0.0/24中的所有电脑可以借助网关192.168.0.1透明地访问互联网。这其实是IPnat的最基本的功能，上面的已经做了详尽的分析，rules设置如下：

map rl1 192.168.0.0/24 -> 202.115.65.225/32 portmap tcp/udp 10000:39999
map rl1 192.168.0.0/24 -> 202.115.65.225/32

4.2需求二的实现

　　案例需求二是要实现外网的客户机可以透明地可以访问IP地址为192.168.0.251的多功能服务器（Web、Email、Ftp服务）和IP地址为192.168.0.2的文件兼打印服务器。这其实也是IPnat的基本功能，rules设置如下：

rdr rl1 202.115.65.225/32 port 80 192.168.0.251 port 80 \\web
rdr rl1 202.115.65.225/32 port 21 192.168.0.251 port 21 \\Ftp
rdr rl1 202.115.65.225/32 port 25 192.168.0.251 port 25 \\smtp
rdr rl1 202.115.65.225/32 port 110 192.168.0.251 port 110 \\pop3
rdr rl1 202.115.65.225/32 port 139 192.168.0.2 port 139 \\文件共享

4.3需求三的实现

　　案例需求三是要实现内网的用户可以以外网的地址访问内网的web、email等服务器，该需求不是非常的普遍，所以很难在现有的资料上找到rules的配置方法。该需求从表面上来看和需求二很相似，但是它们有一个本质的区别，那就是需求二的请求数据报的传给的是外部网卡rl1，而本需求的请求是内网发起的所以请求数据报会被内网卡rl0接收，所以用需求二设置的rules是不能够实现本需求的。

　　首先我们以web服务为例来一步一步地探索rules的配置方法。第一步可以仿照需求二的rules把rl1改为rl0，让防火墙会自动转发内网的请求数据报，这将得到下面的rule：

rdr rl0 202.115.65.225/32 port 80 -> 192.168.0.251 port 80 \\web

　　在设置并执行上面的rule后用客户端192.168.0.221试图访问202.115.65.225后失败，表现为延迟一段时间后弹出打不开网页提示。为了找到问题根源所在，分别在客户端和服务器端用捕获数据报进行分析，在客户端和服务器端捕获的数据报如图4-1所示：


　　　　　　　　图4-1 在配置错误时同时捕获到的客户端和服务器端数据报

　　图中的1-7是数据报收发的顺序，1处表明连接请求是从192.168.0.221发至202.115.65.225的，防火墙将会在内网卡rl0接收到了数据报，按照IPnat的rule，防火墙会给客户机发一个ICMP报文告诉客户机有一条更好的路径可以到达目的主机，如图4-2所示：


　　　　　　　　　图4-2 防火墙发给客户端redirect指令的ICMP报文

　　ICMP报文的code是“5”，说明其目的是一个转发控制，gateway address是192.168.0.251就是告诉客户机把对目的主机的请求数据报去选择一条更好的路由192.168.0.251（原本是192.168.0.1），在ICMP数据报的后面还携带了原IP报的报头信息。2处表明客户机已经知道数据可以直接发送到192.168.0.251，3处可以看到服务器收到了连接请求，4处表明服务器直接回送确认给客户机，5处表明客户机收到了了服务器的确认信息，6处是该次试验失败的直接原因，因为客户机没有发ACK作应答而是发了一个RST同服务器断开连接，7表示服务器收到客户机RST复位指令断开连接。根据TCP/IP协议，RST指令一般在一个TCP连接结束的时候和数据包发生了某些错误时被发出，现在的情况很明显不应该是TCP连接结束的原因那一定是TCP的三次握手没有成功导致的，仔细观察1、5、6这三次握手的报文记录发现原因在于第一个请求是的服务器是202.115.65.225，之后的两次握手的服务器地址是192.168.0.251，对于客户机来说，它会认为在5处的回复信息不是对应于它请求的回复，是非法的所以给予RST消息断开连接。所以问题的关键在于要把第二次握手的服务器IP地址转换为202.115.65.225，从5处可以知道第二次握手是服务器发给直接发给客户机的，所以源地址只能是192.168.0.251，所以不能让它直接回复客户机，为了让其不直接回复客户机又要让客户机可以收到它的回复那只有找防火墙作为中介。如果让防火墙能够记住客户端的地址和端口号然后代替客户端向服务器发送请求，之后再把服务器的回复按照客户端的地址和端口返回给客户端那就可以实现一次完整的TCP连接了，而这个功能恰好是IPnat中的map指令可以完成的，所以解决问题的方法就非常明显了，加入下面rule执行就解决了问题，捕获的包如：

map rl0 192.168.0.0/24 -> 202.115.65.225/32

　　图4-3所示。其工作流程和前面分析的让内网访问外网的原理相同，不同之出就在于这个rule只对内网卡rl0有效。


　　　　　　　　　图4-3 配置正确的rules之后的客户机与服务器的交互过程

　　从图4-3可以清晰地看到，202.115.65.225成为了客户机和服务器的中间代理，忠实地转发着所有的数据报文。

4.4需求四的实现

4.4.1内网Client访问外网Ftp Server

　　需求四首先要求内网的客户机可以访问远程的Ftp服务器。之所以把访问Ftp服务单独拿出来作为一个需求是由Ftp协议的特殊性决定的，以web服务为例，web服务器始终都是在一个端口上为客户机提供HTTP连接和传输服务，缺省的HTTP端口为80端口（但不限定）。所以对于这种服务，客户机仅仅需要随机地打开一个TCP端口和对应的服务器建立连接，而这个端口会被防火墙map指令映射到防火墙portmap范围内的端口后暂存起来，等数据返回时可以正确地递交给客户机。而Ftp服务仅仅使用缺省的21端口来建立连接和传递控制数据，它还需要开辟另外一条TCP连接通道来专门传输文件数据，其实不光Ftp服务，netmeeting,pptp等服务器工作模式也是类似，这里以仅仅是以最常见的Ftp为例而已。

　　Ftp服务器建立第二条TCP连接通道的方法有两种，分别是PORT模式和PASV模式，通常被称为主动模式和被动模式。主动模式就是客户端在确认已经和Ftp服务器建立了连接之后在客户端主动打开一个随机的端口来和服务器进行数据传送，同时向服务器发出PORT指令告诉服务器自己开设的端口；被动模式和主动模式相反，客户端在和服务器端建立连接后发送PASV要求以被动模式建立数据传输通道，服务器端就会先开放一个端口来侦听客户机的连接以便建立数据传输通道。在该案例中，直接用FlashFXP访问外部Ftp服务器只有用PASV模式才能成功，执行情况如图4-4所示：


　　　　　　图4-4 客户端用FlashFXP用PASV和PORT模式访问外部Ftp服务器

　　之所以PASV模式可以成功是因为这种模式下两个TCP连接过程占据主动始终是服务器，客户机被动地连接服务器，仅仅相当于简单增加了一个线程。PORT模式之所以失败是因为在建立第二个TCP数据通道的时候是由客户端先创建端口来让服务器连接，这样内网客户端和外网服务器都同时充当Client和Server的角色。如图4-4客户端发出PORT指令要求外网的服务器端连接自己的143端口，在经过防火墙后携带PORT指令的IP包的源地址会更改为防火墙的对外地址202.115.65.225，所以外网的服务器收到了请求后会去试图连接202.115.65.225的143端口，这等同于外网的服务器是一台欲访问内网Server的Client，如果要实现该数据报的正确转发，须在防火墙上应该加一条rule：“rdr rl1 202.115.65.225 port 143 -> 192.168.0.221 port 143”来实现，但是由于位于内网客户机的端口和IP地址都是随时变化的，无法事先为其设置rules。好在rule中有一种PROXY参数是专门为解决该类问题设计的。在这个案例中rule设置如下：

map rl1 192.168.0.0/24 -> 202.115.65.225/32 proxy port Ftp Ftp/tcp


　　　　　图4-5 设置好proxy rule后捕获的内网客户端和外网服务器的连接数据

　　图4-5是设置成功后内网客户端以PORT模式和外网Ftp建立连接时捕获的数据报，从中可以看出内网的客户机首先打开了2224（一般大于1024）的端口等待外网的服务器的接入，外网的服务器之所以知道客户端的新开的端口号是因为客户端在此之前发送了一个PORT帧，格式为“PORT 192,168,0,221,8,176”，这个帧会先被防火墙一直监听客户机发往外部21端口数据的外网卡捕获并且PORT帧中的客户端地址以及端口会被修改为防火墙地址和映射端口，之后防火墙把修改后的数据转发给Ftp服务器，所以Ftp服务器才会创建一个新端口来和客户机建立连接，完成一次完整的PORT过程。

4.4.2外网Client访问内网Ftp Server

从上一小节介绍了如何让内网的客户端访问外网的Ftp服务器在使用PORT模式可以顺利通过，而这一小节要解决的问题和上一小节的刚好相反，外网的客户端使用PORT模式可以在现有的rules基础上不做任何更改就能和内网Ftp服务器建立连接并传输数据，但用PASV模式反而不行，如图4-6所示。这种现象在上一小节已经分析得比较清楚了，因为PASV模式下，在内网的服务器端会建立一个随机监听端口并在此之前给外网客户机送一个带有其IP地址（192.168.0.*的内网地址）和新建端口号信息的PASV帧，外网的客户端能正确的接收到该帧然后以“192.168.0.*:服务器新端口号”为目的地址回复确认报文，当然这种数据报是不可能发送到目的地的，如图4-7所示。


图4-6 外网客户端FlashFXP用PASV模式时收到到的错误信息


　　　　　　　　　　图4-7 从外网客户端捕获的连接失败过程的数据报

　　通过分析发现问题的主要症结就在于服务器端告诉客户端的IP地址是一个内网地址，这个信息和普通的TCP连接的源地址不一样，后者的地址信息放置在IP报头里，防火墙有能力分析并映射为自己的IP，而前者的地址信息放置在上层的应用层报文内部，防火墙不会对每个报文的应用层数据帧进行分析处理，所以内网IP地址不能被转换成防火墙的真实IP。既然防火墙没有办法实现那只有找发送PASV的服务器寻找解决问题的方法。好在大部分的Ftp服务器都支持手动调节PASV信息帧的内容，拿Windows平台最流行的Server-U服务器为例，设置如图4-8所示：


　　图4-8 Server－U设定PASV的IP和随机端口范围

　　在这种情况下,内网服务器给外网客户会发一个PASV告诉客户端确认报文发送到202.115.65.225，端口为40000到60000随机产生的一个确定数值，外网客户端按照要求回复的数据报会被防火墙接收，但它还不知道怎么转发到内网服务器，还需加入下面rule才能正确转发到内网Ftp服务器。

rdr rl1 202.115.65.225/32 port 40000-60000 -> 192.168.0.221 port 40000 tcp

　　这条rule会把请求40000-60000的端口范围的数据报转发到192.168.0.221 Ftp服务器。


　　　　　　　　　　图4-9 连接成功后的客户端和服务器端捕获的数据报

五、总结

　　把所有的rules汇总生成最后的rules 如下：

map rl1 192.168.0.0/24 -> 202.115.65.225/32 portmap tcp/udp 10000:39999
map rl1 192.168.0.0/24 -> 202.115.65.225/32
map rl0 192.168.0.0/24 -> 202.115.65.225/32
rdr rl1 202.115.65.225/32 port 40000-60000 -> 192.168.0.251 port 40000 tcp
map rl1 192.168.0.0/24 -> 202.115.65.225/32 proxy port Ftp Ftp/tcp
rdr rl1 202.115.65.225/32 port 80 -> 192.168.0.251 port 80
rdr rl1 202.115.65.225/32 port 21 -> 192.168.0.251 port 21
rdr rl1 202.115.65.225/32 port 25 -> 192.168.0.251 port 25
rdr rl1 202.115.65.225/32 port 110 -> 192.168.0.251 port 110
rdr rl1 202.115.65.225/32 port 139 -> 192.168.0.2 port 139
rdr rl0 202.115.65.225/32 port 139 -> 192.168.0.2 port 139
rdr rl0 202.115.65.225/32 port 80 -> 192.168.0.251 port 80
rdr rl0 202.115.65.225/32 port 21 -> 192.168.0.251 port 21
rdr rl0 202.115.65.225/32 port 25 -> 192.168.0.251 port 25
rdr rl0 202.115.65.225/32 port 110 -> 192.168.0.251 port 110
rdr rl0 202.115.65.225/32 port 139 -> 192.168.0.251 port 139

　　把上面的rules保存到nat.conf文件中后运行下面的命令，防火墙就能完成案例的所有需求了。

#ipnat –CF
#ipnat –f nat.conf

　　本文经过分析简单的rule来推测著名防火墙软件IP Filter的NAT工作机理，并在此基础上探讨了复杂路由的设计思路，结合实际案例分析路由数据报的收发流程并提出了完美的解决方案。