acg1000-ee行为管理和认证服务器做联动开启认证，可以弹出认证页面，但是连接超时

多半是兼容性问题

联系服务器查看交互细节吧

可以弹出认证页面，但输入账号密码后提示“连接超时”，这个现象很典型。这表明Portal服务器与终端用户的交互（弹出页面）是正常的，但Portal服务器与RADIUS认证服务器之间的联动出了问题。

简单来说，Portal服务器已经成功地将用户名和密码转交给了RADIUS服务器，但在规定时间内没有收到认证结果，导致超时。

下面是一个系统的排查思路，你可以按步骤操作，逐步定位问题。

 第一步：核实配置一致性（最常见原因）

配置不一致是导致认证超时的首要原因。请逐一核对以下配置，确保ACG1000与认证服务器完全匹配。

• RADIUS共享密钥：请确认ACG1000上配置的RADIUS服务器“共享密钥”与认证服务器上的设置完全一致。这是双方能否正常通信的基础。

• NAS-IP地址：检查ACG1000上的NAS-IP（或NAS-Identifier）配置，确保该地址已正确添加到RADIUS服务器的客户端（NAS）列表中，且IP地址无误。

• UDP端口：确认双方使用的认证端口（默认UDP 1812）和计费端口（默认UDP 1813）配置相同。如果非标准，需互相匹配。

 第二步：检查网络与通信

配置无误后，需要排查物理链路和路由。

• 网络连通性：在ACG1000上，用ping命令测试其到RADIUS服务器的IP地址是否可达。

• 端口可达性：使用telnet [RADIUS服务器IP] 1812命令，测试ACG1000是否能连通RADIUS服务器的认证端口。

• 来回路径一致性：确保ACG1000和RADIUS服务器之间的数据包往返路径一致，避免因来回路由不同导致报文被丢弃。

 第三步：查阅关键日志与调试信息

如果基础配置和网络都正常，就需要查看更详细的内部信息了。

• 检查ACG1000本地日志：登录ACG1000的Web界面，在“系统管理 > 系统日志”中查找与认证失败相关的错误记录。

• 使用命令行进行实时调试（高级步骤）：

  1. 通过SSH或Console登录ACG1000的命令行界面。

  2. 开启调试功能，实时查看RADIUS认证报文：debug radius packet

  3. 同时开启terminal monitor和terminal debugging以显示调试信息。

  4. 发起一次Portal认证，观察命令行输出的调试信息。重点关注是否有Access-Accept（认证通过）或Access-Reject（认证拒绝）报文。

  5. 认证完成后，关闭调试功能：undo debug radius packet

  通过分析调试信息，可以清晰地判断是认证服务器未响应、响应被拒绝，还是其他问题。

 第四步：检查认证服务器侧

如果ACG1000正常发出了认证请求，问题可能出在认证服务器侧。

• 检查服务状态：登录RADIUS服务器，确认其RADIUS服务（如Windows的NPS、Linux的FreeRADIUS）处于运行（Running） 状态。

• 检查认证日志：查看RADIUS服务器的详细认证日志，确认是否收到了来自ACG1000的认证请求，并检查返回的失败原因（如用户不存在、密码错误、账户过期等）。

• 资源与性能：检查服务器的CPU、内存使用率是否过高，以及是否有防火墙策略拦截了来自ACG1000的UDP 1812/1813端口。

一、先明确：为什么 “能弹页但提交超时”

• 能弹页：ACG → 终端 HTTP 重定向正常
• 提交超时：ACG ↔ RADIUS 服务器 1812 端口不通 / 被拒 / 密钥错 / 无响应
  你遇到的就是 后半段 RADIUS 链路故障。

二、100% 必查：4 个核心配置（90% 问题在这）

1. RADIUS 共享密钥（最常见）

• ACG 上：用户管理 → 认证管理 → 认证服务器 → RADIUS
  • 服务器密码（共享密钥） 必须和第三方服务器完全一致（大小写、特殊字符）
  • 不能有空格、不能中文、建议纯字母数字
• 第三方 RADIUS 服务器（如 iMC EIA、FreeRADIUS）
  • 接入设备 IP：必须填 ACG 出口 IP（不是内网口 / 管理口，是发包源 IP）
  • 共享密钥 和 ACG 完全一样
  • 未添加 ACG 为合法客户端 → 直接丢包 → 超时

2. 端口与协议（1812/1813）

• ACG 默认：
  • 认证端口：1812
  • 计费端口：1813
• 检查：
  • 第三方服务器端口必须是 1812（不是 1645）
  • 防火墙 / 安全组 放通 1812/1813 UDP（RADIUS 用 UDP）
• 测试（ACG 命令行）：
  plaintext

  ping 服务器IP # 能通 udp-port 服务器IP 1812 # 关键！测1812是否通

3. Portal 认证 URL 格式（你提到的关键）

• URL 带 portal → 不弹页
• 删掉 portal → 能弹但提交超时

• 必须以？结尾 或 完整路径
• 不能少 /portal、不能多无关参数
• 错误示例：http://x.x.x.x（缺路径）→ 弹页异常 / 提交失败

4. 认证策略绑定（强制模式 + 第三方 RADIUS）

• 用户管理 → 认证管理 → 认证策略
  • 认证模式：强制
  • 认证方式：Portal Server
  • Portal 服务器：选你建的第三方
  • 认证服务器：选RADIUS 服务器（不能默认本地）
• 高级选项 → 识别范围
  • 确认终端 IP 在认证地址段内
  • 排除：RADIUS 服务器 IP、Portal 服务器 IP 必须加免认证

三、ACG 侧：3 个关键排障命令

• RADIUS: no response from server → 1812 不通 / 服务器无响应
• Authenticator error → 共享密钥不匹配（最典型）H3C
• Timeout → 网络不通 / 端口被封

四、第三方 RADIUS 服务器侧（必查）

1. 接入设备添加 ACG IP
   • 设备 IP：ACG 出口 IP（不是内网）
   • 厂商：H3C
   • 共享密钥一致
   • 未添加 → 直接丢包 → 超时
2. 用户 / 服务配置
   • 测试账号存在、未锁定、密码正确
   • 服务类型：802.1X/Portal
3. 服务器状态
   • RADIUS 服务运行
   • 1812 端口监听：netstat -anp | grep 1812

五、按你场景的快速修复步骤（直接照做）

1. 重配 RADIUS 密钥
   • ACG 和服务器完全一致，纯英文数字
2. 确认 1812 UDP 通
   • ACG 上 udp-port 服务器IP 1812 必须成功
3. 修正 Portal URL
   plaintext

   http://服务器IP:8080/portal?
4. 免认证地址
   • 把 RADIUS IP + Portal IP 加入免认证
5. 重启服务
   • ACG：系统 → 服务管理 → 重启 portal/radius
6. 清浏览器缓存再测试

六、一句话总结你这个案例