Appearance
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 这一条。
应用顺序
- 先把
tagOwners配好 - 再给
vm-0-2-ubuntu打tag:relay-cn - 再追加
grants - 保存 policy,确认后台校验通过
你现在这套命名建议
- tag:
tag:relay-cn - relay 节点:
vm-0-2-ubuntu - 目标用户设备:
hfmacbook、hf-air、local_user-mac-mini、your_user-pc2