用iptables在networking服务器上丢弃ACK FIN，ACK RST，RST数据包

我在Debian 7机器上运行一个web服务器（Apache），在同一台机器上使用iptables。 iptables规则由ConfigServer防火墙（CSF）脚本生成。 在那里托pipe的网站没有问题，但是我在端口80上看到很多丢弃的入站stream量 。

以下是日志摘录（webserver IP：11.22.33.44）：

Jan 27 15:21:36 [hostname] kernel: [1229124.817624] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3144 DF PROTO=TCP SPT=36879 DPT=80 WINDOW=510 RES=0x00 ACK FIN URGP=0 Jan 27 15:21:36 [hostname] kernel: [1229124.872795] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3183 DF PROTO=TCP SPT=36684 DPT=80 WINDOW=513 RES=0x00 ACK FIN URGP=0 Jan 27 16:03:36 [hostname] kernel: [1231642.223513] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=19101 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK FIN URGP=0 Jan 27 16:03:41 [hostname] kernel: [1231647.015463] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=26215 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK RST URGP=0 Jan 27 16:03:51 [hostname] kernel: [1231656.677627] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=10630 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 Jan 27 16:04:42 [hostname] kernel: [1231707.911962] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3513 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 Jan 27 16:04:42 [hostname] kernel: [1231707.911976] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3514 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 

数百行的东西。 没有特定的时间模式，随机客户端发生丢弃。

但是这些被丢弃的数据包总是被标记为ACK FIN，RST，ACK RST，并且通常less于SYN。 我明白这些是“确认转移和结束连接”数据包。

• 如何从远程服务器提供对lan mysql数据库的访问？
• 只有一个IP地址通过思科防火墙，无需知道有一台代理服务器
• 禁用天青工人angular色上的Windows防火墙有没有什么危险？
• TFS签入问题：底层连接已closures：预期保持活动状态的连接已被服务器closures
• DNS灰色列表和长时间的重试间隔 – 标准做法？

相关的iptables规则：

 Chain INPUT (policy DROP) ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere ctstate NEW tcp dpt:80 LOGDROPIN all -- anywhere anywhere Chain LOGDROPIN (1 references) LOG tcp -- anywhere anywhere limit: avg 30/min burst 5 LOG level warning prefix "Firewall: *TCP_IN Blocked* " DROP all -- anywhere anywhere 

所以看起来，这些数据包因为相应的连接不再打开而被丢弃，即RELATED或ESTABLISHED。 这意味着传输成功，并且服务器在客户端有时间确认接收到的数据之前closures连接，从而在客户端挂起连接（也可能是HTTP请求？）。

我真的好奇这是什么原因造成的。 也想知道客户是否受到影响，因为我似乎无法复制这个问题。 我希望你们能帮助我理解！

感谢阅读=）

编辑 ：好吧，我去钓鱼，并为[ACK，FIN]数据包被丢弃的这些情况之一（下面我的评论中描述的方法）进行包跟踪。 最后三个数据包是被防火墙丢弃的数据包：

 Source Destination Protocol Length Info Time [CLIENT COMP] [WEBSERVER] TCP 68 55478 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1400 WS=4 SACK_PERM=1 2014-01-29 20:44:36.044009 [WEBSERVER] [CLIENT COMP] TCP 68 http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:36.044052 [WEBSERVER] [CLIENT COMP] TCP 68 http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:37.243948 [CLIENT COMP] [WEBSERVER] TCP 56 55478 > http [ACK] Seq=1 Ack=1 Win=16800 Len=0 2014-01-29 20:44:37.421123 [CLIENT COMP] [WEBSERVER] HTTP 464 GET /sites/default/files/js/js_R9UbiVw2xuTUI0GZoaqMDOdX0lrZt....js HTTP/1.1 2014-01-29 20:44:37.432097 [WEBSERVER] [CLIENT COMP] TCP 56 http > 55478 [ACK] Seq=1 Ack=409 Win=15872 Len=0 2014-01-29 20:44:37.432122 [WEBSERVER] [CLIENT COMP] HTTP 963 HTTP/1.1 200 OK (text/javascript) 2014-01-29 20:44:37.432703 [CLIENT COMP] [WEBSERVER] TCP 56 55478 > http [ACK] Seq=409 Ack=908 Win=15892 Len=0 2014-01-29 20:44:37.769928 [WEBSERVER] [CLIENT COMP] TCP 56 http > 55478 [FIN, ACK] Seq=908 Ack=409 Win=15872 Len=0 2014-01-29 20:44:42.437129 [CLIENT COMP] [WEBSERVER] TCP 56 55478 > http [ACK] Seq=409 Ack=909 Win=15892 Len=0 2014-01-29 20:44:42.580378 [CLIENT COMP] [WEBSERVER] TCP 56 55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0 2014-01-29 20:49:44.668730 [CLIENT COMP] [WEBSERVER] TCP 56 55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0 2014-01-29 20:49:49.194316 [CLIENT COMP] [WEBSERVER] TCP 56 55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0 2014-01-29 20:49:58.869659 

根据这个：

1. 服务器发送它的HTTP 200 OK响应
2. 希望closures连接。 它发送一个[FIN，ACK]数据包给客户端，因为我猜测它正试图使一个同时连接closures。
3. 客户端对服务器的[FIN，ACK]（Seq / Ack编号按正确顺序）而不是[FIN]进行响应，根据规范，这意味着连接只是半封闭的。
4. 但是， 5分钟后 ，客户端发送了一个[FIN，ACK]，这是不寻常的，因为它已经发送了一个ACK到服务器的“连接结束”，我猜测某种forms的TCP超时被涉及，客户端只是试图closures一个打开的连接。

很明显，连接终止握手不会以正确的顺序发生。 看起来问题出现在客户端，直到5分钟超时才closures连接。

我注意到3件事情：

• 这个特定的客户端运行一个现代的浏览器，所以浏览器不是问题。
• 他/她正在发送/接收大量的TCP重传，提示有损连接。 事实certificate，这家伙是从摩洛哥3G连接，所以它加起来^^。
• 最后，Apache日志显示他得到了正确的HTTP响应，所以网站stream量不受“问题”的影响。

有趣的东西。 如果你有什么，射击！