[错误] 错误: 在更新后,无法访问的路由被广播/推送给客户端

这是一个支持请求吗？ - [x] 这不是一个支持请求 ### 此问题是否已存在？ - [x] 我已经搜索了现有问题 ### 当前行为 在更新 Headscale 后，我注意到广告路由的分发方式发生了回退。如果节点 A 广告了多个路由或子网，节点 B 会从节点 A 接收所有广告路由，即使 ACL 规则明确限制了节点 B 访问特定子网。在之前的版本中，Headscale 会过滤客户端无权访问的路由。虽然节点 B 仍然需要访问节点 A 本身（或其上的其他服务），但接收未经授权的子网路由可能会在节点 B 上引起本地路由冲突。 ### 预期行为 不可访问的路由不应推送给无法访问它们的客户端。 ### 重现步骤 1- 设置一个 Headscale 网络，包含节点 A 和节点 B。 2- 配置节点 A 广告一个子网路由（例如 192.168.1.0/24）。 3- 配置 ACL 规则，使节点 B 能够直接与节点 A 通信（或访问特定端口/服务），但明确禁止访问广告的子网 192.168.1.0/24。 4- 将两个节点连接到 Headscale 并批准节点 A 上的子网路由。 5- 检查节点 B 的路由表（tailscale status 或 ip route）。 ### 运行环境 - [x] Headscale 位于反向代理后面 - [ ] Headscale 在容器中运行 - [ ] Headscale 位于云中 - [ ] Headscale 位于本地 - [ ] Headscale 位于其他网络中 ### 调试信息 通过 ACL 明确禁止访问这些子网，将子网路由推送到无法访问它们的设备是没有实际意义的。它绕过了预期的隔离控制，迫使客户端节点接受它们无法与之交互的网络的路由条目。 在我们的环境中，此更改破坏了系统路由，并在客户端设备上引发 IP/子网冲突。如果此路由行为是为特定边缘情况故意更改的，则至少应通过 config.yaml 使其可配置（例如 filter_unauthorized_routes: true），以便现有部署不会因意外的网络中断而受到影响。