企业官网建设流程全解析

1. 从一次会议室断网说起：Portal认证到底在解决什么问题

很多人第一次接触Portal认证，是因为遇到了一个很具体的场景：公司会议室来了访客，对方问WiFi密码，你把密码告诉了他，然后他连上了，但打开浏览器却弹出一个页面，要求输入手机号获取验证码，或者输入一个会议专属的访问码。这个"弹出来的页面"就是Portal，而整个过程就是Portal认证。

Portal认证在WLAN接入认证体系里，属于应用层认证的一种。它和WPA2-PSK这种链路层加密认证最大的区别在于：PSK是在设备接入网络之前就完成身份校验，而Portal是在设备已经获得IP地址、网络层已经通了之后，再通过浏览器重定向的方式做身份确认。换句话说，Portal认证的用户在认证之前，网络层是通的，但应用层的流量被拦截了。

这个特性决定了Portal认证的典型应用场景：酒店、商场、机场、企业访客网络、校园网。这些场景的共同特点是——用户群体不固定、设备类型五花八门、不可能给每个人预配置证书或密码。Portal认证用"浏览器"这个所有设备都有的东西作为认证入口，把兼容性问题降到了最低。

但兼容性好的代价是安全性相对弱。Portal认证本身不加密无线空口，如果业务数据敏感，通常还需要配合WPA2或WPA3做链路层加密，Portal只作为身份认证和权限控制的补充。这一点在后面讲配置的时候会反复提到，因为很多初学者容易把Portal当成"安全认证"的全部，结果配出来的网络谁都能抓包。

我个人的经验是：Portal认证的核心价值不在于"安全"，而在于"可控"。它让你能知道谁在什么时候接入了网络，能对不同的人给不同的权限，能在用户离开后自动清理会话。理解了这一点，后面的配置思路就顺了。

2. Portal认证的三种实现路径：直连、旁路与AC网关模式

在动手配置之前，必须先搞清楚Portal认证的三种主流组网方式。选错了模式，后面怎么调都别扭。这三种模式分别是：直连模式、旁路模式和AC网关模式。它们的核心区别在于Portal服务器相对于无线控制器（AC）的位置，以及流量经过Portal服务器的路径。

2.1 直连模式：Portal服务器串在流量路径上

直连模式下，Portal服务器直接部署在AC和上层网络之间，所有用户流量必须经过Portal服务器。这种模式的好处是控制力最强，Portal服务器能看到所有流量，可以做精细的带宽管理和审计。缺点是Portal服务器成为单点瓶颈，一旦它挂了，整个网络就断了。

直连模式适合用户量不大、但对管控要求极高的场景，比如小型企业的访客网络。配置上，AC需要把Portal服务器的地址配置为"强制Portal服务器"，所有未认证用户的HTTP请求都会被重定向到这台服务器。

2.2 旁路模式：Portal服务器旁挂在核心交换机上

旁路模式是我最推荐新手先上手的方式。Portal服务器不串在流量路径上，而是旁挂在核心交换机或AC的某个端口上。用户流量正常转发，只有未认证用户的HTTP请求会被AC重定向到Portal服务器。Portal服务器处理完认证后，把结果告诉AC，AC再放行该用户的流量。

旁路模式的好处是Portal服务器故障不影响正常转发，只是新用户无法认证而已。已经认证的用户不受影响。这种模式在企业访客网络中非常常见，也是大多数商用Portal服务器的默认部署方式。

2.3 AC网关模式：Portal功能集成在AC内部

AC网关模式是把Portal服务器的功能直接集成在AC上，不需要额外的服务器。这种模式适合预算有限、用户量不大的场景。AC自己就是Portal服务器，自己处理重定向、认证页面推送和权限下发。

但这种模式的缺点也很明显：AC的Portal功能通常比较基础，页面定制能力弱，认证方式有限（一般只支持本地账号或简单的短信验证）。如果需求稍微复杂一点，比如要对接企业微信、要按部门下发不同权限，AC网关模式就力不从心了。

下面这张表把三种模式的关键差异列出来，方便对照选择：

选型的时候，我的建议是：先看用户量，再看管控需求，最后看预算。用户量超过500人，直接上旁路模式；用户量在100人以内且没什么定制需求，AC网关模式够用；只有对审计和带宽管理有硬性要求时，才考虑直连模式。

3. 认证流程拆解：一个HTTP请求的完整旅程

理解了组网模式，接下来要搞清楚Portal认证的完整流程。这部分是很多人的知识盲区——配置命令能敲，但出了问题不知道从哪查。我把一个未认证用户的HTTP请求从发出到最终放行的完整旅程拆成六个阶段，每个阶段都标注了可能出问题的环节。

3.1 阶段一：终端关联与IP获取

用户设备首先通过WPA2-PSK或开放认证关联到AP，然后通过DHCP获取IP地址。这个阶段Portal认证还没介入，但DHCP地址池的配置至关重要。如果地址池配置在AC上，要确保地址池的网关指向AC的对应VLAN接口；如果配置在核心交换机上，要确保AC能透传DHCP报文。

我踩过的一个坑是：地址池配在核心交换机上，但AC上没放行DHCP报文，导致用户拿不到IP，自然也就触发不了Portal重定向。排查的时候用display dhcp server statistics看有没有DHCP请求上来，如果没有，就是中间链路的问题。

3.2 阶段二：首次HTTP请求触发重定向

用户拿到IP后，打开浏览器访问任意HTTP网站。这个HTTP请求到达AC后，AC发现源IP不在已认证用户列表中，于是拦截该请求并返回一个302重定向，把用户浏览器指向Portal服务器的认证页面URL。

这里有个关键细节：只有HTTP请求会被重定向，HTTPS请求不会。因为HTTPS是加密的，AC无法在不解密的情况下插入重定向。所以用户如果直接访问HTTPS网站，浏览器会报证书错误或连接超时，而不是弹出认证页面。这就是为什么很多Portal认证的提示牌上会写"请访问任意HTTP网站"。

3.3 阶段三：Portal页面推送与用户输入

浏览器跳转到Portal服务器后，服务器返回认证页面。用户在这个页面上输入手机号、验证码或访问码，点击提交。Portal服务器收到后，进行本地校验或向第三方认证源（如短信网关、RADIUS服务器）发起校验。

这个阶段最常见的问题是页面加载慢或加载不出来。原因通常是Portal服务器的证书问题（如果用了HTTPS）、DNS解析问题，或者AC和Portal服务器之间的共享密钥配置不一致。

3.4 阶段四：Portal服务器通知AC认证结果

用户校验通过后，Portal服务器需要告诉AC"这个用户可以放行了"。这个通知通过Portal协议完成，通常是REQ_AUTH报文。AC收到后，把用户加入已认证列表，并下发对应的权限（如ACL、VLAN切换、带宽限制）。

这里的关键是共享密钥（Shared Secret）。AC和Portal服务器之间必须配置相同的共享密钥，否则报文会被拒绝。我见过很多次认证失败都是因为密钥多了一个空格或者大小写不一致。

3.5 阶段五：AC放行用户流量

AC收到认证成功通知后，会修改该用户的转发策略。具体来说，就是把用户从"未认证"状态迁移到"已认证"状态，并应用对应的授权策略。如果配置了VLAN切换，用户会被重新分配到业务VLAN；如果配置了ACL，用户的流量会按照ACL规则转发。

这个阶段要注意授权策略的优先级。如果同时配置了VLAN切换和ACL，要确认两者的作用顺序。一般来说，VLAN切换先执行，ACL在切换后的VLAN内生效。

3.6 阶段六：会话保持与超时下线

用户认证成功后，AC会维护一个会话表项。这个表项有空闲超时时间和绝对超时时间两个参数。空闲超时是指用户多长时间没有流量后自动下线；绝对超时是指无论有没有流量，到时间就强制下线。

这两个参数要根据场景设置。酒店场景通常设置空闲超时30分钟、绝对超时24小时；企业访客场景可以设置空闲超时15分钟、绝对超时8小时。设置太短会导致用户频繁重认证，设置太长会导致IP地址池被长期占用。

4. 配置实战：从零搭建一套旁路Portal认证环境

理论讲完了，现在进入实操环节。我以旁路模式为例，完整走一遍配置流程。这套配置基于常见的AC+核心交换机+Portal服务器的组网，适用于大多数企业访客网络场景。

4.1 基础网络配置：VLAN、DHCP与路由

首先在核心交换机上创建两个VLAN：VLAN 100用于用户接入，VLAN 200用于Portal服务器。AC上配置VLAN 100的网关接口，地址为192.168.100.1/24。Portal服务器地址为192.168.200.10/24。

# 核心交换机配置 vlan 100 description User_Access vlan 200 description Portal_Server interface GigabitEthernet0/0/1 port link-type trunk port trunk allow-pass vlan 100 200 # AC上配置VLAN接口 interface Vlanif100 ip address 192.168.100.1 255.255.255.0 # DHCP地址池配置在AC上 dhcp enable ip pool user_pool network 192.168.100.0 mask 255.255.255.0 gateway-list 192.168.100.1 dns-list 114.114.114.114

这里要注意：DHCP的DNS列表一定要配，否则用户拿到IP后无法解析域名，连HTTP请求都发不出去，自然触发不了Portal重定向。我见过有人只配了网关没配DNS，排查了半天以为是Portal配置问题。

4.2 Portal服务器对接配置：共享密钥与URL

在AC上配置Portal服务器的地址和共享密钥。共享密钥要足够复杂，建议用16位以上的随机字符串。

# 配置Portal服务器 web-auth-server portal_server server-ip 192.168.200.10 port 50100 shared-key cipher MyStr0ngSh@reKey2024 url http://192.168.200.10:8080/portal

url字段是Portal认证页面的地址，用户会被重定向到这个地址。这个地址必须是Portal服务器上真实可访问的页面，否则用户会看到404错误。

4.3 认证前域与认证后域配置

AC上需要配置两个域：认证前域和认证后域。认证前域是用户未认证时所在的域，通常只允许访问Portal服务器；认证后域是用户认证成功后所在的域，允许访问业务网络。

# 认证前域 aaa authentication-scheme pre_auth authentication-mode none authorization-scheme pre_authz authorization-mode none domain pre_domain authentication-scheme pre_auth authorization-scheme pre_authz # 认证后域 authentication-scheme post_auth authentication-mode radius authorization-scheme post_authz authorization-mode radius domain post_domain authentication-scheme post_auth authorization-scheme post_authz radius-server template radius_template

认证前域的authentication-mode none表示不做认证，直接放行到Portal服务器。认证后域配置RADIUS模板，用于向RADIUS服务器请求授权。

4.4 认证前域ACL：只放行Portal服务器

认证前域必须配置ACL，只允许用户访问Portal服务器的IP和端口，其他流量全部丢弃。这是Portal认证安全性的关键——如果认证前域不限制，用户不认证也能上网，Portal就形同虚设。

acl number 3000 rule 5 permit ip destination 192.168.200.10 0 rule 10 deny ip # 在认证前域应用ACL domain pre_domain authorization-scheme pre_authz acl 3000

ACL 3000只放行目的地址为192.168.200.10的流量，其他全部拒绝。这样用户未认证时只能访问Portal服务器，无法访问其他任何网络。

4.5 验证与调试：常用命令与排查思路

配置完成后，用以下命令验证：

# 查看Portal服务器状态 display web-auth-server portal_server # 查看在线用户 display access-user # 查看Portal认证统计 display web-auth-server statistics

如果用户无法触发重定向，按以下顺序排查：

1. 确认用户是否拿到IP：display dhcp server ip-in-use
2. 确认AC是否收到HTTP请求：debugging web-auth-server packet
3. 确认Portal服务器是否可达：ping 192.168.200.10
4. 确认共享密钥是否一致：对比AC和Portal服务器配置

我个人的经验是：80%的Portal认证问题出在ACL和共享密钥上。ACL配错了导致用户访问不了Portal服务器，共享密钥不一致导致认证结果无法同步。把这两个点检查一遍，大部分问题都能解决。

5. 那些配置文档不会告诉你的坑

配置文档通常只讲"怎么做"，不讲"为什么这么做"和"做错了会怎样"。这一节我把自己和同行踩过的坑整理出来，每个坑都附上排查思路和修复方法。

5.1 坑一：HTTPS重定向失败导致的"白屏"

用户访问HTTPS网站时，AC无法插入重定向，浏览器会显示连接超时或证书错误。用户看到的是"白屏"或"无法访问此网站"，而不是Portal认证页面。这不是故障，是Portal认证的固有特性。

解决办法有两个：一是在提示牌上明确写"请访问HTTP网站"；二是配置HTTPS重定向功能（部分AC支持），通过中间人方式拦截HTTPS请求。但后者需要AC导入证书，配置复杂且有安全风险，一般不建议。

5.2 坑二：DNS解析失败导致的"重定向死循环"

用户拿到IP后，浏览器访问www.example.com，DNS解析失败，浏览器显示"找不到服务器"。用户以为是网络问题，反复刷新，但始终触发不了Portal重定向。原因是DNS请求本身没有被重定向——AC只重定向HTTP请求，不重定向DNS请求。

解决办法是确保DHCP下发的DNS服务器地址是可达的。如果DNS服务器在认证后才能访问，就需要在认证前域ACL里放行DNS服务器的IP和53端口。这个细节很多配置文档都不会提，但实际部署中非常常见。

5.3 坑三：Portal服务器时间不同步导致的认证失败

Portal协议报文里带有时间戳，如果AC和Portal服务器的系统时间相差超过5分钟，报文会被认为是重放攻击而拒绝。这个坑非常隐蔽，因为配置看起来完全正确，但认证就是失败。

排查方法是登录AC和Portal服务器，用display clock和date命令对比时间。修复方法是配置NTP同步，让两台设备从同一个时间源同步时间。

5.4 坑四：用户量突增导致的地址池耗尽

Portal认证的用户在认证前就会占用一个IP地址。如果地址池太小，用户量突增时会出现"连上了但拿不到IP"的情况。用户看到的现象是"WiFi已连接，但无法访问网络"。

解决办法是地址池要按峰值用户数的1.5倍配置。比如预计峰值500人，地址池至少配750个地址。另外，要合理设置DHCP租约时间，访客网络建议设置为2小时，避免地址被长期占用。

5.5 坑五：ACL顺序错误导致的"认证后仍无法上网"

认证后域的ACL如果配置不当，用户认证成功后仍然无法访问业务网络。常见错误是把deny ip规则放在了permit规则前面，导致所有流量都被拒绝。

ACL的匹配顺序是从上到下逐条匹配，匹配到第一条就执行。所以permit规则必须放在deny规则前面。这个规则在认证前域和认证后域都适用。

6. 从能用 to 好用：Portal认证的进阶优化

基础配置跑通后，还有一些优化手段能让Portal认证从"能用"变成"好用"。这些优化不改变核心流程，但能显著提升用户体验和运维效率。

6.1 无感知认证：让用户只认证一次

无感知认证的原理是：用户首次认证成功后，AC记录用户的MAC地址。后续该设备再次接入时，AC自动识别MAC地址并放行，用户不需要再次输入账号密码。

配置无感知认证需要在AC上开启MAC优先的Portal认证功能，并设置MAC地址的老化时间。老化时间一般设置为7到30天，太短会导致用户频繁重认证，太长会导致MAC地址表膨胀。

但无感知认证有个前提：用户的MAC地址不能随机化。现在很多手机默认开启MAC地址随机化，每次连接WiFi都会用不同的MAC地址，导致无感知认证失效。解决办法是在Portal页面上引导用户关闭MAC随机化，或者接受部分用户需要重复认证。

6.2 短信验证码认证：对接短信网关

短信验证码认证是访客网络最常用的认证方式。用户输入手机号，Portal服务器向短信网关发起请求，网关发送验证码，用户输入验证码完成认证。

对接短信网关的关键是接口协议和频率限制。大多数短信网关提供HTTP API，Portal服务器通过API发送验证码。频率限制要设置合理，一般同一手机号60秒内只能发送一次，同一IP每小时最多发送10次，防止短信轰炸。

6.3 社交媒体认证：扫码即上网

社交媒体认证是让用户通过扫描二维码，授权Portal服务器获取其社交账号信息，从而完成认证。这种方式用户体验好，但需要Portal服务器对接社交平台的开放接口。

配置社交媒体认证的难点在于回调地址的配置。社交平台要求回调地址必须是HTTPS且域名已备案，这对内网部署的Portal服务器是个挑战。通常的做法是在DMZ区部署一台反向代理，把外部请求转发到内网Portal服务器。

6.4 基于时间的权限控制：不同时段不同策略

Portal认证可以结合时间策略，对不同时段认证的用户下发不同的权限。比如工作时间访客只能访问互联网，非工作时间可以访问内部服务器；或者白天限速2Mbps，晚上限速10Mbps。

配置时间策略需要在AC上配置时间范围（Time Range），然后在授权策略里引用。时间范围的匹配精度通常是分钟级，足够满足大多数场景。

7. 排查工具箱：当Portal认证出问题时先看什么

最后分享一套我常用的排查流程。这套流程覆盖了从终端到服务器的全链路，按顺序排查能快速定位问题。

7.1 终端侧检查：IP、DNS与浏览器

第一步永远是从终端开始。让用户打开命令行，执行ipconfig /all（Windows）或ifconfig（Mac/Linux），确认三件事：是否拿到IP、网关是否正确、DNS是否配置。

如果IP是169.254开头的，说明DHCP失败，问题在DHCP服务器或中间链路。如果IP正确但DNS为空，说明DHCP地址池没配DNS。如果都正确，让用户访问一个HTTP网站（如http://neverssl.com），看是否弹出认证页面。

7.2 AC侧检查：在线用户与Portal统计

登录AC，执行display access-user查看在线用户列表。如果用户不在列表里，说明认证没成功。执行display web-auth-server statistics查看Portal报文的收发统计，如果REQ_AUTH报文有发送但没有ACK_AUTH回复，说明Portal服务器没响应或共享密钥不一致。

7.3 Portal服务器侧检查：日志与认证记录

登录Portal服务器，查看认证日志。大多数Portal服务器会记录每次认证的详细信息，包括用户IP、MAC、认证时间、认证结果。如果日志显示"认证成功"但AC没放行，说明Portal服务器和AC之间的通信有问题。

7.4 抓包分析：最后的杀手锏

如果以上步骤都查不出问题，就需要抓包了。在AC的上行口抓包，过滤Portal协议端口（通常是50100），看REQ_AUTH和ACK_AUTH报文的交互过程。如果REQ_AUTH发出去了但没有ACK_AUTH回来，检查Portal服务器是否收到；如果收到了但没回复，检查Portal服务器的处理逻辑。

抓包工具推荐用AC自带的抓包功能，或者用镜像端口配合Wireshark。抓包时要注意过滤条件要精确，否则报文太多看不过来。

这套排查流程我用了很多年，基本上能在30分钟内定位90%的Portal认证问题。剩下的10%通常是厂商实现差异或版本bug，需要联系厂商支持。

我个人在实际操作中的体会是：Portal认证的配置本身不难，难的是理解每个配置项背后的意图。知道了"为什么要配这个ACL"、"为什么要设这个超时时间"，排查问题时就能快速缩小范围。希望这篇内容能帮你少走一些弯路。