Skip to content

Access Controls 配置

这一页是最容易误操作的部分,先记住一句话:

只把下面的片段追加到你现有的 tailnet policy 中,不要整份覆盖。

目标

让带有 tag:relay-cn 的设备可以被当作 relay 使用,并且避免“relay 配好了,但成员之间普通 SSH/端口访问突然失效”的问题。

需要追加的内容

如果你当前 policy 里还没有 tagOwners,可以新增:

json
"tagOwners": {
  "tag:relay-cn": ["autogroup:admin"]
}

如果你已经有 tagOwners,就只把这一项加进去。

然后在 grants 里追加 relay 能力:

json
{
  "src": ["autogroup:member"],
  "dst": ["tag:relay-cn"],
  "app": {
    "tailscale.com/cap/relay": []
  }
}

仅有上面这一条还不够。

因为 tailscale.com/cap/relay 只是在授权:

  • 谁可以使用 tag:relay-cn 设备的 relay 能力

不等于普通网络层访问授权。

如果你的 tailnet 当前使用 grants,又没有别的网络层放行规则,那么很可能会出现:

  • tailscale ping 正常
  • ssh 100.x.x.x:22 超时
  • autossh 也跟着报 port 22: Operation timed out

所以建议同时补上普通成员之间的网络层授权。

最宽松、最省事的写法:

json
{
  "src": ["autogroup:member"],
  "dst": ["autogroup:member"],
  "ip": ["*"]
}

如果你只想先恢复 SSH,可以收紧成:

json
{
  "src": ["autogroup:member"],
  "dst": ["autogroup:member"],
  "ip": ["tcp:22"]
}

完整示例

参考文件:

推荐的初始策略

先用:

json
"src": ["autogroup:member"]

这样你的 tailnet 成员设备都能在需要时使用这台 relay。

如果后续你想更细化,可以改成更小范围,例如只允许某几个来源。

如果你是第一次加 grants,建议一开始就把“relay 能力”和“普通网络访问”一起考虑,不要只加 relay 这一条。

应用顺序

  1. 先把 tagOwners 配好
  2. 再给 vm-0-2-ubuntutag:relay-cn
  3. 再追加 grants
  4. 保存 policy,确认后台校验通过

你现在这套命名建议

  • tag:tag:relay-cn
  • relay 节点:vm-0-2-ubuntu
  • 目标用户设备:hfmacbookhf-airlocal_user-mac-miniyour_user-pc2