上周远程帮朋友处理了一台USG6000的故障内网一台终端对外连接时断时续日志里看不出所以然。我登上去第一件事就是按IP查会话表结果发现某个IP的SYN包几乎清一色停在半开状态问题方向一下就清楚了。这种操作在华为USG防火墙排障里非常基础但很多刚接触防火墙的朋友反而不知道从哪下手只知道Web界面上点点鼠标一到CLI就犯怵。这篇文章就把“华为USG防火墙查看指定IP的连接表”这件事彻底讲透会话表里存了什么、命令怎么敲、输出怎么读、常见坑怎么绕以及查不到会话时下一步往哪查。适合正在学防火墙配置的初级网工、偶尔要排障的运维同学以及用eNSP做实验但又不太明白命令含义的兄弟。1. 查连接表之前先弄明白USG里存的到底是什么1.1 连接表、会话表、流表别被叫法绕晕做网络的人都知道同一个东西在不同厂商叫法不一样。思科那边习惯叫连接表华为USG文档里通常写作“会话表”Session Table老工程师也可能随口说“流表”。别被这些名词搞晕它们指的是同一个核心数据结构一张按五元组组织的表记录了防火墙当前正在维护的所有通信连接。所谓五元组就是源IP、源端口、目的IP、目的端口、协议类型。防火墙是状态检测设备第一个报文到达时它会查路由、过安全策略、做NAT转换把这些结果缓存在会话表里后续双向报文直接查表转发不再重新走一遍完整流程。这个设计的好处一眼就能看出来性能提升而且能保证同一条连接的正向和反向流量能对上号。我经常打一个比方会话表就像小区门卫手里的登记表。访客第一次进来门卫问清楚去几栋几单元、找谁、待多久登记好再放行后面这个人反复进出门卫瞄一眼表就能放人不用每次都盘问。防火墙处理连接也是这个逻辑第一次报文“盘问”完了后续数据包只要查表对得上就直接放行。1.2 一条会话里存了哪些跟排障直接相关的信息打开一条会话记录字段不少但排障时真正有用的就那么几个五元组源/目的IP和端口、协议这是查询入口也是定位问题的锚点。状态TCP连接走到哪一步了是SYN半开、ESTABLISHED还是FIN关闭能直接反映握手是否正常。接口Interface In和Interface Out告诉你流量从哪个口进来、从哪个口出去辅助判断转发路径和策略方向。NAT映射转换前和转换后的地址、端口搞清楚用户到底是用什么地址跟外界通信。老化时间这条会话还能活多久。查不到会话时有可能是连接已经老化清了。另外要留意华为USG执行查询时输出顶部通常有一行计数包含“total session”和“deny session”。被安全策略拒绝的连接不一定完全无痕deny session 的计数变化本身就是排障线索。后面聊“查不到会话”的场景时会详细说。把会话表的组成搞明白再去看命令输出就不会一头雾水。下面正式上命令。2. 日常排障最常用的三种查询姿势以及命令版本差异2.1 按源IP查最标准的操作华为USG查会话表的命令在VRP8平台USG6000系列多数是这套系统下长这样display firewall session table ipv4 source-ip 192.168.1.100这条命令会把这个IP作为源IP的所有会话都列出来不管目的地址是什么。适合什么场景内网用户反馈访问什么都慢你想看看他到底在跟哪些IP通信、跑了哪些协议。有时候一眼就能看出问题比如发现对方一直在连一堆未知IP、大量TCP连接没有建立成功那基本就有排查方向了。如果你用的是老版本设备比如USG2000、早期USG5000那批跑VRP5系统的设备命令参数写法有差异。最稳妥的办法不是背命令而是敲display firewall session table ?让设备自己提示当前版本支持哪些关键字。命令提示符是排障时最好的老师记不清就按一下Tab补全或者看问号。2.2 按目的IP查最容易忽略的反查细节如果怀疑某个外部IP在访问内网或者想看内网用户访问特定服务器的情况就按目的IP过滤display firewall session table ipv4 destination-ip 10.10.10.10但这个操作里藏着一个非常典型的坑如果业务配置了NAT外网看到的往往是公网地址不是内网真实IP。比如内网用户上网用的是出接口做Easy IP也就是PAT端口地址转换所有用户共享一个公网地址。你按destination-ip 1.2.3.4查看到的会话里源IP全是转换后的公网地址根本定位不到具体用户。想找原始内网IP必须加verbose参数看转换关系display firewall session table ipv4 destination-ip 1.2.3.4 verbose加了这个参数后输出里会多出NAT转换前后的地址字段才能真正把用户和连接对应起来。这个细节在厂商文档里往往一笔带过但实际排障十次有八次要靠它。信我查NAT相关问题时直接把verbose带上否则你会多跑很多冤枉路。2.3 按IP加端口组合过滤快速锁定业务查连接表时光有IP还不够。用户可能同时开着浏览器、IM软件、远程桌面会话有几十上百条一条条翻很累。更好的思路是IP加目的端口组合display firewall session table ipv4 source-ip 192.168.1.100 destination-port 443这条命令直接过滤出该用户的HTTPS会话。想看TCP协议就补个protocol tcp想看UDP协议就补protocol udp组合条件越多输出越少、定位越快。我实际排障时的习惯是先粗查IP看全貌再用端口和协议逐步收窄最后锁到可疑会话看详细状态和接口信息。盲查不如组合查信息越精确结论越干脆。2.4 老版本和Web界面怎么查实在记不住命令的时候Web管理界面也是个退路。华为USG的Web里有会话监控入口大致路径是“监控 会话管理 会话表”里面可以填源IP、目的IP、端口来过滤。不过Web界面刷新慢、翻页不便在线会话多时体验很差。真到了救火现场还是CLI效率高。有一点可以安心eNSP里内置的USG6000模拟器和真机命令逻辑基本一致初学阶段在模拟器上反复敲这些查询命令练熟了再到真机上差别不大。会话表、策略、NAT这些核心概念模拟器上手反而比真机更放心因为敲错了也不影响生产。3. 把输出拆开看一行会话数据里藏着哪些线索3.1 一段典型的会话表输出长什么样以我手头某台USG6000VRP8为例执行查询后的输出大致是这样不同版本字段顺序可能有差异以实际设备为准Current total session: 1, current total deny session: 0 Session ID: 0x00000000000001 Source IP/port: 192.168.1.100/52345 Dest IP/port: 10.10.10.10/443 Region: 0x0 Vsys: public VPN instance: public Protocol: TCP(6) Interface In: GE1/0/1 Interface Out: GE1/0/0 Session State: TCP_EST Created time: 2025/06/11 10:00:01 Expired time: 2025/06/11 10:05:01如果带NAT场景输出里会额外显示转换前后的地址和端口。大家不用纠结字段顺序重点是理解每个字段在排障中能干什么。3.2 状态字段怎么读TCP_EST、TCP_SYN和UDP_EST的含义会话状态是输出里最有排障价值的信息。TCP会话常见这么几个TCP_SYN_SENTSYN发出去了但没收到回应连接卡在第一步。通常说明对端不可达、被中间设备丢弃或者SYN包被策略拦了。TCP_EST三次握手完成连接建立正常。TCP_FIN/TCP_RST连接正在关闭或者被重置。如果在某个IP下看到一堆TCP_SYN_SENT会话基本可以判定握手失败。这时候别急着怀疑防火墙策略先确认目标服务器监听没监听、路径上有没有丢包。UDP没有握手动作状态一般显示为UDP_EST一段时间没流量就会老化掉。还有一点值得注意大量TCP_RST不一定代表攻击也可能是双方TCP参数不匹配比如MTU协商问题导致握手后立即断连。遇到这种情况光看会话表就不够了需要配合抓包确认重置包是谁发出来的这个后面讲排查思路时会再提到。3.3 Interface In/Out流量转发路径的路标Interface In和Interface Out这两个字段很多人扫一眼就略过但实际价值很高。比如某台服务器双网卡接入防火墙一个口接内网一个口接DMZ。如果会话表显示流量从GE1/0/1进、从GE1/0/2出那说明服务器访问内部数据库时走了DMZ口策略接口配置或路由可能有偏差。再比如内网用户访问公网Interface Out应该是接运营商链路的接口如果显示的是接内网核心交换机的接口说明流量根本没从正确出口转发问题多半出在路由优先级、策略路由或出口选路配置上。所以查会话表不只是确认“有没有连接”还要确认“连接走的路径对不对”。路径不对连接起不来而且问题往往不在防火墙自身而在上层路由设计。4. 实战走一遍三个真实场景里查连接表怎么用4.1 场景一用户能登聊天工具但打不开网页以前处理过一起故障一个部门说某位同事的浏览器死活打不开网页但聊天软件完全正常。第一反应是DNS或HTTP代理问题但我先按IP查了一下会话display firewall session table ipv4 source-ip 10.10.1.50结果发现这个IP下几乎没有到公网DNS服务器的UDP会话也没有443的TCP会话反而有一堆SYN半开连接指向某些未知地址。继续查路由和策略发现这个用户所属网段的NAT策略被人误加了一个目的地址限制导致部分公网地址没有被转换。调整策略后会话立刻建立网页正常打开。这个案例想说明的是查会话表能帮你把“用户侧问题”和“网络侧问题”分得特别清楚。用户侧问题通常表现为终端上ping不通、路由不可达而如果防火墙上根本看不到这个IP的任何会话问题大概率出在用户到防火墙之间的链路或者策略在更早的环节就丢弃了报文。4.2 场景二内网某个IP同时发起超量连接还有一种典型情况内网某台主机中木马或者跑了个不正经的下载工具每秒向外发出几十条新连接把设备的并发会话数推到上限导致其他用户上网都卡顿。此时同样按IP查会话display firewall session table ipv4 source-ip 10.10.1.88看到单个IP的会话条数异常多比如几十上百条连接指向同一个IP的同一个端口基本就能锁定问题源。再往下按目的端口过滤把同一目标的会话全部拉出来很容易看出是什么业务在跑。实际排障中还可以结合设备的会话总数监控一旦Total session数异常暴增优先按会话数排行去查能省很多时间。这里顺带多说一句查会话时如果发现某个IP的会话数一直不涨新建连接全部失败别忘了检查是否配置了针对单个IP的会话数限制session-limit。USG支持限制每IP的会话数超出后新连接直接拒绝现象同样是“连不上”。4.3 场景三NAT之后找原始IP外网反馈某个公网IP在做端口扫描需要定位是内网哪台机器干的。如果只配置了出接口Easy IPPAT所有内网用户共用一个公网地址。这时不能按内网IP查要按公网IP查display firewall session table ipv4 source-ip 202.102.1.10 verbose华为USG在verbose输出里会给出NAT转换前的内网信息和转换后的公网信息。从转换前的源端口结合设备日志、DHCP绑定关系就能逆推出具体用户。这也是为什么我一直强调涉及NAT排障时把verbose带上不带它看到的只是外衣带它才能看到本质。5. 查不到会话时按这个顺序排查排查中最难受的场景不是会话太多而是压根查不到你想找的IP。这种时候别慌按顺序往下走就能逐步缩小范围。5.1 先确认报文真的到了防火墙查不到某个IP的会话首先要问流量到底有没有经过这台防火墙很多网络拓扑里防火墙上联口后面还挂着其他路由器或二层交换设备流量可能根本没走到防火墙就转向了。验证的办法是看接口流量统计直接用display interface看接口计数或者看防火墙的会话统计趋势。如果入口接口的流量都看不到增长问题大概率是链路或路由层面的防火墙只是个旁观者。如果需要进一步确认华为USG的Web界面里有报文捕获功能可以按五元组条件抓包导出pcap用Wireshark分析报文到底有没有到防火墙、到了之后是转发还是丢弃。抓包比看会话表更底层能解答“这个包到底有没有来过”这种终极问题。5.2 被策略deny的连接去哪了流量到了防火墙却被策略拒绝也会留下痕迹只是默认会话表不一定直接显示。查询时注意看输出开头Current total session: 1, current total deny session: 3如果deny session的数字在增长说明设备正在主动丢弃某类连接。配合安全策略的命中计数在策略视图下可以查看匹配次数再看黑名单列表有没有命中通常就能锁定是哪条策略把流量给杀了。这类场景我踩过坑曾经有人反馈外网访问内网服务器打不开我查会话表确实没有对应会话以为策略没放行排查半天。最后才发现是防病毒配置里某个签名把业务会话重置了会话表里连deny计数都不涨必须在威胁日志里翻。所以查不到会话时别忘了把入侵防御、反病毒、URL过滤这些安全模块也列入怀疑清单。5.3 会话数限制和老化时间的影响USG对并发会话数量有上限也支持针对单个IP、单个用户的会话数限制。如果超限新连接会被拒绝反应到会话表上就是该IP的会话一直不增长新建连接持续失败。查一下设备当前会话总数和限制值再看看安全策略里有没有session-limit相关配置往往就能回答“为什么连不上”。会话老化时间也是个隐蔽因素。TCP连接长时间空闲会被回收UDP更快有些长连接业务比如数据库连接池、WebSocket看起来“明明还挂着”但防火墙已经超时清理连接表里自然不会留下记录。这类问题不是设备故障而是业务长连接和防火墙老化机制之间的冲突解法是调整对应协议的老化时间而不是一通乱查。5.4 别忽略虚墙和双机热备这两个特殊情况华为USG支持虚拟系统vSystem配置了虚墙后每个虚拟系统有独立的会话表。如果你在根系统下执行display firewall session table看不到某个虚拟系统内部的连接这完全正常不是设备坏了。需要先进入对应虚拟系统再查或者确认视图切换是否到位。初学虚墙的人在这上面卡住很常见先确认自己在哪个“墙”里查表再下结论。双机热备HRP环境下主备机之间靠会话备份同步连接信息。如果备机上查不到会话要先确认会话备份是否开启、主备状态是否正常。实际运维中我习惯优先登主用设备查看备机的会话信息偶尔会因备份延迟不是实时状态拿它做判断容易误导。尤其是刚切换过主备的场景备机上会话表是空白或者不完整都很正常。6. 顺便整理一份命令速查表说说我平时的习惯6.1 查询命令速查下面这张表按我常用的场景整理命令基于VRP8平台USG6000系列。老版本VRP5平台的设备先敲?确认参数再执行。目标命令查所有IPv4会话display firewall session table ipv4按源IP查会话display firewall session table ipv4 source-ip 192.168.1.100按目的IP查会话display firewall session table ipv4 destination-ip 10.10.10.10按源IP查并看NAT转换display firewall session table ipv4 source-ip 192.168.1.100 verbose按源IP加目的端口查display firewall session table ipv4 source-ip 192.168.1.100 destination-port 443按源IP加协议查display firewall session table ipv4 source-ip 192.168.1.100 protocol tcp查会话统计信息display firewall session table statistics查会话老化时间display firewall session aging-time命令名以设备实际提示为准清空会话表reset firewall session table6.2 几个实际运维中养成的习惯第一查会话默认加verbose。虽然输出更长但能看到NAT前后映射、会话ID等信息少跑很多冤枉路。第二先看输出顶部的计数再逐条翻明细汇总数字是最快的风向标。第三会话表只反映当前瞬间的状态连接建立、超时、拆除都在动态发生一次查询没看到不代表业务没来过想确认历史情况要配合日志或连续多次采样别武断下结论。第四也是最想提醒的reset firewall session table非常危险。清空所有会话等于把所有在线连接全部断掉哪怕你正在用的SSH也会被踢掉。远程操作时务必三思最好在变更窗口内才用。清会话前先确认影响范围不然一场“例行维护”可能就变成全员断网的“事故报告”。6.3 把查会话变成例行巡检也好用查连接表不只是故障排查才用。维护过设备的人都懂定期抽查关键内网IP的会话数量、看有没有异常的连接方向比等用户投诉再排查要舒服得多。可以配合脚本定时采集display firewall session table statistics的输出把会话总数曲线拉出来出现异常突增时提前介入。华为设备本身支持通过SNMP监控会话资源不需要额外部署但要把对应的MIB和告警阈值配好。关于虚墙、IPv6、双机热备这些进阶场景后面有机会我再单独整理。至少对大多数人来说学会按IP翻会话表已经是解决“连不上、通不通、谁在跑”这三类老大难问题最直接的一步。我个人的经验是每次碰到网络相关的投诉先让防火墙说话让会话表告诉我流量到底走没走、走到哪一步、卡在哪里比自己瞎猜路由和策略配置高效太多。你下次排障时也试试把“按IP查会话表”变成肌肉记忆效率会明显不一样。