The story really starts when the WiFi authentication system is online. For the first three months of the network, unexpected conditions will turn up: one reflects Portal's white screen, one complains that the code won't come through, and one finds a lot of failures in the 3-point certification record. The system does not have problems with design, but with fast positioning feed. The system has unique features, it's not just server or network service.Cross-areas of networks and applicationsThe root causes of the failure may be in the AC configuration, in the course of Radius services or in the operator's SMS channel.
The first line of daily transport isMonitoring system developmentThe core indicators of the certification system are as many: the success rate of authentication, average time for certification, number of requests, RADIUS service response times, SMS access rates. These indicators require real-time collection, visualization, and warning thresholds. Certification success rates are less than 95% continuous to exceed five minutes, automatically sending warnings. The average certification period is three seconds longer to trigger the screening process. These thresholds are not brain-tapping but are repeated according to business scenes. The speed of WiFi connectivity is far less tolerated by shop-site users than at campuses, and the ViFi certification page loads more than three seconds before users turn off the page to traffic, so that the market alarm threshold is more sensitive than the campus.
The RADIUS server has a CPU usage rate of 80% or more at its peak, and 90% or more at the lateral level. Memory leakage is a problem that all long-term operations may encounter, with certification systems no exception, and requires attention to long-term trend curves in memory use, stable growth but never falling, probably an internal leakage, which will require upgrade patches or regular reboot services.
The second line is...Account life cycle managementThe WiFi account for campus and enterprise is not static. When a student graduate, the account should be automatically cancelled. If an employee leaves office, the account should be disabled immediately. After one visit, the visitor ' s account should be cleared automatically. These administrative logics are more automated scripts than manual maintenance. The problem with manual management of accounts is not that people make mistakes but forget them. The WiFi account for a three-month staff member is still active in the system, which is a typical cut item in security audits. This is the only way to keep the account running for the check-out process that will be connected to HR or to the academic change process in the teaching system, and to follow the automatic flow of accounts with personnel changes.
The third line is...Fault detection capabilityThe root cause is not only the known faults, but the problems that users have reported cannot be repeated. Users say you are not connected to WiFi and you go up to the field using your own mobile phone, which is much more common in WiFi authentication than expected. The reason is usually the difference on the end side: some of Andre's WebView’s inner version is too low to normally render Portal pages; some laptop’s wireless card drives are compatible, causing 802.1X certification failure; certain security software uses all HTTP redirection as an intermediary attack for interception. The problem of these end-sides is organized into a knowledge base, and the next time they come across the same type of machine, they are more efficient than always being front-loaded.
The error check path requires a standard process. User feedback does not open the authentication page, first lets users check whether an IP address is available or not. If DHCP has been assigned to an automatic configuration address at the beginning of 169.254, it means that DHCP has not obtained the correct IP, the problem is in AP or DHCP servers. If there are normal IPs but no pages open, step two checks if AC's Portal recalibration rules are configured correctly and HTTPS jumps are enabled. HTTPS jumping is inconsistent with technical logic: HTTPS design aims to prevent middlemen from tampering, whereas Portal certification precisely requires intermediaries intercept redirection. The common solution to this contradiction is for AC to enforce the release of a DNS query on an uncertified terminal, parsing a given domain name to the Portal server address and directing any page access by users to the Portal page.
Authentication is passed but not accessible. The root cause is usually incomplete release rules from the RADIFUS server to AC. RADIUS protocols use attribute values to pass parameters, and there are differences in support of properties fields by different manufacturers, such as the mapping of RADIFUS attributes by aAC that is H3Cs. One property field is misspelled, the access strategy that AC solves is empty, and user authentication is successful but still blocked outside the door. In response to this problem, the screening steps were to grab a package on the RADIUS server and see what properties were carried in the certified Access-Accept report, and then to check on AC whether they had been correctly solved and applied.
Performance optimizationThe result of the authentication cache is immediately visible: a terminal breaks WiFi and reconnects it within seconds, if you go straight to the full certification process, a database query plus protocol interaction; if you leave a cache, resources are almost non-consumption. The second direction is Portal page performance and load experience, with the resources working on CDN acceleration, compressed pictures and script sizes, and ensuring that first screens are also done in three seconds under 3G network. The third direction is to optimize the network level, adjust AC certification time-consuming, avoid inefficient semi-connection draining resources, optimize AP's channel distribution and reduce the time-time-over-certification caused by peer interference.
The high-availability structure is the last security for the carrier. A single point failure is unacceptable in the certification system. Radius service has been disabled, and WiFi throughout the region is a major production accident. Radius services require at least two nodes to be deployed, with a switch of main preparation through VRRP or load balance. After the main node is down, all authentication requests are taken over within seconds, with little knowledge of the end side. Databases also need to be copied from the main repository and automatically upgraded from the main warehouse to the main bank after the failure.
The web WiFi authentication system, not the single point of depth, is a dish.Understanding the whole system chainFrom AP to AC, from Radius to Portal, from SMS Channel to database, there is a problem with any link in the chain. The user sees the same result: WiFi cannot connect. The operator is going to follow this link and find that link within the shortest time possible.