|
|
@@ -0,0 +1,47 @@
|
|
|
+---
|
|
|
+title: RustDesk 连接被拒 - Clash TUN 干扰
|
|
|
+date: 2026-08-23
|
|
|
+tags: [RustDesk, Clash, TUN, 远程连接, 排错]
|
|
|
+---
|
|
|
+
|
|
|
+# RustDesk 远程连接被拒（Clash TUN 干扰）
|
|
|
+
|
|
|
+## 问题现象
|
|
|
+
|
|
|
+- MacBook Air（公司网络 192.168.7.x）通过 **ID 连接** 家庭 Mac mini（ID: 1 525 811 388）提示「连接被拒绝」
|
|
|
+- 改用 **IP 直连**（10.10.10.21）完全正常
|
|
|
+- 自建 ID/中继服务器（aliyun 119.23.65.115 的 hbbs/hbbr）端口全开、运行正常
|
|
|
+
|
|
|
+## 排查过程
|
|
|
+
|
|
|
+1. 确认服务器正常：119.23.65.115 上 hbbs.exe/hbbr.exe 运行中，21115-21119 全部监听，无异常
|
|
|
+2. 确认 Mac mini 正常：RustDesk --server 进程运行中，21118 端口开放
|
|
|
+3. 双向日志交叉验证（本机 `~/Library/Logs/RustDesk/`，Mac mini `~/Library/Logs/RustDesk/server/`）：
|
|
|
+ - Mac mini 向本机公网 IP（111.121.127.7）打洞全部 `Failed to connect`
|
|
|
+ - 本机 punch 到 Mac mini 显示「TCP Hole Punched」假成功，约 3 秒后被 RST（Reset by the peer）
|
|
|
+ - 打洞失败后没有走中继（hbbr）兜底
|
|
|
+4. IP 直连走的是公司→家 VPN 隧道（Mac mini 日志显示连接来源为 10.10.10.23 群晖），绕过公网打洞，所以正常
|
|
|
+
|
|
|
+## 根因
|
|
|
+
|
|
|
+- 本机 Clash Verge 开启了 **TUN 模式**（虚拟网卡 198.18.0.1）
|
|
|
+- TUN 模式下 RustDesk 打洞流量被 Clash 接管，从代理出口发出，**源 IP 变成代理节点 IP**，与 Mac mini 看到的本机真实公网 IP（111.121.127.7）不一致
|
|
|
+- 双向打洞无法交汇（Mac mini 打洞打不到本机真实 NAT 映射）→ P2P 直连失败 → ID 连接被拒绝
|
|
|
+- IP 直连走 VPN 隧道（公司→群晖→内网），不经过公网打洞，所以不受影响
|
|
|
+
|
|
|
+## 解决方案
|
|
|
+
|
|
|
+- **连接前关闭 Clash TUN 模式**（或切回系统代理模式），ID 连接立即恢复
|
|
|
+- 日志中 punch 源地址 `198.18.0.1` 就是 TUN 虚拟网卡 IP——看到它就应想到 TUN 干扰
|
|
|
+
|
|
|
+## 经验教训
|
|
|
+
|
|
|
+- Clash TUN 模式影响的不只是浏览器流量，**P2P 类应用**（RustDesk/远程桌面/游戏联机/语音）的打洞都会被破坏，且表现为「打洞假成功后被 RST」
|
|
|
+- 排查远程连接问题时，**先确认本机是否开了 TUN/全局代理**，再查服务器和网络
|
|
|
+- 不想全局关 TUN 的话，可尝试在 Clash 规则里给 RustDesk 流量加 DIRECT 分流（本机未验证，TUN 出口 IP 一致性问题可能仍需关闭 TUN 解决）
|
|
|
+
|
|
|
+## 相关文档
|
|
|
+
|
|
|
+- `08-个人空间/账号密码/Rustdesk-key.md` — 各设备 RustDesk ID 记录
|
|
|
+- `05-系统配置/Windows/Rustdesk-windows.md` — Windows 自建 hbbs/hbbr 服务器
|
|
|
+- `02-家庭实验室/Docker服务/Docker-compose合集/Rustdesk.md` — Docker 版自建服务器
|
