最有效排查通信故障的方式是在iptables中为DROP规则前添加LOG目标。需新建LOGDROP链，插入INPUT末尾，先限速记录再丢弃；可按协议/端口精细记录；用rsyslog将日志分流至专用文件；结合iptables计数器快速定位异常流量源头。
直接在 iptables 规则中加入 LOG 目标，是排查通信故障最有效的方式之一。关键不是记录所有包，而是让丢弃行为“说话”——让每条 DROP 规则前先记一笔日志，你才能知道谁被拦了、为什么被拦。
给默认 DROP 策略加日志链
大多数安全策略最后都设为 iptables -P INPUT DROP，但这个兜底动作本身不输出任何信息。要让它可追踪，需插入一个自定义链：
- 新建日志链：
iptables -N LOGDROP - 把 INPUT 链末尾跳转过去：
iptables -A INPUT -j LOGDROP - 在 LOGDROP 链里先记录再丢弃：
iptables -A LOGDROP -m limit --limit 5/min -j LOG --log-prefix "DROP-IN: " --log-level 4 - 最后执行丢弃：
iptables -A LOGDROP -j DROP
这样所有未被前面规则放行的入站包，都会先打上时间戳和源IP等信息，再被丢弃。注意 --limit 是必须的，避免日志刷屏；--log-prefix 建议带方向（如 DROP-IN / DROP-OUT），方便后续过滤。
按协议或端口精细记录可疑流量
如果怀疑某类连接异常（比如 SSH 登录失败、HTTP 无响应），不要全局记录，而应针对性加 LOG 规则，并放在对应 ACCEPT 规则之前：
- 记录并放行新 SSH 连接：
iptables -I INPUT 1 -p tcp --dport 22 -m state --state NEW -j LOG --log-prefix "SSH-NEW: "，再跟一条-j ACCEPT - 记录被拒的 ICMP 请求：
iptables -A INPUT -p icmp -j LOG --log-prefix "ICMP-BLOCKED: "，然后-j DROP - 记录所有未匹配的 TCP 包：
iptables -A INPUT -p tcp -j LOG --log-prefix "TCP-UNMATCHED: "
这类规则要插在链开头或关键位置，否则可能被前面的 ACCEPT 或 DROP 跳过，导致日志缺失。
把日志单独存到专用文件
默认日志混在 /var/log/messages 或 /var/log/syslog 里，查找困难。用 rsyslog 分流更清晰：
- 编辑
/etc/rsyslog.conf，在末尾添加：kern.warning /var/log/iptables.log - 重启服务：
sudo systemctl restart rsyslog - 确认文件已创建且有写入权限：
sudo touch /var/log/iptables.log && sudo chmod 644 /var/log/iptables.log
之后所有 --log-level 4（warning）及以上的 iptables 日志，都会自动写入该文件，用 tail -f /var/log/iptables.log 实时观察即可。
结合计数器快速定位问题源头
光看日志还不够快，配合规则命中计数能立刻判断异常：
- 运行
sudo iptables -L INPUT -v -n --line-numbers - 关注两列：
Pkts（匹配包数）和Bytes（字节数） - 若某条 DROP 规则
Pkts在 10 秒内猛增数百，极可能是扫描或攻击；若 ACCEPT 规则长期Pkts=0，说明流量根本没走到这儿——检查前面是否有更宽泛的 DROP 截断了路径 - Chain 默认策略后的计数（如
pkts=12345）代表被兜底丢弃的包，持续上涨说明规则覆盖不全
查到可疑 IP 后，可临时加一条带日志的规则定向监控：iptables -I INPUT 1 -s 192.168.1.100 -j LOG --log-prefix "SUSPECT-IP: "，再观察日志内容确认行为模式。
