你是否遇到过这样的场景？

• 入住酒店，连接Wi-Fi后浏览器自动弹出认证页面，输入手机号和验证码才能上网；
• 拜访朋友公司，连接访客Wi-Fi，页面提示输入密码或扫码认证；
• 在商场、机场、星巴克，连接免费Wi-Fi后总会弹出广告或认证页面。

这就是Portal认证在生活中的典型应用。但你或许不知道，Portal认证不仅限于无线网络——在企业办公室，员工电脑插入网线后，同样可能被重定向到认证页面，输入工号密码才能访问内网资源。

本文将从技术原理、系统架构、协议演进、认证流程到配置实践，全面解析Portal认证。

Portal认证（又称Web认证、门户认证）是一种基于应用层的网络准入控制技术，通过在用户首次访问网络时强制重定向至认证页面，完成身份核验后方可授予网络访问权限。与工作在数据链路层的802.1X认证不同，Portal认证无需预装客户端，仅依赖浏览器即可完成认证流程，因此在访客接入、BYOD场景及公共场所Wi-Fi中应用广泛。

一、什么是Portal认证

Portal，门户、入口的意思，如web portal 门户网站。Portal认证的本质是应用层准入控制：

1. 当未认证用户尝试访问互联网时，接入设备会拦截其HTTP请求（应用层），强制重定向至Portal认证页面；
2. 用户输入凭据（账号密码、短信验证码等）提交后，系统完成身份校验并动态开放网络权限。

与802.1X认证的关键区别在于：

• 802.1X：工作在数据链路层，认证通过前仅允许EAP报文通行，终端无法获取IP地址，安全性更高，适合企业固定员工设备 。
• Portal：工作在应用层，认证前终端已获取IP地址，通过HTTP重定向引导用户完成认证，便捷性强，适合访客、BYOD及临时接入场景 。

Portal认证不仅限于无线网络——在园区有线网络中，接入交换机同样可作为Portal接入设备，对有线终端实施Web认证准入。

二、Portal系统架构

Portal认证系统由四个核心角色构成

1. 客户端：认证发起方。终端浏览器或Portal客户端软件，通过HTTP/HTTPS发起认证
2. 接入设备：策略执行点。交换机/路由器/无线控制器等，①认证前重定向HTTP/HTTPS请求；②认证中与Portal服务器/RADIUS交互；③基于认证结果控制用户访问权限。
3. Portal服务器：认证门户。①提供Web认证页面；②与客户端交互HTTP/HTTPS；③与接入设备交互认证信息。
4. RADIUS服务器：认证/授权/计费。校验用户身份，返回授权信息，处理计费报文。

与802.1x相比，多了个portal服务器角色。如果厂商的NAC解决方案带客户端的，同样可以增加策略服务器进行联动。可以参考802.1x认证的​​安全策略​​。

三、三种Portal协议版本演进

1. 私有阶段（2006年前）：厂商各自为政，协议互不兼容。
2. Portal 1.0（2006年）：中国移动发布《中国移动WLAN业务PORTAL协议规范》V1.0，统一接口实现互联互通，但无报文校验机制，存在安全漏洞。
3. Portal 2.0（2008年）：中国移动发布《中国移动WLAN业务PORTAL协议规范》V2.0.0，采纳华为方案，新增16字节Authenticator（MD5） 实现完整性校验，并引入CHAP与防重放机制，成为国内事实标准。
4. Portal 3.0（双轨并行）：

• 企业网：厂商私有Portal 3.0，算法升级SHA256，扩展属性对接安全策略服务器，实现终端安全检测与动态ACL/VLAN授权。
• 运营商：中国移动CMCC Portal 3.0规范，明确Portal-AC/RADIUS/终端三大接口，算法升级SHA256，新增漫游推送等流程，满足4A审计、等保2.0及多厂商互通。

四、Portal协议报文详解

Portal协议采用UDP端口2000作为传输层承载，报文结构由固定长度报文头和可变长度属性字段（TLV格式） 两部分组成。V1.0与V2.0/V3.0的核心差异在于报文头中是否包含Authenticator校验字段。

Version

版本号，1字节。

• ​​0x01​​：Portal 1.0；
• ​​0x02​​：Portal 2.0（主流）；
• ​​0x03​​：Portal 3.0

Type

报文类型，1字节。常见取值：

• 0x01 (REQ_CHALLENGE)：Portal服务器向接入设备发送的Challenge请求报文
• 0x02 (ACK_CHALLENGE)：接入设备对Challenge请求的响应报文
• 0x03 (REQ_AUTH)：Portal服务器向接入设备发送的认证请求报文
• 0x04 (ACK_AUTH)：接入设备对认证请求的响应报文
• 0x05 (REQ_LOGOUT)：Portal服务器向接入设备发送的下线请求报文
• 0x06 (ACK_LOGOUT)：接入设备对下线请求的响应报文
• 0x07 (AFF_ACK_AUTH)：Portal服务器向接入设备发送的认证成功确认报文
• 0x08 (NTF_LOGOUT)：接入设备向Portal服务器发送的用户被强制下线通知报文
• 0x09 (REQ_INFO)：Portal服务器向接入设备发送的信息询问报文
• 0x0A (ACK_INFO)：接入设备对信息询问的应答报文
• 0x0E (ACK_NTF_LOGOUT)：Portal服务器通知接入设备用户强制下线成功
• 0x10 (USER_SYN)：Portal服务器向接入设备发送的用户信息同步请求报文
• 0x11 (ACK_USER_SYN)：接入设备对用户信息同步请求的响应报文
• 0x30 (MAC_QUERY)：接入设备向Portal服务器发送的MAC缓存查询报文
• 0x31 (ACK_MAC_QUERY)：Portal服务器对MAC缓存查询的回应报文
• 0x81 (STATUS_NOTIFY)：Portal服务器定时向接入设备发送的状态通知报文
• 0x82 (ACK_STATUS_NOTIFY)：接入设备对状态通知报文的响应报文

AuthType

认证方式，1字节。该字段仅在Type为认证请求报文（REQ_AUTH，0x03）时生效。两种认证方式：

• 0x00（CHAP）：挑战握手认证协议，密码以密文方式传输，安全性较高。Portal 1.0不支持，Portal 2.0及以后版本支持。
• 0x01（PAP）：密码认证协议，密码以明文方式传输，安全性较低。全版本支持，但Portal 2.0及以后版本不推荐使用。

Rsvd

保留字段，1字节，在所有报文中固定取值为0

SerialNo

报文的序列号，2字节，Portal服务器生成，同一用户的上线过程中所有报文使用相同的SerialNo，用于关联这些报文属于同一次认证会话。

RequestID

报文ID，2字节，接入设备生成，用于CHAP认证。设备下发Challenge时带上这个ID，Portal服务器认证时回传同一个ID，设备据此找到之前下发的Challenge值完成密码校验。

UserIP

用户IP地址，4字节。标识正在认证或已在线用户的IPv4地址，是接入设备识别用户的核心依据。

长度固定为4字节，因此原生不支持IPv6地址。

• 厂商可以通过RADIUS扩展属性（如Framed-IPv6-Address）传递用户IPv6地址。
• AC通过HTTP重定向URL参数直接传递用户IPv6地址（例如 ?userip=2001:db8::1）。

UserPort

用户端口，2字节，目前为保留字段，所有报文固定填0。

ErrCode

错误码，1字节。与Type字段配合使用，0表示成功，非0表示特定错误。

• ACK_CHALLENGE（0x02）：0=成功，1=请求被拒绝，2=链接已建立，3=用户认证中，4=失败，0xFD=未找到用户
• ACK_AUTH（0x04）：0=成功，1=请求被拒绝，2=链接已建立，3=用户认证中，4=认证失败（如用户名错误），5=Portal在线用户数达最大值，6=设备正在进行其他方式认证，0xFD=未找到用户
• REQ_LOGOUT（0x05）：0=正常下线请求，1=超时重传的下线请求
• ACK_LOGOUT（0x06）：0=成功，1=被拒绝，2=失败
• NTF_LOGOUT（0x08）：2=用户被强制下线
• ACK_INFO（0x0A）：0=成功，1=不支持该功能，2=消息格式错误
• 其他未列出的 Type 中ErrCode字段无意义恒为0。

AttrNum

属性个数，长度为1字节，指示报文头后跟随的TLV属性数量，取值范围0-255。

Authenticator

验证字，长度为16字节。用于报文完整性校验，发送端对整个报文（Authenticator字段本身填0参与计算）进行哈希计算，结果填入该字段；接收端重新计算并比对，一致则报文合法。V2.0使用MD5算法，V3.0升级为SHA256算法。V1.0无此字段。

Attribute

可变长字段，由多个属性组合而成，每个属性采用TLV格式（ Type-Length-Value，类型-长度-值）。

• AttrType：属性类型，1字节。0x01：用户名（UserName）；0x02：密码（Password），PAP方式使用；0x03：Challenge值，CHAP方式使用；0x04：CHAP密码，CHAP方式下加密后的凭证；0x05：文本信息（TextInfo）
• AttrLen：属性长度，1字节。值为AttrType、AttrLen、AttrValue三个字段的长度之和。
• AttrValue：属性值，长度可变（最长不超过253字节）。具体内容由AttrType决定，如用户名、密码等。

五、三种Portal认证方式

Portal认证方式的核心区别在于客户端与接入设备之间的网络层次（二层或三层）以及IP地址分配策略。

5.1 二层认证方式

网络拓扑：客户端与接入设备之间无三层转发设备，处于同一广播域。

技术原理：接入设备通过ARP学习或DHCP Snooping获取客户端MAC地址，以IP为主标识、MAC为辅标识建立IP-MAC绑定表项。认证通过后下发基于IP-MAC二元组的ACL规则，未认证用户仅允许访问Portal服务器。

特点：安全性高（可防御IP仿冒），认证流程简洁，但组网受限（需同网段）。

典型场景：企业办公网络：员工电脑直连接入交换机，交换机作为接入设备。员工打开浏览器访问任意网站，被重定向至Portal认证页面，输入账号密码通过后，交换机下发ACL放行该IP+MAC，员工正常上网。

5.2 三层认证方式

网络拓扑：客户端与接入设备之间允许存在三层转发设备，可跨网段组网。

技术原理：ARP广播无法跨越三层，接入设备无法获取MAC地址，仅以IP地址为用户唯一标识。认证通过后下发基于IP的ACL规则。可通过DHCP Option 82、IP-MAC绑定表导入或SNMP联动查询等方式跨三层获取MAC地址增强安全。

特点：组网灵活（支持大规模分布式接入），但安全性较低（单凭IP易被伪造），认证延迟略高。

典型场景：大型园区无线网络：AP通过CAPWAP隧道将用户流量汇聚到无线控制器（AC），用户网关在AC上，终端与AC之间跨越三层网络。用户连接Wi-Fi后，AC拦截HTTP流量推送Portal页面，认证通过后基于用户IP放行。

5.3 二次地址分配认证方式

网络拓扑：客户端与接入设备之间无三层转发设备。

技术原理：两阶段IP分配——认证前分配私网IP（仅访问Portal），认证后触发DHCP强制续租（如发送DHCP NAK）获取业务IP（公网/业务网段），基于业务IP放开网络访问权限。

特点：节省公网IP资源（未认证用户不占用地址池），实现安全隔离，但强依赖专用客户端，不支持IPv6。

典型场景：校园网宽带接入：学生宿舍区认证前分配私网IP（如10.0.0.0/16），ACL仅允许访问校内资源（教务系统、图书馆）和Portal服务器，访问内网不触发认证；当学生首次访问互联网时被重定向至Portal页面，认证通过后接入设备发送DHCP NAK强制客户端重新申请业务IP（如202.112.0.0/16），此后即可正常访问外网，实现“内网免费直通、外网按需认证”的精细化控制。

六、两种Portal认证触发方式

认证的第一件事情就是发起认证，有两种认证触发方式：主动认证和重定向认证。

6.1 主动认证

用户通过浏览器主动访问Portal认证网站时，即在浏览器中直接输入Portal服务器的网络地址，然后在显示的网页中输入用户名和密码进行认证，这种开始Portal认证过程的方式即为主动认证，即由用户自己主动访问Portal服务器发起的身份认证。

此外，用户也可运行专用Portal客户端软件（如H3C的iNode），由客户端主动向Portal服务器发送认证请求报文，该方式通常支持二次地址分配、终端安全检测等扩展功能。

6.2 重定向认证

用户输入的访问地址不是Portal认证网站地址时，将被强制访问Portal认证网站（通常称为重定向），从而开始Portal认证过程，这种方式称作重定向认证。

其技术原理是：接入设备拦截未认证用户的HTTP请求（TCP 80端口），构造HTTP 302重定向响应，将用户浏览器自动跳转至Portal服务器地址，并携带用户IP、原始访问URL等参数。该方式用户无需记忆Portal地址，体验友好，是当前主流的触发方式，典型应用如酒店Wi-Fi、商场免费Wi-Fi连接后自动弹出认证页面

七、两种Portal服务形态

• 内置Portal服务器：集成在接入设备内部，轻量级Web认证，适合中小型企业快速部署。代表：华为、华三、锐捷等网络设备（交换机/无线控制器）内置Portal功能。
• 外置Portal服务器：独立服务器部署，支持高并发、个性化页面和复杂认证逻辑（短信、OAuth等），适合运营商、大型园区、公共场所Wi-Fi。代表：华为Agile Controller、H3C iMC、城市热点Dr.COM。

八、两种Portal认证流程

1. 基于Portal协议：Portal服务器与接入设备之间通过Portal协议（UDP 2000）交互，支持CHAP加密认证，安全性高。适用于企业网、运营商WLAN等对安全性要求较高的场景。
2. 基于HTTP/HTTPS协议的Portal重定向：Portal服务器不转发用户凭证，而是通知客户端直接向接入设备发起HTTP/HTTPS认证请求。适用于Portal服务器不支持Portal协议时的兼容对接场景。

8.1 基于Portal协议

1. 接入设备：建立网络连接（二层认证独有）。在二层认证方式下，客户端通过DHCP获取IP地址，接入设备通过ARP学习或DHCP Snooping获取客户端MAC地址，建立IP-MAC绑定表项。此时仅允许访问Portal服务器和免认证地址，其他网络访问被阻断。
2. 客户端：HTTP连接请求。客户端发起HTTP连接请求，分为两种触发场景：
   1. 主动访问：用户直接访问Portal服务器认证页面地址（如 ​​http://1.1.1.1​​），接入设备识别目标为Portal服务器予以放行，直接进入步骤4。
   2. 重定向触发：用户访问其他HTTP网站（如 ​​http://www.baidu.com​​），接入设备判断目标地址非Portal服务器或免认证地址，拦截该请求并进入步骤3。
3. 接入设备：HTTP重定向（仅重定向场景）。接入设备构造HTTP 302重定向响应，Location字段携带Portal服务器地址，返回给客户端。
4. 客户端：请求认证页面。客户端向Portal服务器发起HTTP连接请求，请求Portal认证页面。
5. Portal服务器：返回认证页面。Portal服务器向客户端返回Portal认证页面。
6. 客户端：提交认证请求。用户在Portal认证页面输入用户名和密码后向Portal服务器发起Portal认证请求。
7. Portal服务器：CHAP挑战字请求（PAP方式跳过）。Portal服务器向接入设备发起REQ_CHALLENGE报文。挑战字请求使用的共享密钥通过shared-key命令配置，需确保与Portal服务器保持一致。
8. 接入设备：CHAP挑战字应答（PAP方式跳过）。接入设备向Portal服务器回应ACK_CHALLENGE报文，携带随机生成的16字节Challenge值。
9. Portal服务器：Portal认证请求。Portal服务器将用户名和密码封装在REQ_AUTH报文中发送给接入设备（CHAP方式下密码使用Challenge加密）。
10. 接入设备：RADIUS认证请求。接入设备根据获取的用户名和密码，向RADIUS服务器发送RADIUS认证请求（ACCESS-REQUEST）。
11. RADIUS服务器：RADIUS认证结果。RADIUS服务器对用户名和密码进行认证：成功则返回认证接受报文（ACCESS-ACCEPT），失败则返回认证拒绝报文（ACCESS-REJECT）。认证接受报文中同时包含用户的授权信息（RADIUS合并认证与授权过程）。
12. 接入设备：计费请求。接入设备根据认证结果决定是否接入用户。若允许接入，则向RADIUS服务器发送计费开始请求报文（ACCOUNTING-REQUEST）。
13. RADIUS服务器：计费响应。RADIUS服务器返回计费开始响应报文（ACCOUNTING-RESPONSE），开始计费，并将用户加入自身在线用户列表。
14. 接入设备：Portal认证结果。接入设备向Portal服务器返回ACK_AUTH报文，携带认证结果，并将用户加入自身在线用户列表。
15. Portal服务器：通知认证结果。Portal服务器向客户端发送认证结果报文，通知客户端认证成功，并将用户加入自身在线用户列表。
16. Portal服务器：认证结果确认。Portal服务器向接入设备发送AFF_ACK_AUTH报文，确认认证完成。

8.2 基于HTTP/HTTPS协议

与8.1的相同部分（步骤1-6）：1.建立网络连接（二层独有）→2. HTTP连接请求）→ 3.HTTP重定向 → 4.请求认证页面 → 5.返回认证页面 → 6.portal认证请求。

差异部分（步骤7、8、10）：

7. Portal服务器：通知客户端。Portal服务器不转发凭证，而是通知客户端向接入设备发起认证。例如：①认证页面的表单提交地址直接指向接入设备；②返回302重定向指向接入设备的认证URL。

8.客户端：向接入设备发起认证。客户端通过HTTP POST/GET直接向接入设备发送用户名和密码。

9.接入设备与RADIUS服务器：RADIUS认证与计费交互。接入设备通过解析HTTP请求中的​​username​​、​​password​​等参数获取用户凭证，再与RADIUS服务器完成认证。

10.接入设备：返回认证结果。接入设备直接向客户端返回认证结果（HTTP响应），并将用户加入在线列表。

核心区别：Portal服务器不转发凭证，而是通知客户端直发。仅支持PAP明文传输，用于Portal服务器不支持Portal协议时的兼容对接。

8.3 网元作用总结

1. 接入设备：流量拦截与策略执行。
   1. 拦截未认证HTTP/HTTPS，返回重定向
   2. Portal协议方式：与Portal交互Portal协议，接收转发凭证
   3. HTTP/HTTPS方式：直接接收客户端HTTP认证请求，解析密码
   4. 与RADIUS交互完成认证、计费、ACL下发
   5. 维护用户在线表项
2. Portal服务器：认证门户与调度中心。
   1. 提供Web认证页面
   2. Portal协议方式：转发凭证给接入设备（协议转换）：Portal服务器将HTTP请求中的凭证（用户名/密码）提取出来，封装成Portal协议报文（UDP 2000）发给接入设备。
   3. HTTP/HTTPS方式：通知客户端直发凭证给接入设备（表单指向或302重定向）
   4. 不处理密码校验，向客户端返回结果
3. RADIUS服务器：认证、授权、计费（AAA）。
   1. 校验用户身份
   2. 返回授权信息（VLAN、ACL、带宽等）
   3. 处理计费报文，维护在线用户列表

8.4 为什么需要Portal服务器绕一圈？

Portal认证的核心优势是零客户端——任何能打开浏览器的设备都能使用。但浏览器只能发送HTTP请求，无法直接与接入设备（AC/BAS）交互Portal协议（UDP 2000端口），因此需要Portal服务器作为“翻译官”。

1. 协议转换：接入设备期望收到的是Portal协议报文（UDP端口2000），但浏览器只能发送HTTP请求。Portal服务器将HTTP请求转换为Portal协议报文。
2. 提供认证页面：认证页面（HTML表单）需要独立的Web服务器承载，接入设备不擅长处理TLS证书、会话管理、页面模板等Web业务。

注：通常第三方厂商会将Portal服务器和RADIUS服务器部署为同一台服务器，但这并非标准要求。两者在逻辑上是独立的：Portal服务器负责页面展示和协议转换，RADIUS服务器负责用户身份校验和计费。合并部署只是简化运维的实现方式。

8.5 HTTP/HTTPS重定向重点

HTTP/HTTPS重定向是所有Portal认证流程的基础技术，解决的核心问题：让未认证用户找到Portal服务器。

（1）HTTP重定向

1. 客户端发起HTTP请求（如访问http://www.baidu.com）
2. 接入设备拦截请求，伪装成目标网站与客户端完成TCP三次握手
3. 接入设备返回HTTP 302重定向，Location指向Portal服务器
4. 客户端自动跳转至Portal服务器获取认证页面

若访问域名需DNS解析，设备需放行DNS服务器IP

（2）HTTPS重定向

1. 客户端发起HTTPS请求，接入设备拦截后完成TCP三次握手
2. 接入设备与客户端进行TLS握手，返回自签名证书（非CA颁发）
3. 浏览器验证证书失败，弹出“您的连接不是私密连接”告警
4. 用户需手动点击“继续前往”，TLS握手完成
5. 接入设备返回HTTP 302重定向，客户端跳转至Portal服务器

证书告警无法避免：接入设备无法预知用户访问的原始URL，设备证书无法包含正确域名，也无法购买CA证书覆盖所有可能的目标网站。

九、Portal的配置示例

以华为为例。

9.1 Radius服务配置

# ========== 1. RADIUS配置 ==========
radius-server template test-radius
 radius-server authentication 10.1.1.1 1812    # RADIUS认证服务器IP+端口
 radius-server accounting 10.1.1.1 1813        # RADIUS计费服务器IP+端口
 radius-server shared-key cipher test@123      # 共享密钥，需与RADIUS服务器一致
# ========== 2. AAA配置 ==========
aaa
 authentication-scheme test-auth-scheme
  authentication-mode radius                   # 认证方式为RADIUS
 domain default
  authentication-scheme test-auth-scheme       # 绑定认证方案
  radius-server test-radius                    # 绑定RADIUS模板

9.2 Portal服务配置

# ========== 1. Portal服务器模板 ==========
web-auth-server test-server
 server-ip 10.1.1.1                            # Portal服务器IP
 shared-key cipher test@123                    # 共享密钥，需与Portal服务器一致
 port 50200                                    # Portal协议端口（UDP）
 url http://10.1.1.1:8080/imc                  # Portal认证页面URL
 
# ========== 2. Portal接入模板（关键） ==========
portal-access-profile name test-portal
 web-auth-server test-server direct            # 绑定Portal服务器，direct=二层认证

# ========== 3. 免认证规则（可选） ==========
free-rule-template name test-free
 free-rule 1 destination ip 10.1.1.1 mask 255.255.255.255    # 放行Portal服务器
 free-rule 2 destination ip 8.8.8.8 mask 255.255.255.255     # 放行DNS服务器
 
# ========== 4. 认证模板 ==========
authentication-profile name test-auth
 portal-access-profile test-portal             # 绑定Portal接入模板
 authentication-scheme test-auth-scheme        # 绑定认证方案
 radius-server test-radius                     # 绑定RADIUS模板
 free-rule-template test-free                  # 绑定免认证规则

9.3 接口应用

# ========== 接口应用 ==========
interface Vlanif 100
 authentication-profile test-auth