出口防火墙会话表打满后为何ping通却打开不了网页？一次新建会话被静默丢弃的排查记录

Thu, 06 Aug 2020 07:00:00 +0800

问题背景

办公出口与机房边界几乎都经过状态化防火墙：无论策略放行还是 NAT，真正决定「这条流还能不能建」的，往往不是五元组规则本身，而是会话表（Session / Conntrack / State table）还剩多少坑位。会话表是有限的硬件/软件资源，每一条 TCP/UDP/ICMP 流都要占一项，直到超时老化或被主动拆除。

日常监控如果只看 CPU、内存、接口带宽和丢包率，很容易放过「表快满了」这一层。运维群最常见的投诉组合是：外网能 ping 通，网页打不开 / 企业微信间歇进不去 / 个别 SaaS 登录一直转圈——现象落在应用层，根因却在边界设备新建会话被静默拒绝。本篇复盘一次早高峰会话表打满事故：区别于本站已写的「本机 TIME_WAIT 占满临时端口」「conntrack 在 K8s 节点打满」，这一次故障点在出口防火墙上的会话容量与超时策略，属于边界状态表容量型问题。

故障现象

周二 08:50 起，服务台工单量在 15 分钟内从个位数爬到上百：

外网 ICMP 大多正常：ping www.baidu.com、ping 8.8.8.8 延迟与丢包正常；部分同事甚至用手机热点对比「只有公司网有问题」。
HTTP/HTTPS 建连失败或不稳定：浏览器报 ERR_CONNECTION_TIMED_OUT / ERR_CONNECTION_RESET；同一站点刷新几次偶尔又能打开，呈现强随机性。
已建立长连接相对幸存：早 8 点前就挂着的 VPN、远程桌面、部分 SSH 隧道多数还能用；新开的浏览器标签、新登企业微信、新发起的 Windows Update 检查大批失败。
内外表现不对称：访问机房内网业务基本正常；故障集中在出办公网、经出口防火墙 SNAT 上公网的流量。
监控看起来「很健康」：出口链路利用率 40% 左右，CPU 60% 未触顶，接口无 CRC/runts；链路层告警沉默，应用层已经炸锅。

这种「老会话还活着、新会话建不起来 + ICMP 仍通」的组合，强烈指向状态表类故障，而不是线路中断或 DNS 全挂。

排查过程

1. 先排除 DNS 与客户端侧假象

抽 3 台故障终端：

nslookup www.example.com 内网DNS
nslookup www.example.com 8.8.8.8
curl -v --connect-timeout 5 https://www.example.com/
Test-NetConnection www.example.com -Port 443

结果：解析快且稳定；Test-NetConnection 到 443 大量 TcpTestSucceeded : False；偶发 SYN 重传。说明不是「解析错了」，而是 TCP 握手阶段出不了门或回不来。再对比走 4G 热点一切正常，确认问题在公司出口路径。

2. 沿着路径看「哪一跳开始丢新流」

在汇聚交换机镜像一台故障 PC 的流量，同时在出口防火墙启用包捕获（过滤源 IP = 该 PC 的 NAT 前地址）：

PC 侧：SYN 连续重传，几乎看不到 SYN-ACK。
防火墙 inbound：能看到内网进来的 SYN。
防火墙 outbound / 会话查询：大量「policy allow」但 create session failed / table full 类计数在爬升（不同厂商文案不同，本质是分配会话槽失败）。

再查会话表占用：

# 概念命令，厂商各异
get system performance status
diagnose sys session full-stat
# 或
show asp drop
show conn count

会话使用率已到 98%～100%，新建成功率为 0 附近抖动；drop 计数里 session / conn 相关项与投诉时间轴吻合。至此定位：出口防火墙会话表打满，新 TCP 无法建状态，被静默丢掉。

3. 为什么 ping 还通、老连接还活着？

拆三层机制：

ICMP 回显占用会话极短、条目少：即便表紧张，偶发 ping 仍可能挤进去或命中已有短时缓存；用户主观上「网是通的」。
已建立会话继续命中表项：状态化设备对 ESTABLISHED 流按已有 session 转发，不占用「新建」配额；所以 8 点前连上的业务「看起来还行」。
浏览器/App 一次打开会开多条并发连接：HTTP/2、静态资源、鉴权跳转会同时建十几条流，表一满就表现为「打开网页特别惨」。

4. 谁把表吃满了？——容量 × 超时 × 流量模型

会话表满很少是「今天突然多了相同用户」，更多是三者乘积：

因素	本例观察	影响
硬件/许可上限	会话容量规格约 50 万，早高峰 used 顶满	硬天花板
超时过长	TCP 会话默认 timeout 达 3600s 量级；UDP/DNS 也偏长	死亡连接迟迟不回收
无业务识别的粗放 SNAT	办公 + 访客 + 扫码枪云同步 + Windows 更新同一出口	短连接风暴放大占用
应用侧	部分胖客户端异常重试、杀毒云查杀高峰、自动更新窗口与上班重叠	短生命周期流暴涨

进一步抽样 top talker：某楼层测试网段一台用于压测的客户端在循环拉取外网 API（脚本忘记关）；同时访客 Wi-Fi 未做独立出口/会话配额，早高峰手机推送与视频预加载占了大量短 UDP/TCP。把压测源熔断后，表占用从 100% 缓慢降到 85%，新建开始恢复——证实是容量被异常 + 正常高峰叠加打穿，而不是单条规则写错。

5. 和「本机端口耗尽」如何区分？

本站有一篇「Cannot assign requested address / 本地临时端口耗尽」：那是主机 ss -s 里 TIME_WAIT 爆、源端口耗尽。本例终端 netstat/ss 正常，问题在路径中间设备的 session 计数。排障口诀：

终端报本地端口类错误 → 先看主机；
终端只是超时/重置，中间盒 session full/conntrack table full → 先看防火墙/NAT 设备。

解决方案

止血（分钟级）

立刻掐异常源：定位并断掉压测脚本、中招的外联病毒主机、无限制的爬虫。
临时抬升或释放会话：在许可允许下扩会话规格；对可识别的低价值网段做更短 timeout 或临时限新建速率。
业务分流：让 Windows Update / 云盘同步走独立代理或错峰策略，减少与交互式上网争抢同一张表。
必要时主备切换：仅当备机会话表健康且同步策略不会把满表状态一起带过去时才切；盲目 failover 可能把备机一并打满。

本例通过熔断压测源 + 将访客网超时从 3600s 降到 300s，10 分钟内会话占用降到 70% 以下，网页访问全面恢复。

根治（配置与架构）

按业务分超时：TCP 业务长连接、HTTP 代理、DNS/UDP、半开连接分别设 timeout；半开（SYN-sent）必须短（数十秒级），防止扫描与失败重试长期占坑。
会话表与新建速率监控：对 session used%、session setup rate、session deny/full 做阈值告警（建议 70%/85%/95% 三级），与链路利用率同等重要。
出口拆分与配额：办公生产、访客、终端更新、IDC 出网尽量分防火墙虚拟系统/多出口或至少分策略与超时档案；对访客做连接数/新建速率限速。
SNAT 池与哈希：多公网 IP 时确认未因过小 SNAT 池引发额外碰撞与异常重传（重传会叠加会话压力）。
变更门禁：上线会大批量建短连接的系统（扫描器、同步工具、压测平台）必须评估会话容量与错峰窗口。

示例思路（伪配置，按厂商翻译）：

# 半开会话尽快回收
set session timeout tcp-halfclose 10
set session timeout tcp-timewait 30
set session timeout udp 60
# 访客区更短
set session timeout tcp 300 from zone guest

根因分析

直接原因是：早高峰正常上网 + 访客短连接 + 一台遗忘的压测脚本，在「会话超时偏长、无分级配额、只有链路监控没有会话监控」的前提下，把出口防火墙会话表推到 100%。表满后新建 TCP 无法创建状态项，被设备静默丢弃，于是出现「ping 通、老连接还在、新网页打不开」的经典假通网。

深层原因有三条：

度量错位：把带宽和 CPU 当出口健康的充分条件，忽略状态表这一真实瓶颈；
超时一套用工：办公 ERP 长连接与访客短视频推送共用超长 TCP timeout，表项周转极慢；
平面未隔离：测试/访客/办公共用同一会话资源池，局部异常可以打穿全局上网。

预防措施

把会话表纳入日常容量管理：周报里除了链路 95 峰值，增加会话峰值与新建速率；接近规格 70% 启动扩容或拆分评估。
超时基线标准化：按 zone/策略档案固化 timeout，禁止「全局 3600s 一刀切」上生产。
异常新建检测：对单 IP 新建会话速率做基线；突刺自动限速或隔离，覆盖压测遗忘、蠕虫扫描、被黑外联。
变更与演练：防火墙升级、策略大改后做「会话占用回归」；压测平台默认绑定独立出口与低配额策略。
投诉话术与一线手册：服务台遇到「能 ping 不能上网」优先收：是否仅新业务失败、是否仅出公网失败，并升级网络看 session used，而不是先重装浏览器。

总结

这次故障没有烧板卡、没有环路、也没有 DNS 雪崩，就是出口防火墙一张会话表在早高峰被撑满。状态化网络里，连通性的真相往往藏在「还能不能新建状态」，而不是 ICMP 是否还有回复。处理路径很清晰：用「新流失败 + 老流幸存」锁状态表问题 → 读 full-stat/drop 计数坐实 → 熔断异常源止血 → 用超时分级、配额隔离、会话监控与出口拆分做根治。下次再听到「网是通的但打不开网页」，请先问一句：防火墙的会话表，今天用到百分之几了？

出口防火墙会话表 on Zero Day Notes