基于ip filter的nat透析 - china freebsd user group.htm

ip filter

filter防火墙软件对数据报转发机理，也就是路由功能，对于如何对数据报进行过滤不是本文的内容，请参考IPf的相关文献。）<BR><BR><FONT 
class=subhead>三、IP Filter NAT机理分析</FONT><BR><BR>　　IP 
Filter的功能主要包括过滤和路由两部分，所以该防火墙软件包有两个主要工具－IPf和IPnat。IPf可以实现数据报过滤，上一节就用到了IPf命令来使pass 
in/our all过滤规则生效， 路由功能则由IPnat来实现，IPnat命令用来读取并执行用户设定的路由规则。<BR><BR><FONT 
class=subhead>3.1 
用map指令来共享IP地址</FONT><BR><BR>　　为了让192.168.0.0/24（24=3×8即三个字节的子网）的电脑可以共享一个外网IP来访问互联网，用一条最基本的两条rules就可以实现，如下所示：<BR>
<DIV class=code>map rl1 192.168.0.0/24 -&gt; 202.115.65.225/32 portmap tcp/udp 
10000:39999<BR>map rl1 192.168.0.0/24 -&gt; 
202.115.65.225/32</DIV>　　这两条rules从字面上很好解释，即在网卡rl1上把192.168.0.*(/24表示3字节的子网掩码，标识一个C类网段的所有IP地址)网段的所有IP地址和IP地址202.115.65.225（/32表示4字节的子网掩码，唯一标识一个IP地址）进行单向映射，portmap的用处是告诉防火墙把内网客户机的端口进行临时存储时的映射范围为10000-39999，具体原理在下面将详述。<BR><BR>
<DIV align=center><IMG height=219 alt=issue12_firewallroute.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_firewallroute.jpg" 
width=506 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0></DIV><BR>
<DIV align=center>图3-1 
内网用户访问外网WEB服务器的映射过程</DIV>　　从图3-1中，内网中IP地址为192.168.0.3的PC客户机欲访问外网的IP地址为202.108.249.134的web服务器，连接过程如下：<BR><BR>　　①建立连接阶段（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就是用来在屏蔽外网数据进入的状态下把内网的请求端口号临时保存到一张路由表中以便返回数据报可以顺利被接收。 <BR><BR><IMG 
height=304 alt=issue12_sniff1.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff1.jpg" 
width=553 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0><BR>
<DIV align=center>图3-2 嗅探器捕获的内网访问外网web服务器的数据报</DIV><BR>　　②对方确认阶段（SNY 
ACK第二次握手）：外网WEB服务器接收到了以202.115.65.225为源地址的连接请求，所以它会自动发会一个SYN连接请求并捎带一个ACK确认数据报，这个数据报将被防火墙外网卡rl1接收，防火墙收到后分析IP包的端口号并从临时路由表中计算出该数据报应该转发到哪一个客户机，当然在我们的例子中它会把该数据报发还给192.168.0.3的客户机，正如图3-2②所示。<BR>　　③连接的最后确认（ACK 
第三次握手）：内网客户机收到WEB服务器的ACK＋SYN数据报<BR>后认为连接已经成功了，然后发送最后一个确认数据报给对方，防火墙对该数据报的处理步骤同①。<BR>　　④发送HTTP连接请求：客户机发送的第一个携带HTTP数据的包从这里开始，第一个数据报是HTTP连接请求。<BR>　　⑤WEB服务器回复数据报：WEB服务器顺利接收到HTTP请求马上给予回复的数据报，数据报如果标号是200则表示HTTP连接正常，接下来就可以把对方请求的WEB页传给客户机。<BR>完成了上面的5个过程，一个对用户透明的HTTP连接就建立了起来，对于客户端的用户来说，好像是直接连接到WEB服务器上去的，这都有赖于IPnat的功劳。<BR><BR><FONT 
class=subhead>3.2用rdr指令实现NAT转换</FONT><BR><BR>　　为了让外网的客户机可以通过IP 
202.115.65.225访问到位于内网中的web、mail、Ftp服务器，IPnat的rule相应的设置为：<BR>
<DIV class=code>rdr rl1 202.115.65.225/32 port 80 -&gt; 192.168.0.221 port 
80<BR>rdr rl1 202.115.65.225/32 port 21 -&gt; 192.168.0.251 port 21<BR>rdr rl1 
202.115.65.225/32 port 25 -&gt; 192.168.0.251 port 25<BR>rdr rl1 
202.115.65.225/32 port 110 -&gt; 192.168.0.251 port 
110</DIV>　　这条规则从字面上也很好解释，rdr是rewrites destination 
addresses的意思，其功能是把防火墙上接收到的数据报改变目的地址（转发）到另外的一台或多台主机上，上面的指令可以解释为，把rl1（外网卡）上接收到的数据报按照指定的端口转发到指定的位于内网的服务器上，80、21、25、110分别代表web、Ftp、smtp和pop3服务，所以这四条指令会把外网对防火墙的web、Ftp和mail请求转发到IP为192.168.0.251内网服务器上，下面以web服务为例来分析其工作流程。<BR>如图3-3所示，IP地址为202.115.65.38的客户端欲用IP地址202.115.65.225访问位于局域网内部的IP地址为192.168.0.221的WEB服务器，连接过程如下：<BR>
<DIV align=center><IMG height=217 alt=issue12_firewallroutehttp.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_firewallroutehttp.jpg" 
width=497 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0></DIV>
<DIV align=center>图3-3 外网客户访问内网WEB服务器的过程</DIV><BR>
<DIV align=center><IMG height=143 alt=issue12_sniff2.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff2.jpg" 
width=564 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0><BR></DIV>
<DIV align=center>图3-4 
从外网客户机上捕获的数据报</DIV>　　①发起连接阶段（SYN）：客户机202.115.65.38建立临时端口1123发起对202.115.65.225的80（http）端口的连接请求。该连接请求被传送到了防火墙的外网卡rl1上，按照前面设置的IPnat的规则，防火墙会把在rl1上对80端口的请求数据报要改变其目的地址为192.168.0.221后转发给目的主机。<BR>　　②服务器确认阶段（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步我们可以清晰看到外网客户端接收到了返回的确认数据报。<BR>　　③连接的最后确认（ACK 
第三次握手）：外网客户端回送确认数据报给内网web服务器，这个过程和第一步类似不再详述。<BR>　　④－⑤是HTTP连接建立，和上一节类似。<BR><BR><FONT 
class=subhead>3.3用bimap指令实现NAT转换</FONT><BR><BR>　　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来实现同样的效果则必须每个服务作一个转换。<BR>
<DIV class=code>bimap rl1 192.168.0.251/32 -&gt; 202.115.65.225/32<BR>bimap rl1 
202.115.65.225/32 -&gt; 192.168.0.251/32 
</DIV>　　在我的试验中，上面两个规则都能达到同样的效果，这也充分的说明了该指令执行的是双向的映射。虽然bimap使用起来如此简单，但是bimap并没有被广泛使用，原因非常简单，因为它只能把外部数据报转到内网的一台主机上（负载均衡服务器群组其实相当于一台服务器），如果想把web、Ftp、email服务器分别让两台以上的主机充当用bimap将无法做到，所以rdr被广泛推崇和采纳。<BR>由于前面已经比较详尽的分别分析了rdr和map的工作机理，对于bimap来说就是rdr和map的组合，所以本文将不做详细介绍。<BR><BR><FONT 
class=subhead>四、案例需求的实现</FONT><BR><BR><FONT 
class=subhead>4.1需求一的实现</FONT><BR><BR>　　案例的需求一是让子网192.168.0.0/24中的所有电脑可以借助网关192.168.0.1透明地访问互联网。这其实是IPnat的最基本的功能，上面的已经做了详尽的分析，rules设置如下：<BR>
<DIV class=code>map rl1 192.168.0.0/24 -&gt; 202.115.65.225/32 portmap tcp/udp 
10000:39999<BR>map rl1 192.168.0.0/24 -&gt; 202.115.65.225/32</DIV><FONT 
class=subhead>4.2需求二的实现</FONT><BR><BR>　　案例需求二是要实现外网的客户机可以透明地可以访问IP地址为192.168.0.251的多功能服务器（Web、Email、Ftp服务）和IP地址为192.168.0.2的文件兼打印服务器。这其实也是IPnat的基本功能，rules设置如下：<BR>
<DIV class=code>rdr rl1 202.115.65.225/32 port 80 192.168.0.251 port 80 
\\web<BR>rdr rl1 202.115.65.225/32 port 21 192.168.0.251 port 21 \\Ftp<BR>rdr 
rl1 202.115.65.225/32 port 25 192.168.0.251 port 25 \\smtp<BR>rdr rl1 
202.115.65.225/32 port 110 192.168.0.251 port 110 \\pop3<BR>rdr rl1 
202.115.65.225/32 port 139 192.168.0.2 port 139 \\文件共享 </DIV><FONT 
class=subhead>4.3需求三的实现</FONT><BR><BR>　　案例需求三是要实现内网的用户可以以外网的地址访问内网的web、email等服务器，该需求不是非常的普遍，所以很难在现有的资料上找到rules的配置方法。该需求从表面上来看和需求二很相似，但是它们有一个本质的区别，那就是需求二的请求数据报的传给的是外部网卡rl1，而本需求的请求是内网发起的所以请求数据报会被内网卡rl0接收，所以用需求二设置的rules是不能够实现本需求的。<BR><BR>　　首先我们以web服务为例来一步一步地探索rules的配置方法。第一步可以仿照需求二的rules把rl1改为rl0，让防火墙会自动转发内网的请求数据报，这将得到下面的rule：<BR>
<DIV class=code>rdr rl0 202.115.65.225/32 port 80 -&gt; 192.168.0.251 port 80 
\\web</DIV>　　在设置并执行上面的rule后用客户端192.168.0.221试图访问202.115.65.225后失败，表现为延迟一段时间后弹出打不开网页提示。为了找到问题根源所在，分别在客户端和服务器端用捕获数据报进行分析，在客户端和服务器端捕获的数据报如图4-1所示：<BR><BR><IMG 
height=186 alt=issue12_sniff3.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff3.jpg" 
width=566 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0> <BR>
<DIV align=center>图4-1 
在配置错误时同时捕获到的客户端和服务器端数据报</DIV><BR>　　图中的1-7是数据报收发的顺序，1处表明连接请求是从192.168.0.221发至202.115.65.225的，防火墙将会在内网卡rl0接收到了数据报，按照IPnat的rule，防火墙会给客户机发一个ICMP报文告诉客户机有一条更好的路径可以到达目的主机，如图4-2所示：<BR><BR><IMG 
height=71 alt=issue12_sniff4.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff4.jpg" 
width=567 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0><BR>
<DIV align=center>图4-2 
防火墙发给客户端redirect指令的ICMP报文</DIV><BR>　　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执行就解决了问题，捕获的包如：<BR>
<DIV class=code>map rl0 192.168.0.0/24 -&gt; 
202.115.65.225/32</DIV>　　图4-3所示。其工作流程和前面分析的让内网访问外网的原理相同，不同之出就在于这个rule只对内网卡rl0有效。<BR><BR><IMG 
height=131 alt=issue12_sniff5.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff5.jpg" 
width=567 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0><BR>
<DIV align=center>图4-3 
配置正确的rules之后的客户机与服务器的交互过程</DIV><BR>　　从图4-3可以清晰地看到，202.115.65.225成为了客户机和服务器的中间代理，忠实地转发着所有的数据报文。<BR><BR><FONT 
class=subhead>4.4需求四的实现</FONT><BR><BR><FONT class=subhead>4.4.1内网Client访问外网Ftp 
Server</FONT><BR><BR>　　需求四首先要求内网的客户机可以访问远程的Ftp服务器。之所以把访问Ftp服务单独拿出来作为一个需求是由Ftp协议的特殊性决定的，以web服务为例，web服务器始终都是在一个端口上为客户机提供HTTP连接和传输服务，缺省的HTTP端口为80端口（但不限定）。所以对于这种服务，客户机仅仅需要随机地打开一个TCP端口和对应的服务器建立连接，而这个端口会被防火墙map指令映射到防火墙portmap范围内的端口后暂存起来，等数据返回时可以正确地递交给客户机。而Ftp服务仅仅使用缺省的21端口来建立连接和传递控制数据，它还需要开辟另外一条TCP连接通道来专门传输文件数据，其实不光Ftp服务，netmeeting,pptp等服务器工作模式也是类似，这里以仅仅是以最常见的Ftp为例而已。<BR><BR>　　Ftp服务器建立第二条TCP连接通道的方法有两种，分别是PORT模式和PASV模式，通常被称为主动模式和被动模式。主动模式就是客户端在确认已经和Ftp服务器建立了连接之后在客户端主动打开一个随机的端口来和服务器进行数据传送，同时向服务器发出PORT指令告诉服务器自己开设的端口；被动模式和主动模式相反，客户端在和服务器端建立连接后发送PASV要求以被动模式建立数据传输通道，服务器端就会先开放一个端口来侦听客户机的连接以便建立数据传输通道。在该案例中，直接用FlashFXP访问外部Ftp服务器只有用PASV模式才能成功，执行情况如图4-4所示：<BR><BR><IMG 
height=229 alt=issue12_sniff6.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff6.jpg" 
width=567 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0><BR>
<DIV align=center>图4-4 
客户端用FlashFXP用PASV和PORT模式访问外部Ftp服务器</DIV><BR>　　之所以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 -&gt; 192.168.0.221 port 
143”来实现，但是由于位于内网客户机的端口和IP地址都是随时变化的，无法事先为其设置rules。好在rule中有一种PROXY参数是专门为解决该类问题设计的。在这个案例中rule设置如下：<BR>
<DIV class=code>map rl1 192.168.0.0/24 -&gt; 202.115.65.225/32 proxy port Ftp 
Ftp/tcp</DIV><IMG height=144 alt=issue12_sniff7.jpg 
src="基于IP Filter的NAT透析 - China FreeBSD User Group.files/issue12_sniff7.jpg" 
width=565 
onload="if(this.width>750) {this.style.height='auto';this.style.width='750px'}" 
border=0><BR>
<DIV align=center>图4-5 设置好proxy 
rule后捕获的内网客户端和外网服务器的连接数据报</DIV><BR>　　图4-5是设置成功后内网客户端以PORT模式和外网Ftp建立连接时捕获的数据报，从中可以看出内网的客户机首先打开了2224（一般大于1024）的端口等待外网的服务器的接入，外网的服务器之所以知道客户端的新开的端口号是因为客户端在此之前发送了一个PORT帧，格式为“PORT