Headscale 0.23.0版本ACL规则中/32掩码失效问题分析

在Headscale 0.23.0-alpha5版本中，用户报告了一个关于访问控制列表(ACL)功能的重要问题。该问题影响了使用/32掩码定义的主机访问规则，导致部分用户无法访问特定网络资源。

问题背景

Headscale是一个开源的Tailscale控制服务器实现，它允许用户管理自己的Tailscale网络。在Tailscale网络中，ACL规则用于定义哪些用户可以访问哪些网络资源。

在0.22.3版本中，用户可以正常使用/32掩码来精确控制对单个IP地址的访问。例如，在ACL配置中可以定义：

hosts:
  net.dns01: 172.16.0.21/32

然后通过ACL规则允许特定用户组访问该主机。

问题表现

升级到0.23.0-alpha5版本后，用户发现：

1. 使用/32掩码定义的ACL规则不再生效
2. 用户无法访问通过/32掩码定义的主机
3. 只有将掩码改为更大的范围(如/24)才能恢复访问，但这会导致访问控制过于宽松

技术分析

从用户提供的netmap转储可以看出：

• 在0.23.0-alpha5版本中，虽然ACL配置了/32主机，但生成的netmap中并未包含这些主机的路由信息
• 只有当使用/24掩码时，netmap中才会出现对应的路由条目

这表明新版本在ACL规则处理逻辑上发生了变化，导致/32掩码的主机定义没有被正确转换为netmap中的路由规则。

影响范围

该问题主要影响：

1. 需要精确控制单个IP访问的场景
2. 依赖/32掩码实现精细化访问控制的网络环境
3. 使用子网路由器的配置

解决方案

Headscale开发团队在后续版本(0.23.0-alpha10)中修复了这个问题。修复内容包括：

1. 恢复了/32掩码在ACL规则中的正确处理
2. 确保所有定义的主机无论掩码大小都能正确出现在netmap中
3. 同时解决了相关的出口节点功能问题

最佳实践建议

对于使用Headscale管理Tailscale网络的用户，建议：

1. 在升级前充分测试ACL规则在新版本中的表现
2. 对于关键业务环境，考虑暂缓升级到存在已知问题的版本
3. 定期检查netmap输出，确认ACL规则是否被正确应用
4. 对于需要精确控制的场景，同时配置/32和更大范围的规则作为冗余

通过理解这个问题，用户可以更好地规划Headscale的升级路径和网络访问控制策略，确保网络环境的安全性和可用性。