前阵子一个业务系统频繁超时，从客户端到服务器全程 ping 通、路由正常，TCP 连接却总卡在 SYN。

查到最后，竟是防火墙的会话表满了，新连接直接被静默丢弃！运维说：“防火墙没告警啊？”我说：“它不说话，不代表没吞包。”

80% 的“诡异丢包”，根源不在链路，而在安全设备——它们默默过滤、限速、拒绝，却不留痕迹。

今天，我不讲功能，专扒防火墙“丢包”的五大暗门。

01

会话表溢出

• 原理：

  防火墙为每个连接（如 TCP 会话）创建状态条目，存储源/目的 IP+端口、协议、状态等。

• 问题：
  • 设备规格有限（如低端墙仅支持 1 万会话）
  • DDoS 攻击、爬虫、P2P 应用可瞬间耗尽会话表
  • 新连接无法建立，SYN 包被静默丢弃（无 RST，无 ICMP）
• 表现：
  • 客户端卡在 “Connecting…”
  • 服务器根本收不到 SYN
  • 防火墙 CPU/内存看似正常

✅ 排查命令（以华为 USG 为例）：

display firewall session statistics

若 Current sessions 接近 Max sessions → 确认溢出。

02

安全策略未放行（或顺序错误）

• 典型场景：
  • 策略只放行了 80 端口，但应用实际用 8080
  • 策略顺序靠后，被前面的“deny all”拦截
  • 未放行 ICMP，导致 ping 不通（误判为网络故障）
• 关键特性：

  防火墙默认拒绝所有未明确允许的流量（与交换机/路由器相反）

• 隐蔽性：

  大多数防火墙默认不记录 deny 日志（为性能考虑），导致“丢得无声无息”

✅ 对策：

• 在策略末尾加一条 log-enabled deny rule 用于调试
• 使用 packet capture 或 flow trace 功能追踪包路径

03

深度检测（DPI/IPS/AV）性能过载

• 原理：

  启用 IPS、防病毒、URL 过滤等功能后，每个包需解码、比对特征库、重组流。

• 后果：
  • CPU 使用率飙升
  • 突发流量下处理不过来，直接丢包
  • 即使带宽未打满，也会出现高延迟或连接失败
• 误区：

  “千兆防火墙 = 能跑满千兆” → 实际开启 DPI 后，吞吐可能只剩 200Mbps

✅ 验证方法：
临时关闭高级安全功能，测试业务是否恢复。若恢复 → 性能瓶颈在 DPI。

04

MTU/分片处理异常

• 场景：
  • 防火墙接口 MTU=1500，但中间链路有 GRE/IPsec 封装（额外开销 24~50 字节）
  • 终端发 1500 字节包 → 到防火墙需分片
• 问题：
  • 某些防火墙默认丢弃分片包（防碎片攻击）
  • 或重组超时，导致大包丢失
• 表现：
  • ping -l 1472 通，ping -l 1473 不通（Windows）
  • HTTPS 能建连，但文件上传失败

✅ 解决：

• 调整终端 MSS（ip tcp adjust-mss 1400）
• 或在防火墙上启用分片重组（谨慎，有安全风险）

05

连接速率/并发限制（DoS 防护误伤）

• 功能本意：

  防止单 IP 发起过多连接（如每秒 100 个 SYN）

• 现实问题：
  • 业务系统本身是高并发（如 API 网关、微服务）
  • 被防火墙 DoS 策略误判为攻击
  • SYN 包被限速或丢弃
• 日志线索：

  查看 DoS 防护日志，常见关键词：syn-flood, connection-limit, rate-exceed

✅ 建议：
对可信业务 IP 设置白名单，豁免 DoS 检测。

06

结语

防火墙不是管道，而是安检门——它要开箱、查证、比对黑名单。每一道检查都可能成为阻塞点。

真正专业的排障，不是绕过防火墙，而是学会看它的“安检记录”和“排队人数”。

下次再遇“通而不通”，别只盯着路由表——答案往往藏在会话表和策略日志里。