Rocky Linux服务器IPtables规则下S3关联已建立会话数据包异常丢弃的排查咨询

看起来你遇到的是典型的已建立会话数据包被iptables错误拦截的问题——虽然实际S3上传下载业务没受影响，但日志里的丢弃记录确实值得深究，咱们一步步来拆解排查：

先从你的iptables规则逻辑入手分析 #

你的INPUT链第一条就配置了放行RELATED,ESTABLISHED状态的数据包，正常来说S3的回包应该直接命中这条规则被放行，根本不会走到后面的admin/prod链以及最终的DROP规则。那出现丢弃日志的核心问题大概率是：这些被丢弃的数据包没有被conntrack正确标记为已建立/关联状态，或者是会话过期后的残留数据包。

具体排查步骤 #

1. 实时跟踪conntrack会话状态

用conntrack工具实时监控S3目标IP的会话变化，当日志出现丢弃记录时，同步查看对应会话是否存在、状态是什么：

# 实时跟踪S3 IP的会话事件
conntrack -E -s 52.218.197.1
# 列出当前所有与该IP关联的会话
conntrack -L -s 52.218.197.1

如果丢弃日志出现时，对应的会话已经不存在，说明这是会话超时销毁后的残留数据包，属于正常日志噪音，不会影响业务。

2. 检查iptables规则的匹配计数

查看每条规则的实际命中次数，确认S3回包是否真的没命中第一条放行规则：

# 查看INPUT链的规则匹配数
iptables -nvL INPUT
# 查看admin和prod链的匹配数（确认S3回包是否误命中了这两个链的规则）
iptables -nvL admin
iptables -nvL prod

如果第一条RELATED,ESTABLISHED规则的匹配数一直在增长，而丢弃日志对应的数据包确实没命中这条，那就要排查conntrack的状态跟踪是否异常。

3. 检查conntrack的超时配置

TCP会话的超时设置如果过小，可能导致会话提前被销毁，后续回包被视为新连接：

# 查看已建立TCP会话的超时时间（默认是432000秒=5天）
sysctl net.netfilter.nf_conntrack_tcp_timeout_established
# 查看TIME_WAIT状态的超时时间
sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait

如果你的业务有长连接需求，可以适当调大这些参数，减少会话提前销毁的概率。

4. 增强日志的上下文信息

修改日志规则，增加TCP和IP选项的日志内容，方便判断被丢弃数据包的类型（比如是延迟ACK、FIN包还是其他）：

# 先查看INPUT链的规则序号，找到原来的两条日志规则
iptables -L INPUT --line-numbers
# 假设日志规则是第7和第8条，修改它们增加日志字段
iptables -R INPUT 7 -m limit --limit 10/sec -j LOG --log-prefix "iptables " --log-level 4 --log-tcp-options --log-ip-options
iptables -R INPUT 8 -j LOG --log-prefix "iptables " --log-level 4 --log-tcp-options --log-ip-options

后续查看日志时，就能通过新增的字段判断数据包是否属于过期会话的残留流量。

5. 用tcpdump抓包验证

直接抓取对应网卡的S3流量，直观查看被丢弃数据包的TCP状态：

tcpdump -i em2 src 52.218.197.1 and dst 10.0.51.153 -vvv

当丢弃日志出现时，观察抓到的数据包的TCP flags（比如是否是ACK但没有对应的会话，或者是RST包），进一步确认原因。

大概率的结论 #

从你描述的“业务正常但有部分丢弃日志”来看，最可能的情况是会话超时销毁后，对方服务器仍在发送延迟的残留数据包，这种情况属于正常现象，不会影响业务，只是会产生日志噪音。如果觉得日志烦人，可以调整conntrack的超时参数，或者在日志规则里过滤这类流量。

备注：内容来源于stack exchange，提问作者user22395539