4. 防火墙拦截：iptables规则检查、云平台安全组策略、企业防火墙ACL
说到TCP连接超时，防火墙这块儿，我敢说至少有一半的“疑难杂症”都跟它有关。你想想看，网络通着，ping也通，但业务就是连不上，或者连上就断。这时候，十有八九是防火墙在中间“作祟”。
我个人习惯，排查TCP超时问题时，永远把防火墙放在第三位检查——第一是物理链路，第二是IP路由，第三就是防火墙。为什么？因为防火墙的拦截行为，在客户端看来，就是“连接超时”，而不是“连接被拒绝”。
4.1 iptables规则检查：Linux主机的“守门员”
如果你排查的服务器是Linux，那iptables/nftables就是第一道坎。我记得有一次，一个同事调了三天数据库连接超时，最后发现是测试环境里一条iptables规则把3306端口给DROP了。
这里有个关键点：DROP和REJECT的区别。
| 动作 | 客户端表现 | 抓包特征 |
|---|---|---|
| DROP | 连接超时（TCP连接无响应） | 客户端发SYN，无任何回应，重试直到超时 |
| REJECT | 连接被拒绝（立即返回RST） | 客户端发SYN，服务器回RST，连接立即失败 |
说白了，如果你遇到的是“连接超时”，那大概率是DROP。REJECT反而好办，因为它会立刻告诉你“此路不通”。
4.1.1 快速排查命令
我一般按这个顺序查：
- 先看当前规则：
iptables -L -n -v，注意看INPUT和FORWARD链的计数。如果某个规则的packets计数一直在涨，那它就是“凶手”。 - 检查默认策略：
iptables -L | grep policy。如果INPUT链默认策略是DROP，那所有未显式放行的端口都会被拦。 - 看连接跟踪表：
conntrack -L | grep [目标IP]。有时候规则没问题，但连接跟踪表满了，新连接会被丢弃。
实战案例：我曾经遇到一个Nginx反向代理超时问题。客户端到Nginx正常，Nginx到后端也正常，但就是偶尔超时。最后用iptables -L -n -v一看，FORWARD链里有一条规则匹配了所有ESTABLISHED状态的包，但NEW状态的包没放行。导致长连接没问题，新连接全被DROP了。
4.1.2 避坑指南：规则顺序
iptables是顺序匹配的。我曾经犯过一个低级错误：把放行规则写在了拒绝规则后面。结果放行规则永远匹配不到，所有流量都被拒绝了。
注意：iptables规则匹配到第一条就停止。所以放行规则要写在拒绝规则前面。如果你用-A追加规则，一定要确认顺序。
4.2 云平台安全组策略：看不见的墙
现在大部分业务都在云上。云平台的安全组，说白了就是一张分布式的iptables。但它的排查难度比iptables大，因为你没法直接登录到“防火墙”上看日志。
我个人的经验是，云平台安全组导致超时，通常有这几个特征：
- 单向通，双向不通：比如从A能ping通B，但从B ping不通A。这往往是安全组只放行了入方向，没放行出方向。
- 特定端口超时：其他端口都正常，就某个端口连不上。这基本就是安全组没放行该端口。
- 跨区域/跨VPC超时：不同VPC或不同区域之间通信，除了安全组，还要检查对等连接或云联网的路由。
4.2.1 排查步骤
- 检查安全组入方向规则：确认源IP/源安全组、协议、端口是否正确。注意，云平台安全组默认是“白名单”机制，没写就是拒绝。
- 检查安全组出方向规则：很多云平台默认出方向全放通，但有些安全策略会限制出方向。如果出方向被限制，客户端发出去的SYN包根本到不了服务器。
- 检查网络ACL：VPC级别的网络ACL是“无状态”的，需要同时配置入方向和出方向。我曾经踩过这个坑：安全组放行了，但网络ACL没放行回程流量，导致连接超时。
小技巧：在云平台上，可以用“连通性测试”或“路径分析”工具。比如AWS的Reachability Analyzer，阿里云的“网络诊断”。这些工具能直接告诉你哪个安全组规则拦住了流量，比你自己翻规则快得多。
4.3 企业防火墙ACL：最复杂的“黑盒”
企业级防火墙（比如思科ASA、华为USG、Palo Alto）的ACL，是排查难度最高的。因为防火墙通常不是你自己管的，你得找网络团队配合。而且防火墙的日志量巨大，默认可能没开日志。
我记得有一次，一个客户说他们的ERP系统经常超时。我让他们在防火墙上抓包，结果发现防火墙把TCP的SYN包正常转发了，但回程的SYN+ACK包被拦截了。为什么？因为防火墙的ACL只放行了入方向的SYN，没放行出方向的SYN+ACK。
4.3.1 防火墙ACL的常见“坑”
| 问题类型 | 现象 | 原因 |
|---|---|---|
| ACL顺序错误 | 部分用户能连，部分不能 | 放行规则被拒绝规则覆盖 |
| 缺少回程规则 | 单向通，双向不通 | 只配了入方向，没配出方向 |
| 状态检测失效 | 连接建立后一段时间断连 | 防火墙会话超时时间太短 |
| NAT与ACL冲突 | 内网能通，外网超时 | NAT转换后的地址不在ACL放行范围内 |
4.3.2 排查方法
面对企业防火墙，我一般这么做：
- 先看会话表：登录防火墙，查看当前会话。如果能看到TCP连接处于SYN_SENT或SYN_RECV状态，说明防火墙放行了；如果根本看不到会话，那大概率是被ACL拦截了。
- 开启ACL日志：在怀疑的ACL规则上开启log选项。然后模拟触发超时，去防火墙的日志里找deny记录。
- 抓包验证：在防火墙的内外网口同时抓包。对比两边的包，看哪个方向的包丢了。这是最直接的方法。
重要提醒：在企业防火墙上做变更前，一定要先备份配置。我曾经见过有人删了一条ACL规则，结果整个部门的网络都断了。恢复配置花了两个小时，那场面……嗯，你懂的。
4.4 防火墙拦截排查流程图
下面这张图，是我自己总结的防火墙拦截排查流程。每次遇到TCP超时，我就按这个走一遍，基本能定位问题。
4.5 总结一下
防火墙拦截导致的TCP超时，排查思路其实就三条线：
- Linux主机：查iptables规则、查连接跟踪表、确认是DROP还是REJECT。
- 云平台：查安全组入方向和出方向、查网络ACL、用云平台自带的诊断工具。
- 企业防火墙：查会话表、开ACL日志、内外网口同时抓包对比。
嗯，这里再啰嗦一句：防火墙规则改完后，一定要验证。我见过太多人改完规则就跑，结果第二天业务又超时了——原来是规则没保存，防火墙重启后失效了。