简介：华为防火墙USG6000V基于IP地址和端口的安全策略实验文档，面向网络工程师及防火墙初学者，以企业服务器访问控制为场景，系统讲解如何限制特定IP地址的PC在固定时段内访问非知名端口服务，并说明安全策略的配置顺序与匹配规则。资源为单个PDF文件，仅1.18MB，从实验要求、拓扑设计、配置思路到详细命令步骤与验证结果一应俱全，可对照真实环境快速复现。截至目前已有1581人次浏览与下载，适用于HCIP安全方向备考或日常防火墙策略调试。文档特别演示了地址集与自定义服务集的创建及引用方式，通过先拒绝特殊PC再放行整个域间流量的策略编排，帮助读者理解默认缺省规则的作用，避免策略误配，从而高效掌握基于IP与端口的安全策略实战技能。
1. USG6000V上基于IP地址和端口的安全策略，先解决“你到底想放谁去看哪个端口”
刚开始做USG6000V实验时，我拿着“基于IP地址和端口的安全策略”这句话，以为只要把源IP、目的IP、源端口、目的端口写在一条策略里就完事。结果在eNSP里配了三条规则，内网还是ping不通服务器，最后发现是源安全区域写反了。基于IP地址和端口的安全策略，在USG6000V上不是“一条命令里的四个参数”，而是一整套拆分动作：IP要落到地址对象或源地址字段，端口要落到服务对象或协议端口字段，再加上接口所属安全区域、策略匹配顺序、会话表状态，缺一个都会让规则“看起来放行了、流量却原地消失”。这篇笔记按我的配置习惯，把从区域检查、对象定义、策略落地到排错验证的完整链路过一遍。适合刚在eNSP里搭USG6000V的人，也适合手里有台USG6000系列设备、需要把业务需求翻译成安全策略的运维。
2. 安全策略的匹配模型：IP地址和端口在USG6000V里是怎么被拆开的
配置之前，我建议你先花十分钟搞清楚USG6000V的安全策略是怎么处理报文的，否则后面加策略就是撞运气。
2.1 一条策略的五个要素：地址和端口只是其中两项
在USG6000V上，一条完整的安全策略至少要包含这五类信息：源安全区、目的安全区、源/目的地址、协议与端口、动作。很多人第一次配的时候，只盯着IP和端口，把source-zone和destination-zone当成“可选项”，这是最大的误解。接口必须划入某个安全区域，策略里的源/目的区域必须和流量实际进出口一致，否则规则连匹配的机会都没有。举例来说，内网主机用192.168.1.100访问服务器10.1.1.100，内网口在trust区域，服务器口在untrust区域，策略里就应该写source-zone trust、destination-zone untrust。如果写成untrust到trust，这条策略永远不会被命中，因为报文根本不会从untrust口进来。
再看地址和端口。在命令行里，你可以直接在策略下写source-address 192.168.1.0 mask 24，也可以先定义地址对象再被引用。端口其实是“服务”的一部分，标准说法是“服务对象”，必须指定协议类型，比如TCP、UDP，然后才是端口号。协议不写，防火墙不知道你要放行的是TCP还是UDP，这也是“端口加上了还不通”的一个常见来源。
我一般建议先创建对象再建策略，原因有两个：一是地址和端口对象可以在多条策略里复用，改需求时只改对象；二是策略列表里显示的是对象名，排错时一眼能看出这条策略在管哪段IP、哪个端口。下面的小节会说对象怎么做，这里先记住“IP+端口”只是策略的一部分，不是全部。
2.2 首包建会话，后续包查会话表：改策略不能“秒生效”
USG6000V是状态防火墙，处理新连接时，首包会去做安全策略匹配，匹配通过后生成一条会话表项；同一条连接后续的数据包不再重复匹配策略，而是直接查会话表转发。这个机制对性能是好事，但会带来一个很实际的问题：你在防火墙上改了策略，已经存在的连接不会立刻按新策略执行，它们还走旧会话。
我记得有一次在内网测试环境里，把一条策略的目的端口从8080改成443，改完立刻从客户端发起新连接，443是通的，但旧的8080连接还在，用netstat看依然存在。当时一度以为防火墙策略没有“热更新”，后来才想起来是先有会话后有转发，旧连接要等老化或手动清会话。
所以在配置基于IP和端口的安全策略时，我养成了一个习惯：每次改动涉及源地址、目的地址、端口、动作或区域，测试前先执行reset session清理相关会话，或者至少把测试主机对应IP的会话筛出来清掉。这个命令放在排错章节详细说。
2.3 默认策略与同区域互访：地址端口之外的第三个“隐形规则”
你可能会想：我只放行了一条“IP+端口”的permit规则，那其他流量是不是自动被拒绝？在USG6000V上，不同安全区域之间的报文在没有匹配到任何安全策略时，默认是丢弃的，所以不需要显式写“拒绝所有”也能达到默认拒绝的效果。但要注意两个边界：一个是同区域互访，一个是local区域。
先说同区域互访。某些USG版本和虚拟系统里，同一安全区域内的两台主机默认可能放行，也可能不放行，取决于系统版本和默认安全策略模板。不要拿“网上说同区域默认通”来赌业务，最稳妥的办法是在策略里显式写一条“同区域允许指定IP端口”的规则，或者先抓包确认默认行为。
再说local区域。防火墙自己产生的流量，比如你从内网SSH登录防火墙管理口，或者防火墙主动发起连接，走的是local区域和对应接口区域的交互，普通的安全策略不一定能管到。所以当你发现“管理IP能ping通，但管理端口不通”的时候，先别急着怀疑IP地址和端口，很可能是local区域的策略或接口的service-manage设置没放开。
这三块搞明白了，再继续配置就不容易翻车。下一步我们把IP和端口变成对象，把“地基”打好。
3. 地址和端口怎么“变成”对象：配置IP与端口服务前的三步准备
在配置安全策略之前，我一般会按顺序做三件事：检查接口IP和区域、创建地址对象、创建服务对象。下面分别讲。
3.1 先给USG6000V的接口配上IP，确认虚拟网卡和网段在一条船上
USG6000V通常在eNSP或VMware里跑。如果你用VMware，第一步不是进防火墙敲策略，而是确认虚拟网卡的网段和USG6000V的管理口IP在同一子网。比如你在VMware里给USG6000V添加了一块VMnet2网卡，网卡subnet是192.168.50.0/24，那防火墙GE0/0/0就应该配成192.168.50.x，不能在192.168.1.0/24里乱配，否则策略再对也没有接收链路。
命令行下，我一般这样配接口IP：
# 进入USG6000V接口视图，GE0/0/0作为管理口/内网口 interface GigabitEthernet0/0/0 ip address 192.168.50.254 255.255.255.0 service-manage ping permit quit # 查看接口IP和状态，确认没有admin down display ip interface brief # 查看接口划在哪个安全区域，后面写策略要用到这个区域名 display zone参数说明：ip address后面的地址和掩码必须和虚拟机网卡在同一网段，否则报文根本过不来；service-manage ping permit是允许这台防火墙的接口响应ping，这是USG设备上比较特殊的控制项，不影响转发的安全策略，只影响防火墙自身被ping。display zone输出里能看到GigabitEthernet0/0/0属于哪个zone，你在命令行里看到的zone名字就是后面策略里的source-zone或destination-zone。
如果是在VMware里，还需要检查虚拟机网卡是否改成了“仅主机模式”或“自定义VMnet2”，以及宿主机上对应虚拟网卡的IP有没有冲突。你可以用ipconfig或ifconfig查看宿主机本机的IP地址，确认192.168.50网段只有一个地址分配来源，避免IP地址冲突导致后面策略验证时忽通忽断。这一步是很多实验翻车的起点——IP和端口策略写得很严谨，但物理链路压根不在同一网图里。
3.2 定义IP地址对象：用“对象”代替写上几十条裸IP
如果你只有一台服务器和一个固定的网段，其实可以直接在策略里写源地址和目的地址；但当规则增多、IP要跨多条策略复用时，对象才是正路。在USG6000V的Web界面里，路径是“对象 > 地址管理 > 地址组/地址”，新建一个“地址”或“地址组”，类型选“IPv4地址”，然后把网段填进去。
命令行也有对应的地址对象命令，需要注意的是不同版本字段差异比较大，在设备上输到一半用?看提示最稳。我常见的一种写法是：
# 创建地址对象，名字叫server-net，保存两个内网段 ip address-set server-net type object address 0 192.168.10.0 mask 24 address 1 192.168.20.0 mask 24 quit # 查看地址对象内容，确认掩码和范围没有写错 display ip address-set name server-net这段命令里的address 0、address 1是序号，不是IP的一部分，后面的IP和掩码才是真正范围。type object表示这是一个地址对象而不是一个空组名。如果这条命令在你设备上不支持，不要硬记，直接用Web界面创建对象，然后复制对象名去策略里引用。
我建议做一次“地址对象体检”，重点看掩码。很多人的坑是把255.255.255.0写成24，或者把两个连续网段压成一个汇总段，导致地址对象比业务实际范围大了一圈，最后防火墙放行了一些本不该放行的IP，这在安全审计时非常难看。下一小节讲端口对象，原则是一样的：先定义，后引用。
3.3 定义端口/服务对象：TCP、UDP和源端口别混在一起
端口在USG6000V的安全策略里不是单独存在的字段，而是“服务对象”的一部分。新建服务对象时，核心参数有三个：协议类型、目的端口、源端口。绝大多数业务需求只关心“目的端口”，比如访问Web就放行TCP 443，访问DNS就放行UDP 53。如果你把TCP和UDP搞混，或者把目的端口写到源端口里，策略就会像没写一样。
Web界面里，路径是“对象 > 服务 > 新建服务”，选TCP，目的端口写443。可以再建一个UDP 123的服务对象用于NTP。命令行里如果你不想走服务对象，直接写在策略规则里也可以，下一章会展示。
这里有个容易踩的边界：防火墙策略里的“端口”通常指目的端口，但这不代表源端口没用。比如你限制内网某些主机只能从本机50000端口出去访问外部TCP 443，就需要额外配置源端口。不过一般业务不建议限制源端口，因为很多客户端端口是随机生成的，强行限制会导致连接建立失败。这个区别一定要在服务对象定义时看清，尤其是从老防火墙配置迁移过来的人，习惯把源端口和目的端口都写上，结果在USG6000V上反而成了障碍。
做完接口IP、地址对象、服务对象这三步准备，你手里就有了“干净的积木”，后面写策略就是往规则里拼积木。
4. 把规则写进去：CLI和Web两种方式落地一条IP+端口安全策略
现在开始正式配置。我用一个典型场景：内网192.168.1.0/24主机要访问服务器10.1.1.100的TCP 443端口，防火墙要把这项访问放行，其他内网到服务器的访问默认拒绝。这个需求正好是“基于IP地址和端口的安全策略”的最小完整样例。
4.1 CLI方式：允许内网访问服务器TCP 443的一条规则
命令行配置前，先确认两件事：GE0/0/0在trust区域，GE0/0/1在untrust区域；服务器IP是10.1.1.100。然后进安全策略视图配置：
security-policy rule name permit_web source-zone trust destination-zone untrust source-address 192.168.1.0 mask 24 destination-address 10.1.1.100 mask 32 service protocol tcp destination-port 443 action permit quit这条规则的含义是：从trust区域进入、从untrust区域出去、源IP属于192.168.1.0/24、目的IP是10.1.1.100、协议是TCP、目的端口是443的流量，允许通过。
参数说明：源地址那里用的是mask 24写网段，目的地址是单个IP所以是mask 32。如果服务器有多个IP，或者你希望用一个地址对象替代，可以把source-address后面换成对象引用。service protocol tcp destination-port 443是这条策略的核心“端口”部分；协议不写UDP，就表示只匹配TCP 443，UDP 443不会被放行。
在这个场景下，其他未匹配到这条permit规则的流量，按前面说的默认动作会被丢弃，所以不需要额外再写一条deny all。但为了审计方便，有些团队喜欢在最后加一条显式deny规则，记录日志。显式deny规则要放在“宽泛规则”之前还是之后？USG6000V的策略匹配顺序是先匹配先生效，如果你的需求是“除了这个网段其他全都拒绝”，可以只保留permit在前面，让后面默认deny兜底。如果一定要写deny，我一般这样放：
security-policy rule name deny_other_net source-zone trust destination-zone untrust destination-address 10.1.1.100 mask 32 service protocol tcp destination-port 443 action deny rule name permit_web source-zone trust destination-zone untrust source-address 192.168.1.0 mask 24 destination-address 10.1.1.100 mask 32 service protocol tcp destination-port 443 action permit quit这样把deny放在permit前面，是可以工作的，但会让策略意图变得难懂。我个人的习惯是“精确放行放前面，宽泛拒绝放后面”，除非业务上要求“源IP不在名单里的一律拒绝”。不要照搬网上的顺序模板，先想清楚你写的策略是“白名单思想”还是“黑名单思想”。
4.2 Web方式：拖拽地址和端口之后一定要点“提交”
如果你面对的是图形化管理的设备，Web界面会更直观。进入“策略 > 安全策略”，新建一条规则，填写名称。源安全区选trust，目的安全区选untrust；源地址选之前创建好的地址对象或直接输入192.168.1.0/24；目的地址输入10.1.1.100或选择对象；服务选择“TCP 443”或你自定义的服务对象；动作选允许，开启日志开关。
配置完成后，很多人在eNSP里就只点了一下“确定”，然后关闭页面。USG设备较新版本里，Web界面修改安全策略后，页面上方通常有一个“提交”按钮，不提交的话配置只停留在临时变更里，运行配置没有更新。我见过不少新手就卡在这个“灵异现象”上：策略明明在列表里，display却不显示，流量也不通。
提示：Web界面改动安全策略后，页面上方出现“提交”按钮时，一定要点，否则只是修改了草稿，没有写进运行配置。
在Web界面上改完策略后，如果想回到命令行核对，可以执行display current-configuration，在输出里找security-policy段，把实际生效的策略抓出来看。Web界面有时候会把用户输入的裸IP自动转成某种内部对象，命令行的显示形式不一定和你输入的一样，这是正常现象，别看到不一样就以为配错了。
4.3 策略顺序与会话参数：决定“通不通”和“稳不稳”
策略顺序这个问题，在只有一两条规则时看不出影响，规则超过五条就会成为主坑。USG6000V默认按配置顺序匹配，display security-policy rule all里每条规则有一个序列号。后面加的规则排在末尾，如果前面有一条宽泛的permit all，后面的精确deny永远不会被命中。调整顺序在Web界面是拖拽，命令行用rule move，例如把permit_web移到deny_other_net前面。调完同样要注意会话问题，老连接还是会按旧顺序走。
端口相关的稳定性参数里，最常碰到的是会话老化时间。数据库连接、websocket长连接这类长时间不交互的连接，如果防火墙老化时间设的比业务保活时间短，中间会出现“断连”，但TCP没有正常结束。USG6000V默认会话老化时间对大部分HTTP业务够用，但对长连接要单独调。在Web界面“系统 > 会话管理”里能找到TCP老化时间，一般调到3600秒起，具体看业务心跳间隔。命令行调法各版本差异大，建议用Web。
另外，如果服务器上同时部署了多个端口，例如443和8443都提供服务，别天真地认为放行了443就“顺便”放行8443。防火墙按端口精确匹配，每开放一个端口就要对应一条服务对象或一条service配置。这里也能看到先建服务对象的好处：把443、8443放进一个服务对象组，策略里引用一次，后续加端口只改对象。
5. 避坑与排查：IP地址、端口和安全策略最常翻车的5个现场
下面的每一条都是我或认识的人在实际配置里踩过的，按“现象 → 原因 → 解决”写，可以直接对照排错。
5.1 source-zone填错导致策略“没生效”：先查display zone
现象：内网主机访问服务器的443端口不通，策略里明明放行了源IP和目的IP，抓包看到内网主机发出的SYN包到了防火墙接口，但防火墙没有转发到服务器。
原因：规则里的source-zone和destination-zone与接口实际所属区域对不上。比如内网接口其实划在dmz区域，你在策略里写source-zone trust，报文从dmz进来，去trust区域查策略时根本看不到这条规则，于是丢包。这是最常见、最难排查的“策略没生效”，因为它不是端口问题，也不是IP问题，而是区域问题。
解决：先执行display zone，确认哪个接口在哪个区域，再display security-policy rule all看现有规则里的区域。把规则里的source-zone改成实际入接口区域，destination-zone改成出接口区域，重新测试。如果设备启用了虚拟系统，还要注意是在哪个虚拟系统里配置的规则。
5.2 改了策略不清会话：老连接仍然按旧规则转发
现象：把允许端口从8080改成443后，新客户端访问443正常，老客户端访问8080还是通；或者把某条deny策略加进去，已经建立的连接还是能继续跑。
原因：前面说过，USG6000V对已经建立的连接走会话表，不会重新匹配策略。你改策略只影响“下一个新连接的首包”，不影响已有会话。
解决：在用户视图执行reset session，可以把整张会话表清掉，但我建议先按IP筛：
# 清理指定源IP相关的全部会话，让这些主机的下一次访问重新走策略匹配 reset session source-ip 192.168.10.100参数说明：source-ip后面写你要测试的主机IP。清完后，让客户端重新发起连接，再用display firewall session table查看，确保新会话已经建立。这个操作对生产环境影响小，只影响那台测试主机的连接。
5.3 服务对象里的源端口和目的端口搞混：端口放行了还是不匹配
现象：规则里写了TCP 8080，客户端从局域网访问服务器8080不通，但服务器本机访问8080是通的，把策略改成permit all之后立刻能通。
原因：服务对象创建时，端口填在了“源端口”字段而不是“目的端口”。对于外部客户端访问服务器这个方向，防火墙匹配的是目的端口；如果对象里只有源端口8080，入方向的报文目的端口并不是8080，策略就匹配不上。还有一种情况是协议选错，例如服务器用UDP 8080，你配了TCP 8080。
解决：回到对象管理里检查服务对象定义，确认协议类型和“目的端口”字段。如果策略里直接写service protocol tcp destination-port 8080，就没有这个歧义，因为命令已经指明destination-port。多端口场景建议用服务对象组，并保证组里每个服务对象都是“目的端口”语义。
如果服务器本地端口被占，也会出现“策略放行了但连接不上”的现象，这属于应用层问题，不要在防火墙上死磕。先用netstat -anp确认端口确实在被监听，再回头查防火墙。
5.4 地址对象掩码写错：部分IP被静默拒绝
现象：同一网段内一部分主机能访问服务器，另一部分不能，两者IP看起来都很接近。策略是permit，没有deny规则，日志里被丢弃的报文也看不到太多信息。
原因：地址对象在定义时掩码写宽了或写窄了。比如业务网段是192.168.1.128/25，你在地址对象里填了192.168.1.0 mask 25，覆盖范围变成192.168.1.0-127，真正业务网段的后半段（128-255）不在对象里，自然被默认拒绝。反过来，如果是安全策略里用了汇总地址，可能把不该放行的网段也放进来。
解决：用display ip address-set name xxx看地址对象实际解析出来的网段范围，或者直接在Web界面的地址管理里检查。有些版本还支持display ip address-set all列出所有对象。把掩码改回业务真实网段，再配合第5.2条重置相关会话。
5.5 local区域的流量不走普通安全策略：管理口“不通”的另一层原因
现象：内网主机能访问业务端口，但SSH登录不了防火墙自身的管理口，或者Web管理界面打不开。明明在安全策略里放行了管理地址和端口，依然不行。
原因：访问防火墙自身的流量，源/目的区域里有一个是local。比如从trust区域SSH到防火墙的GE0/0/0，流量是从trust到local，普通trust到untrust的策略管不到。另外，接口视图下的service-manage设置也会限制防火墙自身响应哪些服务，即使安全策略放行了，接口没开service-manage一样不通。
解决：需要单独配置local区域相关策略，或者在接口视图开放对应服务。常见做法是：
# 在接口视图开放HTTP/HTTPS管理，并允许ping interface GigabitEthernet0/0/0 service-manage http permit service-manage https permit service-manage ping permit quit # 如果有local区域策略，再单独放行trust到local的管理访问 security-policy rule name permit_manage source-zone trust destination-zone local source-address 192.168.1.0 mask 24 service protocol tcp destination-port 22 action permit quit参数说明：destination-zone local是关键，别写成untrust。22是SSH端口，管理界面是443（HTTPS）或80（HTTP），按需保留。这样管理口不通的坑就解开了。
6. 验证策略生效的两种命令，和把“IP+端口”策略升级成“时间+对象”策略
6.1 用会话表核对流量是否真的走了策略
配置完以后，别只盯着策略列表看，要看实际会话。我最常用的验证命令是：
# 查看某台内网主机的会话，确认连接建立、端到端转发正常 display firewall session table source-ip 192.168.1.100 # 核对运行配置里这条策略的存在和参数 display security-policy rule name permit_webdisplay firewall session table能看到这条连接的源/目的IP、端口和状态，如果会话表里没有，说明包还没到防火墙，或者被更早的规则丢弃。display security-policy rule name用来核对规则里的区域、地址、服务、动作有没有写错。命中次数在各版本里不一定都在命令行显示，Web界面的策略列表里通常会带一个“命中次数”列，排错时先用Web判断“哪条规则在捡流量”。
我自己的习惯是：先看会话，再看策略，最后才抓包。因为会话表最能说明“防火墙到底有没有放行这个连接”，省去很多猜疑。
6.2 给IP+端口策略加上时间计划，从“通”升级到“可控”
把IP和端口固定住以后，下一步是做更细的控制。USG6000V支持时间计划，在Web里新建一个“工作时间”对象，然后在策略里引用。比如允许内网访问服务器443，但只在周一到周五9点到18点生效。命令行下需要先配时间计划，再在安全策略里绑定。不同版本命令不一样，Web操作更简单：对象 > 时间计划 > 新建，选周期方式，勾选工作日和时段；然后回到安全策略，在“时间段”字段里选这个计划。
这样原本的“基于IP地址和端口的安全策略”就升级成了“基于IP+端口+时间的策略”。再往上，还可以结合用户认证和应用识别，但那些依赖License和更完整的USG功能包，硬件型号不同能力差异很大。USG6000V作为虚拟设备，主要适合练手和验证配置逻辑，不建议拿它跑生产大数据流量。
最后说个我自己的教训。前几年给客户迁移防火墙，我把一组地址对象从旧设备导入到USG6000V，看着IP和端口都没问题，但服务器始终不通。折腾了一个多小时，最后在会话表里发现流量去了旧服务器的IP，原来是策略里目的地址引用了旧地址对象，而新服务器IP我临时用裸地址写在另一条规则里，两条规则顺序又不对。那一次之后，我养成了一个习惯：每次改完基于IP和端口的策略，先display security-policy rule all看规则顺序，再display firewall session table看实际连接目标；有怀疑就先重置会话，别凭记忆猜。这个习惯帮我省了不少时间。希望帮到你。
本文还有配套的精品资源，点击获取
