我正在pipe理的Web服务器显示了目标端口443上IPv4地址的奇怪的iptables拒绝，尽pipe显式允许HTTPS通信。 端口80也被允许在相同的规则，但该网站是HTTPS-only和80被立即redirect到443由nginx。
事情是：浏览网站的作品 。 你可以加载所有的页面，所有的资源进来就好了等等。但是这里显然是不对的，这可能会伤害页面加载性能。
以下是分别logging在端口443和80的/var/log/iptables_deny.log中的一些错误示例。 这些可以单独或者以连发的方式来判断，从我的tail -f的日志文件来看。 绝大多数是港口443：
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x08 PREC=0x00 TTL=53 ID=61266 DF PROTO=TCP SPT=49264 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=11186 DF PROTO=TCP SPT=58445 DPT=443 WINDOW=254 RES=0x00 ACK FIN URGP=0 iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=16941 DF PROTO=TCP SPT=16278 DPT=80 WINDOW=255 RES=0x00 ACK FIN URGP=0
一个快速的grepping说拒绝的数据包types至less可以是ACK，ACK FIN，ACK RST，ACK PSH和RST。 也许别人，但他们没有吸引我的眼球。
下面是iptables -nvL的输出。 基本模式（允许所有相关和先build立，后来允许所有新的stream量在80和443）应该坚实的基础上我读过的一切。 LOG和DROP规则是INPUT链中的最后一个，因为它们应该是这样。
Chain INPUT (policy ACCEPT 1 packets, 391 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 8893 770K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22 0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22 0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22 0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 63 3840 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW multiport dports 80,443 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:139 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:445 1 40 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/min burst 5 LOG flags 0 level 7 prefix "iptables denied: " 1 40 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 1 packets, 65 bytes) pkts bytes target prot opt in out source destination 7311 19M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
实际的相关规则，如果在输出之后有任何用处：
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 80,443 -j ACCEPT
显而易见的是，这不是恶意stream量。 我从几个不同的IP地址浏览网站，当网站加载看起来很好，我的IP也出现在拒绝日志没有任何模式，我可以看出，没有任何用户可见的错误条件在浏览器中。
任何想法可能是在这背后？
RST和ACK，FIN数据包是TCP连接尾部的一部分。
我的理解是，为了安全起见， iptables的连接跟踪引擎采取了非常稳健的方法来删除状态表项：只要它看到连接的一端试图closures它，然后（知道这样的请求发信号因为它的一端现在认为连接断开了），它删除了已经允许连接stream量的状态表项。
如果还有其他类似的防火墙也在路上，那么等待时间会更长，这可能是不安全的，阻塞了RFC指定的其他整理包; 延迟收集状态表条目，直到看到这些条目可能会在表中留下一些无效的条目一段时间，这将带来潜在的漏洞。
但是RFCs指定了一些更多的整理工作，而且这些包被你拒绝。 是的，这意味着连接中的terminal将使用更多的内存，等待连接老化，而不是看到完全closures，并能够更快地释放连接内存; 但增加安全性往往需要资源，这是这些权衡之一。
那些永不过去的数据包没有什么坏处，所以你可以放心地忽略日志条目。
编辑 ：如果您不想在日志中看到它们，请在您的日志行之前处理它们，例如
iptables -I INPUT 13 -p tcp -m conntrack --ctstate ESTABLISHED --tcp-flags ACK,FIN ACK,FIN -j DROP