基于IP Filter的NAT透析
四、案例需求的实现
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过程。
|
