某局点mac-portal无感知在第三次无线接入后无法上网问题

V7 AC旁挂核心，FIT AP本地转发（AP数量比较少，不到20台，终端数量也不多），服务模板为：远程mac-portal无感知，对接第三方深信服认证服务器

无

(1) 终端连接mac-portal无感知服务模板，首次portal认证能正常通过，通过后AC上有对应的portal表项，服务器侧也有，能正常上网；

(2) 终端断开wifi后，再次连接会自动触发mac无感知认证，AC上能正常创建mac表项，服务器侧也有对应无感知表项；

(3) 第二次断开wifi后，终端再次连接wifi后，此时AC上仍然有该终端的portal和mac表项，但是终端无法上网（无法打开网页，无法ping通百度），并且不会自动弹出portal认证的页面。

1. 首先对照官网mac-portal无感知认证官网典配资料：https://www.h3c.com/cn/d_202312/2005904_30005_0.htm，比如现场的配置发现没有什么异常；

2. 由于现场AC版本比较老且是本地转发（比较老的版本没有默认开启：portal host-check enable），查看是否配置了portal host-check enable，发现是正确配置了的；

3. 查看AC上该mac-portal服务模板对应的mac和portal认证域是否配置了idle-cut，且时间在无线终端业务DHCP租期的1/3~1/2。发现mac认证域下没有配置idle-cut，而portal认证域下配置的idle-cut时间参数是最短的1 min，这个比较奇怪。于是让现场把mac和portal认证域下的idle-cut时间调整为无线终端业务DHCP租期的1/3~1/2，测试发现故障现象还是相同的；

4. 让现场复现测试故障并观察了复现过程AC上portal表项和mac认证表项是否异常（即：vlan，IP地址，用户名等是否有差错），通过如下命令：

<AC> display portal user username xxx

<AC> display portal user ip X.X.X.X

<AC> display mac-authentication connection user-mac xxx

发现同样没有异常。

5. 让现场再次复现故障，并且在AC上开启如下debug收集，收集过程为：

首先在AC上通过：display wlan client mac-address H-H-H 查看对应的认证终端的client表项是否存在？是否正确属于正确的vlan且是否正确获取了IP地址？
    然后在AC上输入如下两个命令查看AC上复现认证故障前的portal报文和radius报文计数：
    <AC> display portal packet statistics
    <AC> display radius statistics
    
    然后在AC上开启如下debug信息
    <AC> debug portal error
    <AC> debug portal event
    <AC> debug portal packet
    <AC> debug radius all 
    <AC> debug radius error
    [AC] info en
    <AC> t m
    <AC> t d
    完成debug开启后，使用测试终端连接无线，并尝试进行portal认证，截屏记录portal认证报错页面。
    收集完所有debug之后，AC上配置如下命令关闭所有debug收集：
    <AC> u d a
    <AC> u t m
    <AC> u t d

    最后在AC上输入如下两个命令查看AC上复现认证故障后的portal报文和radius报文计数：
    <AC> display portal packet statistics
    <AC> display radius statistics

根据debug记录的信息发现整个过程的认证交互完全没有问题，只是第三次终端再次连接wifi的时候，由于AC上已经存在portal表项和mac表项了（如果portal表项已经老化了但是mac表项还存在机制是一样的），因此只有终端上线（即无线关联过程），而没有AC和服务器的认证交互。

因此怀疑是否无线本身没有任何问题，而是认证服务器和出口安全设备有什么联动，终端每次关联无线后出口设备会新建会话，而新建这个会话后要求AC必须给服务器发送Radius报文（计费开始或更新）才能让出口安全设备放通无线终端此次会话对外网地址或域名的访问。

基于这个怀疑，首先让无线终端再次进行到第三次连接的状态，即此时终端无法上网或打开网页，并给终端（该终端是手机，可以安装cloudnet APP进行ping包测试）ping 内网没有AC上portal free-rule放通的IP地址，发现是可以ping通过的，但与此同时ping外网不通。这证明了AC和AP是没有由于mac或portal认证的原因拦截，也证明AC上的mac-portal无感知机制是没问题的。因此终端到外网不通可能是由于出口设备拦截导致的。

因为现场采用本地转发模式，因此建议其在连接AP的POE交换机下行口进行端口镜像抓包，或者交换机的流统看终端报文在哪里被拦截了，但是现场客户反馈其出口防火墙确实是有如上面红字所说的机制，这就印证了我们的判断，即终端每次重新关联无线后，出口设备都会新建一个会话，而这个会话建立后要求AC必须给服务器发送计费开始或更新的Radius报文后，会话才会放通终端对外网的访问。

由于现场没法更改出口安全设备的策略，因此提出终端每次重新关联无线后（这包括了终端断开wifi后再连接，以及终端的漫游切换AP或radio）都需要AC重新发送计费开始或更新报文。

为了实现这个要求，首先考虑了无线服务模板下默认开启的client-security accounting-start trigger ipv4这个机制，但是这个需要终端每次重新关联后IP地址都要改变（终端重新拿地址）才会触发AC重新发送计费更新，但是由于DHCP Server的限制这个是无法实现的。

因此只能让终端每次重新关联后都要重新进行portal认证或mac无感知认证，这样认证过程AC一定会和服务器交互Radius认证和计费报文，就能联动出口防火墙设备。

由于现场使用的是mac-portal无感知的认证方式，这种认证方式的特点是终端经过第一次portal认证上线后，第二次连接wifi时无论AC上是否有这个终端的portal表项，只要没有其mac表项就都要进行一次mac认证，因此只要终端下线或漫游漫出时清掉AC上的mac表项即可，

由于我司AC上无线终端mac认证表项是与client cache表项联动的，因此在服务模板下增加了：client cache-aging time 0，这个问题就得到了解决。

【注意】但是值得注意的是，这种方法会导致终端每次重连wifi（包括漫游）都要触发AC和服务器的Radius认证交互，这对于AP和终端数量很多且漫游频繁的场景来说，会给服务器造成很大的负担，好在这个局点AP和终端数量不多，也主要以办公为主。而更好的方法还是修改出口安全设备的机制，让其对终端对外网访问的放通更加合理一些。

在服务模板下增加了：client cache-aging time 0，让无线终端每次重新关联wifi必然触发mac认证。