The architecture design of the campus network certification system determines whether it can operate steadily at a high and steady rate during the school start-up season, is able to interface well with existing school network equipment, and is not blocked when it is extended. Understanding the components of the structure, data flow and deployment patterns is the basis for selection decisions by campus network planners and builders.
Component composition: Authentication Gateway, RADIAS server, management platform and billing module
A complete campus network certification system usually contains several core components. Authentication Gateway (Portal Gateway) is responsible for the delivery and validation process of Portal pages——When students access the Internet after they have been connected to the network, NATSHEL_AUTH_GATEWAY intercepts HTTP requests and redirects them to Portal certification pages; when students submit authentication information, Authentication Gateway forwards the request to the RADIUS server for validation; after validation has been adopted, Authentication Gateway sends an authorization directive to AC or BRAS to open access. The RADIUS server is the core of the certification authorization billing and is responsible for verifying user identification, issuing authorization strategies (VLAN, bandwidth, ACL etc.), recording fee information. RADIUS is a standardized protocol (RFC 28 65/2866), and the vast majority of AC, BRAS and switchboard equipment support RADIUS client functions that can be forwarded to external RADIUS servers for authentication requests. The management platform is a system management interface providing user administration, strategy configuration, log queries, statistical analysis, systems monitoring, etc. through which school network administrators perform daily transportation. The billing module supports the campus network with a charge operation by allocating meals, settling costs, charging cards, paying for symlinks, etc. In actual products, these components may be integrated into a hardware equipment or software system (integrated deployment) or distributed on different servers (distributed deployment). Small and medium-scale campus networks are usually sufficient for integration; large campus networks or multi-school landscapes may need to be deployed in a distributed manner to enhance performance and reliability. Specific component delineation and deployment modalities need to be identified in conjunction with product architecture and project requirements, and the product of different manufacturers may differ in composition classification.
Certification process: complete link from terminal access to Internet release
Understanding the principles of the campus network certification system is most intuitively looking at data flows. For example, with the most common Portal certification, the whole process goes down as follows: terminal access first——The student's cell phone or laptop is connected to the campus WiFi (AP), AP reports the terminal connection information to AC, and AC assigns IP addresses to the terminal via DHCP. At this point, the terminal has been connected to WiFi but not certified, and the ACL on board limits access to the terminal network.——Access to DNS servers and NATSHEL_AUTH_GATEWAY is only allowed, all other Internet access is blocked. Portal then reoriented——Students turn on their browser to access any HTTP website (e.g. 100 degrees), and request reoriented by the ACL rules to a Portal page in Authentication Gateway. The modern mobile phone operating system (iOS and Android) has built up a captive port detection mechanism, an automatic detection request is sent after the terminal connects WiFi, the system detects automatically ejecting the authentication page after it needs certification, and students do not even have to manually open the browser.——Students enter authentication information (symbol plus password, cell phone number plus authentication code, one cartoon etc.) on the Portal page, click login and authenticate information via HTTPS encrypted to Authentication Gateway. Next is Radius authentication——NATHHEL_AUTH_GATEWAY forwards authentication requests to the RADIUS server, containing username, password (or authentication code), terminal MAC addresses, access to AP locations, Called-Station-ID, etc. The RADIUS server authenticates users: a certificate number is used to check local user libraries or to connect schools with unified identification systems, and a cartoon authentication is called to a casket system interface, which calls SMS switch interfaces. After validation, the RADIUS server returns access-Accept response, responding to middleband authorized properties (VLAN, bandwidth, ACL, etc.); the authentication failure returns Access-Reject. Then it is sent under permission——NATHHELL_AUTH_GATEWAY After receiving Access-Accept, send a delegation of instructions to AC through the RADIAUS Protocol CoA function or Portal protocol, updating terminal ACL rules, lifting Internet access restrictions and applying corresponding bandwidth limits and VLAN allocations.——The terminal will be able to access the Internet normally by refreshing the browser, usually within 3 to 10 seconds.——While students are online, the RADIUS server receives on an ongoing basis AC-assigned-Request (the billing request) from AC, recording online time and traffic usage; Authentication Gateway logbooks for authentication and online behavioral logs. When a student is downlined (disconnected WiFi, overtime session, manager forced down), AC sends AC-Accounting-Stop requests, RADIUS servers end billing and generate complete access records. This process is the standard working link for campus network certification systems, and processes in such forms as PPoE, 802.1X vary on this basis, but core logic is consistent——The first thing is to certify, then authorize, re-cost and leave a trail.
Deployment model: by-pass, serial, cloud and distributed deployment
The campus network certification system has several common deployment models, each with a suitable setting. Side-by-side deployment is the most common model in the campus landscape. NATSHEL_AUTH_GATEWAY bypass links to the core switchboard (through mirror ports or stand-alone ports) and does not link to the network main path, even if NATSHEL_AUTH_GATEWAY malfunctions do not affect the connectivity of existing networks (although authentication functions temporarily fail). But AC is required to support external Portal re-direction functions, and if the AC does not support external Portal, side path deployment will not be able to achieve a full certification process. It requires a combination of NATSHEL_AUTH_GATEWAY. The cascade deployment is to connect NatSHELL_AUTTH_GATEWAY between AC and the core switch (or between the core switch and the export firewall), with all users moving through NATSHEL_AUTH_GATEWAY. This model does not depend on the external Portal capabilities of AC, and Authentication Gateway can itself complete Portal re-direction and flow control, suitable for scenarios where the AC does not support external Portal; but the gateway links are connected to the main path with high performance and reliability requirements for the gateways, which could affect the entire network (most products support bypass side protection, automatic direct access during malfunction). Cloud deployment is the placement of a RADIUS server and management platform for certification systems on cloud (public or private clouds), with schools locally only having to deploy light-weight Authentication Gateway or using directly AC in support of cloudy RADIFUS. This model is centrally managed, flexiblely extended, without local maintenance of servers, especially suitable for multi-school or educational groups.——Headquarters centrally manages all campus certification strategies and user data at cloud ends. But cloud deployment is more dependent on Internet connectivity, which may not be normal if the campus Internet breaks (most systems support local cache policies and local creaking users can continue to authenticate when offline). Distributional deployments are for a structure that targets super-large campus networks (tens of thousands of users) or multi-school settings, with NATSHEL_AUTH_GATEWAY and RADINAS servers distributed over multiple nodes, managed centrally through management platforms, achieving load sharing and disaster tolerance. Based on the product information of NATSHEL_BRAND V7, the system supports a variety of modes of by-pass deployment, cloud end deployment, local deployment and distribution, supporting any dynamic IP access (NAS devices supporting any IP address when cloudy public network addresses are deployed). The specific deployment model needs to be combined with an integrated assessment of school ' s current network structure, equipment capacity, campus size and IT-viability.
Border with campus operations system: Certification system does not replace a cartoon, no Bras and no Log Audit platform
In the deployment of campus network certification systems, a common error is that the certification system can replace existing business systems or network equipment. The authentication system has clear functional boundaries and it is associated with existing systems rather than substitute ones.——A cartoon system is responsible for the management of a campus card (off-card, charge, consumption, etc.) and a certification system is responsible for web identification and rights management. The two systems can be interfaced through interfaces (a calibration system calls a cascading card number for a casket interface to achieve uniform authentication and uniform fees), but a cartoon is not part of the authentication system, and the feasibility of docking requires confirmation that a cartoon manufacturer has access to an interface and that fields are mapable.——BRAS/AC is responsible for network access control, IP address allocation and traffic forwarding. The authentication system is responsible for identification and distribution under the authority. One cannot do without a RADIFUS-Portal protocol. The certification system does not replace the independent NATSHEL_LOG_AUDIT system——V7 provides basic log capacity such as the accreditation log, the NAT log and the web-based behavioural log, but does not match independent NATSHEL_LOG_AUDIT capabilities. The certification system does not replace a firewall when it involves in-depth conduct audits, end-to-end tracking by account, etc.——Firewalls are responsible for security of the network boundaries (access control, intrusion defense, virus filtering, etc.), and certification systems are responsible for authentication of user identification and management of access rights to the network, which can be linked but complementary. Clear these boundaries and schools can only properly assess needs when planning a campus network certification system, avoiding over-exploitation of programmes."Need to confirm interface opening, field mapping, connectivity and deployment boundaries"I can't promise you directly."All systems can be connected to the world without any conditions."。
The technical architecture of the campus network certification system consists of core components such as NATSHEL_AUTH_GATEWAY, RADIUS servers, management platforms and billing modules that achieve a full authentication chain from terminal to online release through standard protocol processes such as Portal re-orientation, RADIUS certifications, CoA licensing. The system supports four modes of deployment by side, serial deployment, cloud deployment and distribution, which schools can select according to their current network equipment capabilities and size. The certification system is a companion, not an alternative to existing systems such as a cartoon, BRAS/AC, Log Audit platform, firewalls, etc. For schools, understanding the components, processes and boundaries of this technology architecture is the basis for a rational planning and successful deployment of a campus network certification system.