Portal计费系统怎么和现有认证网关对接

很多单位在上一套Portal计费系统之前，网络里早就跑着一套认证网关了。可能是园区交换机上的802.1X，可能是出口路由器上的PPPoE，也可能是运营商给的IPoE专线。这时候再上Portal，最怕的不是功能做不出来，而是两套认证叠加在一起，用户连上网要先过一道关再被弹一次登录页，计费口径还前后对不上。对接的本质，是把接入控制、身份认证、计费三个职责重新分配，而不是把两个盒子简单拼起来。

先说旁挂和串接两种拓扑

旁挂是最常见的做法。认证网关继续管接入，Portal计费系统只负责Web认证弹窗和时长流量计费。用户数据包先到网关，网关发现这个终端还没认证，就把它的HTTP请求重定向到Portal页面，用户在Portal上登录，Portal再通知网关放行。这种结构改动小，适合已有网络不想大动的情况。串接则是Portal计费同时承担认证和放行，网关退化为纯转发设备，适合新建网络从头规划。

两种拓扑没有绝对好坏。老网络怕震荡就旁挂，新网络图清爽就串接。真正要命的是拓扑选完之后，谁说了算这件事没定义清楚。见过一个项目，网关和Portal各管各的会话表，用户掉线后网关已经放行了，Portal还在计费，月底对账发现同一台手机被收了两次钱，投诉直接打到运维主管那里。

会话同步才是真正的难点

认证网关和Portal系统背后是两套会话表。用户上线、掉线、IP变化、超时，这四种状态两边必须对齐。常规做法是在Portal认证成功后，下发一个带有效期的token给网关，网关以token的存在和有效期作为放行的唯一依据，计费系统则按token的时长或流量结算。这里的关键词是单一事实来源，token以谁的为准，谁就掌握计费口径。

很多项目在这里栽跟头，是因为网关的会话超时和Portal的计费周期设成了两个值。网关三十分钟踢一次人，Portal按一小时计费，用户被踢掉重连又产生新会话，后台就出现孤儿账单。对接时这两个值必须同源，或者让Portal通过接口实时感知网关的会话销毁事件，而不是各自独立计时。

URL重定向别让两个系统打架

网关自带的强制Portal（captive portal）和计费系统的Portal页面，经常抢同一个重定向入口。用户连上WiFi，先被网关弹一个简单登录页，登录完又被计费系统弹一个，体验非常割裂。正确做法是统一到一个入口：要么关掉网关自带的Portal只留计费系统的，要么让网关把未认证流量全部导给计费系统的Portal，由它做唯一的认证界面。

还有个隐蔽问题，是HTTPS站点的拦截。现在大部分流量都是加密的，网关想弹Portal页，得处理证书和SNI。有些老网关对HTTPS的重定向做得粗糙，会导致用户打开App时弹不出登录页，只在浏览器里能看到。对接前要实测微信、抖音这类App的首屏联网行为，确认Portal能正确触发。

双认证是项目里最容易踩的坑

用户连WiFi先走802.1X输一遍账号密码，连上了又被Portal弹出来再输一遍，这种双认证在项目早期特别常见。体验差是一方面，更麻烦的是计费口径乱：802.1X那层算不算钱，Portal这层算不算钱，两套账号体系怎么对应。解决思路是明确分工，802.1X只做网络接入的身份核验，Portal做合规实名和计费；或者反过来，Portal做唯一认证，802.1X退化为免认证接入。

掉线重连要能延续会话

手机锁屏、笔记本休眠，都是短暂的断网，重连后如果用户被要求重新登录，体验会非常差，计费也会断成一截一截的。靠token续期能解决这个问题：终端重连时带上之前的token，网关和Portal校验有效就恢复旧会话，计费连续累计。这个机制要在对接阶段就约定好，否则后期加设备也补不回来。

对接不是把两个系统拼到一起，是把认证、计费、放行三种职责重新分配清楚。前期把拓扑选型和会话同步想明白，比后期堆设备、加带宽都省钱。很多单位卡在Portal计费上不去，根子不在产品不行，在于没人先回答那个最朴素的问题：这套网络里，到底谁在管用户，谁在收钱。

灰度切换比一次性割接稳

老网关不能停，Portal上线时建议先灰度，挑一栋楼或者一个SSID先走新链路，观察会话同步和计费对账无误再全量切换。一次性割接风险太高，一旦会话同步有漏洞，全网上不了网就是事故。灰度期间两套系统并存，计费口径要以Portal为准，老网关自带的计费先关掉，避免出现双账单让财务无从对账。

等Portal在新链路稳定跑上一周，再把老网关的认证职责逐步收回，最后老网关退化为纯转发。这个节奏看起来慢，但每一步都有回退余地。见过不少项目为了赶工期直接全量割接，结果半夜被计费异常叫醒，反而比灰度多花了三倍时间。

对接完成不是终点。建议输出一份拓扑图和会话同步说明文档，把谁管认证、谁管放行、token有效期怎么设、故障怎么回退都写清楚，留给运维和后来的同事。很多单位Portal跑得好好的，换个人接手就出问题，根子就是对接时的决策没有沉淀成文档，全在当初那个工程师的脑子里。