1. 项目背景与核心价值最近在帮一个朋友的公司做网络架构优化他们内部有几个业务部门比如研发、市场和行政每个部门对网络访问的需求差异很大。研发需要稳定访问代码仓库和测试服务器市场部则希望访问社交媒体和客户网站时能走更快的线路而行政只需要能流畅使用办公软件就行。他们之前用的是一台华为USG6000系列防火墙所有流量都走同一个出口结果就是高峰期研发拉代码慢市场刷网页卡互相影响体验很差。朋友找到我问有没有办法让不同的人走不同的网络出口。我一听这不就是典型的基于用户的策略路由需求吗基于用户的策略路由说白了就是让防火墙能“认人”。传统的策略路由是基于源IP地址、目的IP地址或者协议端口来选路的但在办公网里用户用的是DHCP获取IPIP地址是动态变化的今天坐这个工位明天可能就换到另一个用IP来绑定策略就非常麻烦且不准确。而基于用户则是将网络访问权限和路径与具体的用户账号绑定。用户无论从哪里、用什么设备接入网络只要用他的账号登录了认证系统他的流量就会被施加预设好的路由策略。这就像给每个员工发了一张“交通卡”研发的卡只能坐“专线地铁”去机房市场的卡可以坐“高速公交”去公网互不干扰。这个功能在华为防火墙上实现起来非常顺畅尤其是USG6000V及后续的系列。它不仅仅是解决了多出口负载和选路的问题更深层的价值在于实现了网络访问的精细化管理。结合用户身份你不仅能控制“他从哪条路走”还能在策略里集成“他能去哪”、“他能用什么服务”实现安全与效率的统一。接下来我就结合这次实际的配置过程把从规划到上线的完整步骤、背后的原理以及我踩过的几个坑给大家详细拆解一遍。2. 前期规划与逻辑拓扑设计在动手敲命令之前花点时间把规划做好能省掉后面一大半的麻烦。基于用户的策略路由不是一个孤立的功能它牵扯到用户认证、安全策略和路由策略三个核心模块的联动。2.1 核心组件与工作流程整个方案的运转依赖于以下几个关键组件用户与用户组在防火墙上创建用户账号或者对接外部认证服务器如AD域、Radius。为了管理方便通常将具有相同访问需求的用户归类到同一个用户组比如developers、marketing。认证策略定义用户如何被识别。常见的是Portal认证网页弹窗登录和802.1X认证接入网络时登录。对于有线办公环境Portal认证部署更灵活。安全策略这是防火墙的看家本领控制“谁”能访问“哪里”的“什么服务”。在基于用户的策略路由中安全策略的源不再是IP地址而是“用户”或“用户组”。策略路由PBR这才是实现流量分流的引擎。策略路由的匹配条件中可以包含“用户”或“用户组”。当流量匹配了策略路由后就会被引导到指定的出接口或下一跳。其工作流程可以简单概括为用户上网 → 触发认证 → 认证成功用户身份与IP绑定 → 流量到达防火墙 → 先匹配策略路由如果配置了基于用户的条件→ 策略路由根据用户身份指示出口 → 再匹配安全策略进行放行或拒绝检查 → 最后从指定出口转发。2.2 网络拓扑与地址规划我朋友的网络拓扑相对典型。防火墙作为网关部署在公司内部网络和外部网络之间。内网接口GigabitEthernet 1/0/1 属于trust安全区域 IP:192.168.1.1/24。内网用户网关指向此地址。外网接口1研发专线GigabitEthernet 1/0/2 属于untrust区域 IP:202.100.1.2/30 下一跳为运营商网关202.100.1.1。这条线路带宽小但延迟低、质量稳定适合访问代码托管站如GitLab、云服务器等。外网接口2普通宽带GigabitEthernet 1/0/3 属于untrust区域 IP:101.200.2.2/30 下一跳为101.200.2.1。这条线路带宽大适合普通网页浏览、视频会议等。用户IP段为192.168.1.0/24通过DHCP分配。我们的目标是将“研发部”用户组的流量导向GE1/0/2专线将“市场部”用户组的流量导向GE1/0/3宽带其他用户走默认路由通常也指向宽带。注意策略路由的优先级高于普通的路由表。也就是说系统会先检查流量是否匹配某条策略路由如果匹配就按策略路由走如果不匹配才去查普通的路由表。这个顺序一定要搞清楚。3. 防火墙基础与用户认证配置配置的第一步是让防火墙能识别“用户”。我们选择在防火墙上本地创建用户并进行Portal认证这种方式对于中小型环境来说最简单直接。3.1 创建本地用户与用户组首先我们创建两个用户组并添加示例用户。# 进入系统视图 system-view # 创建用户组“developers”和“marketing” user-group developers user-group marketing # 创建用户“dev_zhang”并加入“developers”组 local-user dev_zhang class network password cipher Huawei123 # 使用密文密码 service-type http # 允许用于HTTP/Portal认证 level 3 # 用户等级根据管理需要设置 user-group developers quit # 创建用户“mkt_li”并加入“marketing”组 local-user mkt_li class network password cipher Huawei123 service-type http level 3 user-group marketing quit这里service-type http是关键它允许该用户通过网页Portal方式进行认证。level是用户权限等级用于命令分级与网络访问权限无关。3.2 配置Portal认证服务器与认证策略接下来配置Portal认证让用户在打开浏览器时跳转到登录页面。# 配置Portal认证服务器模板采用本地认证 portal-server local server-type http quit # 配置免认证规则可选但重要。让认证页面本身、DNS查询等流量不被拦截否则用户无法弹出登录页。 free-rule-template name default_free_rule free-rule 0 destination ip 192.168.1.1 mask 255.255.255.255 # 允许访问防火墙自身 free-rule 1 destination ip any udp destination-port 53 # 允许DNS free-rule 2 destination ip any tcp destination-port 80 # 允许HTTP用于拉取登录页 free-rule 3 destination ip any tcp destination-port 443 # 允许HTTPS quit # 在用户接入的接口内网口上启用Portal认证 interface GigabitEthernet 1/0/1 portal free-rule default_free_rule portal local-server enable quit配置完成后内网用户首次打开网页就会被重定向到防火墙提供的登录页面输入刚才创建的用户名密码即可上网。3.3 验证认证状态配置完成后可以让测试用户登录然后在防火墙上查看认证状态。display portal-user all如果配置正确你会看到类似下面的输出显示了在线用户、IP地址、所属用户组等信息。这是后续策略路由能生效的基础。User Name IP Address MAC Address Status User Group dev_zhang 192.168.1.101 00-11-22-33-44-55 Online developers mkt_li 192.168.1.102 00-11-22-AA-BB-CC Online marketing4. 策略路由PBR的详细配置与原理用户能识别了现在我们来配置最核心的策略路由告诉防火墙不同用户的流量该往哪走。4.1 创建策略路由节点策略路由的配置分为几个“节点”每个节点包含匹配条件和执行动作。我们可以为研发部和市场部分别创建。# 创建名为“PBR_Developers”的策略路由优先级设为10数字越小优先级越高 policy-based-route PBR_Developers enable policy-based-route PBR_Developers node 10 if-match user-group developers # 匹配条件用户组为“developers” apply next-hop 202.100.1.1 # 执行动作下一跳指向专线网关 quit quit # 创建名为“PBR_Marketing”的策略路由优先级设为20 policy-based-route PBR_Marketing enable policy-based-route PBR_Marketing node 10 if-match user-group marketing # 匹配条件用户组为“marketing” apply output-interface GigabitEthernet 1/0/3 # 执行动作出接口设为宽带接口 quit quit这里展示了两种指定出口的方式apply next-hop和apply output-interface。在点对点链路如PPPoE、专线上两者效果一样。但在有多条路径的复杂环境中指定下一跳更精确。我个人的习惯是如果出口网关地址固定优先用next-hop如果出口是拨号或地址不固定则用output-interface。4.2 在安全域间应用策略路由创建好的策略路由需要被调用才能生效。在华为防火墙上策略路由通常应用在安全区域之间Interzone的流向上。# 假设流量从信任区域trust去往非信任区域untrust时需要应用策略路由 policy interzone trust untrust outbound # 进入域间策略视图trust - untrust方向 policy-based-route PBR_Developers # 应用研发部的策略路由 policy-based-route PBR_Marketing # 应用市场部的策略路由 quit这个配置的意思是所有从trust区域到untrust区域的流量在出方向outbound上都需要依次去匹配PBR_Developers和PBR_Marketing这两条策略路由。匹配上了就按策略走都匹配不上则查找普通路由表。重要心得策略路由的匹配是“首次匹配”原则。一旦流量匹配了某个节点就会执行该节点的动作并停止继续匹配其他节点。因此把更精确、范围更小的策略如访问特定服务器的策略放在前面优先级数字更小把范围更大的策略如整个用户组的默认出口放在后面。5. 安全策略的协同配置与深度调优策略路由只管“怎么走”而“让不让走”则由安全策略控制。两者必须协同工作。基于用户的策略路由一个巨大优势就是安全策略的源也可以设置为“用户”实现真正的身份化访问控制。5.1 创建基于用户的安全策略我们配置两条安全策略在放行流量的同时也限定了只有对应部门的用户才能访问外网。# 创建允许研发组访问外网的安全策略 security-policy rule name Permit_Developers_To_Internet source-user user-group developers # 源研发用户组 destination-zone untrust action permit quit # 创建允许市场组访问外网的安全策略 rule name Permit_Marketing_To_Internet source-user user-group marketing # 源市场用户组 destination-zone untrust action permit quit # 切记默认情况下防火墙拒绝所有流量。如果你有其他默认放行策略要注意顺序基于用户的策略通常需要放在更前面。 quit这样配置后只有属于developers或marketing组的已认证用户其访问互联网的流量才会被安全策略放行。其他未认证或不属于这两个组的用户即使IP地址在内网流量也会被安全策略拒绝。这就把网络权限和用户身份牢牢绑定了。5.2 策略路由与安全策略的联动逻辑这里有一个必须理解的细节数据包的处理顺序。对于华为防火墙以USG6000 V500R系列为例一个会话的首包处理流程大致如下会话建立首包到达。匹配策略路由PBR系统检查是否有应用于该流向的策略路由并基于源IP地址和五元组等信息进行匹配。注意此时用户身份信息如果已认证也是可用的匹配条件之一。如果匹配了基于用户的PBR则确定出口。检测会话状态ASPF。匹配安全策略检查安全策略规则。如果安全策略的源条件配置的是“用户/用户组”则防火墙会查找该会话源IP对应的已认证用户身份。如果匹配则放行。执行NAT地址转换。转发报文。关键在于第2步和第4步。策略路由先利用用户身份决定了出口安全策略再基于用户身份决定是否放行。两者都依赖于同一个“IP-用户”绑定表。这确保了策略的一致性一个被策略路由指定走专线的研发用户其流量也必然能被匹配developers用户组的安全策略所放行。5.3 配置验证与会话查看配置完成后最有效的验证方法就是看会话表。display firewall session table verbose在输出结果中你需要重点关注以下几列Source/Dest: 源目的IP和端口。Zone 流量所属的安全区域及方向如trust-untrust。TTL 会话剩余存活时间。Left 该会话剩余的字节数。Policy:这一列至关重要它会显示该会话匹配了哪一条安全策略如Permit_Developers_To_Internet。这是验证你的安全策略是否正确生效的直接证据。Route: 这一列会显示PBR或具体的路由表如RIB。如果显示PBR则说明该会话的选路是由策略路由决定的这是验证策略路由生效的直接证据。例如当你看到dev_zhang的某个访问公网的会话其Policy列是Permit_Developers_To_InternetRoute列是PBR并且出接口是GigabitEthernet1/0/2那就说明从认证、到策略路由、再到安全策略整个链条都完美运行了。6. 实战排错与常见“坑点”解析理论配置看起来清晰但实际部署中总会遇到各种问题。下面我分享几个这次实施中遇到的和常见的坑以及排查思路。6.1 坑点一用户已在线但策略路由不生效现象用户dev_zhang成功Portal认证能正常上网但流量没有走预设的专线GE1/0/2而是走了默认路由的宽带GE1/0/3。查看会话表Route列显示为RIB路由表而非PBR。排查思路检查策略路由匹配条件确认policy-based-route PBR_Developers node 10下的if-match语句是否正确写为user-group developers并且没有笔误。检查策略路由应用位置执行display current-configuration | include “policy interzone”和display current-configuration | include “policy-based-route (PBR_Developers|PBR_Marketing)”确认策略路由确实被应用在了正确的域间interzone trust untrust outbound和正确的方向上。一个常见错误是应用在了inbound方向。检查用户组归属执行display portal-user all或display access-user online确认在线用户dev_zhang的User Group字段确实是developers。有时在用户创建时user-group命令没有成功执行。检查策略路由优先级与匹配顺序如果配置了多条策略路由用display policy-based-route [policy-name]查看节点顺序。确保没有更高优先级节点号更小的、匹配范围更广的策略例如一条匹配所有源IP的策略在之前被匹配了。我的踩坑记录有一次我把策略路由应用在了interzone trust local outbound访问防火墙本身的方向上而不是访问互联网的trust untrust导致对互联网的流量根本不会去匹配策略路由。这个错误很隐蔽因为访问防火墙管理页面的流量是正常的但上网流量不对。6.2 坑点二流量匹配了PBR但安全策略拒绝导致不通现象用户流量按策略路由走了指定接口会话表Route显示PBR但连接无法建立网页打不开。查看会话表该会话可能很快消失或者根本不存在。排查思路检查安全策略规则执行display security-policy rule all仔细检查Permit_Developers_To_Internet等规则的配置。重点确认source-user或source-address是否正确。destination-zone是否为untrust或更精确的目的地址/区域。action是否为permit。规则是否处于enable状态。检查安全策略顺序安全策略是按配置顺序从上到下匹配的。如果在这条允许规则前面有一条拒绝所有或拒绝该用户/IP的规则那么流量就会被提前拒绝。使用display security-policy rule all查看规则ID确认你的允许规则排在拒绝规则之前。可以临时在规则最前面插入一条permit规则进行测试。开启日志功能在安全策略规则后面加上logging参数然后在防火墙上执行display logbuffer或通过Web界面查看实时日志看是否有该条流量的拒绝日志并查看拒绝原因。rule name Permit_Developers_To_Internet ... action permit logging # 启用日志记录我的踩坑记录早期配置时我习惯先配一条rule name deny_all放在最后作为兜底。但在配置基于用户的策略时我把允许规则加在了这条deny_all规则之后结果就是所有流量都被最后的deny_all拒绝了。切记基于用户的精细规则必须放在通用的、范围大的拒绝规则之前。6.3 坑点三NAT配置冲突导致选路异常策略路由决定了出口但出接口的NAT网络地址转换配置也必须正确。现象策略路由生效会话显示走GE1/0/2但实际不通。抓包发现从GE1/0/2出去的包源IP没有转换或者转换成了错误的公网IP。排查思路检查NAT策略策略路由不负责NAT。你需要为每个出口单独配置NAT策略。确保有类似如下配置并且匹配从trust到untrust且出接口为GE1/0/2的流量。nat-policy rule name NAT_For_Line1 source-zone trust destination-zone untrust out-interface GigabitEthernet 1/0/2 action source-nat easy-ip GigabitEthernet 1/0/2 # 使用接口地址做NAT quit检查NAT地址池如果不使用easy-ip而是使用地址池确保地址池里的IP地址与出口接口GE1/0/2的IP在同一网段并且路由可达。注意NAT策略顺序和安全策略一样NAT策略也是顺序匹配。确保匹配专线出口的NAT规则没有被前面一条匹配所有出口的NAT规则覆盖。我的踩坑记录曾经有一条默认的NAT策略rule name nat_outbound匹配所有trust-untrust的流量并做easy-ip。当我新增了专线接口GE1/0/2后没有为它配置独立的NAT规则。结果就是即使策略路由把流量引到了GE1/0/2但匹配的NAT规则仍然是那条默认的它执行easy-ip时使用了默认路由的出接口GE1/0/3的IP导致从专线出去的包源IP是宽带IP对端无法回包。教训NAT策略必须与策略路由出口严格对应。7. 高级应用与扩展思考基础配置跑通后可以基于这个框架做很多扩展让网络管理更加智能。7.1 基于应用与用户的组合策略策略路由的if-match条件非常强大除了用户还可以匹配应用或服务。例如你可以实现“所有用户访问‘视频流媒体’类应用时都走宽带出口但研发用户访问‘代码管理’如Git应用时走专线出口。”policy-based-route PBR_Developer_Git node 5 if-match user-group developers if-match application app-git # 假设已定义名为‘app-git’的应用 apply next-hop 202.100.1.1 quit这需要对防火墙的应用识别特征库有较好的了解并正确定义应用。这实现了更细粒度的、基于业务内容的流量调度。7.2 与外部认证服务器如AD域对接对于已有Active Directory域环境的企业将防火墙与AD域集成是更佳选择。这样员工可以直接使用域账号密码进行网络认证无需在防火墙上单独维护一套账号。在防火墙配置aaa认证方案服务器类型选择RADIUS或LDAP。配置认证服务器地址、共享密钥、端口等。在portal-server配置中引用该认证方案。防火墙会从AD服务器获取用户信息并可以通过属性映射如将AD的“部门”属性映射为防火墙的“用户组”自动将用户划分到对应的组如developers。后续的策略路由和安全策略配置保持不变。这种方式实现了账号体系的统一减少了管理开销。但初次对接时服务器配置、属性映射和证书问题可能需要一些时间调试。7.3 故障切换与负载均衡考虑当前的配置是静态绑定研发走专线市场走宽带。如果专线故障怎么办可以在策略路由中配置多个apply动作来实现主备。policy-based-route PBR_Developers node 10 if-match user-group developers apply next-hop 202.100.1.1 apply next-hop 101.200.2.1 quit这样配置后当首选下一跳202.100.1.1不可达时流量会自动切换到备用下一跳101.200.2.1。但这是一种故障切换不是负载均衡。华为防火墙也支持基于链路质量如带宽比例的负载均衡但配置更为复杂需要结合链路健康检查和路由策略来实现。经过这一整套从规划、配置到排错的流程下来华为防火墙基于用户的策略路由功能给我的感觉是既强大又严谨。它成功地将网络路径从冰冷的IP地址解放出来赋予了“身份”这个维度让网络策略真正做到了以人为本。对于任何需要区分员工上网行为、优化多出口链路利用率的场景这都是一项值得投入精力去部署的功能。最关键的是理解其数据包处理流程认证→PBR→安全策略→NAT和掌握通过会话表display firewall session table verbose进行排查的方法能让你在遇到问题时快速定位而不是盲目尝试。