Chevnia Blog

Appearance

常见问题 ​

1. 配完后还是走 DERP ​

先看这几件事：

  1. vm-0-2-ubuntu 是否真的执行过 tailscale set --relay-server-port=40000
  2. UDP 40000 是否在云厂商安全组和系统防火墙里都已放行
  3. vm-0-2-ubuntu 是否真的带有 tag:relay-cn
  4. Access controls 中是否已经追加了 tailscale.com/cap/relay
  5. 各设备 Tailscale 版本是否至少 1.86

2. 配完后还是 direct ​

这通常不是坏事，说明设备已经能直连。

peer relay 只在不能直连时才会顶上来，所以如果状态还是 direct，通常代表当前网络环境已经足够好。

3. 端口放开了，但效果一般 ​

这一般说明瓶颈可能不在官方 DERP，而在：

  • 家里网络本身到公网的质量
  • 公司网络的 UDP 限制
  • hfmacbook -> vm-0-2-ubuntu 路径一般
  • 公司设备 -> vm-0-2-ubuntu 路径一般

这时候可以重点比较三段链路的表现，而不是只看最终体验。

4. tag 设置后需要审批 ​

这是正常的。去 Tailscale 管理后台批准对应节点的 tag 变更即可。

5. policy 保存报错 ​

最常见原因：

  1. tagOwners 原本就存在，你又多写了一层
  2. grants 末尾多了逗号
  3. 直接把示例文件整份覆盖了现有 policy

建议做法：

  • 先备份现有 policy
  • 再按“追加片段”的方式合并

6. 要不要只允许部分设备使用 relay ​

可以。

如果你后面想收紧范围，可以把：

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

改成更小的选择器，只给你需要的设备或用户使用。

7. 配完 relay 后，tailscale ping 能通，但 ssh 100.x.x.x:22 不通 ​

这次真实排查里，最终根因就是这个：

  • policy 里只加了：
    • tailscale.com/cap/relay
  • 但没有加普通网络层授权

结果表现为：

  • tailscale ping 正常
  • ssh -o ConnectTimeout=5 user@100.x.x.x 超时
  • nc -vz 100.x.x.x 22 卡住
  • 远端机器本身 sshd 其实是正常监听的

修复方式是在 policy 里补一条网络层 grant，例如：

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

如果你只想放行 SSH，也可以改成：

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

8. 这次真实问题的排查过程是什么 ​

这次问题的关键排查链路如下：

  1. autossh-log 里反复出现：
text
ssh: connect to host 100.x.x.x port 22: Operation timed out
  1. 先怀疑：
  • autossh
  • SSH 服务
  • 端口监听
  • 本机代理
  • Tailscale 路由
  1. 逐步确认：
  • 远端 hf-air 的 22 在监听
  • 远端本机访问 100.x.x.x:22 成功
  • tailscale ping 正常
  • 发起端抓包能看到发往 100.x.x.x:22 的 SYN
  • 目标端系统抓包看不到对应 22 端口流量

  1. 最终回到 policy，发现只加了 relay 能力，没有普通网络层授权

  2. 补上：

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

之后立即恢复