华为H3C实战 | 第41章 酒店无线与有线统一接入
📚 本系列共 48 篇（第 41 / 48 篇） · 第六卷 实战与附录篇 —— 把它们拼起来
← 上一篇：第 40 章 医院双核心高可用网络 下一篇：第 42 章 企业双出口冗余与链路选路 →
本章导读：这一章把前文的无线那套零件装成一台能跑的设备——一栋 18 层、320 间客房的中端商务酒店。它要同时接住三类完全不同的用户：会弹窗但明天就走的房客、刷工卡的员工、以及既不会弹窗也不会认证的电视盒子，并且让它们的权限彼此严格隔离。
本章结构：
- 41.1 项目背景与需求 —— 客户六句大白话翻译成技术需求，以及三个"看起来简单其实最坑"的需求
- 41.2 网络拓扑 —— 整体架构与三类业务的流量走向
- 41.3 IP 与地址规划 —— VLAN/网段/VRF 划分，以及
/22容量的算账过程- 41.4 关键设计决策 —— 五个决策的取舍（Portal 还是 PSK、VRF 还是 ACL、限速放哪层）
- 41.5 华为完整配置 —— 十个模块，逐块标注对应章节
- 41.6 H3C 完整配置 —— 同构拓扑的 H3C 版
- 41.7 验证清单 —— 15 项逐项打勾
- 41.8 本项目踩过的坑 —— 五个真实故障
- 41.9 本章小结
这是一栋 18 层、320 间客房的中端商务酒店。
酒店网络和写字楼网络有个根本区别：房客是"流动人口"。今天住 1203 房的张先生，明天就换成李女士；后天又来了个旅行团一次性入住 60 间。你不能给每个房客建账号，也不能让他们每次连 Wi-Fi 都要找前台要密码。
同时，酒店里还跑着两套完全不同的业务：
- 房客网：谁都能连，但只能上网，绝对看不到酒店内部系统（PMS 前台系统、财务、监控）
- 办公网：前台、客房部、工程部员工用，走 802.1X 刷工卡，能访问内部系统
再加上一堆"哑终端"：房间里的智能电视盒子、IPTV、门锁网关、楼层弱电间的温湿度传感器——它们既不会弹 Portal 页面，也不会做 802.1X。
本章要解决的核心问题是：怎么用一套 AC，同时把房客、员工、哑终端三类用户接进来，并且让它们的权限彼此严格隔离。
这一章会串起前文的 8 个功能模块：AP 上线（第 20 章）、WLAN 基础业务（第 21 章）、企业级认证（第 22 章）、无线漫游（第 23 章）、VRF 隔离（第 17 章）、QoS 限速、端口隔离、AP 故障排查（第 25 章）。
适用版本：华为 VRP V200R019 及以上（AC6005/AC6605）配合 AP4050DN/AP7060DN；H3C Comware V7（R2610 及以上，WX3540H）配合 WA6320。本章命令均以这两条产品线为基准。
41.1 项目背景与需求
41.1.1 客户的原始描述
酒店 IT 负责人给的需求原话是这么几条：
- “客房 Wi-Fi 要稳定，客人一进房间就能连，不能每层都要重新连一次”
- “客人上网要输房间号加姓氏，别搞太复杂，老人也会用”
- “员工用 Wi-Fi 要能访问 PMS 和财务系统，客人绝对不能访问”
- “房间里的电视盒子、门锁这些要能自动连上，别每次换房间都要重配”
- “走廊、大堂、餐厅、会议室都要有信号”
- “客人要是下大文件把带宽占满了，别人就上不了网了，得限一限”
41.1.2 翻译成技术需求
上面六条大白话，逐条翻译成网络设计上的要求：
| 客户原话 | 技术需求 | 对应章节 |
|---|---|---|
| 一进房间就能连、不能每层重连 | 二层漫游（同一业务 VLAN）+ 快速漫游 802.11r | 第 23 章 |
| 房间号 + 姓氏上网 | Portal 认证，账号规则为"房间号+姓氏拼音" | 第 22 章 |
| 员工能访问内网、客人不能 | 房客 VLAN 与办公 VLAN 分离 + VRF 隔离 + ACL | 第 17、18 章 |
| 电视盒子自动连上 | MAC 认证白名单（哑终端免 Portal） | 第 22 章 |
| 走廊大堂餐厅都有信号 | AP 点位规划，覆盖设计 | 第 19、23 章 |
| 防止个别客人占满带宽 | 每终端上下行限速（QoS） | 本章 + 第 21 章 |
41.1.3 三个"看起来简单其实最坑"的需求
经验告诉我们，酒店项目里真正难的不是"能不能实现"，而是下面这三件事：
（1）“一进房间就能连"背后是 VLAN 规划问题
如果每层楼用不同的业务 VLAN，客人从 5 楼餐厅走回 8 楼房间就是三层漫游，IP 地址要变，认证状态要重建，体感就是"卡一下”。所以房客网必须所有 AP 用同一个业务 VLAN，才能做到二层漫游。但 320 个房间住满可能有 500+ 个终端，一个 192.168.0.0/24 只有 254 个地址，不够用。
解决：用 VLAN Pool（一个 SSID 对应多个 VLAN，按终端分配），既保证二层漫游的"同一个大二层"体感，又突破了单 VLAN 的地址上限。这是本章的第一个关键设计决策。
（2）“房间号+姓氏"这个账号规则，其实是个非标需求
标准 Portal 认证是"账号+密码"或者"手机号+验证码”。酒店要的"1203zhang"这种规则，需要 Portal 服务器（通常对接 PMS 前台系统）动态生成。AC 只负责把认证请求转给 Portal 服务器，账号规则本身在服务器侧实现。
这一条要在方案里写清楚，否则容易被误会成"AC 上配一下就行"。
（3）电视盒子这类哑终端，最容易被漏掉
它们不能弹 Portal 页，也不会做 802.1X。如果房客网的 SSID 一律要求 Portal 认证，电视盒子就永远连不上。解决：单独开一个隐藏 SSID，SSID 层面只做 MAC 白名单认证，不做 Portal。
41.2 网络拓扑
41.2.1 整体架构
[运营商光猫] --- [酒店出口路由器 AR6140]
|
[核心交换机 S5735+（VRF）]
/ | \
/ | \
[AC6005 旁挂] [办公接入] [客房接入交换机 ×18]
| | |
| [前台/财务 PC] [AP4050DN ×96]
| |
(CAPWAP 管理) [客房面板 AP ×320]
|
[房客手机/笔记本]
[电视盒子/MAC白名单]
41.2.2 详细拓扑（VA 线）
+----------------+ +-----------------------+
| 运营商光猫 |----------| AR6140 出口路由器 |
+----------------+ | NAT / 防火墙策略 |
+-----------+-----------+
|
| Trunk
|
+------------------+------------------+
| CORE S5735+（核心，VRF） |
| VRF GUEST / VRF OFFICE / VRF MGMT |
+----+-----------+-----------+--------+
| | |
+------------+ +------+------+ +-------------+
| | | |
+-----+-----+ +-----+-----+ +----+----+ +-------+------+
| AC6005 | | 办公接入 | | 弱电间 | | 弱电间 |
| 旁挂 | | S5735-L | | 5F 交换机| | 18F 交换机 |
+-----+-----+ +-----+-----+ +----+----+ +--------------+
| | | |
CAPWAP: VLAN 100 | 客房 AP ×6 客房 AP ×6
(管理) | (每层约 6-8 台) (每层约 6-8 台)
|
前台/财务PC
(802.1X 员工)
41.2.3 三类业务的流量走向
【房客网 - Portal】
手机 --无线--> AP --CAPWAP隧道--> AC6005 --VRF GUEST--> CORE --出口---> 互联网
|
Portal 服务器（认证）
|
PMS 前台系统（账号源）
【办公网 - 802.1X】
前台PC --无线/有线--> AP --> AC6005 --VRF OFFICE--> CORE --> PMS/财务系统
【哑终端 - MAC白名单】
电视盒子 --无线--> AP --> AC6005 --VRF GUEST(独立VLAN)--> 仅放行IPTV组播
41.3 IP 与地址规划
41.3.1 VLAN 与网段规划
| 用途 | VLAN | 网段 | 网关 | 说明 |
|---|---|---|---|---|
| AP 管理 | 100 | 172.16.100.0/24 |
172.16.100.1 |
DHCP 带 Option 43 |
| 房客业务 Pool-A | 200 | 10.20.0.0/22 |
10.20.0.1 |
约 1022 个地址 |
| 房客业务 Pool-B | 204 | 10.20.4.0/22 |
10.20.4.1 |
约 1022 个地址 |
| 哑终端（电视/门锁） | 210 | 10.20.10.0/24 |
10.20.10.1 |
独立隔离 |
| 办公无线 | 300 | 10.30.0.0/24 |
10.30.0.1 |
员工 802.1X |
| 办公有线 | 301 | 10.30.1.0/24 |
10.30.1.1 |
前台/财务 PC |
| 服务器区 | 400 | 10.40.0.0/24 |
10.40.0.1 |
PMS/财务 |
| AC 管理 | 500 | 172.16.50.0/24 |
172.16.50.1 |
AC 旁挂互联 |
41.3.2 为什么房客网用 /22 而且分两个 Pool
（1）/22 的容量算账
一栋 320 间房的酒店，住满约 600 人。人均手机+笔记本约 1.5 个终端，加上 iPad、Switch 等，峰值终端数约 900~1000。
一个 192.168.0.0/24 只有 254 个地址——远远不够。所以要用 /22（1022 个可用地址）甚至更大。
（2）为什么要两个 Pool 而不是一个 /21
单个 /21 有 2046 个地址，一个就够。但实践中有两个考虑：
- DHCP 广播域不宜过大：
/21意味着 2046 个终端在同一个广播域，ARP 广播、DHCP 广播的量都不小。 - 按客源分流：部分酒店会把"协议客户"和"散客"分到不同 Pool，方便后续做差异化的带宽策略。
本案例用两个 /22 组成 VLAN Pool，由 AC 按终端分配到不同 VLAN。
⚠ 关键约束：VLAN Pool 里的多个 VLAN 必须在同一台设备上有三层接口（这里是核心交换机），且 VLAN Pool 属于二层漫游的扩展——终端在 Pool 内不同 VLAN 间漫游时 AC 会保持原地址。这条是 VLAN Pool 存在的意义，否则没必要用它。
41.3.3 VRF 划分
| VRF 名 | 包含 VLAN | 用途 | 能否互访 |
|---|---|---|---|
GUEST |
200、204、210 | 房客网 | 不能访问 OFFICE/MGMT |
OFFICE |
300、301、400 | 办公网 | 可访问 GUEST 的网关做运维 |
MGMT |
100、500 | 设备管理 | 仅运维可访问 |
41.4 关键设计决策
这一节是本章的核心。每个决策都写清"为什么这么选"和"代价是什么"。
41.4.1 决策一：房客认证为什么用 Portal 而不是 PSK
| 方案 | 优点 | 缺点 | 酒店场景适配度 |
|---|---|---|---|
| WPA2-PSK 统一密码 | 配置最简单，终端无感 | 密码一旦泄露全网失守；无法审计到房间；换密码要通知所有客人 | ❌ 差 |
| PPSK（每房间独立密码） | 每房一密，可审计 | 需要 AC/PMS 联动生成，终端支持度参差 | ⚠ 中 |
| Portal（房间号+姓氏） | 零终端安装；账号可动态生成；可审计到人；可做差异化带宽 | 必须弹浏览器；部分 App 内嵌浏览器不弹窗 | ✅ 好 |
最终选择：Portal。理由是酒店房客是"一次性用户"，Portal 的"打开浏览器就跳转"体验最符合住宿场景，且账号能直接对接 PMS 的入住记录。
代价：① 房客第一次连必须打开浏览器，有些 App 不走系统浏览器会失败，需要有提示；② Portal 页面必须做得极简，房间号+姓氏两个输入框就够。
41.4.2 决策二：员工为什么必须用 802.1X
员工和房客的差别是**“员工离职了要能立刻收回权限”**。PSK 做不到，Portal 账号虽然能停但员工日常访问内网系统每次都要登录也很烦。
802.1X 的优势：开机自动刷工卡认证，无感；离职当天在 AD 里禁用账号即刻失效；还能通过 RADIUS 下发 VLAN 和 ACL。
最终选择：员工用 802.1X（EAP-PEAP），认证服务器为 Windows AD + NPS（RADIUS）。
41.4.3 决策三：VRF 还是 ACL？为什么两个都要
这是最容易做错的一步。很多人以为"配个 ACL 禁止房客访问办公网"就够了，实际上不够：
| 手段 | 解决什么 | 局限 |
|---|---|---|
| ACL | 在转发路径上过滤特定流量 | 房客终端与办公终端仍在同一台设备的路由表里，“配错一条 ACL 就全漏” |
| VRF | 把房客网和办公网做成两套独立的路由表 | 配置量增加；跨 VRF 通信要显式指定 |
本案例的做法：VRF 做"硬隔离"，ACL 做"细粒度控制"。
- VRF 保证：房客网的路由表里根本看不到办公网段，即使 ACL 配错也访问不到。
- ACL 保证：在 VRF 内部再做细粒度管控（例如房客网内禁止终端互访、只放行 DNS/DHCP/HTTP 等）。
代价：AC 和核心交换机都要配 VRF 绑定，配置量比单 VRF 多一倍；排障时要先确认"你在查哪个 VRF"。
41.4.4 决策四：哑终端为什么单独一个 SSID 和一个 VLAN
电视盒子、门锁网关这类设备：
- 不会弹 Portal：如果挂在房客 SSID 上，认证永远过不去
- 带宽需求稳定但很小：IPTV 盒子要看 4K 视频，其实是走组播，不是普通上网流量
- 数量固定：320 间房 × 约 2 个设备 = 640 个，可以提前录入 MAC
最终选择：单独一个隐藏 SSID HOTEL-DEVICE，只做 MAC 白名单认证，业务 VLAN 210，独立隔离。
代价：每换一个电视盒子就要更新一次 MAC 白名单，需要跟工程部约定更换流程。
41.4.5 决策五：限速放在哪一层
限速有三个可选位置：
| 位置 | 命令位置 | 优点 | 缺点 |
|---|---|---|---|
| AC 的 VAP 模板 | traffic-profile 下 rate-limit client |
统一管理，改一处全网生效 | 只对无线生效 |
| AC 的 VAP 级限速 | rate-limit vap |
控制单 SSID 总带宽 | 粒度太粗 |
| 核心交换机 | QoS CAR | 无线有线都能管 | 配置分散，不易维护 |
最终选择：AC 的 traffic-profile 做每终端限速 + 核心交换机做 VRF 级总带宽保障。
具体数值：房客每终端 上行 2Mbps / 下行 8Mbps（够看 1080P，不够下大文件影响别人）；办公不限速；哑终端下行 20Mbps（4K 组播需要）。
41.5 完整配置（华为）
分模块给，每块标注对应章节。
41.5.1 模块一：核心交换机 VRF 与三层规划（第 17 章）
先建 VRF 实例并把 VLAN 接口绑进去。这一步是整个隔离方案的地基。
# 进入系统视图
system-view
sysname CORE-SW
# 创建三个 VRF 实例
ip vpn-instance GUEST
ipv4-family
quit
ip vpn-instance OFFICE
ipv4-family
quit
ip vpn-instance MGMT
ipv4-family
quit
# 批量创建 VLAN
vlan batch 100 200 204 210 300 301 400 500
# 房客网关：绑到 GUEST
interface Vlanif200
ip binding vpn-instance GUEST
ip address 10.20.0.1 255.255.252.0
quit
interface Vlanif204
ip binding vpn-instance GUEST
ip address 10.20.4.1 255.255.252.0
quit
interface Vlanif210
ip binding vpn-instance GUEST
ip address 10.20.10.1 255.255.255.0
quit
# 办公网关：绑到 OFFICE
interface Vlanif300
ip binding vpn-instance OFFICE
ip address 10.30.0.1 255.255.255.0
quit
interface Vlanif301
ip binding vpn-instance OFFICE
ip address 10.30.1.1 255.255.255.0
quit
interface Vlanif400
ip binding vpn-instance OFFICE
ip address 10.40.0.1 255.255.255.0
quit
# 管理网关：绑到 MGMT
interface Vlanif100
ip binding vpn-instance MGMT
ip address 172.16.100.1 255.255.255.0
quit
interface Vlanif500
ip binding vpn-instance MGMT
ip address 172.16.50.1 255.255.255.0
quit
# 到出口路由器的路由：各 VRF 分别指
ip route-static vpn-instance GUEST 0.0.0.0 0 10.40.0.254
ip route-static vpn-instance OFFICE 0.0.0.0 0 10.40.0.254
第 17 章要点回顾：
ip binding vpn-instance必须在配 IP 之前执行，顺序反了接口地址会落到公网实例里，排查时表现为"接口有地址但路由表里查不到"。
41.5.2 模块二：DHCP 与 Option 43（第 8、20 章）
AP 拿地址这一环，Option 43 必须指对。
# 开 DHCP
dhcp enable
# AP 管理地址池：跨三层的 AP 靠 Option 43 找 AC
ip pool ap-mgmt
network 172.16.100.0 mask 255.255.255.0
gateway-list 172.16.100.1
# 指向 AC 的 CAPWAP 源接口地址
option 43 sub-option 2 ip-address 172.16.100.2
excluded-ip-address 172.16.100.1 172.16.100.2
quit
# 房客地址池 A（10.20.0.0/22）
ip pool guest-a
vpn-instance GUEST
network 10.20.0.0 mask 255.255.252.0
gateway-list 10.20.0.1
dns-list 114.114.114.114
lease day 0 hour 12
quit
# 房客地址池 B（10.20.4.0/22）
ip pool guest-b
vpn-instance GUEST
network 10.20.4.0 mask 255.255.252.0
gateway-list 10.20.4.1
dns-list 114.114.114.114
lease day 0 hour 12
quit
# 哑终端池
ip pool device
vpn-instance GUEST
network 10.20.10.0 mask 255.255.255.0
gateway-list 10.20.10.1
lease day 30
quit
第 8 章要点回顾：VRF 下的 DHCP 地址池必须用
vpn-instance绑定，否则地址池落不到正确的路由实例里，表现为"终端拿不到地址"。注意租期：房客用 12 小时短租期（今天退房明天就回收），哑终端用 30 天（设备长期在线）。
41.5.3 模块三：AC 侧 WLAN 基础业务（第 21 章）
三套 SSID：房客、员工、哑终端。先建模板，再绑 AP 组——这是第 21 章讲的引用链。
# 进入 WLAN 视图
wlan
# ---------- SSID 模板 ----------
# 房客 SSID（广播）
ssid-profile name guest-ssid
ssid HOTEL-GUEST
quit
# 员工 SSID（广播）
ssid-profile name staff-ssid
ssid HOTEL-STAFF
quit
# 哑终端 SSID（隐藏，不广播）
ssid-profile name device-ssid
ssid HOTEL-DEVICE
ssid-hide enable
quit
# ---------- 安全模板 ----------
# 房客：开放认证，靠 Portal 卡权限
security-profile name guest-sec
security open
quit
# 员工：WPA2-802.1X
security-profile name staff-sec
security wpa2 dot1x aes
quit
# 哑终端：开放认证，靠 MAC 白名单
security-profile name device-sec
security open
quit
设计说明：房客网用
security open（开放认证）是有意的——房客的"第一道门"是 Portal，不是空口加密。这样房客第一次连上时不会被密码拦住，直接进入弹窗流程。代价是空口不加密，所以房客网的内容安全完全依赖 Portal 和 VRF，这也是为什么 41.4.3 强调 VRF 是"硬隔离"。
41.5.4 模块四：流量模板（限速）（第 21 章）
# 房客流量模板：每终端上行 2M / 下行 8M
traffic-profile name guest-traffic
# rate-limit client 针对单终端限速，单位 kbps
rate-limit client up 2048
rate-limit client down 8192
quit
# 员工流量模板：不限速
traffic-profile name staff-traffic
quit
# 哑终端模板：下行 20M（4K 组播）
traffic-profile name device-traffic
rate-limit client up 4096
rate-limit client down 20480
quit
✅ 已核实：
rate-limit client { up | down } rate-value为华为 AC 流量模板下的单终端限速命令（官方原文"执行命令rate-limit client { up | down } rate-value对用户进行静态限速"），出处EDOC1100332873（AC V200R023C00 配置指南）→ VAP 模板/WLAN 流量优化章节。
41.5.5 模块五：VAP 模板与 VLAN Pool（第 21 章）
这是房客网的核心：一个 SSID 绑定一个 VLAN Pool，终端被分配到 Pool 内不同 VLAN。
# ---------- 房客 VAP：业务 VLAN 用 VLAN Pool ----------
# 先建 VLAN Pool
vlan pool guest-pool
# 把两个 /22 的 VLAN 加进池子
vlan 200 to 204
quit
vap-profile name guest-vap
# 隧道转发（房客流量集中到 AC 处理，便于做 VRF 和 Portal）
forward-mode tunnel
# 引用 VLAN Pool（替代单一的 service-vlan）
service-vlan vlan-pool guest-pool
# 引用安全模板
security-profile guest-sec
# 引用 SSID 模板
ssid-profile guest-ssid
# 引用流量模板（限速）
traffic-profile guest-traffic
quit
# ---------- 员工 VAP ----------
vap-profile name staff-vap
forward-mode tunnel
service-vlan vlan-id 300
security-profile staff-sec
ssid-profile staff-ssid
traffic-profile staff-traffic
quit
# ---------- 哑终端 VAP ----------
vap-profile name device-vap
forward-mode tunnel
service-vlan vlan-id 210
security-profile device-sec
ssid-profile device-ssid
traffic-profile device-traffic
quit
✅ 已核实：
vlan pool <名>+vlan { start-vlan [ to end-vlan ] }创建 VLAN Pool 并向其中添加 VLAN（官方原文"执行命令vlan pool pool-name，创建 VLAN pool……执行命令vlan { start-vlan [ to end-vlan ] } &<1-10>，将指定 VLAN 添加到 VLAN pool 中"），出处EDOC1100332873。⚠ VLAN Pool 的地址池对齐：Pool 里放的是 VLAN 200
204，但地址池只建了 200 和 204 两个203，/22。这里要注意——**vlan 200 to 204包含 200/201/202/203/204 五个 VLAN，但10.20.0.0/22只覆盖 VLAN 20010.20.4.0/22覆盖 VLAN 204~207**。实际部署时 VLAN 与网段必须一一对应，本案例为简化写作只建两个池。生产环境建议 Pool 内每个 VLAN 都配独立地址池。 ⚠ 待核实：待核实——VLAN Pool 内多个 VLAN 与网段映射的具体要求，官方文档未明确说明 VLAN 数必须等于网段数，需按实际项目确认
41.5.6 模块六：AP 组绑定与射频（第 19、20、23 章）
# 创建 AP 组并绑定三个 VAP
ap-group name ap-group-hotel
# 房客 VAP：2.4G 与 5G 都开
vap-profile guest-vap wlan 1 radio 0
vap-profile guest-vap wlan 1 radio 1
# 员工 VAP
vap-profile staff-vap wlan 2 radio 0
vap-profile staff-vap wlan 2 radio 1
# 哑终端 VAP（只开 2.4G，电视盒子一般只支持 2.4G）
vap-profile device-vap wlan 3 radio 0
# 国家码
regulatory-domain-profile default
# 射频模板
radio-2g-profile r2g
radio-5g-profile r5g
quit
第 23 章要点：
regulatory-domain-profile决定可用信道，酒店走廊和客房都要覆盖，2.4G 只能用 1/6/11 三个不重叠信道，每层 6~8 台 AP 时 2.4G 必然同频，所以主力覆盖靠 5G，2.4G 只做兼容兜底。这也是为什么房客 VAP 在 2.4G 和 5G 都开、但功率上 2.4G 要压低。
41.5.7 模块七：员工 802.1X（第 22 章）
员工认证走"接入模板 → 认证模板 → VAP 引用"三层链（第 22 章详解）。
# 1) RADIUS 服务器模板
radius-server template hotel-radius
radius-server shared-key cipher Hotel@Radius2026
radius-server authentication 10.40.0.50 1812
radius-server accounting 10.40.0.50 1813
quit
# 2) AAA 认证方案
aaa
authentication-scheme radius-auth
authentication-mode radius
quit
# ISP 域
domain hotel.local
radius-server hotel-radius
quit
domain default
radius-server hotel-radius
quit
quit
# 3) 802.1X 接入模板
wlan
dot1x-access-profile name staff-1x-access
quit
# 4) 认证模板：绑接入模板 + AAA 方案 + 域
authentication-profile name staff-1x-auth
dot1x-access-profile staff-1x-access
authentication-scheme radius-auth
access-domain hotel.local
quit
# 5) 员工 VAP 引用认证模板
vap-profile name staff-vap
authentication-profile staff-1x-auth
quit
41.5.8 模块八：房客 Portal 认证（第 22 章）
Portal 比 802.1X 多一个"服务器模板"环节。
# 1) Portal 页面 URL 模板
url-template name hotel-portal-url
url http://10.40.0.60:8080/portal
quit
# 2) Portal 服务器模板
web-auth-server hotel-portal
server-ip 10.40.0.60
shared-key cipher Portal@Hotel2026
port 50200
url-template hotel-portal-url
quit
# 3) Portal 接入模板
portal-access-profile name guest-portal-access
web-auth-server hotel-portal direct
quit
# 4) 认证模板：绑 Portal 接入模板
authentication-profile name guest-portal-auth
portal-access-profile guest-portal-access
authentication-scheme radius-auth
access-domain hotel.local
quit
# 5) 房客 VAP 引用
vap-profile name guest-vap
authentication-profile guest-portal-auth
quit
✅ 已核实：
url-template→web-auth-server（server-ip/shared-key cipher/port/url-template）→portal-access-profile（web-auth-server <名> direct）→authentication-profile（portal-access-profile <名>）整条链，来自华为官方《配置 Navi AC+外置 Portal 认证示例》，出处EDOC1100332873。⚠ V200R021C00 及之后必配（官方原文）：必须用
portal web-authen-server server-source或server-source配置接收 Portal 报文的本机网关地址，否则 Portal 不生效：portal web-authen-server server-source all-interface
41.5.9 模块九：哑终端 MAC 白名单（第 22 章）
电视盒子这类设备，用 MAC 认证放行。
# 1) 创建 MAC 接入模板
mac-access-profile name device-mac-access
quit
# 2) 认证模板：绑 MAC 接入模板，认证方式用本地认证
# （哑终端数量固定，用本地 MAC 名单最省事，不必上 RADIUS）
authentication-profile name device-mac-auth
mac-access-profile device-mac-access
authentication-scheme local-auth
quit
# 3) 房客 VAP 之外的哑终端 VAP 引用
vap-profile name device-vap
authentication-profile device-mac-auth
quit
白名单在本地认证方案里维护：
aaa
# 本地认证方案（对上一步 authentication-scheme local-auth）
authentication-scheme local-auth
authentication-mode local
quit
# 逐个录入电视盒子 MAC 与房间号
local-aaa-user mac-address 00e0-fc11-2233 password cipher Hotel@Device1
local-aaa-user mac-address 00e0-fc11-2244 password cipher Hotel@Device2
quit
⚠ 上面
local-aaa-user mac-address的具体命令形式需以本机?为准，各版本对"本地 MAC 用户"的录入命令命名不完全一致。 ⚠ 待核实：待核实——华为 AC 上"本地 MAC 认证用户"的录入命令确切形式（local-aaa-user 还是 local-user mac-address 等），以及是否需要在认证模板里额外指定认证方式
41.5.10 模块十：ACL 精细化管控（第 18 章）
VRF 已经做了硬隔离，这一层做 VRF 内部的细粒度控制。
# 房客网内部：禁止终端互访（防 ARP 欺骗、防横向扫描）
acl number 3000
rule 5 deny ip destination 10.20.0.0 0.0.3.255
rule 10 deny ip destination 10.20.4.0 0.0.3.255
rule 15 deny ip destination 10.20.10.0 0.0.0.255
rule 20 permit ip
quit
# 应用到房客网关入方向
interface Vlanif200
traffic-filter inbound acl 3000
quit
interface Vlanif204
traffic-filter inbound acl 3000
quit
# 办公网：允许访问服务器区，但服务器区不能主动访问办公终端
acl number 3001
rule 5 permit ip source 10.30.0.0 0.0.255.255 destination 10.40.0.0 0.0.0.255
rule 10 deny ip destination 10.30.0.0 0.0.255.255
quit
41.6 完整配置（H3C）
41.6.1 模块一：虚拟化实例（VRF）（第 17 章）
system-view
sysname CORE-SW
# H3C 的 VRF 叫"VPN 实例"
ip vpn-instance GUEST
ipv4-family
route-distinguisher 100:200
vpn-target 100:200 both
quit
quit
# 接口绑定
vlan 200
vlan 204
vlan 300
quit
interface Vlan-interface200
ip binding vpn-instance GUEST
ip address 10.20.0.1 255.255.252.0
quit
H3C 与华为差异：H3C 的
ip vpn-instance需要route-distinguisher和vpn-target（华为在纯 VRF（非 MPLS）场景可以只写ipv4-family）。RD/RT 在纯 VRF 隔离里不是必须的，但 H3C 部分版本要求配齐。
41.6.2 模块二：DHCP Option 43（第 8、20 章）
dhcp enable
dhcp server ip-pool ap-mgmt
network 172.16.100.0 mask 255.255.255.0
gateway-list 172.16.100.1
# H3C 用 hex 格式，AC 地址 172.16.100.2 → AC A0 64 02
option 43 hex 8007000002ACA06402
forbidden-ip 172.16.100.1 172.16.100.2
quit
✅ 已核实：H3C 的 Option 43 用
option 43 hex格式（官方示例option 43 hex 800700000102010102），各字节含义为80（PXE 厂商类型）+07（长度）+000001（H3C 厂商 ID）+02（子选项类型）+ 4 字节 AC 地址。出处h3c/1266096_30005_0.txt。
41.6.3 模块三：WLAN 服务模板（第 21 章）
# 房客服务模板
wlan service-template guest
ssid HOTEL-GUEST
vlan 200
client forwarding-location ac
# 开放认证，靠 Portal
service-template enable
quit
# 员工服务模板
wlan service-template staff
ssid HOTEL-STAFF
vlan 300
client forwarding-location ac
akm mode dot1x
cipher-suite ccmp
security-ie rsn
# 关键：用户认证方式必须显式指定为 802.1X
client-security authentication-mode dot1x
dot1x domain hotel.local
service-template enable
quit
# 哑终端服务模板（隐藏 SSID）
wlan service-template device
ssid HOTEL-DEVICE
vlan 210
client forwarding-location ac
service-template enable
quit
✅ 已核实：
akm mode dot1x+client-security authentication-mode dot1x+dot1x domain <域名>三条配合使用，来自 H3C 官方《Anchor AC 集中转发模式下 802.1X 远程认证典型配置举例》。只配akm mode dot1x不够——终端能连上但不会要求 802.1X 认证。出处h3c/1721433_30005_0.htm。
41.6.4 模块四：Portal 认证（第 22 章）
# Portal Web 服务器
portal web-server hotel-portal
url http://10.40.0.60:8080/portal
url-parameter wlanuserip source-address
quit
# 在服务模板上开 Portal
wlan service-template guest
portal enable method direct
portal domain hotel.local
portal bas-ip 10.20.0.1
portal apply web-server hotel-portal
service-template enable
quit
✅ 已核实：H3C 的 Portal 命令链
portal web-server→portal enable method direct+portal domain+portal bas-ip+portal apply web-server，出处h3c/1552967_30005_0.txt（Portal 配置）、h3c/1831739_30005_0.htm。⚠
portal bas-ip不是可选项——官方说明 Portal 2.0 版本下主动发给 Portal 服务器的报文必须携带 BAS-IP 属性，否则强制下线等功能失效。
41.6.5 模块五：AP 组与射频（第 19、20 章）
wlan ap-group ap-group-hotel
ap-model WA6320
radio 1
radio enable
service-template guest
service-template staff
service-template device
quit
radio 2
radio enable
service-template guest
service-template staff
quit
quit
quit
H3C 射频编号：
radio 1= 2.4G，radio 2= 5G（与华为相反，华为 0=2.4G/1=5G）。这是跨厂商最容易配错的地方，第 19 章专门强调过。
41.7 验证清单
逐项打勾，全部通过才算交付。
41.7.1 AP 与射频
| # | 检查项 | 命令 | 期望结果 |
|---|---|---|---|
| 1 | AP 全部上线 | display ap all |
96 台全部 nor |
| 2 | AP 归属正确 | display ap all |
Group 列为 ap-group-hotel |
| 3 | 三个 SSID 都广播 | display vap ssid HOTEL-GUEST 等 |
Status 均 ON |
| 4 | 隐藏 SSID 确实隐藏 | 现场手机扫描 | HOTEL-DEVICE 看不到 |
41.7.2 三类终端认证
| # | 检查项 | 方法 | 期望结果 |
|---|---|---|---|
| 5 | 房客能弹 Portal | 手机连 HOTEL-GUEST | 自动跳转认证页面 |
| 6 | 房客账号可用 | 输入"房间号+姓氏" | 认证通过、能上网 |
| 7 | 员工能 802.1X | 笔记本连 HOTEL-STAFF | 提示输入账号后连上 |
| 8 | 电视盒子能连 | 观察设备 SSID | 白名单内自动连上 |
41.7.3 隔离与限速
| # | 检查项 | 命令/方法 | 期望结果 |
|---|---|---|---|
| 9 | 房客看不到办公网 | 房客终端 ping 10.30.0.1 |
不通 |
| 10 | 房客看不到服务器 | ping 10.40.0.1 |
不通 |
| 11 | 办公能访问 PMS | 前台 PC ping 服务器 | 通 |
| 12 | 房客限速生效 | 房客终端测速 | 下行约 8Mbps |
| 13 | 房客互访被禁 | 两台房客终端互 ping | 不通 |
41.7.4 漫游
| # | 检查项 | 方法 | 期望结果 |
|---|---|---|---|
| 14 | 楼层间漫游不断 | 手机从 5F 走到 8F 持续 ping | 丢包 ≤ 3 个 |
| 15 | 漫游后 IP 不变 | 走动前后看 IP | 同一 IP |
# 查看终端漫游轨迹（第 23 章）
display station roam-track sta-mac 4c77-6600-1234
41.8 本项目踩过的坑
坑一：AP 装着装着就不上线了，一查是 PoE 功率不够
现象：前 5 层 AP 全部正常，6 层开始陆续有 AP 亮红灯、不上线。
排查：display poe interface 看总功率，发现 5 层那台 24 口 PoE 交换机总功率 370W，接了 8 台 AP4050DN（每台约 12.95W）+ 若干面板 AP，已经接近上限。
根因：AP4050DN 按 802.3af 供电约 13W，但部分型号（尤其带 5G 双频的）启动瞬间功率上冲，多台同时上电就超预算。
处置：换成 PoE+（802.3at）交换机，并分批上电（先上一半 AP，5 分钟后再上另一半）。
教训：AP 数量统计时，一定要按"峰值功率 × 台数 × 1.2 余量"算 PoE 预算，别按额定功率算。
坑二：Portal 页面在酒店 App 里不弹
现象：房客用手机连上 Wi-Fi 后，很多人反馈"没看到登录页"，但连上又上不了网。
排查：现场测试发现，用系统浏览器访问任意 HTTP 网站能弹出 Portal；但如果房客直接在微信/抖音里操作，App 内嵌浏览器用的是 HTTPS，Portal 的 HTTP 重定向拦不住 HTTPS 请求。
根因：Portal 认证靠 HTTP 302 重定向。HTTPS 流量（微信、支付宝、抖音）在认证前被丢弃，但不会跳转页面，用户看到的是"正在加载"然后失败。
处置：① 在酒店前台准备"上网指引卡"，明确写"请用手机浏览器打开任意网页"；② 在 AC 上配置首次连 Wi-Fi 时的弹窗提示（部分 AC 支持 Captive Portal 探测，会自动触发系统登录页）。
教训：Portal 的体验上限取决于终端的"Captive Portal 检测"能力。iOS 和部分安卓会自动弹，其余必须引导用户开浏览器。
坑三：员工 802.1X 认证通过但拿不到地址
现象：员工笔记本认证成功，但显示"无法获取 IP 地址"。
排查：display station all 看终端状态正常，但交换机上查不到 DHCP 分配记录。
根因：认证模板里配了 access-domain hotel.local，但 RADIUS 没有下发授权 VLAN。员工认证通过后落到默认 VLAN 1，而 VLAN 1 上没有 DHCP 地址池。
处置：两种改法——① 在 RADIUS（NPS）里下发 Tunnel-Private-Group-ID = 300；② 在 VAP 模板上指定 service-vlan vlan-id 300 作为缺省 VLAN。
教训：802.1X 的"授权 VLAN"是独立的一环。认证通过 ≠ 拿到正确的 VLAN，验收时必须逐项确认。
坑四：VLAN Pool 里某个 VLAN 没建地址池，个别房客上不了网
现象：绝大多数房客正常，但每天总有几间房的客人报"连上但打不开网页"。
排查：display station all 发现出问题的终端都落在 VLAN 201/202/203 上，而这三个 VLAN 只建了 VLANIF，没有对应的 DHCP 地址池。
根因：VLAN Pool 配置成 vlan 200 to 204（5 个 VLAN），但只建了 200 和 204 两个地址池。
处置：给 201/202/203 补齐地址池，或者把 Pool 改成只包含有地址池的 VLAN。
教训：VLAN Pool 里的每一个 VLAN 都必须有完整的三层配置（VLANIF + 地址池），这是本章 41.5.5 特别标注过的地方。
坑五：电视盒子换型号后全部掉线
现象：工程部统一更换了一批电视盒子，第二天所有客房的 IPTV 都连不上。
根因：新盒子 MAC 地址不在白名单里。
处置：① 紧急把新盒子的 MAC 批量导入；② 建立流程——工程部更换任何哑终端前，先把 MAC 报给 IT 录入。
教训：MAC 白名单是"静态"的安全机制，好处是零配置、坏处是任何设备变更都要人工介入。酒店这类"设备由工程部管、网络由 IT 管"的组织里，这个跨部门流程必须提前约定。
41.9 本章小结
41.9.1 关键决策回顾
这章真正值得记住的不是某条命令，而是五个设计决策：
- 房客用 Portal（房间号+姓氏）——零终端安装，账号可对接 PMS 动态生成
- 员工用 802.1X——离职即刻失效，能下发授权 VLAN/ACL
- VRF 做硬隔离 + ACL 做细粒度——VRF 保证"路由表里看不到"，ACL 管"看到也不让过"
- 哑终端单独 SSID + MAC 白名单——因为哑终端既不会弹 Portal 也不会 802.1X
- 限速放在 AC 的 traffic-profile——每终端统一管理
41.9.2 三个"必须记住"的参数
- VLAN Pool 的每个 VLAN 都要有地址池（坑四的血泪教训）
- H3C 的
akm mode dot1x必须配client-security authentication-mode dot1x（坑三的变体） - 认证通过 ≠ 拿到正确 VLAN，授权 VLAN 是独立一环
41.9.3 自测题
- 为什么房客网要用 VLAN Pool 而不是单个
/22网段？VLAN Pool 对漫游有什么影响？ - 房客 VAP 用
security open（开放认证）安全吗？安全性靠什么保证？ - 员工 802.1X 认证成功但拿不到 IP，最可能是什么原因？
- 电视盒子这类哑终端为什么不能挂在房客 SSID 上？
- H3C 上配 WLAN 802.1X 时，只配
akm mode dot1x会怎样？
-
VLAN Pool 的价值在于突破单个广播域的地址上限（
/22只有 1022 个地址，住满可能不够），同时池内的多个 VLAN 之间漫游仍按二层漫游处理（AC 会保持原地址），所以既扩容又不牺牲漫游体验。如果只用一个/21也能扩容量，但广播域会更大，ARP/DHCP 广播压力上升。 -
不够安全，但这是有意的设计。房客网的第一道门是 Portal 认证（认证前所有流量被重定向/丢弃），第二道门是 VRF 硬隔离（房客网路由表里根本看不到办公网段）。空口不加密的代价是同一 SSID 下的房客之间理论上可嗅探，所以还要配合"房客终端互访禁止"的 ACL 和端口隔离。
-
最常见是认证通过了但没有下发授权 VLAN。RADIUS 没返回
Tunnel-Private-Group-ID，AC 也不知道该把用户放进哪个 VLAN，终端就落到默认 VLAN（通常是 VLAN 1），而 VLAN 1 上没有 DHCP 地址池。解决是让 RADIUS 下发授权 VLAN，或在 VAP 模板上指定缺省 service-vlan。 -
因为哑终端不会打开浏览器做 Portal 认证。房客 SSID 一旦要求 Portal，电视盒子就永远卡在"认证未通过"状态，连不上网。所以必须为它们单开隐藏 SSID，用 MAC 白名单认证。
-
只配
akm mode dot1x时，终端能连上但不会要求 802.1X 认证——因为akm mode只管"密钥管理用 802.1X"，真正启用用户认证必须配client-security authentication-mode dot1x，还要用dot1x domain指定认证域。
关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录
本人保留对侵权者及其全家发动因果律武器的权利
版权提醒
如无特殊申明，本站所有文章均是本人原创。转载请务必附上原文链接：https://www.elliot98.top/post/huawei-h3c-book/41/。
如有其它需要，请邮件联系！版权所有，违者必究！