Homelab 异地升级 Tailscale 失联与全链路恢复

背景

在异地远程维护 Homelab 时，将 Mac Mini M2 手动升级 Tailscale 新版本后，节点随即从 Tailscale 网络掉线，主力宿主机完全失联，而物理机距我 200 多公里。以下是整个远程排障与恢复过程的记录。

• 故障设备：Mac Mini M2（<Hostname>，内网 IP <LAN_IP_Mac_Mini>）
• 跳板设备：FriendlyWrt 软路由（WAN <LAN_IP_Router_WAN>，LAN <LAN_IP_Router_LAN>，Tailscale <Tailscale_IP_Router>）
• 涉及组件：OpenSSH、Linux iproute2、Tailscale macsys v1.104.x、macOS SystemExtensions、nesessionmanager、OrbStack

建立跳板机 SSH 通道

Mac Mini 失去直连通道后。虽然手足无措，但是思考 homelab 网络拓扑，想到可以尝试通过同局域网内仍在线的软路由（FriendlyWrt）做 SSH 跳板穿透，然后排查设备故障原因。

在配置跳板机到故障设备的 ssh 连接凭证时先后踩了两个坑。

私钥权限过宽

在软路由上执行 ssh <SSH_Alias> 直接报错：

1

Permissions 0644 for '/root/.ssh/<private_key_file>' are too open

1

chmod 0600 /root/.ssh/<private_key_file>

改完权限再连，依然报错：

1

<Username>@<LAN_IP_Router_WAN>: Permission denied (publickey)

ssh -vvv 确认客户端公钥签名发出去了，但服务端直接拒绝。

连错了机器

确认 rsa 私钥无误，考虑可能是记错内网 IP 地址了，放弃盲调，先用 iproute2 把软路由自身的网络拓扑摸清楚：

1
2

ip addr
ip neigh show

结果发现：

1
2
3
4
5
6
7

上级主路由 (<Gateway_IP>)
       │
  [eth0: <LAN_IP_Router_WAN>/24]   ← 软路由自身 WAN 口 ← 之前一直在连这个！
   FriendlyWrt 软路由
  [br-lan: <LAN_IP_Router_LAN>/24] ← LAN 网桥网关
       │
  [<LAN_IP_Mac_Mini>]              ← Mac Mini 真实内网 IP（MAC: <MAC_Address>）

而之前尝试的 <LAN_IP_Router_WAN> 实际上绑在软路由自身的 eth0 上，所以之前一直在用 <Username> 账户 SSH 进软路由自己，而软路由上根本没有这个用户，自然 Permission denied。

ip neigh show 在 br-lan 下级发现唯一活跃邻居条目，确认 Mac Mini 的真实 IP。

把 /root/.ssh/config 里的 HostName 从 <LAN_IP_Router_WAN> 改成 <LAN_IP_Mac_Mini>，重连立即通过。

诊断 Tailscale 失联根因

登上 Mac Mini 的 CLI 后，开始排查 Tailscale 为什么无法启动。

CLI 崩溃

不管是 tailscale status、tailscale version，还是直接调 .app 内的 CLI 二进制（注入 TAILSCALE_BE_CLI=1），统一报错：

1

The Tailscale CLI failed to start: The operation couldn't be completed. (Tailscale.CLIError error 1.)

open -a Tailscale 唤 GUI 也没反应。

进程在运行，但通信断了

ps aux 能看到 Tailscale.app（v1.104.4）和底层网络扩展 io.tailscale.ipn.macsys.network-extension（root 权限）都在运行。进程没死，问题出在前端 CLI 和后台扩展的 LocalAPI Socket 之间的通信没建立。

旧版扩展没清掉

systemextensionsctl list 看到了堆积的旧版本：

1
2
3

<Team_ID>  io.tailscale.ipn.macsys.network-extension (1.104.2/...)  [terminated waiting to uninstall on reboot]
*   *      <Team_ID>  io.tailscale.ipn.macsys.network-extension (1.104.4/...)  [activated enabled]
<Team_ID>  io.tailscale.ipn.macsys.network-extension (1.104.1/...)  [terminated waiting to uninstall on reboot]

1.104.1 和 1.104.2 都卡在等待重启卸载，和新版 1.104.4 产生冲突。

OrbStack 触发了请求风暴

用 log show --last 10m 抓 Tailscale 相关日志，找到了死锁的直接触发原因：

1
2
3

nesessionmanager: NESMVPNSession[Primary Tunnel:Tailscale:<UUID>]: got On Demand start message from pid <PID>
nesessionmanager: NESMVPNSession[Primary Tunnel:Tailscale:<UUID>]: Received a start command from OrbStack Helper[<PID>]
nesessionmanager: NESMVPNSession[Primary Tunnel:Tailscale:<UUID>]: Skip a start command from OrbStack Helper[<PID>]:session in state connecting

跨版本手动升级时，nesessionmanager 没能正常回收旧版 VPN 隧道，新隧道一直卡在 connecting 状态。与此同时 OrbStack Helper 以极高频率不断发送 On Demand start 请求，把状态机彻底锁死——LocalAPI Socket 始终无法启动，CLI 报 error 1，节点掉线。

解决

macOS 的 SystemExtension 只有重启才能清理 [terminated waiting to uninstall on reboot] 状态的扩展，没有别的办法。

重启前确认了 Mac Mini 的 SSH LaunchDaemon 开机自启、没有 FileVault 预启动密码阻塞，然后通过跳板机远程重启。

重启后再次通过跳板机登录验证：旧版扩展全部清理，nesessionmanager 隧道正常初始化，tailscale status 恢复输出。

两分钟后异地直连完全恢复。

事后复盘

远程 homelab 最好有多个内网穿透链路，避免线路单点故障导致完全无法维护

这次能远程自救，全靠软路由还维持有独立的、可用的 Tailscale 入口。尽管在最初配置跳板机的 ~/.ssh/config 时凭记忆写入了错误的 IP，但多亏了能通过这台跳板机可以扫描获取局域网设备实际的 IP 地址。

OrbStack + Tailscale 升级要当心

带 GUI 的 Tailscale（macsys）强依赖 SystemExtension 和 nesessionmanager，在宿主机跑着 OrbStack 或 Docker 的情况下，多次免重启升级很容易引发 VPN 隧道死锁。