最近有朋友在阿里云 ECS 上装完 Tailscale转头发现控制台自带的 Workbench 远程连接死活连不上了要么卡在“连接中”要么用一会就掉线。我先说清楚这里的 Workbench 是阿里云 ECS 控制台里的网页远程连接工具不是 MySQL Workbench也不是 ANSYS Workbench。很多人一搜“workbench 断连”跑偏到别的软件里所以先把这个坑位占住。实际上问题不复杂Tailscale 启动后会在 Linux 上创建一个叫 tailscale0 的虚拟网卡并把 100.64.0.0/10 这个网段的路由接管掉。而阿里云 ECS 的元数据服务地址 100.100.100.100 刚好落在这个网段里。Tailscale 一运行系统访问阿里云内网服务的流量就被送进了 tailscale0Workbench 背后依赖的云助手 Agent 拿不到必要信息会话建立不起来表现出来就是 Workbench 连不上、连上就断。这篇文章我会把链路原理讲清楚再给出三种可落地的解决办法。最推荐的是第一种给阿里云内网地址单独加一条高优先级路由不动 Tailscale也不影响你用它组网。后面两种作为备用适合不同场景。1. 先说结论不是 Workbench 挂了是 Tailscale 把路由“吃”了很多人遇到断连第一反应是重启 Workbench、重装云助手、换浏览器结果折腾一圈还是不行。其实问题出在系统路由表。Tailscale 在 Linux 上启动后会做两件事创建虚拟网卡 tailscale0同时往路由表里写入一条到 100.64.0.0/10 的直连路由。这两件事本身没毛病但放到阿里云 ECS 上就撞车了。1.1 Workbench 的连接链路和云助手Workbench 不是简单的“浏览器帮你建一条 SSH 连接”。你在 ECS 控制台点开 Workbench 时控制台会通过阿里云内部服务找到这台 ECS然后由实例里预装的云助手 Agent 来回接管连接。云助手本身要去访问阿里云的内部服务以及元数据服务 100.100.100.100用来获取实例的 RAM 角色、网络配置、运行状态等关键信息。如果这些内部地址访问不到云助手就会处于“失联”状态控制台自然无法建立远程会话。所以 Workbench 断连很多时候不是 SSH 端口或密码的问题而是云助手和阿里云内网之间的链路断了。1.2 Tailscale 默认动了哪条路由Linux 选择路由时遵循“最长前缀匹配”也就是说掩码越长优先级越高。Tailscale 写入的 100.64.0.0/10 是一条前缀较长的路由它会让系统把目标地址在 100.64.0.0 到 100.127.255.255 范围内的流量都扔给 tailscale0 网卡。看一下典型的 Tailscale 启动后的路由ip route你会看到类似这样的输出100.64.0.0/10 dev tailscale0 proto kernel scope link src 100.x.x.x这条路由一旦存在只要目标 IP 落在 100.64.0.0/10 里面就不会走原来的 VPC 默认网关而是进入 Tailscale 的虚拟网卡。1.3 阿里云为什么“躺枪”阿里云 ECS 的元数据服务地址是 100.100.100.100。这个地址并不是什么私有 IP它属于 100.64.0.0/10 这个运营商级 NAT 网段。换句话说阿里云当初设计元数据服务时地址选在了 100.64.0.0/10 内部。这不影响正常 VPC 环境因为 ECS 默认路由不会对 100.64.0.0/10 特殊处理流量还是会走本地网关去访问元数据服务。但 Tailscale 天生就把 100.64.0.0/10 当作自己的虚拟网段一启动就添加直连路由。两个东西撞在同一个地址段上结果就是Tailscale 一开元数据服务访问不了云助手失联Workbench 断连。这就是整件事的核心原因理解了这一点后面所有修复方案都是在解决同一个问题想办法让阿里云内网流量绕过 Tailscale 的虚拟网卡。2. 三步自查确认是不是路由冲突如果你手头正好有台 ECS 遇到同样问题先别急着重装东西按照下面三步走五分钟就能基本确认原因。2.1 查流量到底走了哪张网卡先看路由表里有没有 Tailscale 写进去的 100.64.0.0/10 路由ip route show table all | grep 100.64如果有类似下面的记录说明路由冲突已经存在100.64.0.0/10 dev tailscale0 proto kernel scope link src 100.x.x.x接着查默认路由记住你的 VPC 网关和主网卡名称ip route show default正常输出大概是default via 172.17.0.253 dev eth0 proto static metric 100记下这里的网关地址和网卡名后面加路由要用。2.2 验证到元数据服务是否通阿里云元数据服务可以通过 100.100.100.100 访问通常用 HTTP 请求测试curl -m 3 -s -o /dev/null -w %{http_code}\n http://100.100.100.100/latest/meta-data/如果返回 200说明元数据服务还能访问问题可能不在路由上。如果请求卡住超时或者返回 0那就很可能是被 Tailscale 路由劫持了。为了更直观可以强制走 eth0 再测一次curl -m 3 --interface eth0 -s -o /dev/null -w %{http_code}\n http://100.100.100.100/latest/meta-data/如果指定网卡后能通不指定就不通基本可以锁定是路由问题。2.3 看日志和抓包的关键点如果前面两步还不够确定可以看 Tailscale 的日志journalctl -u tailscaled -f或者看云助手的运行状态systemctl status aliyun需要注意不同发行版的服务名不完全一样可能是 aliyun、aliyun-assist 或 ecs_assist。如果云助手显示 active 但 Workbench 还是连不上就把重点放在网络层而不是软件本身。抓包也有很多讲究。这种问题抓 eth0 上的 100.100.100.100 流量最有说服力sudo tcpdump -i eth0 host 100.100.100.100 -nn如果发现请求根本没有出现在 eth0 上说明流量没走这张网卡路由劫持实锤了。3. 方案一给阿里云内网地址单独加一条高优先级路由推荐这个方案最稳因为它只针对阿里云元数据服务做“引流”不影响 Tailscale 本身的任何功能。Tailscale 继续用它的虚拟网段阿里云内网流量走原来的链路两边井水不犯河水。3.1 为什么加一条 /32 就能救回来Tailscale 写入的是 100.64.0.0/10掩码是 10 位。Linux 路由匹配时前缀越长优先级越高。我们手动加一条 100.100.100.100/32 的路由/32 的掩码比 /10 长所以这条路由会优先生效。效果就是访问 100.100.100.100 的请求不再进 tailscale0而是走 VPC 的默认网关和 eth0 网卡出去元数据服务立刻恢复。3.2 手动执行命令先从默认路由里提取网关和网卡名称GW$(ip route show default | awk /default/ {print $3}) DEV$(ip route show default | awk /default/ {print $5}) echo 网关: $GW, 网卡: $DEV然后添加 /32 主机路由sudo ip route add 100.100.100.100/32 via $GW dev $DEV metric 20这里把 metric 设成 20是为了让这条路由在系统里排到默认路由前面避免其他路由策略干扰。加完之后再验证ip route get 100.100.100.100看到类似输出就说明已经生效100.100.100.100 dev eth0 src 172.17.0.2再试一下curl -m 3 -s -o /dev/null -w %{http_code}\n http://100.100.100.100/latest/meta-data/应该能返回 200。3.3 让路由开机自启手动命令重启后会丢所以必须做成开机自动执行。最简单的做法是写一个 systemd 服务。如果系统有 /etc/rc.local 也可以用但 systemd 更通用不容易被安全策略干掉。创建服务文件 /etc/systemd/system/aliyun-metadata-route.service[Unit] DescriptionRoute Aliyun metadata traffic to local NIC Afternetwork-online.target Wantsnetwork-online.target [Service] Typeoneshot RemainAfterExityes ExecStart/sbin/ip route add 100.100.100.100/32 via $(/sbin/ip route show default | awk /default/ {print $3}) dev $(/sbin/ip route show default | awk /default/ {print $5}) metric 20 ExecStop/sbin/ip route del 100.100.100.100/32 [Install] WantedBymulti-user.target然后启用sudo systemctl daemon-reload sudo systemctl enable --now aliyun-metadata-route.service注意如果默认路由在服务启动时还没有生成ExecStart 里的命令可能取不到网关。可以在 ExecStartPre 加一个等待逻辑或者直接写死网关和网卡。比如你的 VPC 网卡确定是 eth0网关是 172.17.0.253那就直接写ExecStart/sbin/ip route add 100.100.100.100/32 via 172.17.0.253 dev eth0 metric 20这样更省事也更好排查。3.4 验证和回滚重启后记得确认服务状态systemctl status aliyun-metadata-route.service然后立刻打开 ECS 控制台的 Workbench 试一下连接。如果恢复正常说明问题解决。想要回滚也很简单sudo ip route del 100.100.100.100/32删除服务文件再禁用服务就行。4. 方案二让 Tailscale 不接管系统路由如果你的使用场景对 Tailscale 的性能要求不高或者你只是希望“能加入组网就行”可以考虑让 Tailscale 用用户态网络模式运行。这种模式下Tailscale 不会创建 tailscale0 网卡也不会往系统路由表里写任何路由自然就不会和阿里云元数据服务冲突。4.1 用户态网络模式怎么开如果你是用 tailscaled 服务启动的可以通过修改启动参数来切换。不同发行版改法略有差别Debian 和 Ubuntu 通常在 /etc/default/tailscaled 里有 FLAGS 变量。先看当前 tailscaled 是怎么启动的ps aux | grep tailscaled然后编辑 /etc/default/tailscaled把启动参数改成FLAGS--tunuserspace-networking重启服务sudo systemctl restart tailscaled sudo tailscale up如果系统没有 /etc/default/tailscaled可以创建 systemd drop-insudo mkdir -p /etc/systemd/system/tailscaled.service.d sudo tee /etc/systemd/system/tailscaled.service.d/userspace.conf /dev/null EOF [Service] ExecStart ExecStart/usr/sbin/tailscaled --tunuserspace-networking EOF sudo systemctl daemon-reload sudo systemctl restart tailscaled注意不同发行版 tailscaled 的路径可能不同建议先用 which tailscaled 确认。4.2 两种模式的取舍用户态网络模式的好处很明显不碰系统路由不碰 iptables和阿里云内网完全隔离。但代价是性能和功能都受限。项目默认 TUN 模式用户态网络模式是否需要 root 权限需要降低部分权限要求是否修改系统路由会不会是否修改 iptables会不会性能好一般直接访问组网设备的方式直接 IP 访问需要配置本地转发入口适合场景长期在线、需要高性能传输临时使用、只做普通客户端所以如果你已经重度依赖 Tailscale 组网比如 ECS 要单向访问家里 NAS或者要接收来自组网内其他设备的主动连接那方案二可能不适合直接用方案一更省心。4.3 顺手解决“浏览器打不开”的问题切换到用户态网络模式后首次登录 Tailscale 时会让你打开浏览器完成认证。有些无桌面环境连浏览器都没有命令容易卡住。解决办法很简单在执行 tailscale up 后终端会输出一个类似 http://login.tailscale.com/a/xxxx 的链接。不要直接输入回车而是手动复制链接到本地电脑的浏览器里打开登录之后 ECS 这边的授权就会自动完成。这个坑经常出现在云服务器上遇到就复制链接别在终端里死等。5. 方案三检查 exit node 和防火墙干扰路由冲突是 Workbench 断连最常见的原因但如果你加完路由还是不行就需要往另外两个方向排查exit node 和防火墙规则。5.1 看看自己有没有意外使用 exit node如果你在 tailscale up 时带了 --exit-node 参数那么 ECS 的全部互联网流量都会被送进组网链路包括访问阿里云元数据服务的流量。这种情况下即使你加了 100.100.100.100/32 路由也可能被策略路由覆盖。先用命令看看当前状态tailscale status如果看到当前节点旁边有 exit node 标记或者你确认自己设了退出节点先取消sudo tailscale up --exit-node在 Tailscale 的新版本里也可以用sudo tailscale set --exit-node取消之后再测 Workbench。如果你确实需要出口节点可以考虑使用出口节点允许列表只让特定网段走 exit node其他流量走本机默认路由避免把阿里云内网地址也带偏。5.2 关闭 netfilter 控制Tailscale 默认会管理一部分 netfilter 规则主要是 NAT 和转发规则。虽然这不是 Workbench 断连的主因但某些安全加固过的系统里可能会影响云助手 Agent 的通信。关闭 Tailscale 对 netfilter 的接管sudo tailscale up --netfilter-modeoff这个参数的意思是Tailscale 自己不去改 iptables 规则。如果之前有残留规则重启 tailscaled 后再 up 一次让规则重置。需要留意生产环境上不要随手关 netfilter除非你明确知道自己在做什么。关闭后如果还要做流量转发就得自己维护 iptables 规则。5.3 阿里云安全组的配合Workbench 走的是阿里云内部链路一般不受安全组入方向规则限制但如果你额外给实例配置了严格的出方向规则比如只允许特定目标 IP 通过那么云助手访问内部服务的请求可能被安全组挡住。这时候可以把阿里云公共云的服务网段和安全组放通。阿里云文档里可以查到对应的服务 CIDR 列表逐个加进安全组出方向规则。我实际操作中遇到的情况是安全组入方向规则往往被误认为影响 Workbench但其实出方向更值得检查。6. 我把修复过程串一遍 避坑清单最后把整个排查和修复过程按顺序整理一遍方便你直接照着操作。6.1 一个可以照抄的排查顺序第一步确认 Workbench 指的是阿里云 ECS 控制台的远程连接工具。如果搜到的是 MySQL Workbench 或 ANSYS Workbench 的教程先跳回正确的场景。第二步查看路由表ip route | grep 100.64第三步测试元数据服务curl -m 3 -s -o /dev/null -w %{http_code}\n http://100.100.100.100/latest/meta-data/第四步执行核心修复添加 /32 路由GW$(ip route show default | awk /default/ {print $3}) DEV$(ip route show default | awk /default/ {print $5}) sudo ip route add 100.100.100.100/32 via $GW dev $DEV metric 20第五步重启云助手确认状态sudo systemctl restart aliyun-assist第六步回到 ECS 控制台测试 Workbench 连接。这套顺序对大多数发行版都适用。我前前后后按照这个流程处理过三四台机器基本每次都在第五步之前就恢复了。6.2 几个容易再次踩到的坑第一不要只加临时路由就完事。服务器重启后临时路由会丢Workbench 又会断。务必做成 systemd 服务或写进开机启动脚本否则下次重启你会以为问题复发了。第二不要在路由还没验证成功时就卸载 Tailscale。问题根源是网段冲突不是 Tailscale 本身。卸了再装下次照样断。优先用加路由的方式解决保留 Tailscale 功能。第三不要在 ECS 上把 Tailscale 当成默认出口。即使你没有显式设置 exit node某些配置方式也可能导致全部流量进入组网链路。如果真的需要出口节点设置好允许列表别让 100.100.100.100 被带进去。第四如果同时跑着 Docker、frp 这类会改 iptables 的工具可能会让排查变复杂。可以先临时停掉 Docker 网络或者用 systemctl stop docker 试一下确认是否和防火墙规则叠加。6.3 最后对一下“Workbench”到底是哪个开头说了这里的 Workbench 是阿里云 ECS 控制台自带的远程连接功能。如果你是在搜 MySQL Workbench 连不上数据库或者在搜 ANSYS Workbench 模块异常那和本文场景不同。不过“断连”的排查思路是通用的先看服务端日志再看网络路径最后看路由和防火墙。只要抓住这条主线不管哪种 Workbench 出了问题都能很快定位到具体环节。我在实际处理这个问题的过程中最深刻的体会是云服务器上的很多“奇怪断连”往往不是软件挂了而是路由表被某个工具悄悄改了。遇到这种情况别急着重装先用 ip route 看一眼流量走向再决定要不要动刀。加一条 /32 路由这个操作五分钟能解决但能帮你省下大半天排查时间值得记在本子上。