iptables和qq

DreamCat

****************（转贴）************************iptables和qq作者：shixudong (stranger)一、提出问题    在用iptables作nat时，qq间通信经常需要通过服务器中转，而且有些时候发送速度很慢。具体表现为以下几种情形：    1、隐身用户或在线用户发送信息给nat后面的隐身用户、离线用户时，总需要经过服务器中转，但此时发送速度并不慢。    2、隐身用户发送信息给nat后面的在线用户时，不管这个隐身用户是不是也在nat后面，总需要经过服务器中转，而且此时发送速度很慢。    3、在线用户a发送信息给nat后面的在线用户b时，又分三种情况：      （1）、在线用户a不在nat后面，当a向b发送信息时，只要b不回答a，那么a发给b的信息总需要经过服务 器中转，而且此时发送速度很慢；一旦b答复了a（由于a不在nat后面，所以b答复a很正常），那么此后a发给b的信息将恢复正常（即不需要中转，发送速度也很快）。      （2）、在线用户a也在nat后面，那么不论是a向b发送信息，还是b回答a的信息，有时候经过服务器中转，此时发送速度很慢；有时候又不必中转，此时发送速度很快。      （3）、是（2）的一个特例，在线用户a和在线用户b在同一个nat后面，他们之间互发信息，总是需要经过服务器中转，而且发送速度很慢。二、分析问题    解铃还需系铃人，既然是在用iptables作nat时出现的问题，那我们还是通过分析iptables的工作原理来分析qq的问题。netfilter/iptables是基于linux2.4内核的具有状态检测功能的新一代包过滤防火墙，它的状态检测功能是通过连接跟踪模块实现的。iptables的连接跟踪模块不仅可以跟踪tcp，还可以跟踪无连接的udp。udp跟踪的实现原理如下：   当一个“初始”udp包从内网到达nat时，iptables会在/proc/net/ip_conntrack文件里记录该udp“连接”的一些信息：源地址/端口、目标地址/端口、期待的应答包的源地址/端口（对应于发送包的目标地址/端口）、期待的应答包的目标地址/端口（对应于发送包的masqed后的源地址/端口，即nat的外部地址/端口）。当该udp的应答包从外网到达nat时，在目标地址/端口符合的前提下，iptables还将用应答包的源地址/端口去匹配先前iptables保存的期待的应答包的源地址/端口。如果源地址/端口匹配，则iptables对其demasq并转交给nat后面的原始发送者；如果源地址/端口不匹配，则由于应答包的目标地址/端口是nat本身，iptables将该包放入INPUT链。一般情况下，INPUT链的默认策略为ACCEPT，则该udp应答包将被转交给nat的本地进程处理，但事实上由于不存在这样的本地进程，结果是nat向产生udp应答包的机器发回一个icmp-port-unreachable包（注意，这个包是linux系统产生的，不是iptables的REJECT目标产生的）。如果INPUT链的策略为DROP，则该udp应答包被DROP。    qq的即时通讯使用了udp，当nat后面的qq用户在登陆注册时，它必须向qq服务器的8000（udp）端口发送登陆请求，这是iptables看到的该udp的初始包，所以iptables记下了它的相关信息，当qq服务器的udp应答包到达nat时，能够匹配源地址/端口，所以iptables将其转交给nat后面的原qq用户。当该qq用户在qq服务器上登陆的同时，也注册了它的地址（发送包的masqed后的源地址/端口，即nat的外部地址/端口）。如果用户a向nat后面的用户b发送信息，分两种情况：    1、b隐身，则a向qq服务器发送信息，然后再由b登陆时对应的qq服务器中转，由于这个中转包总是能够匹配源地址/端口，于是iptables将其转交给nat后面的b，所以此时虽然需要中转，但发送速度并不慢。    2、b在线，则a向b发送信息，实际上就是向b注册的地址发送udp包。然而，iptables在处理这个从外网来的udp包时，由于无法匹配该包的源地址/端口。如前所述，一般情况下，nat会向a发回一个icmp-port-unreachable包（用户a如果使用sniffer，应该能够捕获到这个icmp包）。然后，a会重复这个过程若干次，都无法发送成功。最后只能通过服务器中转，所以发送速度很慢。其实在这种情况下，还可细分：       （1）、a在线且不在nat后面，则只要b答复a，由于这个答复包在iptables看来是一个udp初始包，所以，iptables记下它的相关信息。当以后a再向b发送信息时，就能够匹配源地址/端口，从而a与b之间的通信不必再由服务器中转。        （2）、a在线但也在nat后面，当a第一次向b发送信息时，在a的nat处的iptables也会记录该udp包（ab）的相关信息，但如前所述，这个包无法直接发送到b，必须经由服务器中转。当b答复a时，可分为两种情况：    如果b一收到a发来的信息（由服务器中转），就立即答复a。由于这个答复包在iptables看来是一个udp初始包，所以，iptables记下它的相关信息。当这个答复包到达a处的nat时，由于a处nat的iptables先前记下的相关信息尚未超时，能够匹配源地址/端口，所以该答复包（ba）能够直接发送到a，此后a到b也能直接发送信息。    如果b收到a发来的信息（由服务器中转）后，过了一段时间才答复a。由于这个答复包在iptables看来是一个udp初始包，所以，iptables记下它的相关信息。当这个答复包到达a处的nat时，由于a处nat的iptables先前记下的相关信息已因超时而删除，因而无法匹配源地址/端口，所以该答复包（ba）也只能够经由服务器中转发送到a。作为（2）的一个特例，当a与b在同一个nat后面，无论如何，总是需要经过服务器中转，而且发送速度很慢。在（1）和（2）两种情况下，即使a和b之间已经能够直接互发信息，但如果a与b之间长时间不联络，则由于udp“连接”的超时，iptables会删除超时的相关信息。从而a与b之间的通信将重复上述过程，所以会出现有时需要中转、有时不必中转的现象。（3）、a隐身，则b答复a总是通过服务器中转，当以后a再向b发送信息时，仍然无法匹配源地址/端口，所以a与b之间的通信始终只能通过服务器中转 。虽然双方都需要中转，但是a向b发送消息很慢，而b向a发送消息很快。由上面的分析可知，qq间通信经常需要通过服务器中转，“罪魁祸首”不是nat，而是iptables的连接跟踪。在iptables中，连接跟踪已经作为一个单独的模块被实现，对于nat来说，该模块自动且必须被启用，而在用iptables实现包过滤时，也可以使用连接跟踪功能。换句话说，不仅是nat，即使是包过滤（即和internet直接相连），只要使用了连接跟踪模块，同样无法避免qq间通信时产生服务器中转的现象。如果使用ipchains取代iptables，尽管它没有连接跟踪功能，但在用ipchains作nat时，ipchains会记录一个masq表，该表的功能有些类似于iptables的连接状态表。所以，用ipchains作nat，一般情况下，qq间通信也会出现通过服务器中转的现象。但由于ipchains是基于linux2.2内核，而从linux2.2.3内核开始，另有一个参数专门用于控制udp，即/proc/sys/net/ipv4/ip_masq_udp_dloose。如果ip_masq_udp_dloose为0，则ipchains处理从外网到来的udp时，必须去匹配源地址/端口。如果ip_masq_udp_dloose为1，则ipchains处理从外网到来的udp时，不去匹配源地址/端口，任何目标地址/端口符合的udp包，都将被ipchains转交给nat后面的原qq用户，从而也就不会出现qq间通信通过服务器中转的现象。从linux2.2.16内核开始，ip_masq_udp_dloose默认为0，而在此之前，ip_masq_udp_dloose默认为1。也就是说，如果使用linux2.2.3内核以后、linux2.2.16内核以前的ipchains，默认情况下，qq间通信是不会出现通过服务器中转现象的。三、解决问题前文提到，qq间通信经常需要通过服务器中转，是由iptables的连接跟踪功能造成的。事实上，不仅是qq，只要是基于udp的即时通讯软件，在使用iptables的连接跟踪功能时都有这个问题；还有我们常用的tftp客户端，由于tftp服务端返回的udp包使用的源端口不同于客户端发出的udp包的目标端口，所以也无法和iptables的连接跟踪功能一道使用。为了使这些软件能和iptables的连接跟踪功能协同工作，需要加载附加的连接跟踪模块，如ip_conntrack_qq.o、ip_conntrack_tftp.o。此外，为了使这些软件在nat后面也能正常工作，考虑到nat总是和iptables的连接跟踪捆绑在一起，所以，在nat环境下，不仅需要加载这些软件的连接跟踪模块，还需要加载它们的nat模块，如ip_nat_qq.o、ip_nat_tftp.o。然而，到目前为止，netfilter/iptables的标准发布只提供ftp和irc的相关模块。至于其他软件的相关模块，则需要自行编写。有关编写这些连接跟踪和nat相关模块的资料可以参见如下网址：http://www.gnumonks.org/ftp/pub/doc/conntrack+nat.html。下面这个网址列出了一些常用软件（如tftp客户端）的已经可用的连接跟踪和nat相关模块的一些资料：http://netfilter.samba.org/documentation/HOWTO//netfilter-extensions-HOWTO-5.html，具体的模块则可以通过google搜索得到。对于qq软件，编写相关模块的大致思路如下，在qq用户登陆注册时，它必须向qq服务器的8000（udp）端口发送登陆请求，所以该模块只要监控向外的8000（udp）端口的初始连接，一旦发现这个初始连接，该模块就可记住初始udp包对应的masqed后的源地址/端口，即nat的外部地址/端口。以后，当有其他qq用户向这个nat后面的qq用户发送信息时，实际上就是向该模块记住的nat的外部地址/端口发送udp包，只要这些udp包的目标地址/端口符合该模块记住的nat的外部地址/端口，该模块就不去匹配源地址/端口，直接将这些udp包转交给nat后面的原qq用户，从而也就不会出现qq间通信通过服务器中转的现象。这就是ip_conntrack_qq/ip_nat_qq模块的简单实现，至于复杂的实现，还可以让不同nat后面的qq用户进行文件传输。附：LooseUDP与ip_conntrack_qq/ip_nat_qq对qq处理时的区别。前文提过，在用ipchains作nat时，由于使用了LooseUDP的缘故，所以，一般情况下，qq间通信是不会出现通过服务器中转现象的（事实上，也可以disable LooseUDP，而使用一个同样需要自行编写的相关模块ip_masq_qq）。但从linux2.2.16内核开始，出于udp端口扫描漏洞的考虑，LooseUDP的默认状态是disable的。而从linux2.4内核开始，则彻底取消了LooseUDP的功能，这是因为LooseUDP在netfilter/iptables环境下，无法正常工作。仔细研究LooseUDP后，发现它的工作原理与ip伪装的源端口映射方式有关。在使用ipchains作ip伪装时，一般来说，ip伪装后的源端口通常>60000，且在61000--64999之间（具体限制请参阅ip_masq.h文件中的PORT_MASQ_BEGIN 和 PORT_MASQ_END的取值），并且ip伪装后的源端口不可能出现重复，也就是说，根据这个伪装后的源地址/端口，可以唯一映射到nat后面的客户。如果使用LooseUDP，即ip_masq_udp_dloose为1，则ipchains处理从外网到来的udp时，不去匹配源地址/端口，任何目标地址/端口符合ip伪装后的源地址/端口的udp包，都将被ipchains转交给nat后面的唯一客户。由于qq使用udp，所以LooseUDP也对qq有效。但在使用iptables作ip伪装时，nat尽量不去修改源端口，也就是说，ip伪装后的源端口尽可能保持不变。此外，更为重要的是，ip伪装后只需保证源地址/端口与目标地址/端口（即所谓的socket）唯一即可，因此，ip伪装后的源端口有可能出现重复。在这种情况下，只凭伪装后的源地址/端口，就无法唯一映射到nat后面的客户。此时，必须依靠伪装后的源地址/端口（即外网来的udp包的目标地址/端口）加上外网来的udp包的源地址/端口，才可以唯一映射到nat后面的客户。举例说明如下：由于qq的源端口默认总是4000（udp），设想这么一种情况，nat后面有两个qq用户，同时注册到不同的qq服务器，在nat处理他们的udp包时，由于两者的目标地址/端口不同，因而nat不必修改他们的源端口，换句话说，这两个用户经ip伪装后的源端口相同，仍然是4000（udp）。如果按ipchains下的LooseUDP处理方式，iptables在4000端口收到udp包后，如果不匹配该udp包的源地址/端口，就不知道将其转交给nat后面的哪一个qq用户。这也就是LooseUDP在netfilter/iptables环境下无法正常工作的原因。基于同样的理由，在编写qq的相关模块时，千万要注意这一点：必须按照ipchains下的ip伪装方式来处理qq的udp包的源端口映射（当然，端口号的限制不必按该方式），否则，该模块在相应端口（如4000）收到udp包后也无法知道将其转交给nat后面的哪一个qq用户。作者信箱：shixudong@163.com****************（转贴）************************

smile787

基本上看不懂说的什么，描述的不好。用了这么久iptable和模块，都没出现这个问题，全文好像建设在假设上，作者本身理解的就不是很深，为什么说软件有缺陷呢？还不如写点实用的教材。。。iptables连接追踪有问题？看了很多国外官方的，别人的iptable资料，都没说到有这个缺陷了。。。。一直一来用iptables在应用上，没出现这个问题。

cloudsea

基本一，如上楼所说，甚是不解..当然因为我是菜菜...　呵呵不过，我这里的网吧，用SM2.0bate7版，没能这种状态，没能客人反映　QQ发信息慢...而且内网的FTP pasv可用..　这点，我很是不解。照理说，在iptables后面的FTP　，虽然映射了端口...　但可以pasv也太牛了吧？　注：我只映射了21

tikebaby

QUOTE (哈啤猫 @ Aug 22 2004, 11:35 PM)
****************（转贴）************************iptables和qq作者：shixudong (stranger)一、提出问题    在用iptables作nat时，qq间通信经常需要通过服务器中转，而且有些时候发送速度很慢。具体表现为以下几种情形：    1、隐身用户或在线用户发送信息给nat后面的隐身用户、离线用户时，总需要经过服务器中转，但此时发送速度并不慢。    2、隐身用户发送信息给nat后面的在线用户时，不管这个隐身用户是不是也在nat后面，总需要经过服务器中转，而且此时发送速度很慢。    3、在线用户a发送信息给nat后面的在线用户b时，又分三种情况：      （1）、在线用户a不在nat后面，当a向b发送信息时，只要b不回答a，那么a发给b的信息总需要经过服务 器中转，而且此时发送速度很慢；一旦b答复了a（由于a不在nat后面，所以b答复a很正常），那么此后a发给b的信息将恢复正常（即不需要中转，发送速度也很快）。      （2）、在线用户a也在nat后面，那么不论是a向b发送信息，还是b回答a的信息，有时候经过服务器中转，此时发送速度很慢；有时候又不必中转，此时发送速度很快。      （3）、是（2）的一个特例，在线用户a和在线用户b在同一个nat后面，他们之间互发信息，总是需要经过服务器中转，而且发送速度很慢。二、分析问题    解铃还需系铃人，既然是在用iptables作nat时出现的问题，那我们还是通过分析iptables的工作原理来分析qq的问题。netfilter/iptables是基于linux2.4内核的具有状态检测功能的新一代包过滤防火墙，它的状态检测功能是通过连接跟踪模块实现的。iptables的连接跟踪模块不仅可以跟踪tcp，还可以跟踪无连接的udp。udp跟踪的实现原理如下：   当一个“初始”udp包从内网到达nat时，iptables会在/proc/net/ip_conntrack文件里记录该udp“连接”的一些信息：源地址/端口、目标地址/端口、期待的应答包的源地址/端口（对应于发送包的目标地址/端口）、期待的应答包的目标地址/端口（对应于发送包的masqed后的源地址/端口，即nat的外部地址/端口）。当该udp的应答包从外网到达nat时，在目标地址/端口符合的前提下，iptables还将用应答包的源地址/端口去匹配先前iptables保存的期待的应答包的源地址/端口。如果源地址/端口匹配，则iptables对其demasq并转交给nat后面的原始发送者；如果源地址/端口不匹配，则由于应答包的目标地址/端口是nat本身，iptables将该包放入INPUT链。一般情况下，INPUT链的默认策略为ACCEPT，则该udp应答包将被转交给nat的本地进程处理，但事实上由于不存在这样的本地进程，结果是nat向产生udp应答包的机器发回一个icmp-port-unreachable包（注意，这个包是linux系统产生的，不是iptables的REJECT目标产生的）。如果INPUT链的策略为DROP，则该udp应答包被DROP。    qq的即时通讯使用了udp，当nat后面的qq用户在登陆注册时，它必须向qq服务器的8000（udp）端口发送登陆请求，这是iptables看到的该udp的初始包，所以iptables记下了它的相关信息，当qq服务器的udp应答包到达nat时，能够匹配源地址/端口，所以iptables将其转交给nat后面的原qq用户。当该qq用户在qq服务器上登陆的同时，也注册了它的地址（发送包的masqed后的源地址/端口，即nat的外部地址/端口）。如果用户a向nat后面的用户b发送信息，分两种情况：    1、b隐身，则a向qq服务器发送信息，然后再由b登陆时对应的qq服务器中转，由于这个中转包总是能够匹配源地址/端口，于是iptables将其转交给nat后面的b，所以此时虽然需要中转，但发送速度并不慢。    2、b在线，则a向b发送信息，实际上就是向b注册的地址发送udp包。然而，iptables在处理这个从外网来的udp包时，由于无法匹配该包的源地址/端口。如前所述，一般情况下，nat会向a发回一个icmp-port-unreachable包（用户a如果使用sniffer，应该能够捕获到这个icmp包）。然后，a会重复这个过程若干次，都无法发送成功。最后只能通过服务器中转，所以发送速度很慢。其实在这种情况下，还可细分：       （1）、a在线且不在nat后面，则只要b答复a，由于这个答复包在iptables看来是一个udp初始包，所以，iptables记下它的相关信息。当以后a再向b发送信息时，就能够匹配源地址/端口，从而a与b之间的通信不必再由服务器中转。        （2）、a在线但也在nat后面，当a第一次向b发送信息时，在a的nat处的iptables也会记录该udp包（ab）的相关信息，但如前所述，这个包无法直接发送到b，必须经由服务器中转。当b答复a时，可分为两种情况：    如果b一收到a发来的信息（由服务器中转），就立即答复a。由于这个答复包在iptables看来是一个udp初始包，所以，iptables记下它的相关信息。当这个答复包到达a处的nat时，由于a处nat的iptables先前记下的相关信息尚未超时，能够匹配源地址/端口，所以该答复包（ba）能够直接发送到a，此后a到b也能直接发送信息。    如果b收到a发来的信息（由服务器中转）后，过了一段时间才答复a。由于这个答复包在iptables看来是一个udp初始包，所以，iptables记下它的相关信息。当这个答复包到达a处的nat时，由于a处nat的iptables先前记下的相关信息已因超时而删除，因而无法匹配源地址/端口，所以该答复包（ba）也只能够经由服务器中转发送到a。作为（2）的一个特例，当a与b在同一个nat后面，无论如何，总是需要经过服务器中转，而且发送速度很慢。在（1）和（2）两种情况下，即使a和b之间已经能够直接互发信息，但如果a与b之间长时间不联络，则由于udp“连接”的超时，iptables会删除超时的相关信息。从而a与b之间的通信将重复上述过程，所以会出现有时需要中转、有时不必中转的现象。（3）、a隐身，则b答复a总是通过服务器中转，当以后a再向b发送信息时，仍然无法匹配源地址/端口，所以a与b之间的通信始终只能通过服务器中转 。虽然双方都需要中转，但是a向b发送消息很慢，而b向a发送消息很快。由上面的分析可知，qq间通信经常需要通过服务器中转，“罪魁祸首”不是nat，而是iptables的连接跟踪。在iptables中，连接跟踪已经作为一个单独的模块被实现，对于nat来说，该模块自动且必须被启用，而在用iptables实现包过滤时，也可以使用连接跟踪功能。换句话说，不仅是nat，即使是包过滤（即和internet直接相连），只要使用了连接跟踪模块，同样无法避免qq间通信时产生服务器中转的现象。如果使用ipchains取代iptables，尽管它没有连接跟踪功能，但在用ipchains作nat时，ipchains会记录一个masq表，该表的功能有些类似于iptables的连接状态表。所以，用ipchains作nat，一般情况下，qq间通信也会出现通过服务器中转的现象。但由于ipchains是基于linux2.2内核，而从linux2.2.3内核开始，另有一个参数专门用于控制udp，即/proc/sys/net/ipv4/ip_masq_udp_dloose。如果ip_masq_udp_dloose为0，则ipchains处理从外网到来的udp时，必须去匹配源地址/端口。如果ip_masq_udp_dloose为1，则ipchains处理从外网到来的udp时，不去匹配源地址/端口，任何目标地址/端口符合的udp包，都将被ipchains转交给nat后面的原qq用户，从而也就不会出现qq间通信通过服务器中转的现象。从linux2.2.16内核开始，ip_masq_udp_dloose默认为0，而在此之前，ip_masq_udp_dloose默认为1。也就是说，如果使用linux2.2.3内核以后、linux2.2.16内核以前的ipchains，默认情况下，qq间通信是不会出现通过服务器中转现象的。三、解决问题前文提到，qq间通信经常需要通过服务器中转，是由iptables的连接跟踪功能造成的。事实上，不仅是qq，只要是基于udp的即时通讯软件，在使用iptables的连接跟踪功能时都有这个问题；还有我们常用的tftp客户端，由于tftp服务端返回的udp包使用的源端口不同于客户端发出的udp包的目标端口，所以也无法和iptables的连接跟踪功能一道使用。为了使这些软件能和iptables的连接跟踪功能协同工作，需要加载附加的连接跟踪模块，如ip_conntrack_qq.o、ip_conntrack_tftp.o。此外，为了使这些软件在nat后面也能正常工作，考虑到nat总是和iptables的连接跟踪捆绑在一起，所以，在nat环境下，不仅需要加载这些软件的连接跟踪模块，还需要加载它们的nat模块，如ip_nat_qq.o、ip_nat_tftp.o。然而，到目前为止，netfilter/iptables的标准发布只提供ftp和irc的相关模块。至于其他软件的相关模块，则需要自行编写。有关编写这些连接跟踪和nat相关模块的资料可以参见如下网址：http://www.gnumonks.org/ftp/pub/doc/conntrack+nat.html。下面这个网址列出了一些常用软件（如tftp客户端）的已经可用的连接跟踪和nat相关模块的一些资料：http://netfilter.samba.org/documentation/HOWTO//netfilter-extensions-HOWTO-5.html，具体的模块则可以通过google搜索得到。对于qq软件，编写相关模块的大致思路如下，在qq用户登陆注册时，它必须向qq服务器的8000（udp）端口发送登陆请求，所以该模块只要监控向外的8000（udp）端口的初始连接，一旦发现这个初始连接，该模块就可记住初始udp包对应的masqed后的源地址/端口，即nat的外部地址/端口。以后，当有其他qq用户向这个nat后面的qq用户发送信息时，实际上就是向该模块记住的nat的外部地址/端口发送udp包，只要这些udp包的目标地址/端口符合该模块记住的nat的外部地址/端口，该模块就不去匹配源地址/端口，直接将这些udp包转交给nat后面的原qq用户，从而也就不会出现qq间通信通过服务器中转的现象。这就是ip_conntrack_qq/ip_nat_qq模块的简单实现，至于复杂的实现，还可以让不同nat后面的qq用户进行文件传输。附：LooseUDP与ip_conntrack_qq/ip_nat_qq对qq处理时的区别。前文提过，在用ipchains作nat时，由于使用了LooseUDP的缘故，所以，一般情况下，qq间通信是不会出现通过服务器中转现象的（事实上，也可以disable LooseUDP，而使用一个同样需要自行编写的相关模块ip_masq_qq）。但从linux2.2.16内核开始，出于udp端口扫描漏洞的考虑，LooseUDP的默认状态是disable的。而从linux2.4内核开始，则彻底取消了LooseUDP的功能，这是因为LooseUDP在netfilter/iptables环境下，无法正常工作。仔细研究LooseUDP后，发现它的工作原理与ip伪装的源端口映射方式有关。在使用ipchains作ip伪装时，一般来说，ip伪装后的源端口通常>60000，且在61000--64999之间（具体限制请参阅ip_masq.h文件中的PORT_MASQ_BEGIN 和 PORT_MASQ_END的取值），并且ip伪装后的源端口不可能出现重复，也就是说，根据这个伪装后的源地址/端口，可以唯一映射到nat后面的客户。如果使用LooseUDP，即ip_masq_udp_dloose为1，则ipchains处理从外网到来的udp时，不去匹配源地址/端口，任何目标地址/端口符合ip伪装后的源地址/端口的udp包，都将被ipchains转交给nat后面的唯一客户。由于qq使用udp，所以LooseUDP也对qq有效。但在使用iptables作ip伪装时，nat尽量不去修改源端口，也就是说，ip伪装后的源端口尽可能保持不变。此外，更为重要的是，ip伪装后只需保证源地址/端口与目标地址/端口（即所谓的socket）唯一即可，因此，ip伪装后的源端口有可能出现重复。在这种情况下，只凭伪装后的源地址/端口，就无法唯一映射到nat后面的客户。此时，必须依靠伪装后的源地址/端口（即外网来的udp包的目标地址/端口）加上外网来的udp包的源地址/端口，才可以唯一映射到nat后面的客户。举例说明如下：由于qq的源端口默认总是4000（udp），设想这么一种情况，nat后面有两个qq用户，同时注册到不同的qq服务器，在nat处理他们的udp包时，由于两者的目标地址/端口不同，因而nat不必修改他们的源端口，换句话说，这两个用户经ip伪装后的源端口相同，仍然是4000（udp）。如果按ipchains下的LooseUDP处理方式，iptables在4000端口收到udp包后，如果不匹配该udp包的源地址/端口，就不知道将其转交给nat后面的哪一个qq用户。这也就是LooseUDP在netfilter/iptables环境下无法正常工作的原因。基于同样的理由，在编写qq的相关模块时，千万要注意这一点：必须按照ipchains下的ip伪装方式来处理qq的udp包的源端口映射（当然，端口号的限制不必按该方式），否则，该模块在相应端口（如4000）收到udp包后也无法知道将其转交给nat后面的哪一个qq用户。作者信箱：shixudong@163.com****************（转贴）************************  
  好老的帖子,我想是从linuxforum.net上抄过来的吧?新版QQ早就没有这个问题了.

smile787

就是猜测，该不会是很久以前的吧。iptables在历经从写后，资料报告都没有这个。。。

dccall

此贴不错。其实很多NAT后的QQ通讯超时，QQ视频连通困难。在双方都处在NAT后现象明显。  据我所知，TP-LINK的宽带路由器，WINDOWS下的WINROUTE 都有这种情况。但几种基于LINUX的软路由器还好。其实大多的宽带路由器都是基于LINUX的，差异却很大，不知为何...

tikebaby

QUOTE (dccall @ Aug 24 2004, 02:20 PM)
此贴不错。其实很多NAT后的QQ通讯超时，QQ视频连通困难。在双方都处在NAT后现象明显。  据我所知，TP-LINK的宽带路由器，WINDOWS下的WINROUTE 都有这种情况。但几种基于LINUX的软路由器还好。其实大多的宽带路由器都是基于LINUX的，差异却很大，不知为何...  
  有写路由器在应用iptables之前没有载入必须的模块!这些模块是用来实现一些特殊nat用的.比如 ip_nat_ftp 那么FTP在反向连接时会出错!

DreamCat

QUOTE (dccall @ Aug 24 2004, 02:20 PM)
此贴不错。其实很多NAT后的QQ通讯超时，QQ视频连通困难。在双方都处在NAT后现象明显。  据我所知，TP-LINK的宽带路由器，WINDOWS下的WINROUTE 都有这种情况。但几种基于LINUX的软路由器还好。其实大多的宽带路由器都是基于LINUX的，差异却很大，不知为何...  
  不错，不同发行版本的基于linux的软盘路由器确实存在差异，具体原因还不清楚。曾经用过freesco，但是由于上述问题，其实比上述问题还要糟糕，qq也会掉线，而且从日志当中看不出任何问题。