华为H3C实战 | 第34章 IPoE 接入与 Web/Portal 认证

📚 本系列共 43 篇（第 34 / 43 篇）　·　第五卷 BRAS 与认证计费篇 —— 大规模用户接入

← 上一篇：第 33 章 AAA 认证与 RADIUS 对接 　下一篇：第 35 章 BRAS 用户策略与 QoS →

本章导读：PPPoE 要求用户先装拨号软件，酒店商场显然做不到。IPoE 反过来：先给地址、再在网页上补认证——这个顺序决定了它零配置的便利，也带来了"先给了地址就等于进了门"的风险。

本章结构：

• 34.1 功能原理与业务场景 —— 两种接入顺序的差异、DHCP 触发会话的十步交互、未认证/预认证/已认证三种状态各区能干什么
• 34.2 华为设备配置详解 —— IPoE 会话参数、DHCP 触发、Portal 认证对接的完整模板（含预认证 ACL）
• 34.3 H3C 设备配置详解 —— H3C 侧写法与差异标注
• 34.4 华为 / H3C 命令对照表
• 34.5 配置验证 —— 在线用户状态、预认证 ACL 是否生效、Portal 跳转是否正常
• 34.6 排错与故障树 —— “拿到 IP 但弹不出页面"“页面弹了认证不过"的分支定位
• 34.7 新手踩坑与注意事项
• 34.8 本章小结

重点提示：调不完别改 BRAS 配置，先确认 34.1.2 第②步"DHCP 触发会话"到底建没建起来；验证时一定要检查预认证 ACL 有没有配严——只给 Portal 和 DNS 放行才叫安全，忘了配就是开放网络（见 34.1.1 的缺点段）。 关联章节：PPPoE 的"先认证后进门"对照见第 32 章；RADIUS 属性与 Portal 服务器不用见第 33 章；DHCP 地址池与 DHCP Snooping 见第 8 章。

34.1 功能原理与业务场景

34.1.1 这功能是干嘛的（通俗版）

上一章讲的 PPPoE 要求用户装拨号软件、输账号密码才能上网。这在宿舍可以，但在酒店、商场、图书馆就完全不现实——你不能要求每位客人先装个拨号软件。

IPoE（以太网上的 IP 接入，IP over Ethernet）的思路是：让用户像插网线一样直接上网，先给地址，再在网页上补一次认证。

打个比方，PPPoE 像进公司要刷工卡才能进大门（先认证后进门）；IPoE + Portal 像进商场直接进，但想用商场的免费 WiFi 得先点开一个登录页同意条款（先进门后认证）。

这个「先给地址、后认证」的顺序，是 IPoE 和 PPPoE 最本质的区别，也是 IPoE 所有优缺点的根源：

• 优点：用户零配置、即插即用、终端兼容性最好（手机、电视、IoT 设备都支持）。
• 缺点：用户拿到 IP 的那一刻，他其实已经「进了门」，必须靠 Portal 强制弹页面把认证补上，否则就变成开放网络了。

34.1.2 IPoE 会话是怎么建立的

IPoE 的核心问题是：BRAS 凭什么知道「有用户来了」？ PPPoE 有 PADI 报文，IPoE 没有链路建立过程，那怎么建会话？

答案是：看 DHCP。用户插上网线第一件事是要 IP，发 DHCP Discover，BRAS 从这条 DHCP 报文里「顺手」建一个会话。这个过程叫 DHCP 触发上线。

  用户终端                               BRAS                     DHCP/AAA
  ────────                               ────                     ────────
  ① DHCP Discover ──────────────────────→
     （BRAS 看到 → 创建 IPoE 会话）
                                         ② DHCP Relay/Access-Request ─→ AAA
                                         ③ 分配地址
  ④ DHCP Offer ←─────────────────────────
  ⑤ DHCP Request ────────────────────────→
  ⑥ DHCP Ack ←───────────────────────────
     ┌──────── 用户拿到 IP，但还不能上网 ────────┐
  ⑦ 用户打开浏览器访问任意网页
  ⑧ BRAS 拦截 HTTP，重定向到 Portal 页面 ────→
  ⑨ 用户在网页上输账号密码
                                         ⑩ Portal 服务器 → RADIUS 认证
  ⑪ 认证通过 → BRAS 放开该用户的访问权限
     ┌──────── 现在才是真正能上网 ───────────────┐

关键点：第 ②步和第 ⑩步是两次完全独立的认证概念。 第 ②步是 DHCP 分配地址（技术上叫「DHCP 认证」或「免认证」），第 ⑩步才是真正的用户身份认证。很多新手以为「DHCP 拿到地址就等于上线成功了」，其实只是一个中间状态。

用户在整个过程中经历三种状态：

这个三态模型是 IPoE 排错的骨架：用户「上不了网」，先判断他卡在哪个状态。

34.1.3 三种触发方式：报文触发、DHCP 触发、ARP 触发

BRAS 发现「用户来了」有三种时机，各有适用场景：

华为官方文档对 BAS 接口的描述里，把「IP 报文触发用户上线」列为 BAS 接口的可选能力之一，说明这三种触发是可以按需选择的能力。

对新手来说，默认用 DHCP 触发就够了——它和「先给地址」的模式天然契合。

34.1.4 Web 认证与 Portal 认证：到底有什么区别

这两个词经常混用，但严格讲有区别：

   Web 认证                               Portal 认证
   ─────────                              ────────────
   BRAS 本机提供认证页面                   独立的 Portal 服务器提供页面
   （H3C 叫「本地 portal 服务」）           （也叫"远程 portal 服务器"）
   
   优点：不依赖外部服务器，部署快           优点：页面可高度定制、可做广告、
   缺点：页面简单、承载能力有限              可与多台 BRAS 共享
                                          缺点：多一个服务器要维护

H3C 官方文档明确把 portal 认证分成两种部署：远程 portal 服务器 和 本地 portal 服务。华为的 IPoE 侧则把认证方式分为 Web 认证、快速认证、绑定认证三类。

对读者来说，记住这个判断就够了：

• 小规模（酒店的几百人）：用 BRAS 自带的本地 Web 服务，省一台服务器。
• 大规模（校园几万人）：用独立 Portal 服务器，页面可定制、可承载、可集中运维。

34.1.5 Portal 协议：BRAS 和 Portal 服务器怎么对话

Portal 认证不是 RADIUS，它是一套独立协议，最常用的是 Portal 协议（基于 UDP 的 portal 报文）。三个角色：

    用户浏览器                BRAS                   Portal 服务器
    ─────────               ─────                   ────────────
  ① 访问任意网址 ───────────→
                            ② 重定向到 Portal 页面
  ③ 浏览器打开登录页 ←────────────────────────────────────────
  ④ 提交账号密码 ────────────────────────────────────→
                                                    ⑤ 发 Portal 报文校验
  ⑥ 认证通过 ←───────────────────────────────────────
                            ⑦ Portal 服务器通知 BRAS「放行该用户」
                            ⑧ BRAS 放开访问权限

要理解两个关键报文方向：

• BRAS → Portal 服务器：用户上网请求（REQ_CHALLENGE、REQ_AUTH），把用户 IP、账号密码送给服务器校验。
• Portal 服务器 → BRAS：认证结果（ACK_AUTH、ACK_CHALLENGE），告诉 BRAS 放不放行。

另有一个 BAS-IP 的概念：BRAS 在 Portal 报文里带上自己的 IP，Portal 服务器据此知道该通知哪台 BRAS 放行。多台 BRAS 共用一台 Portal 服务器时，BAS-IP 配错会导致「认证成功了但用户还是上不了网」——服务器通知错了 BRAS。H3C 文档里专门有一节讲「配置 BAS-IP 属性」，说明这是实际踩过的坑。

34.1.6 校园网与酒店的典型部署对比

酒店为什么必须用 IPoE？ 因为客人带什么设备都有可能——手机、平板、游戏机、智能电视。这些设备里大部分根本不支持 PPPoE 拨号。只有 IPoE 才能做到「插上网线或连上 WiFi 就自动拿地址」。

校园宿舍为什么常用 PPPoE？ 因为人均多设备、需要严格限速、需要精确计费、需要防私接。PPPoE 一人一会话的特性天然适合。

当然现在越来越多的校园网也在转向 IPoE + Portal，主要原因是移动设备（手机、平板）不支持 PPPoE。这个趋势值得注意。

34.1.7 IPoE 会话与 PPPoE 会话的本质区别

把两种会话并排放，差异一目了然：

「用户隔离」这一行是 IPoE 最大的安全隐患。 PPPoE 的点对点特性天然让用户之间看不到对方；IPoE 用户都在同一个二层网络里，如果不做 VLAN 隔离或端口隔离，用户 A 可以直接访问用户 B 的电脑——这在宿舍区是绝对不可接受的。

这就是为什么 IPoE 部署必须配套「二层隔离」：

   PPPoE 场景：不需要额外隔离（PPP 天然隔离）
   
   IPoE 场景：
   ├── 接入交换机上启用端口隔离（port-isolate）
   ├── 或给每个用户一个独立 VLAN（成本高）
   └── 或 BRAS 上配置隔离策略

新手做 IPoE 方案时最容易漏掉这一条，结果上线后发现宿舍里可以互相访问共享文件夹，这是严重的安全事件。所以本书要在这里明确提醒：IPoE ≠ 只是换个认证方式，它改变了二层安全模型。

另一个差异是**「会话身份」的区别**。PPPoE 有明确的用户名，计费和限速都绑在用户名上，非常干净。IPoE 的用户身份是「IP + MAC」，而这两样都可以被伪造：

• IP 可以手工配置（冒用别人的 IP）
• MAC 可以改（冒用别人的 MAC）

所以 IPoE 部署必须做几件事来加固：

   ① 禁止手工配静态 IP（只允许 DHCP 分配的 IP 上网）
      → H3C 有「只允许 DHCP 分配的用户通过 portal 认证」的功能
   ② 绑定 MAC 与 IP（DHCP Snooping 表项 + IP Source Guard）
   ③ 防 ARP 欺骗（ARP 检测）

这几条都是第 8 章（DHCP）和第 9 章（MAC 安全）的内容，但在 IPoE 场景下变得更加关键，因为 IPoE 的整个信任模型都建立在这上面。

34.1.8 快速认证与绑定认证：无感认证的两种思路

除了弹页输密码的 Web 认证，还有两种「用户无感」的认证方式，在特定场景非常好用：

快速认证（MAC 快速认证）：用户第一次通过 Web 认证后，设备记住「这个 MAC 已经认证过」，下次自动放行，不用再输密码。

   第一次：Web 认证 → 记住 MAC
   一周内再次接入：直接放行（用户无感）
   一周后：重新要求 Web 认证

绑定认证：管理员预先在 RADIUS 上把「MAC / IP / 端口」和账号绑定好，用户一接入就自动认证通过，全程无界面。

两者的区别：

对 IoT 设备来说绑定认证几乎是唯一选择——打印机不会打开浏览器，摄像头也不会输密码。所以做园区网 IPoE 方案时，一定要规划「哪些设备走 Web 认证、哪些走绑定认证」：

   人用的设备（PC、手机、平板）  → Web 认证 / 快速认证
   固定在墙上的设备（打印机、摄像头、AP）→ 绑定认证
   访客设备                        → Web 认证 + 简化流程（扫码/短信）

这个分类规划是 IPoE 方案设计的第一件事，比配命令重要得多。

34.2 华为设备配置详解

34.2.1 华为 IPoE 的三种形态与认证方式

华为官方把 IPoE 接入分成三种组网形态，先分清楚它们：

认证方式方面，官方明确 IPoE 支持三种：Web 认证、快速认证、绑定认证。

• Web 认证：弹页面输入账号密码（就是我们说的 Portal）。
• 快速认证：基于 MAC/IP 等信息自动认证，用户无感（如「认证一次，一周内免认证」）。
• 绑定认证：预先绑定 IP/MAC/端口，用户无需任何操作直接上线（如给打印机、摄像头用）。

34.2.2 完整配置模板：DHCP + Web 认证

下面这份是华为 IPoE + Web 认证的完整配置骨架，按顺序敲：

第一段，基础对象（地址池、RADIUS、域）——和 PPPoE 基本一样：

# 进入系统视图
system-view

# 地址池（IPoE 用户从这里拿地址）
ip pool pool_hotel bas local
gateway 10.200.30.1 255.255.255.0
section 0 10.200.30.2 10.200.30.254
dns-server 10.200.1.53
commit
quit

# RADIUS 服务器组
radius-server group rd1
radius-server shared-key-cipher Bras@2024
radius-server authentication 10.200.1.10 1812
radius-server accounting 10.200.1.10 1813
commit
quit

# 认证与计费方案
aaa
authentication-scheme auth_radius
authentication-mode radius
quit
accounting-scheme acct_radius
accounting-mode radius
quit

第二段，域（IPoE 的认证方式在这里声明）：

# 仍在 aaa 视图
domain isp_hotel
authentication-scheme auth_radius
accounting-scheme acct_radius
radius-server group rd1
ip-pool pool_hotel

commit
quit
quit

重要：华为的「认证方式」不是一条命令声明的。 这一点和 H3C 完全不同（H3C 只要 ip subscriber authentication-method web 一句），华为是靠「配了哪些东西」来体现的：

你想要	华为侧的做法
Web 认证	配置 web-auth-server（见下面的第四段）+ 域内配 web-server 重定向
快速认证	同上，但用户访问认证页时不输用户名密码，设备按 BAS 接口信息自动生成
绑定认证	不配 web-auth-server，靠 access-type layer2-subscriber 自动生成用户名密码

官方对三种方式的定义（原文）：

• Web authentication：用户在 web 认证服务器页面输入用户名密码
• Fast authentication：用户访问认证页但不输入账号密码，路由器根据 BAS 接口信息自动生成用户名密码
• Binding authentication：路由器根据用户物理位置自动生成用户名密码

出处：NE40E V800R023C10《Configuring an Authentication Mode for IPoE Access》，URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/f72bd139

第三段，BAS 接口（IPoE 的二层普通用户）：

# 子接口绑用户 VLAN（IPoEoVLAN 形态）
interface GigabitEthernet1/0/3.1
user-vlan 300 399
commit
quit

# 创建 BAS 接口并指定接入类型
interface GigabitEthernet1/0/3.1
bas
access-type layer2-subscriber default-domain authentication isp_hotel
commit
quit
quit

注意这里和 PPPoE 的唯一区别：没有 pppoe-server bind virtual-template。IPoE 不需要 VT，因为没有 PPP 协商。这一个小差别，就决定了两条技术路线的全部不同。

第四段，Web 认证服务器（Portal 服务器）的对接：

# 配置 Web 认证服务器：IP + 端口 + 共享密钥 + 上报自身IP
web-auth-server 10.200.1.20 port 50100 key simple Bras@2024 nas-ip-address

# 指定设备接收 portal 报文的源地址（这里是 LoopBack0）
web-auth-server source-ip 10.200.0.2

# portal 协议版本用 v3（v1/v2 安全性弱，官方建议不用）
web-auth-server version v3

# 指定发送 portal 报文的源接口
web-auth-server source interface LoopBack0

commit

还需要在域里配重定向（aaa → domain 视图下），否则用户未认证时不会被强制弹页：

# 进入 AAA 视图，再进域视图
aaa
domain isp_hotel

# 强制 Portal 服务：指定 portal 服务器地址、跳转 URL 等
portal-server url http://10.200.1.20/portal

# 或配强制 Web 认证的跳转地址
web-server url http://10.200.1.20/portal

# 指定认证服务器 IP（多 BRAS 共用 Portal 时必配）
web-server 10.200.0.2 bind web-auth-server 10.200.1.20

commit
quit

以上全部命令均已核实，出处为 NE40E V800R023C10《Configuring an Authentication Mode for IPoE Access》（配置 Web 认证或快速认证的完整步骤），URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/f72bd139

官方给出的 web-auth-server 完整语法：

web-auth-server { ip-address | ipv6-address } [ vpn-instance <name> ] [ port <n> ]
                [ key { simple <k> | cipher <k> } ] [ nas-ip-address ]
                [ detect-time <t> ] [ user-query { exclude pre-domain | version1 } ]

域内的强制 Web 认证相关命令还包括：web-server url-parameter / web-server mode { get | post } / web-server redirect-key user-mac-address ... / mac-authentication enable（开启后用户仅首次认证需输账号密码）等。

⚠ 安全提示（官方原文）：portal 协议 v1.0 没有认证字、v2.0 用 MD5 安全性弱，官方建议不要用 v1.0/v2.0，优先用 version v3。

34.2.3 IPoE 的四类接入类型

华为在 BAS 接口上定义的 access-type 参数，决定了「这类用户怎么建会话、怎么认证」。四类：

新手只需要掌握前两个：

# 二层普通用户（最常用）：用户报文带 VLAN
interface GigabitEthernet1/0/3.1
bas
access-type layer2-subscriber default-domain authentication isp_hotel
commit

# 三层普通用户：按源 IP 段归属域
access-type layer3-subscriber default-domain authentication isp_hotel
commit

layer3-subscriber 还有一个配套的「按 IP 段分域」的能力，可以在系统视图里给不同网段指定不同域：

# 按 IP 段指定认证域（系统视图）
layer3-subscriber 10.200.40.0 10.200.40.255 domain-name isp_office
layer3-subscriber 10.200.41.0 10.200.41.255 domain-name isp_guest

这对于「同一台 BRAS 上跑多个网段、每个网段走不同策略」的场景非常有用——不用在每个接口上分别配。

34.2.4 逐行讲解

再强调一次最重要的差异：IPoE 不需要虚拟模板。因为它没有 PPP 协商过程（没有 LCP、没有 PAP/CHAP、没有 IPCP），地址通过 DHCP 给，身份通过 Portal 验。没有 VT，就没有 PPP 会话，这是理解 IPoE 的关键。

34.2.5 IPoE 的维护命令

# 查看在线 IPoE 用户
display access-user

# 查看某用户详情（能看到认证状态、IP、策略）
display access-user username user1@isp_hotel

# 查看 BAS 接口配置
display current-configuration interface GigabitEthernet1/0/3.1

# 查看地址池
display ip pool name pool_hotel

重点看 display access-user 输出里的用户状态字段。IPoE 用户的状态会明确区分预认证（pre-auth）与已认证（online），这是判断「用户卡在哪」的核心依据。

34.2.6 完整案例：一个酒店网络的 IPoE + Portal 方案

把前面所有概念串成一个完整案例。需求：一栋酒店，200 个房间，每间房一个网口 + 一个 WiFi AP，客人插网线或连 WiFi 后应该自动弹认证页，用房号和姓氏登录。

组网设计：

   [客人手机/笔记本]
        │
   [房间接入交换机]  VLAN 300-399（每层或每段一个VLAN）
        │
   [楼层汇聚]        透传 VLAN
        │
   ====[BRAS]====
        ├── GE1/0/3.1  user-vlan 300 399   → 域 isp_hotel → 池 pool_hotel
        ├── GE1/0/1   上行三层口            → OSPF 到核心
        └── GE1/0/4   Portal 服务器所在网段
        
   [Portal 服务器 10.200.1.20]
   [RADIUS 服务器 10.200.1.10]（可以和 Portal 合设）

配置顺序与要点：

   第1步 地址池 pool_hotel      ← 容量 = 200 房间 × 2~3 设备 = 600 地址
   第2步 RADIUS 服务器组        ← 认证 + 计费
   第3步 认证/计费方案
   第4步 域 isp_hotel           ← 绑定方案 + 池 + Web 认证方式
   第5步 子接口 GE1/0/3.1       ← user-vlan 300 399
   第6步 BAS 接口               ← access-type layer2-subscriber + 默认域
   第7步 Portal 服务器对接       ← 服务器地址、端口、密钥、URL
   第8步 上行 OSPF              ← import-route unr
   第9步 二层隔离（接入交换机）  ← 关键！IPoE 必须做

容量规划的几个数字（这是实际项目里最该算的）：

为什么地址池要留 1.5 倍余量？ 因为用户下线后，DHCP 地址有租期，不会立刻释放。如果池子刚好等于并发数，在换房高峰期就会出现「池子满了新用户进不来」。

酒店场景的三个特殊要求：

1. 认证页面必须极简：客人只有 30 秒耐心，输房号 + 姓氏就够，别要密码。
2. 必须有 fail-permit 兜底：Portal 服务器挂了，客人也要能上网——宁可放开，别让整栋楼断网。
3. 会话时长要合理：客人可能连住几天，会话不能因为空闲被踢。IPoE 的在线检测时间要调长（比如 30 分钟）。

这三条都是「业务需求驱动配置」，而不是技术要求。做方案时先想清楚业务，再决定配什么参数——这是从「会敲命令」到「会做方案」的分水岭。

34.3 H3C 设备配置详解

34.3.1 H3C 的 IPoE 体系：用户类型与认证方式

H3C 的 IPoE 分类比华为更细，先理清概念：

对新手来说，动态个人用户 + Web 认证是最常用的组合，也就是酒店/校园场景。

34.3.2 完整配置模板：DHCP + Web 认证（酒店场景）

下面是 H3C 侧的一份配置骨架。请注意本节给出的命令中，部分命令形式需要按设备版本核对，我会明确标注。

第一段，基础对象：

# 进入系统视图
system-view

# RADIUS 方案
radius scheme rs1
primary authentication 10.200.1.10
primary accounting 10.200.1.10
key authentication simple Bras@2024
key accounting simple Bras@2024
quit

# ISP 域
domain name isp_hotel
authentication ppp radius-scheme rs1
authorization ppp radius-scheme rs1
accounting ppp radius-scheme rs1
authorization-attribute ip-pool pool_hotel
quit

# 地址池
dhcp server ip-pool pool_hotel
gateway-list 10.200.30.1 export-route
network 10.200.30.0 mask 255.255.255.0
quit

第二段，在接口上启用 IPoE 并设置访问模式（接口视图）：

# 进入用户侧接口
interface GigabitEthernet3/1/2

# 启用 IPoE：l2-connected 表示二层接入方式
# 不写 ipv4/ipv6 则同时为两个协议栈启用
ip subscriber l2-connected enable

# 认证方式改为 Web 认证（默认是 bind 绑定认证）
ip subscriber authentication-method web

# 指定预认证域与 Web 认证域
ip subscriber pre-auth domain isp_hotel
ip subscriber web-auth domain isp_hotel

quit

已核实的语法（重要）：ip subscriber enable 是不完整的，官方命令必须带访问模式参数——ip subscriber { l2-connected | routed } enable [ ipv4 | ipv6 ]；认证方式为 ip subscriber authentication-method { bind | web [ mac-auth ] }，默认是 bind，不显式改成 web 就不会走 Web 认证。出处：H3C CR16000-F《14-IPoE configuration》「Configuring the authentication method」与官方 Web 认证完整举例，URL：https://www.h3c.com/en/d_202001/1262641_294551_0.htm

第三段，Portal 认证服务器与 Portal Web 服务器（系统视图）：

# 创建 Portal 认证服务器并进入其视图
portal server pt1

# 指定认证服务器 IP 与共享密钥（ip 是独立子命令）
ip 10.200.1.20 key simple Bras@2024

# 可选：目的 UDP 端口，默认 50100，须与服务器监听端口一致
port 50100

# 可选：服务器类型，默认 imc，须与实际服务器类型一致
server-type imc

quit

# 创建 Portal Web 服务器并进入其视图
portal web-server wbs

# 指定认证页面 URL
url http://10.200.1.20/portal

quit

第四段，在接口上启用 Portal 认证并引用 Web 服务器：

# 进入三层接口视图
interface GigabitEthernet3/1/2

# 启用 Portal 认证：direct 二层直连 / layer3 三层跨网 / redhcp 二次地址分配
portal enable method direct

# 引用 Portal Web 服务器
portal apply web-server wbs

# 指定 Portal 报文里的 BAS-IP（多 BRAS 共用 Portal 服务器时必配）
portal bas-ip 10.200.0.2

quit

已核实的语法要点：

• portal server <name> 只负责创建并进入视图，IP 和密钥是视图内的独立子命令 ip <ip> key { cipher | simple } <string>。不能写成 portal server <name> ip ... 一行。
• portal enable method 的取值是 { direct | layer3 | redhcp }——注意是 redhcp，不是 re-dhcp。
• portal apply web-server <name> [ secondary ] 在接口视图引用 Web 服务器。
• portal bas-ip <ipv4-address> 在接口视图配置 BAS-IP 属性。
• 出处：H3C《11-User Access and Authentication Configuration Guide - 08-Portal configuration》，URL：https://www.h3c.com/en/d_202106/1419274_294551_0.htm ；命令清单亦见《08-Portal命令》https://www.h3c.com/cn/d_202204/1585010_30005_0.htm

⚠ 一个必须知道的限制（官方原文）：接口上同时配置 IPoE Web 认证和 Portal 认证时，只有 IPoE Web 认证生效。所以本节的 IPoE 方案与 Portal 方案不要在同一接口上叠加，要按业务二选一。

34.3.3 H3C IPoE 的关键配置项解析

虽然完整命令串需要按版本核对，但 H3C IPoE 有几个配置思想必须讲清楚，因为它们直接决定方案设计：

① 会话建立方式：H3C 把 IPoE 会话分为「动态」和「静态」，动态会话由用户主动请求触发（DHCP/IP 报文/ARP），静态会话由管理员预先定义。酒店用动态，专线用静态。

② 认证用户命名规则：动态用户没有固定用户名，H3C 需要一套「命名规则」来决定这些用户的用户名怎么生成。这在官方文档中是一节专门的内容（Configuring authentication user naming conventions for dynamic individual users）。

为什么重要？因为 RADIUS 服务器要按用户名查账号。如果 IPoE 动态用户的用户名是根据 MAC 生成的（如 mac-001122334455），那 RADIUS 里就得按这个格式建账号。命名规则配错，用户就永远认证不过，而现象是「Portal 页面提交后失败」，很难直接联想到命名规则。

③ 密码生成规则：动态用户没有用户输入的密码（在「绑定认证」模式下），H3C 允许配置密码规则。Web 认证模式下用户会输密码，就不用这个。

④ 可信 DHCP 选项：H3C 文档有一节讲「Configuring trusted DHCP options for DHCP users」，用于解析 DHCP Option 82 里的 circuit-id / remote-id。这两个字段记录了「用户从哪个交换机的哪个口进来的」，是定位和分域的关键信息。

⑤ DHCP 用户的分域：H3C 提供「域名生成规则」（domain name generation rules）来决定 DHCP 用户属于哪个 ISP 域。默认可能按接口分，也可按 DHCP 选项内容分。这一项的配置直接决定「用户走哪套策略」。

这五点合起来，构成了 H3C IPoE 方案设计的完整逻辑链：

   DHCP 报文进来
      ↓
   ① 从 DHCP Option 82 取 circuit-id/remote-id（定位用户）②
      ↓
   ② 按域名生成规则决定域（走哪套策略）⑤
      ↓
   ③ 按命名规则生成用户名 ②
      ↓
   ④ 按密码规则生成密码（绑定认证时）③
      ↓
   ⑤ 送 RADIUS 认证

只要这条链上任何一环配错，用户就上不了线。 这也是为什么 H3C IPoE 排错比 PPPoE 更难——PPPoE 的用户名密码是用户自己输的，一目了然；IPoE 的用户名密码是设备「算」出来的，看不见。

34.3.4 Portal 认证的几种模式（选型关键）

H3C 文档里把 Portal 认证模式区分为几种，这是做方案时必须选对的：

「二次地址分配」是什么意思？ 用户刚接入时先拿一个「预认证地址段」的临时 IP，只能访问 Portal；认证通过后，重新分配一个正式地址。这样做的好处是：未认证用户根本不在业务网段里，安全隔离最彻底。代价是每次认证都要多一次 DHCP 交互。

对酒店来说，二层直连就够；对需要严格安全隔离的政企网，才上二次地址分配。

Portal 认证流程（对应官方文档的流程图）：

   ① 用户发起 HTTP 访问
   ② BRAS 检测到未认证用户 → 重定向到 Portal 页面
   ③ 用户在 Portal 页面提交账号密码
   ④ Portal 服务器向 BRAS 发 REQ_CHALLENGE
   ⑤ BRAS 回应 ACK_CHALLENGE
   ⑥ Portal 服务器向 BRAS 发 REQ_AUTH（带账号密码）
   ⑦ BRAS 组装 Access-Request 发 RADIUS 服务器
   ⑧ RADIUS 回 Access-Accept
   ⑨ BRAS 向 Portal 服务器回 ACK_AUTH（认证成功）
   ⑩ BRAS 放开该用户访问权限

注意第 ⑥、⑦ 步：Portal 服务器不直接连 RADIUS（在这个流程里），是把账号密码交给 BRAS，由 BRAS 去问 RADIUS。这跟很多人的直觉不同——直觉上以为 Portal 服务器直接查 RADIUS。理解这一点很重要：RADIUS 上的 client 配置应该是 BRAS 的地址，不是 Portal 服务器的地址。

34.3.5 H3C 的 Portal 增强功能清单

官方《Portal 配置》章节列出了一批增强功能，了解这些能在方案阶段少走弯路：

「Portal fail-permit」这一项特别值得说：Portal 服务器挂了，用户全部上不了网，这是负面体验。fail-permit 的取舍是「宁可暂时放开，也别让所有人上不了网」。这是个业务决策，不是技术决策——要不要开，取决于你对「断网」和「被蹭网」哪个更敏感。

34.3.6 本地 Portal 服务：小规模部署的省钱方案

H3C 支持「本地 portal 服务」，即认证页面由 BRAS 自己提供，不需要额外一台 Portal 服务器。这对小规模部署（比如一栋独立办公楼、一家小旅馆）非常划算。

它的能力边界（从官方文档的功能清单看）：

什么时候该用本地 Portal、什么时候该用独立服务器？

   用本地 Portal 服务：
   ├── 用户规模 < 1000
   ├── 页面不需要经常改
   ├── 无专门的 Web 运维人员
   └── 希望减少故障点（少一台服务器）

   用独立 Portal 服务器：
   ├── 用户规模 > 1000（设备本地页面承载能力有限）
   ├── 需要品牌化页面、广告位
   ├── 需要和多套认证系统对接（统一身份认证）
   └── 多台 BRAS 需要共享一套认证体验

一个常见的误区：以为「本地 Portal 服务」连 RADIUS 都不用了。其实不是——本地 Portal 只是把「页面」放在设备上，认证依旧要送去 RADIUS（或本地账号）。页面和认证中心是两回事。

34.3.7 IPoE 与 PPPoE 共存的部署策略

现实网络里，同一台 BRAS 往往需要同时服务 PPPoE 用户和 IPoE 用户。两家的做法：

华为的方案——同一条配置体系，靠接口区分：

   接口A（子接口 1）：
     user-vlan + pppoe-server bind virtual-template 1 + bas + access-type layer2-subscriber
     → 这类用户走 PPPoE

   接口B（子接口 2）：
     user-vlan + bas + access-type layer2-subscriber（无 pppoe-server bind）
     → 这类用户走 IPoE

   两者可以在不同的域上，用不同的认证方案

关键：PPPoE 和 IPoE 的接口配置本质区别只有一条——有没有 pppoe-server bind。有就是 PPPoE，没有就是 IPoE。这个判断标准极为好用，排错时也可以用：「这个接口到底是 PPPoE 还是 IPoE？」看这一条就够了。

H3C 的方案——两套独立体系共存：

   接口A：pppoe-server bind virtual-template 1   → PPPoE 用户
   接口B：ip subscriber l2-connected enable       → IPoE 用户

H3C 的一套域可以同时为 ppp 和 ipoe 两类用户配置策略（32 章讲过 authorization ipoe radius-scheme rs1 这种写法），所以共存时域可以复用。

共存部署的三条实务建议：

1. 地址池分开：PPPoE 用户和 IPoE 用户用不同的池，便于统计和排错。
2. 域尽量分开：虽然技术上可以共用一个域，但混在一起会让限速和计费策略难以差异化。
3. VLAN 规划分开：把 PPPoE 用户和 IPoE 用户划到不同的 VLAN 段，接入层也好维护。

这三条不是技术强制要求，但做过实际项目的都知道——混在一起的代价，会在半年后的某次排错里连本带利还给你。

34.4 华为 / H3C 命令对照表

表格里最需要注意的是第一行：华为把 IPoE 也纳入「BAS 接口」这套统一模型，H3C 用独立的 ip subscriber 体系。这意味着：

• 华为的 IPoE 和 PPPoE 共用同一套域、地址池、RADIUS 配置，只是接口侧声明不同。
• H3C 的 IPoE 是独立的一套，概念（动态/静态个人用户、命名规则、域名生成规则）都要重新学。

从学习成本看，华为的模型更统一；从灵活性看，H3C 的分类更细。这个差异在做跨厂商迁移时要心里有数。

34.5 配置验证

IPoE 的验证有一个和 PPPoE 完全不同的重点：要验证「两个状态」而不是「一个状态」。

第一步：验证 DHCP 能给地址（预认证状态）

# 华为：查地址池使用情况
display ip pool name pool_hotel

期望：used 字段有值，说明有用户拿到了地址。如果 used 一直是 0，说明 DHCP 都没走通，先解决 DHCP 问题，别往下看了。

第二步：验证会话已建立（预认证 → 认证中）

# 华为：查在线用户
display access-user

IPoE 用户此时应该能看到，但用户状态显示为预认证（pre-authentication）而不是已认证。这一步能查到但上不了网，是完全正常的中间状态。

第三步：验证 Portal 认证能通

在用户终端上实际操作：打开浏览器，应该被重定向到登录页；输入账号密码后应提示成功。如果卡在这里，问题在 Portal/RADIUS 链路。

第四步：验证认证后状态变更

# 华为：再看一次在线用户
display access-user username user1@isp_hotel

期望：用户状态从预认证变为已认证（online），并且能看到分配的 IP、策略信息。这一步是 IPoE 验证的关键——状态变了，说明整条链路都通了；状态没变但浏览器提示成功，说明 Portal 服务器通知 BRAS 失败（多半是 BAS-IP 配错）。

第五步：在 Portal 服务器侧验证

看 Portal 服务器的日志，应有：

• 收到用户的认证请求
• 向 BRAS 发送认证请求报文
• 收到 BRAS 的认证结果

如果服务器侧显示成功但 BRAS 侧用户还是预认证状态，就是 BRAS 和 Portal 服务器之间的 Portal 报文没通（共享密钥、端口、BAS-IP 三者之一）。

第六步：验证免认证资源可达

在未认证状态下，用户应该能访问 Portal 页面、DNS 服务器，但访问其他网站应该被拦截。这个验证能确认「预认证策略」生效了。如果未认证也能上网，说明 Portal 根本没劫持成功，这个网络等于完全开放——这是最严重的安全问题，必须马上修。

34.6 排错与故障树

IPoE 的故障树和 PPPoE 完全不同，因为它有两个认证状态：

   用户上不了网
     │
     ├─ Q1: 用户拿到 IP 了吗？
     │     │
     │     ├─ 没拿到 ──┬─ ① DHCP 不通（没开/中继错/池没配）
     │     │           ├─ ② 地址池耗尽
     │     │           └─ ③ 接口没启用 IPoE
     │     └─ 拿到了 ──→ Q2
     │
     ├─ Q2: 会不会自动弹认证页面？
     │     │
     │     ├─ 不弹 ──┬─ ① BRAS 没启用 Portal
     │     │         ├─ ② HTTPS 站点不弹（只劫持 HTTP）
     │     │         └─ ③ Portal Web 服务器地址配错
     │     └─ 弹了 ──→ Q3
     │
     ├─ Q3: 输账号密码后成功了吗？
     │     │
     │     ├─ 失败了 ──┬─ ① RADIUS 认证失败（见第33章）
     │     │           ├─ ② 用户名/密码生成规则错（H3C）
     │     │           └─ ③ Portal 与 BRAS 的共享密钥不一致
     │     └─ 成功了 ──→ Q4
     │
     └─ Q4: 认证后能上网吗？
           │
           ├─ 不能 ──┬─ ① BAS-IP 配错（通知错了 BRAS）
           │         ├─ ② 用户状态仍是预认证（通知没送达）
           │         └─ ③ 路由/NAT 问题
           └─ 能 ──→ 正常

逐条排查表：

几个高频场景的完整路径：

场景一：用户拿到 IP，但从不弹认证页，直接能上网。

这是最危险的故障——网络等于完全开放。排查：

# 1. 确认接口上 Portal 是否真的启用了
display current-configuration interface GigabitEthernet1/0/3.1
#    找 portal 相关配置，没有就是没启用

# 2. 确认域上的认证方式
display domain isp_hotel
#    看认证方式是否为 Web

# 3. 确认用户处于什么状态
display access-user username user1@isp_hotel
#    如果显示"online"而不是"pre-authentication"，说明被当成了已认证用户

如果用户一上来就是 online 状态，通常是域配错了——用户走了一个「免认证」的域。

场景二：弹了页面，输账号密码提示成功，但还是上不了网。

这是 Portal 报文链路的问题，按顺序查：

   ① Portal 服务器 → BRAS 的报文通不通？
      → 检查 BAS-IP 配置（服务器要通知哪台 BRAS）
   ② 两边共享密钥一致吗？
      → Portal 协议也有共享密钥/校验字段
   ③ 端口对不对？
      → Portal 服务器端口（常见 50100）与 BRAS 配置要一致
   ④ 用户状态变了吗？
      → display access-user，仍为 pre-authentication 就是通知没到

BAS-IP 配错是多 BRAS 共用 Portal 服务器时的头号嫌疑：Portal 服务器收到认证请求后，要通知「哪台 BRAS 放行这个用户」。如果 BRAS 上报的 BAS-IP 不是服务器认识的那个地址（比如上报了接口地址而不是 LoopBack），服务器就通知不到，用户永远停在预认证状态。

场景三：HTTPS 网站不弹认证页。

这个其实不算故障，是设计使然。Portal 劫持的是 HTTP 请求（端口 80），用户如果要访问 https://... 的网站，浏览器会直接用 443 端口，BRAS 劫持不了（因为证书校验会失败）。

解决方法有几种：

• 让 Portal 服务器支持 HTTPS 重定向（H3C 文档里就有「HTTPS redirect 监听端口」和「配置 SSL server policy for HTTPS redirection」）。
• 引导用户先访问一个 HTTP 地址（如门户页）。
• 用「captive portal 检测」：终端连上后会自动访问一个特定的 HTTP 探测地址（iOS/Android 都有这个机制），从而触发弹窗。H3C 文档里的 captive-bypass 就是相关功能。

场景四：IPoE 用户频繁掉线（会话老化）。

IPoE 用户的会话维持依赖「在线检测」，如果检测参数配得太激进，用户会被误判为离线：

   检测机制：BRAS 定期探测用户是否还在（ARP 探测 / 流量检测）
   → 用户设备休眠（手机会自动省电断网）→ 探测不到 → 判定离线
   → 踢掉会话 → 用户需要重新认证

这是移动终端在 IPoE 下的通病：手机锁屏后为了省电会停止响应 ARP，BRAS 就把它踢了。解决方法：把在线检测的超时时间调长，或改用「有流量即认为在线」的检测方式。

34.7 新手踩坑与注意事项

1. 以为 IPoE 拿到 IP 就等于能上网——拿到 IP 只是预认证状态，必须 Portal 认证后才算上线。
2. 未认证用户能上网却没发现——这是最严重的安全问题。上线前一定验证「未认证状态」的访问限制。
3. 只测试 HTTP 网站——HTTPS 网站不会弹认证页，用户会以为「认证系统坏了」。
4. BAS-IP 配错——多 BRAS 共用 Portal 服务器时的头号故障，现象是「认证成功但上不了网」。
5. 以为 Portal 服务器直接连 RADIUS——在标准流程里是 BRAS 去问 RADIUS，所以 RADIUS 的 client 配 BRAS 地址。
6. H3C 的用户名生成规则配错——IPoE 动态用户的用户名是设备算出来的，配错了服务器查不到账号。
7. 手机锁屏后掉线——在线检测太激进。手机省电断网被误判离线，调长检测时间。
8. IPoE 也去配虚拟模板——不需要！IPoE 没有 PPP 协商。多配了反而可能引发冲突。
9. 忘了 DHCP 也可能是问题源——IPoE 完全依赖 DHCP，DHCP 不通则用户连预认证状态都进不去。
10. Portal 服务器挂了没配 fail-permit——全员上不了网。要不要开容错是业务决策。

34.8 本章小结

• IPoE 的核心是「先给地址、后认证」，与 PPPoE 的「先认证、后给地址」正好相反。
• IPoE 会话靠 DHCP 报文触发建立，不需要虚拟模板，因为没有 PPP 协商。
• 用户有三种状态：未认证 → 预认证 → 已认证。排错必须先确定用户在哪个状态。
• Portal/Web 认证有三个角色：用户浏览器、BRAS、Portal 服务器。认证请求由 BRAS 转发给 RADIUS，不是 Portal 服务器直接查 RADIUS。
• BAS-IP 决定了服务器通知哪台 BRAS，多 BRAS 场景最容易在这翻车。
• 华为把 IPoE 纳入统一的 BAS 接口模型（access-type layer2-subscriber），H3C 用独立的 ip subscriber 体系并细分为动态/静态/租用用户。
• HTTPS 网站不会触发认证页，这是设计限制，需要 HTTPS 重定向或 captive portal 机制解决。
• 酒店/商场用 IPoE + Portal，宿舍/小区倾向 PPPoE，但移动终端普及正在推动校园网转向 IPoE。

适用版本：华为 NE40E V800R023C10 系列《IPoE 接入配置》；H3C CR16000-F Release 795x《IPoE 配置》《Portal 配置》。注意：本章涉及 Web/Portal 认证的具体命令串在两家都存在较大的版本差异，正文已标注待核实项，实施前必须以设备版本官方文档为准。

自测题

1. IPoE 与 PPPoE 在「认证」和「分配地址」的先后顺序上有什么区别？
2. IPoE 用户的三种状态是什么？为什么拿到 IP 还不算上线成功？
3. Portal 认证中，RADIUS 服务器的 client 应该配谁的 IP？
4. BAS-IP 配错会出现什么现象？
5. 为什么用户访问 HTTPS 网站时不会弹出认证页面？

1. IPoE 是「先通过 DHCP 分配地址，再通过 Web/Portal 认证」，即先给地址后认证；PPPoE 是「先 LCP/PAP/CHAP 认证，再通过 IPCP 分配地址」，即先认证后给地址。
2. 未认证 → 预认证（pre-authentication）→ 已认证（online）。拿到 IP 只是进入预认证状态，此时只能访问 Portal 服务器、DNS 等资源，必须完成 Portal 认证后才会变为已认证状态，才能正常访问网络。
3. 应该配 BRAS 的 IP。标准流程是 Portal 服务器把账号密码交给 BRAS，由 BRAS 组装 Access-Request 发给 RADIUS 服务器，所以 RADIUS 的 client 是 BRAS 而非 Portal 服务器。
4. 现象是「用户在 Portal 页面提示认证成功，但实际仍然上不了网」，用户状态一直停留在预认证。因为 Portal 服务器需要根据 BAS-IP 决定通知哪台 BRAS 放行用户，BAS-IP 错误会导致通知发到错误的 BRAS 或发不出去。
5. 因为 Portal 劫持通常只针对 HTTP（80 端口）的请求。用户访问 HTTPS（443 端口）时，为了校验证书 BRAS 无法直接重定向。解决方式包括配置 HTTPS 重定向、使用 captive portal 探测机制，或引导用户先访问 HTTP 站点。

关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录