尧图网页设计 
简介面向网络工程师与华为设备学习者这份PDF完整演示了USG6000V防火墙基于IP地址和端口实施安全策略的典型实验。场景设定为企业两台业务服务器分别通过TCP 8888和UDP 6666非知名端口对外服务要求在工作日8:00至17:00禁止特定IP访问其余时段及用户不受限。文档从实验拓扑、配置思路讲起逐步展示如何配置接口IP、加入DMZ区域、创建源IP地址集、自定义服务集及时间段对象并在此基础上下发两条安全策略与trust到dmz的域间放行规则。其中特别说明零散地址适合用地址集管理、非知名端口必须自定义服务集、策略按配置顺序匹配且应先细化后宽泛等易错要点并给出验证结果。资源仅含1个PDF文件大小1.18MB内容紧凑、步骤完整适合作为防火墙策略配置的实操参考或认证备考笔记。目前已有1581人学习对想系统理解USG6000V域间策略设计逻辑的读者颇具价值。1. USG6000V 安全策略为什么配了 IP 和端口流量还是不通华为防火墙 USG6000V 的“基于 IP 地址和端口的安全策略”说白了就是一套按五元组做流量放行和阻断的规则系统源 IP、目的 IP、源端口、目的端口、协议再加上区域和动作。很多第一次在虚拟化平台里部署 USG6000V 的兄弟都会遇到同一个场景管理口能登录、接口 IP 都通了但业务网段之间就是互相访问不了或者访问半个钟头后忽然断一下查了半天最后发现是安全策略里没写对目的端口、没选对区域甚至规则顺序反了。这类问题在物理防火墙上少一些因为拓扑直观一旦跑到 USG6000V 这种虚拟防火墙上配合多网卡、多虚墙、多网段的网络环境问题就明显变多了。这篇笔记面向正在用 USG6000V 做网段隔离、端口放行、出口管控的运维和网络工程师。我会把安全策略的匹配模型、配置顺序、常用命令、验证手段和最容易踩的坑一次讲透让你照着配完能自己查会话表、看命中计数而不是靠猜。2. 安全策略的匹配机制规则顺序为什么能决定流量生死2.1 安全策略和 ACLUSG 上有两条路径别混着用USG6000V 上控制流量有两套东西老一代的 ACL访问控制列表和新一代的安全策略Security Policy。ACL 配置起来像路由器写在接口下、绑定在流量入方向或出方向上匹配后执行 permit / deny逻辑简单但有个很大的问题——它只管 IP 和端口管不了用户、应用和时间段规则一多还容易互相覆盖排查时候得把整条链路翻一遍。安全策略则是在系统视图下的 security-policy 域里统一配置规则可以引用地址组、服务组、用户组、时间段动作有 permit、deny还能配置是否记录日志和会话老化时间。它和 ACL 最大的区别是匹配模型安全策略按规则序号逐条匹配命中即停止不再看后面的规则而 ACL 在部分场景下还会继续匹配或做隐式拒绝。USG6000V 默认在所有安全策略末尾有一条隐藏的 deny all也就是没被任何显式规则放行的流量最终都会被丢弃。这是新手最容易误解的地方配了 permit 规则但顺序不对流量被前面的 deny 吃掉后端业务自然不通。提示在 USG6000V 上做端口放行优先用安全策略不要用 ACL。ACL 更适合在接口上做简单的协议过滤安全策略才是业务放行的主战场。2.2 匹配顺序和命中行为先阻断还是先放行效果完全不同安全策略的匹配顺序默认按优先级和规则编号综合决定但你可以显式指定规则是 depth深度优先还是 auto按配置顺序。实际工作中我一般让规则按业务维度手动排好顺序把明确要阻断的高危流量放前面把大范围放行放后面最后留一条 default deny 兜底。举个例子你要放行 192.168.10.0/24 访问 192.168.20.10 的 8080 端口同时阻断这个网段访问 192.168.20.10 的 22 端口。如果只写一条“放行所有 IP 访问 192.168.20.10 的 8080”那么 22 端口的流量会继续往下匹配直到撞上默认 deny最终也是不通的。但如果你先写了一条“deny 192.168.10.0/24 访问 192.168.20.10 所有端口”结果后面即使写了放行 8080流量也会在第一条规则就停止匹配8080 照样不通。所以规则顺序的核心是精确的、动作更严格的规则放前面宽泛的放行放后面。别把“全部放行”这种规则写在开头否则后面的安全策略全部形同虚设。2.3 配置入口Web 界面和命令行看到的规则有什么不同USG6000V 支持 Web 管理和命令行两种配置方式。Web 界面在“策略 → 安全策略”菜单下可以新建规则界面里能看到源区域、目的区域、源地址、目的地址、服务、动作这些字段适合单条规则的创建和修改。命令行则是系统视图下进入 security-policy 视图来配置。命令行最大的优势是能快速查看规则之间的顺序和命中情况一次执行 display security-policy rule hit-count 就能看到所有规则的命中次数Web 界面虽然也能看但刷新不及时字段列也不全。我一般建议日常调参用 Web批量配置和故障排查用命令行。特别是当你通过 SSH 登录 USG6000V 时命令行是唯一可靠的操作路径因为 Web 服务在业务中断或管理口异常时可能登录不进去。3. 从端口需求到策略下发一组可复现的最小配置3.1 先把 IP、端口、方向写进需求表再动手配置安全策略之前我习惯先拿一张需求表把规则要素列清楚避免在防火墙上东加一条西加一条最后自己都不知道哪些规则在起作用。一张标准需求表至少包含以下几列规则名称、源区域、目的区域、源 IP、目的 IP、协议、目的端口、动作、是否记日志。别小看这一步USG6000V 上很多水土不服的案例根源都在需求阶段没把“哪个区域访问哪个区域”写清楚。规则名源区域目的区域源 IP目的 IP协议目的端口动作allow_web_8080trustuntrust192.168.10.0/24192.168.20.10TCP8080允许deny_admin_22trustuntrust192.168.10.0/24192.168.20.10TCP22拒绝allow_dns_querytrustuntrust192.168.10.0/24anyUDP53允许这个例子是典型的业务网段访问服务器场景内网办公网段在 trust 区域服务器或外网在 untrust 区域。源端口一般不写因为大多数应用连接的方向都是客户端用随机高端口访问服务器的固定低端口安全策略只需关注目的端口即可。3.2 定义地址对象和服务对象配置策略前的必要准备USG6000V 上写安全策略有两种方式直接在规则里敲 IP 和端口或者先定义地址对象和服务对象再引用。直接敲适合临时测试生产环境一定要用对象。原因很简单业务扩容时如果服务器 IP 变化或端口调整只需改动对象规则不受影响直接敲 IP 的策略则要逐条改漏改一条就翻车。地址对象用 address-group 创建服务对象用 service-set 创建。服务对象里可以组合协议和端口号比如一条服务组包含 TCP 8080 和 TCP 8443策略引用这个服务组后两条端口同时被放行。IP 地址也可以做组例如把前端服务器的三个业务 IP 放进一个地址组策略里直接引用组名后续新增 IP 加进组即可策略本身不用改。提示服务组的名字最好带上业务含义比如 web-service、db-service不要叫 service1、group2。USG6000V 的策略一多名字没有可读性自己都很难维护。3.3 安全策略配置命令一组带注释的完整配置下面这段命令对应 3.1 的需求表从创建对象到配置安全策略到保存配置一条龙走完。USG6000V 的 CLI 语法和华为其他安全产品基本一致可以直接在系统视图下执行。# 进入系统视图 system-view # 1. 定义地址组把办公网段和后端服务器地址都放进去 ip address-set name office_net type group address 192.168.10.0 mask 24 quit ip address-set name server_ip type group address 192.168.20.10 mask 32 quit # 2. 定义服务组放行 TCP 8080 / 8443拒绝 22 ip service-set name web_service type group service protocol tcp destination-port 8080 service protocol tcp destination-port 8443 quit ip service-set name admin_service type group service protocol tcp destination-port 22 quit # 3. 进入安全策略视图按顺序配置规则 security-policy # 3.1 阻断管理端口必须放在放行规则前面 rule name deny_admin_22 source-zone trust destination-zone untrust source-address address-set office_net destination-address address-set server_ip service service-set admin_service action deny enable log quit # 3.2 放行业务端口精确指定 IP 和端口 rule name allow_web_8080 source-zone trust destination-zone untrust source-address address-set office_net destination-address address-set server_ip service service-set web_service action permit enable log quit quit # 4. 保存配置 save这段配置的逻辑是先阻断 22再放行 8080 和 8443。规则顺序上阻断必须在放行前面一旦放行规则先命中deny 规则就不会被匹配到。service 引用的服务组和地址组都是对象好处是后续加端口或换 IP 只需修改对象本身不用碰策略。参数说明source-zone 和 destination-zone 代表流量从哪里进、从哪里出zone 不匹配时规则直接不生效source-address 引用内网网段destination-address 指向服务器地址service 引用服务对象动作分 permit 和 denyenable log 可以让流量日志上送到日志服务器或本地缓存排障时非常关键。3.4 验证配置查看策略和会话表的状态配置完成后不要急着收工先在命令行里确认策略是否真正生效。验证分两步看规则列表和命中计数再看会话表。# 查看所有安全策略规则包含命中次数 display security-policy rule all display security-policy rule hit-count # 查看某条规则的详细内容确认配置没写错 display security-policy rule name allow_web_8080 # 查看通过防火墙的实时会话确认端口放行后的连接状态 display firewall session tabledisplay security-policy rule hit-count 返回结果里每条规则后面会有 Hit-count 字段表示这条规则匹配到了多少个数据包。如果策略配了但命中计数一直是 0基本可以断定流量根本没走到这条规则要么是区域方向不对要么是前置规则已经先命中了。display firewall session table 则是查看当前活跃连接里面能看到源 IP、目的 IP、目的端口、协议和会话状态。比如 192.168.10.1 访问 192.168.20.10 的 8080 端口成功后这里会出现一条对应会话。看到会话表有这条流量才是真正说明业务通了。4. USG6000V 安全策略常见问题与排查四个让我半夜翻车的坑4.1 策略不生效、命中次数是 0问题出在区域和方向现象安全策略明明写了放行 192.168.10.0/24 访问 192.168.20.10 的 8080但业务端始终连不上看策略命中计数是 0。原因USG6000V 的策略匹配第一要素不是 IP而是区域。如果流量实际是从 trust 区域进来但规则里写的源区域是 untrust规则永远不可能被匹配到。另一种常见情况是流量从接口进来后先被接口下的 ACL 拒绝根本没进入安全策略匹配流程。解决先查接口加入的区域display ip interface brief 看接口信息display firewall zone 看区域和接口绑定关系确认流量实际进出方向对应哪个 zone再回头核对规则里的 source-zone 和 destination-zone。命中计数为 0 时直接在防火墙执行 display firewall log 看是否有流量被默认 deny 拦截的记录通常能发现流量的真实走向。4.2 忘了 boot 密码直接恢复整台设备的配置被清空现象USG6000V 部署久了管理密码遗失或被误改同事急着恢复访问直接进 boot 菜单恢复出厂重启后所有接口 IP、安全策略、地址对象全部丢失。原因USG 系列防火墙的 boot 菜单里有密码恢复功能但恢复密码这件事本身要求清空配置文件。很多人没注意这个提示按了确认后设备直接恢复出厂设置之前没备份就等于全部重新来过。解决密码丢失时先看有没有最近的配置文件备份比如在升级或割接前导出的 cfg.zip 文件没有备份再进 boot 菜单但执行前确认能接受配置清空的后果。恢复后第一件事是把所有安全策略按需求表重新录入然后立刻在命令行执行 save 并导出配置备份。这个习惯一定要养成每次策略批量修改前先做一次配置备份花两分钟能省掉中途改崩后一整夜的抢救。4.3 源地址被源 NAT 改写后策略匹配顺序反了现象内网服务器访问外部业务时USG6000V 做了源地址转换把内网真实 IP 换成了接口地址。这时按真实内网 IP 写的目的侧策略完全没意义因为防火墙看到的是 NAT 后的源地址。原因USG6000V 的安全策略和 NAT 策略有固定的处理顺序。流量入站后先匹配安全策略再做源 NAT而部分场景下策略引用的源地址如果写的是 NAT 转换前的内网地址在回程流量上就会因为源地址已是接口 IP 而匹配到错误的规则。解决策略匹配要按防火墙实际看到的 IP 来写。内网出口做源 NAT 的场景把安全策略里的源地址写成内网真实网段但要注意策略和 NAT 规则的先后关联如果策略里的源地址与 NAT 转换后的地址冲突检查 NAT 策略里的源地址池是否覆盖了安全策略的匹配范围。简单说策略里的 IP 是“转换前”还是“转换后”取决于流量是入站还是出站别凭直觉写。4.4 虚拟防火墙里管理口和业务口划分混乱规则互相串扰现象USG6000V 部署在虚拟化平台上创建了多个虚拟防火墙实例虚墙每个虚墙需要独立的管理 IP。但配置时把管理流量和业务流量混在同一个接口区域里结果虚墙之间流量互通安全策略怎么配都隔离不住。原因USG6000V 支持虚拟防火墙功能每个虚拟系统有独立的接口、路由和安全策略但底层物理接口和 VLAN 划分如果不隔离虚墙之间会通过虚拟接口转发流量策略写得再严格也管不住这部分流量。解决虚墙环境下先规划接口和 VLAN 的对应关系管理口单独划分一个 VLAN 并配置独立管理 IP业务接口按区域绑定到对应虚墙再在虚墙上分别配置安全策略确保虚墙之间的流量要么被阻断、要么被显式规则放行。学习虚墙配置时重点先搞懂接口视图、系统视图与虚墙的嵌套关系否则策略看着在实际管的是另一个实例的流量。5. 用命中计数、会话表和抓包验证安全策略真的在干活5.1 命中计数是最快的体检报告策略配置完我第一眼先看 display security-policy rule hit-count这个命令能一次性列出所有规则的命中次数比逐条看规则内容直观得多。规则命中次数持续增长说明这条规则正在处理真实流量命中计数一直是 0优先怀疑区域方向、规则顺序或前置 ACL 拦截。清空计数再观察也是个好办法执行 reset security-policy rule hit-count 清零后模拟一次业务访问如果命中次数从 0 变 1说明刚才的流量确实被这条规则接收了。这个操作很适合变更验证能快速区分“规则没起作用”和“流量没走到这条规则”。5.2 会话表能看到策略生效后的真实连接display firewall session table 是所有状态检测防火墙的真相来源。USG6000V 是状态检测防火墙流量匹配安全策略并放行后会创建一条会话记录后续同一个连接的所有报文都直接匹配会话不再看策略规则。所以会话表不仅验证了策略放行还能看到连接的方向、状态和剩余时间。排查“策略放行了但业务还是不通”时先看会话表里有没有对应会话。有会话且状态正常问题大概率不在防火墙而在后端服务器或链路没有会话说明流量在防火墙就被拦截了再回到命中计数去查看是哪条规则拦截的。5.3 抓包对比“策略放行”和“业务失败”的关键差异命中计数和会话表都查过之后仍然不通就要上抓包工具了。USG6000V 可以在接口下发数据捕获常用的命令是 capture-packet抓包后导出为文件用 Wireshark 分析。抓包时注意抓两个方向入接口和出接口然后对比报文进防火墙之后是否发生 IP 或端口变化。例如内网访问服务器不通入接口能抓到 TCP SYN出接口却没有报文出去说明策略或会话创建出了问题入接口有 SYN出接口也有 SYN但回包被丢弃则要查反向策略和回程路由。有一类问题是端口方向被搞混写安全策略时把服务端口填进了源端口字段导致只有源端口恰好是 8080 的流量才能通过而大多数客户端源端口是随机的业务自然不通。看防火墙日志时这类错误很隐蔽抓包对比源端口和目的端口一目了然。我自己的习惯是每次安全策略变更之后都在命令行下看一眼命中计数然后用业务测试工具实际连一次端口再顺手查一条会话记录留存。这套动作看起来多其实就是三句话的命令却帮我避开了很多深夜翻车的局面。配置策略这事最怕的不是不会写而是写完了心里没底命中计数、会话表、抓包这三件套就是那颗定心丸。希望帮到你。本文还有配套的精品资源点击获取 华为USG6000V防火墙安全策略详解：匹配机制、配置顺序与排错实战
简介面向网络工程师与华为设备学习者这份PDF完整演示了USG6000V防火墙基于IP地址和端口实施安全策略的典型实验。场景设定为企业两台业务服务器分别通过TCP 8888和UDP 6666非知名端口对外服务要求在工作日8:00至17:00禁止特定IP访问其余时段及用户不受限。文档从实验拓扑、配置思路讲起逐步展示如何配置接口IP、加入DMZ区域、创建源IP地址集、自定义服务集及时间段对象并在此基础上下发两条安全策略与trust到dmz的域间放行规则。其中特别说明零散地址适合用地址集管理、非知名端口必须自定义服务集、策略按配置顺序匹配且应先细化后宽泛等易错要点并给出验证结果。资源仅含1个PDF文件大小1.18MB内容紧凑、步骤完整适合作为防火墙策略配置的实操参考或认证备考笔记。目前已有1581人学习对想系统理解USG6000V域间策略设计逻辑的读者颇具价值。1. USG6000V 安全策略为什么配了 IP 和端口流量还是不通华为防火墙 USG6000V 的“基于 IP 地址和端口的安全策略”说白了就是一套按五元组做流量放行和阻断的规则系统源 IP、目的 IP、源端口、目的端口、协议再加上区域和动作。很多第一次在虚拟化平台里部署 USG6000V 的兄弟都会遇到同一个场景管理口能登录、接口 IP 都通了但业务网段之间就是互相访问不了或者访问半个钟头后忽然断一下查了半天最后发现是安全策略里没写对目的端口、没选对区域甚至规则顺序反了。这类问题在物理防火墙上少一些因为拓扑直观一旦跑到 USG6000V 这种虚拟防火墙上配合多网卡、多虚墙、多网段的网络环境问题就明显变多了。这篇笔记面向正在用 USG6000V 做网段隔离、端口放行、出口管控的运维和网络工程师。我会把安全策略的匹配模型、配置顺序、常用命令、验证手段和最容易踩的坑一次讲透让你照着配完能自己查会话表、看命中计数而不是靠猜。2. 安全策略的匹配机制规则顺序为什么能决定流量生死2.1 安全策略和 ACLUSG 上有两条路径别混着用USG6000V 上控制流量有两套东西老一代的 ACL访问控制列表和新一代的安全策略Security Policy。ACL 配置起来像路由器写在接口下、绑定在流量入方向或出方向上匹配后执行 permit / deny逻辑简单但有个很大的问题——它只管 IP 和端口管不了用户、应用和时间段规则一多还容易互相覆盖排查时候得把整条链路翻一遍。安全策略则是在系统视图下的 security-policy 域里统一配置规则可以引用地址组、服务组、用户组、时间段动作有 permit、deny还能配置是否记录日志和会话老化时间。它和 ACL 最大的区别是匹配模型安全策略按规则序号逐条匹配命中即停止不再看后面的规则而 ACL 在部分场景下还会继续匹配或做隐式拒绝。USG6000V 默认在所有安全策略末尾有一条隐藏的 deny all也就是没被任何显式规则放行的流量最终都会被丢弃。这是新手最容易误解的地方配了 permit 规则但顺序不对流量被前面的 deny 吃掉后端业务自然不通。提示在 USG6000V 上做端口放行优先用安全策略不要用 ACL。ACL 更适合在接口上做简单的协议过滤安全策略才是业务放行的主战场。2.2 匹配顺序和命中行为先阻断还是先放行效果完全不同安全策略的匹配顺序默认按优先级和规则编号综合决定但你可以显式指定规则是 depth深度优先还是 auto按配置顺序。实际工作中我一般让规则按业务维度手动排好顺序把明确要阻断的高危流量放前面把大范围放行放后面最后留一条 default deny 兜底。举个例子你要放行 192.168.10.0/24 访问 192.168.20.10 的 8080 端口同时阻断这个网段访问 192.168.20.10 的 22 端口。如果只写一条“放行所有 IP 访问 192.168.20.10 的 8080”那么 22 端口的流量会继续往下匹配直到撞上默认 deny最终也是不通的。但如果你先写了一条“deny 192.168.10.0/24 访问 192.168.20.10 所有端口”结果后面即使写了放行 8080流量也会在第一条规则就停止匹配8080 照样不通。所以规则顺序的核心是精确的、动作更严格的规则放前面宽泛的放行放后面。别把“全部放行”这种规则写在开头否则后面的安全策略全部形同虚设。2.3 配置入口Web 界面和命令行看到的规则有什么不同USG6000V 支持 Web 管理和命令行两种配置方式。Web 界面在“策略 → 安全策略”菜单下可以新建规则界面里能看到源区域、目的区域、源地址、目的地址、服务、动作这些字段适合单条规则的创建和修改。命令行则是系统视图下进入 security-policy 视图来配置。命令行最大的优势是能快速查看规则之间的顺序和命中情况一次执行 display security-policy rule hit-count 就能看到所有规则的命中次数Web 界面虽然也能看但刷新不及时字段列也不全。我一般建议日常调参用 Web批量配置和故障排查用命令行。特别是当你通过 SSH 登录 USG6000V 时命令行是唯一可靠的操作路径因为 Web 服务在业务中断或管理口异常时可能登录不进去。3. 从端口需求到策略下发一组可复现的最小配置3.1 先把 IP、端口、方向写进需求表再动手配置安全策略之前我习惯先拿一张需求表把规则要素列清楚避免在防火墙上东加一条西加一条最后自己都不知道哪些规则在起作用。一张标准需求表至少包含以下几列规则名称、源区域、目的区域、源 IP、目的 IP、协议、目的端口、动作、是否记日志。别小看这一步USG6000V 上很多水土不服的案例根源都在需求阶段没把“哪个区域访问哪个区域”写清楚。规则名源区域目的区域源 IP目的 IP协议目的端口动作allow_web_8080trustuntrust192.168.10.0/24192.168.20.10TCP8080允许deny_admin_22trustuntrust192.168.10.0/24192.168.20.10TCP22拒绝allow_dns_querytrustuntrust192.168.10.0/24anyUDP53允许这个例子是典型的业务网段访问服务器场景内网办公网段在 trust 区域服务器或外网在 untrust 区域。源端口一般不写因为大多数应用连接的方向都是客户端用随机高端口访问服务器的固定低端口安全策略只需关注目的端口即可。3.2 定义地址对象和服务对象配置策略前的必要准备USG6000V 上写安全策略有两种方式直接在规则里敲 IP 和端口或者先定义地址对象和服务对象再引用。直接敲适合临时测试生产环境一定要用对象。原因很简单业务扩容时如果服务器 IP 变化或端口调整只需改动对象规则不受影响直接敲 IP 的策略则要逐条改漏改一条就翻车。地址对象用 address-group 创建服务对象用 service-set 创建。服务对象里可以组合协议和端口号比如一条服务组包含 TCP 8080 和 TCP 8443策略引用这个服务组后两条端口同时被放行。IP 地址也可以做组例如把前端服务器的三个业务 IP 放进一个地址组策略里直接引用组名后续新增 IP 加进组即可策略本身不用改。提示服务组的名字最好带上业务含义比如 web-service、db-service不要叫 service1、group2。USG6000V 的策略一多名字没有可读性自己都很难维护。3.3 安全策略配置命令一组带注释的完整配置下面这段命令对应 3.1 的需求表从创建对象到配置安全策略到保存配置一条龙走完。USG6000V 的 CLI 语法和华为其他安全产品基本一致可以直接在系统视图下执行。# 进入系统视图 system-view # 1. 定义地址组把办公网段和后端服务器地址都放进去 ip address-set name office_net type group address 192.168.10.0 mask 24 quit ip address-set name server_ip type group address 192.168.20.10 mask 32 quit # 2. 定义服务组放行 TCP 8080 / 8443拒绝 22 ip service-set name web_service type group service protocol tcp destination-port 8080 service protocol tcp destination-port 8443 quit ip service-set name admin_service type group service protocol tcp destination-port 22 quit # 3. 进入安全策略视图按顺序配置规则 security-policy # 3.1 阻断管理端口必须放在放行规则前面 rule name deny_admin_22 source-zone trust destination-zone untrust source-address address-set office_net destination-address address-set server_ip service service-set admin_service action deny enable log quit # 3.2 放行业务端口精确指定 IP 和端口 rule name allow_web_8080 source-zone trust destination-zone untrust source-address address-set office_net destination-address address-set server_ip service service-set web_service action permit enable log quit quit # 4. 保存配置 save这段配置的逻辑是先阻断 22再放行 8080 和 8443。规则顺序上阻断必须在放行前面一旦放行规则先命中deny 规则就不会被匹配到。service 引用的服务组和地址组都是对象好处是后续加端口或换 IP 只需修改对象本身不用碰策略。参数说明source-zone 和 destination-zone 代表流量从哪里进、从哪里出zone 不匹配时规则直接不生效source-address 引用内网网段destination-address 指向服务器地址service 引用服务对象动作分 permit 和 denyenable log 可以让流量日志上送到日志服务器或本地缓存排障时非常关键。3.4 验证配置查看策略和会话表的状态配置完成后不要急着收工先在命令行里确认策略是否真正生效。验证分两步看规则列表和命中计数再看会话表。# 查看所有安全策略规则包含命中次数 display security-policy rule all display security-policy rule hit-count # 查看某条规则的详细内容确认配置没写错 display security-policy rule name allow_web_8080 # 查看通过防火墙的实时会话确认端口放行后的连接状态 display firewall session tabledisplay security-policy rule hit-count 返回结果里每条规则后面会有 Hit-count 字段表示这条规则匹配到了多少个数据包。如果策略配了但命中计数一直是 0基本可以断定流量根本没走到这条规则要么是区域方向不对要么是前置规则已经先命中了。display firewall session table 则是查看当前活跃连接里面能看到源 IP、目的 IP、目的端口、协议和会话状态。比如 192.168.10.1 访问 192.168.20.10 的 8080 端口成功后这里会出现一条对应会话。看到会话表有这条流量才是真正说明业务通了。4. USG6000V 安全策略常见问题与排查四个让我半夜翻车的坑4.1 策略不生效、命中次数是 0问题出在区域和方向现象安全策略明明写了放行 192.168.10.0/24 访问 192.168.20.10 的 8080但业务端始终连不上看策略命中计数是 0。原因USG6000V 的策略匹配第一要素不是 IP而是区域。如果流量实际是从 trust 区域进来但规则里写的源区域是 untrust规则永远不可能被匹配到。另一种常见情况是流量从接口进来后先被接口下的 ACL 拒绝根本没进入安全策略匹配流程。解决先查接口加入的区域display ip interface brief 看接口信息display firewall zone 看区域和接口绑定关系确认流量实际进出方向对应哪个 zone再回头核对规则里的 source-zone 和 destination-zone。命中计数为 0 时直接在防火墙执行 display firewall log 看是否有流量被默认 deny 拦截的记录通常能发现流量的真实走向。4.2 忘了 boot 密码直接恢复整台设备的配置被清空现象USG6000V 部署久了管理密码遗失或被误改同事急着恢复访问直接进 boot 菜单恢复出厂重启后所有接口 IP、安全策略、地址对象全部丢失。原因USG 系列防火墙的 boot 菜单里有密码恢复功能但恢复密码这件事本身要求清空配置文件。很多人没注意这个提示按了确认后设备直接恢复出厂设置之前没备份就等于全部重新来过。解决密码丢失时先看有没有最近的配置文件备份比如在升级或割接前导出的 cfg.zip 文件没有备份再进 boot 菜单但执行前确认能接受配置清空的后果。恢复后第一件事是把所有安全策略按需求表重新录入然后立刻在命令行执行 save 并导出配置备份。这个习惯一定要养成每次策略批量修改前先做一次配置备份花两分钟能省掉中途改崩后一整夜的抢救。4.3 源地址被源 NAT 改写后策略匹配顺序反了现象内网服务器访问外部业务时USG6000V 做了源地址转换把内网真实 IP 换成了接口地址。这时按真实内网 IP 写的目的侧策略完全没意义因为防火墙看到的是 NAT 后的源地址。原因USG6000V 的安全策略和 NAT 策略有固定的处理顺序。流量入站后先匹配安全策略再做源 NAT而部分场景下策略引用的源地址如果写的是 NAT 转换前的内网地址在回程流量上就会因为源地址已是接口 IP 而匹配到错误的规则。解决策略匹配要按防火墙实际看到的 IP 来写。内网出口做源 NAT 的场景把安全策略里的源地址写成内网真实网段但要注意策略和 NAT 规则的先后关联如果策略里的源地址与 NAT 转换后的地址冲突检查 NAT 策略里的源地址池是否覆盖了安全策略的匹配范围。简单说策略里的 IP 是“转换前”还是“转换后”取决于流量是入站还是出站别凭直觉写。4.4 虚拟防火墙里管理口和业务口划分混乱规则互相串扰现象USG6000V 部署在虚拟化平台上创建了多个虚拟防火墙实例虚墙每个虚墙需要独立的管理 IP。但配置时把管理流量和业务流量混在同一个接口区域里结果虚墙之间流量互通安全策略怎么配都隔离不住。原因USG6000V 支持虚拟防火墙功能每个虚拟系统有独立的接口、路由和安全策略但底层物理接口和 VLAN 划分如果不隔离虚墙之间会通过虚拟接口转发流量策略写得再严格也管不住这部分流量。解决虚墙环境下先规划接口和 VLAN 的对应关系管理口单独划分一个 VLAN 并配置独立管理 IP业务接口按区域绑定到对应虚墙再在虚墙上分别配置安全策略确保虚墙之间的流量要么被阻断、要么被显式规则放行。学习虚墙配置时重点先搞懂接口视图、系统视图与虚墙的嵌套关系否则策略看着在实际管的是另一个实例的流量。5. 用命中计数、会话表和抓包验证安全策略真的在干活5.1 命中计数是最快的体检报告策略配置完我第一眼先看 display security-policy rule hit-count这个命令能一次性列出所有规则的命中次数比逐条看规则内容直观得多。规则命中次数持续增长说明这条规则正在处理真实流量命中计数一直是 0优先怀疑区域方向、规则顺序或前置 ACL 拦截。清空计数再观察也是个好办法执行 reset security-policy rule hit-count 清零后模拟一次业务访问如果命中次数从 0 变 1说明刚才的流量确实被这条规则接收了。这个操作很适合变更验证能快速区分“规则没起作用”和“流量没走到这条规则”。5.2 会话表能看到策略生效后的真实连接display firewall session table 是所有状态检测防火墙的真相来源。USG6000V 是状态检测防火墙流量匹配安全策略并放行后会创建一条会话记录后续同一个连接的所有报文都直接匹配会话不再看策略规则。所以会话表不仅验证了策略放行还能看到连接的方向、状态和剩余时间。排查“策略放行了但业务还是不通”时先看会话表里有没有对应会话。有会话且状态正常问题大概率不在防火墙而在后端服务器或链路没有会话说明流量在防火墙就被拦截了再回到命中计数去查看是哪条规则拦截的。5.3 抓包对比“策略放行”和“业务失败”的关键差异命中计数和会话表都查过之后仍然不通就要上抓包工具了。USG6000V 可以在接口下发数据捕获常用的命令是 capture-packet抓包后导出为文件用 Wireshark 分析。抓包时注意抓两个方向入接口和出接口然后对比报文进防火墙之后是否发生 IP 或端口变化。例如内网访问服务器不通入接口能抓到 TCP SYN出接口却没有报文出去说明策略或会话创建出了问题入接口有 SYN出接口也有 SYN但回包被丢弃则要查反向策略和回程路由。有一类问题是端口方向被搞混写安全策略时把服务端口填进了源端口字段导致只有源端口恰好是 8080 的流量才能通过而大多数客户端源端口是随机的业务自然不通。看防火墙日志时这类错误很隐蔽抓包对比源端口和目的端口一目了然。我自己的习惯是每次安全策略变更之后都在命令行下看一眼命中计数然后用业务测试工具实际连一次端口再顺手查一条会话记录留存。这套动作看起来多其实就是三句话的命令却帮我避开了很多深夜翻车的局面。配置策略这事最怕的不是不会写而是写完了心里没底命中计数、会话表、抓包这三件套就是那颗定心丸。希望帮到你。本文还有配套的精品资源点击获取