跳至主要内容

如何为WiFi认证设置RADIUS服务器

本权威指南为IT领导者和网络架构师提供了部署RADIUS服务器进行企业WiFi认证的全面蓝图。涵盖了本地部署与云托管部署之间的架构权衡、EAP方法选择、Active Directory集成以及动态VLAN分配。场馆运营商和IT团队将找到可行的实施步骤、真实案例研究和风险缓解策略,以便在本季度从不安全的PSK环境过渡到强大的802.1X基础设施。

📖 8 分钟阅读📝 1,860 🔧 2 应用实例3 练习题📚 9 关键定义

收听本指南

查看播客转录
欢迎收听Purple的技术简报。今天我们要解决任何企业IT领导者都面临的关键基础设施决策:如何为WiFi认证设置RADIUS服务器。如果您正在管理一个大规模部署——无论是连锁酒店、零售网络还是庞大的大学校园——依赖简单的预共享密钥是一个重大的安全风险。我们需要802.1X,这意味着我们需要RADIUS。 让我们从背景开始。RADIUS,即远程认证拨入用户服务,充当网络的守门人。当设备尝试连接到WiFi接入点时,接入点充当认证者,将凭据转发给RADIUS服务器。服务器根据目录——如Active Directory或LDAP数据库——检查这些凭据,然后返回接受或拒绝消息。它是企业WiFi安全的基础,也是允许您大规模执行精细访问策略的机制。 现在让我们进入技术深度剖析。您将面临的第一个主要架构决策是选择本地RADIUS服务器还是云托管解决方案。过去,像Microsoft的网络策略服务器(NPS)或开源的FreeRADIUS这样的本地解决方案是标准。它们提供了对基础设施的完全控制,并且不依赖外部互联网连接进行认证。然而,它们需要专用硬件、持续维护和手动配置冗余。如果您有一个数据中心和一个人员配备齐全的IT团队,这是一种完全可行的方法。 另一方面,云端RADIUS解决方案越来越受欢迎,特别是对于零售连锁店或酒店场所等分布式环境。云端RADIUS完全抽象了硬件管理,提供内置的高可用性,并与Azure Active Directory或Okta等云身份提供商无缝集成。代价是认证需要可靠的互联网连接,并且有持续的订阅成本。对于一个运营着五十或一百个地点的场馆运营商,不在每个站点部署和维护本地服务器所带来的运营节省几乎肯定会超过该成本。 在部署RADIUS时,可扩展认证协议——EAP——是关键部分。它定义了客户端和服务器如何协商并执行认证。EAP-TLS是安全性的黄金标准,因为它在客户端和服务器上都使用数字证书,完全消除了密码的需要。这意味着即使攻击者捕获了认证交换,也没有可窃取的凭据。然而,部署客户端证书可能会带来沉重的管理负担。您需要一个公钥基础设施和一个MDM解决方案来将证书推送到每台设备。 PEAP-MSCHAPv2是最常见的替代方案。它使用服务器端证书建立加密的TLS隧道,用户在其中使用用户名和密码进行认证。这比EAP-TLS更容易部署,因为您只需要管理一个证书——服务器的证书。然而,这一点至关重要——如果客户端没有被严格配置为验证服务器的证书,它们就容易受到流氓接入点的攻击。攻击者可以搭建一个虚假的接入点,提供伪造的证书,并捕获凭据。这不是理论上的攻击。这是一个有据可查的现实威胁。 让我们谈谈实施建议和陷阱。第一个建议是在每台客户端设备上强制进行严格的证书验证。对Windows设备使用组策略对象,对macOS和移动设备使用MDM配置文件——无论是Intune、Jamf还是其他解决方案。配置文件必须准确指定要信任哪个证书颁发机构以及预期的服务器名称是什么。不要将此留给最终用户手动配置。 第二个建议是实施动态VLAN分配。与其将所有已认证的用户放在同一个扁平网络中,不如配置RADIUS服务器根据用户在目录中的组成员资格,指示接入点将用户放置到特定的VLAN上。这对于将企业设备与BYOD或宾客设备分段至关重要。财务团队的一名员工应该与当天来访的承包商位于不同的网络段上。 第三个建议涉及宾客访问。对于需要为访客提供WiFi的场馆——酒店、零售店、会议中心——将您的RADIUS基础设施与像Purple的Guest WiFi平台这样的Captive Portal解决方案集成是一个强大的组合。员工和企业设备通过802.1X静默认证,而宾客被引导到品牌化的门户进行认证。Purple的平台然后捕获第一方数据并提供访客行为分析,将您的网络从成本中心转变为商业智能资产。 现在是快问快答环节。第一个问题:我需要为RADIUS使用专用服务器吗?对于本地部署,是的,强烈建议在专用虚拟机上运行它,而不是与域控制器共享资源。认证是一个对延迟敏感的操作,资源争用可能导致间歇性故障,这些故障很难诊断。第二个问题:RADIUS能否处理打印机或物联网传感器等无头设备的认证?可以,通过MAC认证绕过(MAB)。这允许没有802.1X能力的设备基于其MAC地址进行认证。然而,由于MAC地址很容易被伪造,通过MAB认证的设备应始终放置在高度受限的VLAN上。第三个问题:如何处理RADIUS服务器冗余?始终部署至少两个RADIUS服务器——一个主服务器和一个辅助服务器。配置所有接入点,在主服务器不可达时自动故障转移到辅助服务器。对于云端RADIUS,这种冗余通常由提供商内置并管理。 总结一下今天简报的关键要点。预共享密钥不适用于企业WiFi。实施802.1X。根据您的IT资源、管理的地点数量以及现有的身份基础设施,选择部署模式——本地或云端。如果您是分布式且云优先的,云端RADIUS几乎肯定是正确答案。在客户端强制进行严格的证书验证。这是不可协商的。使用动态VLAN分配对网络进行分段。最后,考虑您的认证基础设施如何与更广泛的平台集成,以提供超越简单访问控制的业务价值。 进一步阅读,我们建议探索Purple关于配置802.1X WiFi认证以及使用强大的DNS策略保护网络的指南。谢谢收听。

header_image.png

Executive Summary

For enterprise environments — whether a sprawling university campus, a high-density stadium, or a distributed retail chain — relying on a Pre-Shared Key (PSK) for WiFi access is a significant security liability. A single compromised credential exposes the entire network, and revoking access requires changing the password for every device on the estate. Implementing 802.1X authentication via a RADIUS (Remote Authentication Dial-In User Service) server eliminates this problem entirely: each user authenticates individually, access can be revoked instantly, and network segmentation is enforced dynamically.

This guide provides a definitive roadmap for IT managers and network architects to deploy RADIUS authentication. We cover the architectural trade-offs between on-premise and cloud-hosted deployments, the configuration of Extensible Authentication Protocol (EAP) methods, and the integration with directory services like Active Directory. We also demonstrate how a robust authentication layer integrates with Guest WiFi solutions to provide seamless access for visitors, while capturing the WiFi Analytics that turn your network into a business intelligence asset.


Technical Deep-Dive

The 802.1X Architecture

The IEEE 802.1X standard defines port-based Network Access Control (PNAC). In a wireless context, it involves three primary roles working in concert:

Role Component Responsibility
Supplicant Client device (laptop, smartphone) Presents credentials to request network access
Authenticator WiFi Access Point or Controller Enforces access control; relays EAP messages
Authentication Server RADIUS Server Validates credentials; returns accept/reject and policy attributes

When a supplicant associates with an access point, the AP blocks all data traffic except EAP (Extensible Authentication Protocol) messages. The AP encapsulates these EAP messages in RADIUS packets and forwards them to the RADIUS server. The server verifies the credentials against a backend database — typically LDAP or Active Directory — and returns an Access-Accept or Access-Reject message. If accepted, the AP unblocks the port and the client's traffic flows freely.

architecture_overview.png

Choosing an EAP Method

The security of your RADIUS deployment depends heavily on the EAP method selected. The two most prevalent in enterprise deployments are:

EAP-TLS (Transport Layer Security) is the gold standard. It requires digital certificates on both the RADIUS server and every client device, eliminating passwords entirely. Even if an attacker captures the full authentication exchange, there are no credentials to extract. The trade-off is administrative overhead: deploying and managing client certificates requires a functioning Public Key Infrastructure (PKI) and an MDM solution (e.g., Microsoft Intune, Jamf) to distribute certificates to endpoints.

PEAP-MSCHAPv2 (Protected EAP) is the most widely deployed method in practice. It uses a server-side certificate to establish an encrypted TLS tunnel, inside which the client authenticates with a username and password. This is significantly easier to deploy than EAP-TLS because only one certificate — the server's — needs to be managed. However, it carries a critical caveat: if client devices are not explicitly configured to validate the RADIUS server's certificate, they are vulnerable to Man-in-the-Middle (MitM) attacks via rogue access points.

> Critical Security Note: Failing to enforce strict certificate validation on client devices effectively nullifies the security benefits of PEAP-MSCHAPv2. An attacker can deploy a rogue AP, present a fraudulent certificate, and capture user credentials in plaintext. This is not a theoretical risk — it is a well-documented attack vector that has been exploited in real-world environments.


Implementation Guide

Step 1: Architectural Decision — On-Premise vs. Cloud RADIUS

The first decision is where to host the RADIUS infrastructure. This is primarily an operational and cost question, not a security one — both models can be deployed securely.

comparison_chart.png

On-Premise RADIUS (e.g., Microsoft NPS, FreeRADIUS, Cisco ISE) is suited for organisations with dedicated IT staff, existing on-premise directory infrastructure, and stringent data sovereignty or compliance requirements. It does not depend on internet connectivity for authentication, which is a meaningful advantage for environments where internet uptime cannot be guaranteed.

Cloud RADIUS is increasingly the preferred model for distributed environments — Retail chains, Hospitality groups, and Transport hubs where deploying servers at every location is operationally impractical. Cloud RADIUS integrates natively with cloud identity providers (Azure AD, Google Workspace, Okta) and provides built-in high availability and global scalability.

Step 2: Install and Configure the RADIUS Server

For an on-premise deployment using Microsoft NPS (the most common choice in Windows-centric environments):

  1. Install the Network Policy Server role via Server Manager.
  2. Register the NPS server in Active Directory to allow it to read user dial-in properties.
  3. Create a RADIUS Client entry for each access point or wireless controller, specifying the AP's IP address and a strong, unique Shared Secret.
  4. Configure a Network Policy defining the conditions (e.g., user group membership) and constraints (e.g., EAP method, session timeout) for access.
  5. Configure the Connection Request Policy to process requests locally.

For FreeRADIUS on Linux:

  1. Install via package manager: sudo apt-get install freeradius freeradius-ldap.
  2. Configure /etc/freeradius/3.0/clients.conf to define RADIUS clients (APs) and their shared secrets.
  3. Configure the LDAP module in /etc/freeradius/3.0/mods-available/ldap to point to your Active Directory or LDAP server.
  4. Enable the LDAP module: sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/.
  5. Define EAP methods in /etc/freeradius/3.0/mods-available/eap.

Step 3: Configure Access Points

On your wireless controller or individual access points:

  1. Define the RADIUS server IP address(es) and authentication port (default: UDP 1812).
  2. Configure the Shared Secret — use a minimum of 22 characters, mixing alphanumeric and special characters. Use a unique secret per location or AP group.
  3. Configure the SSID to use WPA2-Enterprise or WPA3-Enterprise security mode with 802.1X key management.
  4. Configure a secondary RADIUS server for failover.

Step 4: Directory Integration

For on-premise AD integration, the RADIUS server must be joined to the domain or have LDAP read access. Ensure service accounts used for LDAP binding have the minimum required permissions. For cloud RADIUS, configure the API-based synchronization or SAML/OIDC integration with your IdP.

Define clear user groups in your directory, as these will drive authorization policies. Recommended group structure:

Group VLAN Access Level
Corp_Staff VLAN 10 Full internal network
Corp_Contractors VLAN 20 Internet + specific internal resources
Corp_IoT VLAN 30 Isolated, device-specific ports only
Corp_Guests VLAN 100 Internet only via captive portal

Step 5: Client Configuration and Certificate Validation

This is the most operationally critical step. Use Group Policy (GPO) for Windows and MDM profiles for macOS/iOS/Android to push WiFi configurations silently to managed devices. The profile must specify:

  • The Root CA that issued the RADIUS server's certificate.
  • The expected server name (CN or SAN of the server certificate).
  • The EAP method and inner authentication protocol.

For unmanaged BYOD devices, provide clear self-service onboarding instructions, ideally via a Network Access Control (NAC) portal.

Step 6: Implement Dynamic VLAN Assignment

Configure the RADIUS server to return VLAN assignment attributes in the Access-Accept response:

  • Tunnel-Type = VLAN (13)
  • Tunnel-Medium-Type = IEEE-802 (6)
  • Tunnel-Private-Group-Id = ``

The access point reads these attributes and places the authenticated client on the specified VLAN — no manual reconfiguration required as users change roles or locations.


Best Practices

Redundancy is non-negotiable. Deploy a minimum of two RADIUS servers (primary and secondary) and configure all access points to fail over automatically. For on-premise deployments, consider placing the secondary server in a different physical location or availability zone. A RADIUS outage means nobody can authenticate, which is a complete network outage for 802.1X-protected SSIDs.

Monitor certificate expiry proactively. A RADIUS server certificate expiry is one of the most common causes of sudden, widespread authentication failures. Implement monitoring to alert administrators at least 30 days before expiry. This applies to both the server certificate and any intermediate CA certificates in the chain.

Treat the Shared Secret as a critical credential. The shared secret between the AP and the RADIUS server encrypts RADIUS packets. Use unique secrets per location or AP group, store them in a secrets manager, and rotate them periodically. See our guide on Protect Your Network with Strong DNS and Security for broader network security hygiene recommendations.

Align with compliance frameworks. For environments subject to PCI DSS (e.g., retail payment networks), 802.1X authentication directly supports requirements for network access control and audit logging. For GDPR compliance, RADIUS accounting logs (port 1813) provide a detailed audit trail of who accessed the network, from where, and when — valuable for incident response. For Healthcare environments, network segmentation via dynamic VLAN assignment supports HIPAA requirements for protecting electronic protected health information (ePHI).


Troubleshooting & Risk Mitigation

Failure Mode Symptom Resolution
Certificate expiry Sudden mass authentication failures Monitor expiry; renew and redeploy certificate
NTP desynchronisation Intermittent EAP-TLS failures Ensure RADIUS server and DCs sync to same NTP source
LDAP connectivity loss Authentication fails when AD is unreachable Deploy redundant DCs; configure RADIUS to cache recent authentications
Incorrect Shared Secret AP logs show RADIUS timeout or Bad authenticator Verify secret matches on both AP and RADIUS server
Client certificate mismatch EAP-TLS failures for specific devices Verify client cert is issued by trusted CA; check cert validity period
VLAN not assigned User authenticated but on wrong network segment Verify RADIUS attributes are correctly returned; check AP VLAN configuration

For a deeper dive into the 802.1X configuration process itself, the How to Configure 802.1X WiFi Authentication: A Step-by-Step Guide provides granular, vendor-specific configuration walkthroughs.


ROI & Business Impact

Transitioning from PSK to RADIUS-backed 802.1X requires an initial investment in configuration, and potentially licensing for cloud solutions or hardware for on-premise deployments. The ROI case is straightforward:

Risk mitigation: The average cost of a data breach in the UK is in excess of £3 million (IBM Cost of a Data Breach Report). A compromised PSK can expose the entire network. 802.1X limits the blast radius to a single compromised user account, which can be disabled in seconds via the directory.

Operational efficiency: Dynamic VLAN assignment eliminates manual network reconfiguration as staff change roles. Onboarding a new employee means adding them to the correct AD group — the network access follows automatically.

Compliance posture: For organisations subject to PCI DSS, ISO 27001, or Cyber Essentials Plus, 802.1X is a direct control that auditors expect to see. Deploying it strengthens your compliance posture and reduces audit remediation costs.

Guest experience and analytics: For venue operators, integrating RADIUS for staff authentication with Purple's Guest WiFi platform for visitor access creates a unified, tiered access model. Staff authenticate silently via 802.1X; guests connect via a branded captive portal. Purple's WiFi Analytics platform then provides real-time visibility into visitor dwell times, repeat visit rates, and engagement metrics — data that directly informs marketing spend and venue operations decisions.


For further reading, see the Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo for Portuguese-language implementation guidance, and What Is a Leased Line? Dedicated Business Internet for guidance on ensuring the underlying connectivity meets enterprise requirements.

关键定义

RADIUS(远程认证拨入用户服务)

一种网络协议,为连接到网络服务的用户提供集中的认证、授权和计费(AAA)管理。定义于RFC 2865。

在授予WiFi访问权限之前,根据目录验证用户凭据的核心服务器组件。每个使用802.1X的企业WiFi部署都需要RADIUS服务器。

802.1X

基于端口的网络访问控制(PNAC)的IEEE标准。它为希望连接到LAN或WLAN的设备提供认证机制,阻止所有非EAP流量,直到认证成功。

定义了Supplicant、Authenticator和Authentication Server如何通信的总体框架标准。当IT团队提到“企业WiFi安全”时,他们通常指的是具有802.1X的WPA2/WPA3-Enterprise。

请求者(Supplicant)

客户端设备——更准确地说,是该设备上的802.1X软件栈——通过向网络提供凭据来启动认证过程。

在Windows上,内置的请求者是无线自动配置服务。在macOS和iOS上,它内置于操作系统中。确保请求者配置正确(尤其是证书验证)是部署问题的最常见来源。

认证者(Authenticator)

网络设备——通常是WiFi接入点或无线控制器——充当请求者和RADIUS服务器之间的中介,根据认证结果执行访问控制。

AP会阻止端口上的所有数据流量,直到它从RADIUS服务器接收到Access-Accept。它还会从Access-Accept响应中读取RADIUS属性(例如VLAN分配),并将其应用于会话。

EAP(可扩展认证协议)

一种在RFC 3748中定义的认证框架,为请求者和认证服务器之间的各种认证方法(TLS、PEAP、TTLS等)提供了标准化的传输机制。

EAP是客户端和RADIUS服务器之间交流的“语言”。EAP方法的选择(EAP-TLS与PEAP)决定了认证系统的安全强度和部署复杂性。

PEAP(受保护的可扩展认证协议)

一种EAP方法,首先使用服务器证书建立TLS隧道,然后在该加密隧道内执行二次认证(通常是使用用户名/密码的MSCHAPv2)。

最常见的企业WiFi认证方法,因为它在安全性和部署简便性之间取得了平衡。只需要服务器端证书,因此比EAP-TLS更容易推广。

动态VLAN分配

一种RADIUS功能,服务器在Access-Accept响应中包含VLAN特定属性(Tunnel-Type、Tunnel-Medium-Type、Tunnel-Private-Group-Id),指示AP将已认证的客户端放置到特定的VLAN上。

允许单个SSID为具有不同安全需求的多个用户群体提供服务。无需为不同的用户组广播多个SSID,从而减少射频开销并简化用户体验。

共享机密

预先配置的文本字符串,只有认证者(AP)和RADIUS服务器知道,用于签名和加密RADIUS数据包,确保通信的完整性和真实性。

一个关键的安全配置要素。如果共享机密弱或泄露,攻击者可能伪造RADIUS Access-Accept响应,授予未经授权的网络访问。每个位置使用唯一的机密,并将其存储在机密管理器中。

MAC认证绕过(MAB)

一种回退认证机制,使用设备的MAC地址作为其身份凭据,为不支持802.1X请求者的设备启用网络访问。

用于无头设备(打印机、物联网传感器、IP摄像头)。由于MAC地址是公开可见且容易被伪造,MAB提供设备识别而不是强认证。始终与受限的VLAN分配结合使用。

应用实例

一家拥有500个地点的全国零售连锁店需要为店长的平板电脑和POS终端实施安全的WiFi。他们目前在所有门店使用一个单一的PSK,该PSK经常被未经授权的员工和承包商共享。他们使用Azure AD进行身份管理,并且在分支机构没有专门的IT人员。

部署一个与Azure AD直接集成的云端RADIUS解决方案。这消除了在500个地点部署和管理本地RADIUS服务器的需要。IT团队使用Microsoft Intune将所有店长的平板电脑和POS终端推送一个配置为PEAP-MSCHAPv2的WiFi配置文件,严格强制验证云端RADIUS服务器的证书。云端RADIUS策略在授予访问权限之前检查用户的Azure AD组成员资格:'Store_Managers'组获得VLAN 10(完整的POS和后台访问),'Contractors'组获得VLAN 20(仅互联网访问)。当承包商的服务结束时,将其从Azure AD组中移除,会立即撤销他们在所有500个地点的WiFi访问权限——无需更改PSK。

考官评语: 此方法解决了核心漏洞(共享PSK),同时承认了运营限制(没有分支机构IT人员,Azure AD环境)。云端RADIUS提供了必要的可扩展性,并与现有的身份提供商原生集成。使用动态VLAN分配确保即使承包商的设备在其服务结束后仍在现场,将其从目录组中移除是撤销访问所需的唯一操作。

一家拥有400间客房的市中心酒店需要为员工(前台、客房部、管理层)和客人提供安全的WiFi。员工需要访问物业管理系统(PMS)和内部服务器。客人仅需要互联网访问。酒店有一个单一的本地Windows Server环境。

在专用的Windows Server虚拟机上部署Microsoft NPS。在无线基础设施上配置两个SSID:'Hotel_Staff'(WPA2-Enterprise802.1X)和'Hotel_Guest'(开放或WPA2-Personal,重定向到Captive Portal)。对于员工SSID,NPS根据Active Directory验证凭据,并返回动态VLAN分配:'Management' AD组 → VLAN 10(完全访问),'FrontDesk' → VLAN 20(PMS访问),'Housekeeping' → VLAN 30(仅互联网+排班应用)。对于客人,将Captive Portal与Purple的Guest WiFi平台集成,以提供品牌化的登录体验,收集第一方数据(电子邮件、营销同意),并获得关于停留时间和回头率等的分析。双SSID模型将员工和客人的流量在网络层完全分离。

考官评语: 双SSID模型是此处正确的方法,而不是使用具有复杂策略路由的单一SSID。它提供了清晰的运营分离,并简化了故障排除。将Purple集成用于客人SSID是商业上明智的决定:它将客人网络从成本中心转变为数据捕获和营销渠道,并通过回头率和电子邮件营销参与度提供可衡量的ROI。

练习题

Q1. 您的组织正在将2,000台Windows笔记本电脑从共享PSK迁移到带有PEAP-MSCHAPv2的802.1X。您的安全团队指出PEAP容易受到通过流氓接入点进行的凭据收集攻击。缓解此风险的最重要的配置步骤是什么,以及如何大规模部署它?

提示:考虑是什么阻止客户端信任提供自签名证书的欺诈RADIUS服务器。

查看标准答案

关键步骤是在每个客户端设备上强制进行严格的服务器证书验证。使用组策略对象(GPO),向所有2,000台笔记本电脑推送一个WiFi配置文件,指定:(1)颁发RADIUS服务器证书的确切根CA证书,(2)预期的服务器名称(CN/SAN),以及(3)客户端不得提示用户信任新证书。这确保了即使攻击者部署一个带有欺诈证书的流氓AP,客户端也将拒绝TLS握手并拒绝发送凭据。没有此配置,PEAP对流氓AP攻击没有提供有意义的保护。

Q2. 一位医院IT总监需要为300台不支持802.1X的医疗物联网设备(输液泵、监测设备)提供网络访问。这些设备与员工工作站位于同一无线基础设施上。RADIUS基础设施应如何处理这些设备,以及必须采取哪些网络控制措施?

提示:思考适用于无头设备的认证方法,以及如何弥补其固有的弱点。

查看标准答案

在RADIUS服务器上为这些特定设备配置MAC认证绕过(MAB)。将每个设备的MAC地址注册到专用的Active Directory组或RADIUS数据库中。由于MAC地址容易被伪造,RADIUS服务器必须使用动态VLAN分配,将所有通过MAB认证的设备放置到一个专用的、高度受限的VLAN(例如VLAN 30 - IoT)上。该VLAN应通过防火墙仅允许与特定医疗服务器IP地址通信,并阻止所有其他流量,包括互联网访问和与员工VLAN的横向移动。员工工作站通过802.1X认证,并放置在一个单独的VLAN上。这种架构满足了HIPAA对ePHI邻近设备的网络分段要求。

Q3. 您是一家拥有50个场馆的连锁餐厅的网络架构师。使用云端RADIUS,49个场馆的认证工作正常,但一个特定场馆报告所有设备都无法认证。云端RADIUS管理门户显示没有来自该场馆的认证请求到达。您的诊断方法是什么?

提示:如果RADIUS服务器完全没有收到请求,问题出在认证者和服务器之间的通信路径上——而不是认证逻辑本身。

查看标准答案

由于RADIUS服务器从该场馆收到的请求为零,故障位于接入点和云端RADIUS服务器之间。按顺序进行诊断步骤:(1)验证场馆AP或无线控制器上配置的RADIUS服务器IP地址和端口(UDP 1812)——此处的拼写错误是最常见的原因。(2)检查该场馆的本地防火墙或路由器规则,确认出站UDP 1812流量被允许发送到云端RADIUS IP范围。(3)验证AP上配置的共享机密与云端RADIUS门户中为该场馆配置的机密是否匹配——不匹配会导致RADIUS服务器静默丢弃数据包。(4)检查场馆的互联网连接是否正常——云端RADIUS需要可靠的互联网连接。在AP或上游路由器上运行数据包捕获将确认RADIUS数据包是否正在发送以及是否收到响应。