集群中的动态授权
授权变更
授权变更（CoA）是一项扩展远程认证拨号用户服务（RADIUS）协议功能的特性，定义在 RFC 5176 中。CoA 请求消息通常由 RADIUS 服务器发送到网络接入服务器（NAS）设备，用于动态修改现有会话的授权属性。如果 NAS 设备能够成功实现客户端的请求授权变更，它将向 RADIUS 服务器响应一个 CoA 确认，也称为 CoA-ACK。相反，如果变更失败，NAS 将响应一个 CoA 否定确认或 CoA-NAK。
对于隧道客户端，CoA 请求会被发送到目标客户端的用户指定 Gateway（UDG）。UDG 在成功实现变更后会向 RADIUS 服务器返回确认，若实现失败则返回 NAK。然而，由于维护或故障等原因，客户端的 UDG 可能在正常集群操作期间发生变化。这些场景可能导致 CoA 请求被丢弃，因为预期的客户端将不再与接收 CoA 请求的 Gateway 相关联。HPE Aruba Networking 已实现集群冗余功能以防止此类场景。
集群 CoA 支持
在 AOS 10 中，为集群提供 CoA 支持的主要协议是虚拟路由冗余协议（VRRP）。每个集群中的 VRRP 实例数量与节点数相同，每个 Gateway 作为一个实例的控制器。例如，一个由四个 Gateway 组成的集群将有四个 VRRP 实例和四个虚拟 IP 地址（VIP）。VRRP 控制器会接收针对其实例 VIP 的消息，而集群中的其他 Gateway 作为备份，负责所有其他实例，且不作为控制器。这种配置确保每个集群都由容错和完全冗余的设计保护。
本节描述了根据 RFC 5176 所述的动态授权（Dynamic Authorization）到 RADIUS 的过程，以及 RADIUS 如何与集群中的网关通信。选择变更授权（Change of Authorization）流程作为该通信序列的代表。
AOS 10 在 220-255 范围内保留 VRRP 实例 ID。当每个实例的控制器向 RADIUS 服务器发送 RADIUS 请求时，它会将其实例的 VIP 作为 NAS-IP 注入到消息中，作为默认值。这确保了来自 RADIUS 服务器的 CoA 请求无论由哪个网关作为控制器，都能正确转发。例如，RADIUS 服务器向 VRRP 实例的当前控制器发送 CoA 请求，而不是向单个站点。对于 RADIUS 服务器而言，它是将请求发送给实例的 VIP 地址的当前持有者。以下是将在 CoA 部分使用的示意架构：
示例 CoA 实现
该示例网络由一个四节点集群组成，具有四个 VRRP 实例。分配的 VRRP ID 范围在 220 到 255 之间，因此该集群中的四个实例被分配了 VRRP ID 为 220、221、222 和 223。每个实例中的网关优先级是动态分配的，其中实例的控制器被赋予优先级 255，第一个备份被赋予优先级 235，第二个备份被赋予优先级 215，第三个备份被赋予优先级 195。
| VRRP 实例 | 虚拟 IP | GW-A 优先级 | GW-B 优先级 | GW-C 优先级 | GW-D 优先级 |
|---|---|---|---|---|---|
| 220 | VIP 1 | 255 | 235 | 215 | 195 |
| 221 | VIP 2 | 195 | 255 | 235 | 215 |
| 222 | VIP 3 | 215 | 195 | 255 | 235 |
| 223 | VIP 4 | 235 | 215 | 195 | 255 |
GW-A 是实例 220 的主控，优先级为 255，GW-B 是第一备份，优先级为 235，GW-C 是第二备份，优先级为 215，GW-D 是第三备份，优先级为 195。类似地，GW-B 是实例 221 的主控，优先级为 255，GW-C 是第一备份，优先级为 235，GW-D 是第二备份，优先级为 215，GW-A 是第三备份，优先级为 192。实例 222 和 223 的配置与实例 220 和 221 相同。
具有网关故障的 CoA
集群节点的故障如果没有具备适当容错能力的网络，可能会对 CoA 操作产生不利影响。如果用户的锚点网关发生故障，RADIUS 服务器会将 CoA 请求推送到他们的 UDG，假设它会执行更改并响应 ACK。然而，如果没有实现如 VRRP 这样的冗余机制，请求将得不到响应，导致无法成功执行更改。在这种情况下，与故障节点关联的用户将照常切换到备用的 UDG。然而，由于服务器未能获知集群操作，UDG 不会收到来自 RADIUS 服务器的更改请求。必须为每个节点实现 VRRP 实例，以防止此类情况发生，并保持集群中的 CoA 操作正常。
在下图中，GW-A 是实例 220 的主控，GW-B 作为第一备份，GW-C 作为第二备份，GW-D 作为第三备份。与 GW-A 关联的客户端已通过 802.1X 完全认证，GW-D 作为客户端的备用 UDG。当与 ClearPass 通信时，GW-A 会自动将实例 220 的 VIP 作为 NAS-IP 插入。从 ClearPass 的角度来看，它向 VRRP 实例 220 的当前主控发送 CoA 请求。
客户端对 ClearPass 的认证
如果 GW-A 发生故障，客户端会切换到 GW-D。客户端会迁移到 GW-D，因为它是备用 UDG。然后，GW-D 会承担客户端的 UDG 角色。由于 GW-B 的优先级高于 GW-C 或 GW-D，它将担任主控角色并拥有 VIP。
GW-A 故障
ClearPass 发送的任何针对客户端 1 的 CoA 请求都将指向实例 220 的 VIP。从 ClearPass 的角度来看，实例 220 的 VIP 是针对示例中客户端的任何 CoA 请求的正确地址。由于 GW-A 已故障，GW-B 现在是 VRRP 实例 200 的主控，拥有 VIP。当 ClearPass 发送针对客户端的 CoA 请求时，GW-B 会接收并转发给集群中的所有节点。在这种情况下，GW-B 会将请求转发给 GW-C 和 GW-D。
转发给 GW-B 的 CoA 消息
在成功实施 CoA 请求的更改后，GW-D 会向 ClearPass 发送 CoA 确认消息。
来自 GW-D 的 CoA 确认
最后修改时间：2024年2月28日 (614bf13)