针对深信服 aTrust 接管路由导致 Clash TUN 模式失效的问题,本文提供了一套基于轻量级虚拟机的共存方案。(后文记录了踩坑过程)

解决 aTrust 与 Clash TUN 冲突及服务器全能分流
9 mins
views

最近 PC 上有开启 TUN 模式的需求,同时作为研零参与项目用到实验室服务器时,需要使用深信服 aTrust 连接上科大校内网后,才能 ssh 连接到服务器。

在 aTrust 连接校内网的情况下,开启 clash TUN 模式后,发现 aTrust 的虚拟网卡失效。在开启 TUN 模式下,开启 aTrust 连接内网,由于 atrust 接管系统路由,同样导致与 TUN 模式冲突。

另外,实验室服务器网络无法跨越 GFW,经常导致在配置项目环境时因网络问题而浪费过多时间。

针对以上问题,本文就来分享下对应的解决方案,希望对同样有此需求的友友有所帮助。

解决思路h2

  1. 使用轻量级 xUbuntu 虚拟机运行 aTrust,通过 SSH 动态转发将内网流量暴露给物理机。
  2. 在远程实验室服务器上部署独立 Mihomo 内核,不依赖本地电脑的流量反传。

解决 aTrust 与 Clash TUN 冲突h2

最初直接 google 到一个使用 Docker 进行隔离的方案,其方法是将 aTrust 关进容器里。于是我也尝试使用 docker-easyconnect 项目,配合 VNC Viewer 打开 aTrust 并登录。但操作后,发现在 Docker 的 VNC 环境中,点击登录跳转出的 URL 无法被宿主机浏览器正确回调。容器内缺乏完整的浏览器环境,而上科大 VPN 需要通过网页进行统一师生认证才能登录,故此方法最终因无法登录 aTrust 上科大 VPN 而失败。

既然 Docker 缺的是完整的 GUI 环境,那我就给他一个最轻的 GUI。于是便决定使用虚拟机代替docker的方法,也就是本文的解决方法。

1. 准备工作h3

  • 虚拟机软件:VMware Workstation Player (推荐) 或 VirtualBox。
  • Linux 镜像:xUbuntu 24.04 LTS (推荐,XFCE 桌面仅占用 500MB 内存)。
  • SSH 工具:Windows 需安装 Git (自带 connect.exe 工具) 或使用 Nmap 的 ncat

2. 虚拟机配置h3

安装虚拟机时,网络适配器选择 NAT 模式

NOTE

校园网通常对 MAC 地址有严格限制。桥接模式会赋予虚拟机一个新的 MAC 地址,导致无法通过校园网认证。而 NAT 模式让虚拟机共享宿主机的网络连接,对外隐藏,最稳定。

虚拟机配置图
虚拟机配置图

3. 安装 aTrust 与 SSH 服务h3

进入虚拟机桌面后,需安装:

  • aTrust:从学校官网下载 Linux 版 .deb 包,使用终端安装,安装后正常登录。

    Terminal window
    sudo apt update
    sudo apt install ./aTrustInstaller_amd64.deb
  • SSH 服务:

    Terminal window
    sudo apt install openssh-server

4. SSH 代理脚本h3

为了防止宿主机PC休眠导致 SSH 隧道断开,可以做一个脚本来自动监控并重连。

在虚拟机桌面新建文件 proxy_guard.sh,写入以下内容:

proxy_guard.sh
#!/bin/bash
# === 配置区 ===
TARGET_IP="127.0.0.1" # 连接自身最稳定
USER="root" # 替换为你的虚拟机用户名
PORT="1080" # 暴露的 SOCKS5 端口
# =============
is_running=false
while true; do
# 检查端口监听,2>/dev/null 屏蔽系统权限警告
if netstat -tulpn 2>/dev/null | grep -q ":$PORT "; then
if [ "$is_running" = false ]; then
echo "[$(date +%T)] 代理已连接 (Port $PORT)"
is_running=true
fi
else
echo "[$(date +%T)] 检测到代理断开,已重连"
is_running=false
# 清理残留进程
pkill -f "ssh -N -D 0.0.0.0:$PORT" 2>/dev/null
# 启动 SSH 动态转发
# -f: 后台运行; -o StrictHostKeyChecking=no: 跳过指纹确认
ssh -f -o StrictHostKeyChecking=no -N -D 0.0.0.0:$PORT $USER@$TARGET_IP
sleep 1
fi
sleep 3
done
TIP

记得使用 chmod +x proxy_guard.sh 赋予执行权限,并建议创建一个桌面启动器(Launcher),勾选“在终端中运行”,这样双击即可启动并看到状态日志。

虚拟机配置后展示图
虚拟机配置后展示图

5. 宿主机配置h3

此时虚拟机已经开启了 1080 端口作为通往学校内网的隧道,我们需要配置宿主机的 SSH 客户端,让它在连接学校服务器时自动走这条隧道

以Windows宿主机为例,打开 C:\Users\你的用户名\.ssh\config 文件,添加以下配置:

config
# 实验室服务器IP
Host xx.xx.xx.xx
HostName xx.xx.xx.xx
User root # your username
# 使用 Git 自带的 connect.exe 工具,将流量转发给虚拟机的 1080 端口
# 这里需要根据你 Git 的实际安装路径修改 connect.exe 的位置
# 192.168.192.128 是虚拟机的 IP 地址
ProxyCommand "D:\Develop\Git\mingw64\bin\connect.exe" -S 192.168.192.128:1080 %h %p
# 顺便做一个端口映射,方便后续使用 MetaCubeXD 连接服务器上的 Web 面板,22790 可换为其他自定义端口
LocalForward 22790 127.0.0.1:22790

解决服务器端跨越GFWh2

IMPORTANT

以下解决方法是基于本地电脑已具备使用Clash Verge等工具能够跨越GFW的情况下进行的。 如果友友本地电脑还不能跨越GFW,可参照 一份不负责任的机场使用手册翻墙与科学上网指南 等进行了解与配置。

为了解决服务器下载环境慢的问题,这里直接在服务器上部署独立的 Mihomo (Clash Meta) 内核。

NOTE

解决这一part我先前是将服务器的流量通过 SSH 隧道传回 Windows,利用 Windows 的 Clash 翻墙。虽然没直接在服务器内部使用Clash,但有挺多缺点的:

  • 严重依赖 PC 的网络状况和上传带宽。
  • 容易和同时连接实验室服务器的其他同学有端口冲突。
  • PC 关机,服务器就断网。

最终为了彻底解耦,还是决定在服务器上直接运行 Mihomo (Clash Meta) 内核。

1. 部署 Mihomoh3

下载 mihomo-linux-amd64 二进制文件上传到服务器,并复制宿主机Clash内机场的 config.yaml 配置文件,放到与解压后的 mihomo-linux-amd64 文件同文件夹下。

修改config.yaml 配置文件部分配置,建议将 external-controller 设置为 0.0.0.0:22790 以便通过上一步的 SSH 隧道在本地管理。

下面是我的机场config.yaml 配置文件中修改的部分供参考:

config.yaml
mixed-port: 22789 # 22789 可换为其他服务器端口
allow-lan: true
bind-address: '*'
mode: rule # 可换为其他 Clash 模式
log-level: info
# 22790 可换为其他自定义端口,但需与 C:\Users\你的用户名\.ssh\config 文件内 LocalForward 保持一致
external-controller: '0.0.0.0:22790'
unified-delay: true
tcp-concurrent: true
secret: '123456' # 可换为其他密码

2. 持久化运行h3

为了保证断开 SSH 后代理依然运行,使用 tmux 挂载进程:

Terminal window
tmux new -s mihomo-linux-amd64
./mihomo-linux-amd64 -d .
# 按 Ctrl+B 然后按 D 分离会话

3. 快捷别名配置(可选)h3

在服务器的 ~/.bashrc 中添加别名,方便一键开关代理:

Terminal window
# 开启代理 (指向 Mihomo 的混合端口 22789)
alias gfw-bye="export all_proxy=socks5://127.0.0.1:22789 && export http_proxy=http://127.0.0.1:22789 && export https_proxy=http://127.0.0.1:22789 && echo 'Proxy ON'"
# 关闭代理
alias gfw-back="unset all_proxy http_proxy https_proxy && echo 'Proxy OFF'"

后续只需在服务器输入 gfw-bye,即可使服务器翻阅GFW,不消耗本地电脑的上传带宽。

总结h2

至此,就能构建一个同时可开启 aTrust 和 TUN 的环境:

  1. 物理机(本地电脑) :Clash TUN 可开启,不用再担心与aTrust冲突。
  2. 虚拟机:挂后台维持aTrust隧道,同时也能通过虚拟机完全隔离aTrust,避免深信服后台网络监控。
  3. 服务器:独立跨越GFW能力,环境配置、下载模型数据集等不再卡顿。

P.S. 第一次写博文,可能有一些过程描述或操作不太清楚的地方,如有问题可以发表评论询问告知,希望能帮助到你 :)


Author: Antray
Post: 解决 aTrust 与 Clash TUN 冲突及服务器全能分流

Comments