☰

即使应该接受适当的数据包，为什么 iptables 也会丢弃/记录日志？

tag-icon • tag-icon debian iptables logs fail2ban
即使应该接受适当的数据包，为什么 iptables 也会丢弃/记录日志？

我正在设置一个运行 Debian Jessie 的服务器，其中包含一些应用程序，如 iptables 防火墙、fail2ban、openvpn、apache 等。

iptables 防火墙的配置方式是记录每个被丢弃的数据包。 iptables 配置的一小段摘录：

...
-A INPUT -m comment --comment "003 accept related established rules IPv4" -m state --state RELATED,ESTABLISHED -j ACCEPT
...
-A INPUT -p tcp -m multiport --dports 1194 -m comment --comment "303 allow incoming OpenVPN" -m state --state NEW -j ACCEPT
...
-A INPUT -m comment --comment "900 IPv4 log dropped input chain" -j LOG --log-prefix "[IPTABLES INPUT IPv4] DROP " --log-level 6
-A INPUT -m comment --comment "910 IPv4 deny all other input requests" -j DROP

OpenVPN（使用端口 1194）运行良好。我可以连接、使用连接并工作几个小时，直到我需要传输大量数据为止。此时日志中会出现如下几行：

Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20713 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0
Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20718 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0 
Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20719 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0

[这些日志是从fail2ban中获取的，服务器关闭了与我的本地计算机的连接。]

问：为什么这些数据包会被丢弃（并被记录）？这意味着：为什么这些数据包没有被“RELATED,ESTABLISHED”规则处理？

到目前为止我所做的：阅读文档，思考问题;-)，一次又一次检查规则，在互联网上搜索 - 但没有任何结果。

编辑：也许这很重要：fail2ban 创建的 DROP 列表大约有 500 个条目。

编辑：我想知道原因（这就是我在问题中使用“为什么”的原因）。我对解决方法不感兴趣。

编辑：此行为不仅限于OpenVPN，使用其他协议（例如ssh）也有同样的问题。

编辑：为了给您一个印象，请看一下wireshark屏幕截图：突出显示的数据包已被丢弃/记录 - 屏幕截图中的所有其他数据包都没有。

这是适当的日志：

Mar 03 10:16:23 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress>.117 DST=<ServerIPAddress>.116 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=11550 DF PROTO=TCP SPT=63526 DPT=1194 WINDOW=32038 RES=0x00 ACK URGP=0

我使用IP ID（11550）在wireshark中找到数据包。这是唯一具有该 ID 的 IP 数据包。

记录数据包的 Wireshark 详细信息

编辑：服务器IP是固定IP。我的动态分配的IP地址在测试过程中没有改变。连接由本地计算机向服务器发起。设置如下：

=================      ===================      ===============
| LocalComputer | ---- | NAT Router .117 | ---- | Server .116 |
=================      ===================      ===============
   Private IP            Dynam. Assigned            Fixed IP
                       but fixed during test

答案1

由于您已获得这些iptables日志条目，并且它们与您的规则不匹配RELATED,ESTABLISHED，因此连接跟踪器报告将它们视为与之前的任何内容无关的新会话的开始。通常（但并非总是）当会话闲置时间长于连接跟踪器超时时，可能会发生这种情况。端点之间的其他 NAT 设备可能已超时并生成新的端口号，或者您的其他端点的 IP 地址可能已更改（可能在某些 ISP 的基于 DHCP 的网络上），因此不一定是端点连接跟踪器出现故障。

我想到了三个选项，

  1. 使能够ping 保活在 OpenVPN 配置中。至少，尝试一下ping 10。如果您愿意，并且根据您的客户端/服务器的设置方式，您可能会更喜欢keepalive 10 60。请参阅手册页对于真正血腥的细节。 （如果端点的 IP 地址/端口对发生更改，这将无法解决问题。）

  2. 禁用fail2ban与 1194/tcp 上的 OpenVPN 流量匹配的配置。

  3. 确保避免打印iptables1194/tcp 上 OpenVPN 流量的日志消息，这样fail2ban就没有任何可触发的内容。

答案2

连接跟踪器不仅跟踪数据包是否来自同一连接，而且还检查某些计时（例如迟到的 ACK 或 SEQ 太晚）。

可以使用以下命令打开连接跟踪器日志记录：

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

这向我表明，所有丢弃和记录的包都是以下类型：

nf_ct_tcp: ACK is under the lower bound (possible overly delayed ACK) ...

有一个讨论我在哪里找到这些提示的。

我目前不知道为什么会发生这种情况，但这可能是另一个问题......

相关内容