摘要

  • RFC 9950 的 must 规则要求使用 TACACS+ 作为系统认证方法时，配置至少一个提供认证服务的服务器。
  • 这是一条模型一致性规则，不是对连接、身份、权限、策略或操作结果的证明。

约束语句最容易被读成保证语句。RFC 9950 中的关键 must 条件看上去很强：当设备在系统认证顺序中选择 TACACS+ 时，tacacs-plus 容器必须有提供 authentication 的服务器。它防止一种清晰的自相矛盾——声明要走 TACACS+ 认证，却没有让客户端可以尝试的认证服务器。这个限制是必要的，也很有价值；但它回答的是配置是否自洽，而不是未来某次请求是否成功。

模型中的服务器条目仍是一组前置条件。它有名称、服务类型、地址或主机名、端口和安全选择；还可定义源 IP 或源接口、VRF、单连接模式与等待响应的超时。多个服务器条目用于冗余。每一项都帮助设备形成今后尝试集中式 AAA 的路径。它们不会让某条路径在现实中可达，不会证明远端的身份材料已被正确管理，也不会预先决定某一用户名、命令或活动记录将得到什么处理。

RFC 9950 也刻意保留 AAA 的分工。认证是验证用户名和密码；授权是根据权限级别决定能访问哪些命令；记账是记录已经访问设备的用户活动。一个通过 must 检查的树，不能把这三种事件折叠成“已获准”的单一状态。认证服务器被声明，不等于认证完成；连接受 TLS 保护，不等于授权服务会给出所需的权限；计数器累积，也不等于命令或业务后果已经发生。

安全选择同样需要按其窄范围理解。RFC 9950 可表示 TLS 客户端身份和服务器认证资料，也允许引用全局配置的凭据。它为存量环境保留共享秘密的混淆选项，但明说该机制没有有意义的完整性、保密性或抗重放保护，并已被 TLS 取代。RFC 9887 对 TLS TACACS+ 要求 TLS 1.3 与相互认证。相互认证为一次连接建立受保护的对等关系；它不会替负责方确定用户可做什么，也不会证明该用户的后续操作已经完成。

RFC 9950 的只读统计更能说明边界。连接打开、关闭、失败、超时，收发消息和会话数，都是配置服务器关系的可观测数据。它们能够帮助定位问题，却不能代替某次请求的完整证据。尤其单连接模式允许一条 TCP 连接承载多次 TACACS+ 会话，不能把一个连接数直接等同于一个人、一次授权或一个结果。

真正敏感的是谁可以更改未来的路径。RFC 9950 指出，未经授权地改写服务器列表可能把设备指向已受损的 TACACS+ 服务器，并可能导致对设备的完全控制。因此共享秘密默认拒绝所有访问，客户端身份和服务器认证引用默认拒绝写入。这些机制保护配置面的变更权；它们没有把解释一次 AAA 交换和承担其后果的本地责任交给一条 must 表达式。