上个月出差第三天赶上一个尴尬场景项目临时加了一批数据处理任务脚本全在办公室一台内网机器上。这批任务需要定期查看进度、偶尔手动重启失败进程平时在机器边上一伸手就能干完的事人在几百公里外就只能干瞪眼。那台机器躲在运营商NAT后面没有公网IP没有可用的入站通道我在外面连看一眼脚本心跳日志都做不到。第三方远程控制软件我其实用过好几款免费版限速限画质高峰期连接还得排队某次还收到过“疑似商用”的弹窗提示。数据经过第三方服务器中转心里也不踏实——脚本输出里有敏感数据传出去总归不放心。纠结了两天后我下了个决心用自己的云服务器搭一套RustDesk公网中继服务器把内网机器纳入自己的远程控制网络从注册、握手到数据转发全部走自有设施。这篇记录就是那次从0到1的完整搭建过程包括架构原理、三种部署方式、客户端接入、安全加固、故障排查和实测体验。手里有一台公网服务器、想摆脱第三方远控约束的朋友可以直接照着走一遍暂时没有服务器的也能从原理部分先评估这套方案到底值不值得。1. 为什么自建RustDesk中继把账算清楚再动手1.1 我遇到的实际远程控制难题先说说我当时的具体处境。办公室那台机器跑的不是一次性任务而是跨好几天的批处理流程脚本每隔半小时写一次进度文件偶尔会卡住需要手动干预。任务失败不会自动恢复晚发现一小时就白等一小时。这种情况必须有一个能随时看屏幕、随时敲命令的远程通道。但内网机器最大的问题是“没有入口”。办公室宽带是从运营商租用的普通宽带IP是私网地址外面任何主动连接都进不来。端口映射这条路走不通因为运营商把入站端口基本封死了申请公网IP还要额外加钱流程麻烦。用第三方工具的话安装倒是简单但免费版画质被限制得很死远程看个终端都糊成一团传输的屏幕数据还要经过厂商服务器数据路径完全不受自己控制。市面上几款主流软件我都装过免费档各有各的憋屈有的限设备数有的限会话时长有的干脆弹窗要求付费。把批处理任务挂在别人家的服务器上对我来说既不稳定也不安心。1.2 第三方远控、端口映射、自建中继怎么选在做决定之前我把三条路摆在一起认真比了比方案数据路径成本主要限制适合场景第三方远控软件客户端 - 厂商服务器 - 被控端免费或订阅限速、限设备、可能误判商用临时应急、对数据不敏感公网端口映射客户端 - 被控端公网端口需另申请公网IP家宽大多封入站端口暴露端口风险大少数有公网IP的环境自建RustDesk中继客户端 - 自建服务器 - 被控端云服务器费用需要维护服务器、懂一点Linux长期使用、数据敏感端口映射这条就算运营商肯给公网IP把机器的远程桌面端口直接暴露到公网也不合适扫描器一小时能扫上千次安全风险太高。第三方远控的便利性毋庸置疑但数据始终要绕一圈别人家的机房这个账我越算越觉得不划算。RustDesk自建中继相当于把“信令服务器”和“数据转发服务器”都攥在自己手里客户端连到哪、数据走哪条链路全部由自己说了算。1.3 RustDesk的优势在哪里选RustDesk并不是拍脑袋而是看了一圈开源远控方案之后的结果。第一它完全开源客户端和服务端代码都在GitHub上公开自己能审计也能改不存在“黑盒”问题。第二它原生支持自托管服务端分成ID服务器和中继服务器两个组件分别解决“找到设备”和“转发数据”两个问题架构很清晰。第三它优先尝试P2P直连只有打洞失败才走中继这意味着很多情况下屏幕数据根本不经过服务器服务器带宽压力会小很多。第四客户端覆盖Windows、macOS、Linux、Android、iOS手机、电脑、平板都能纳进来。第五没有设备数限制不会因为你每天用就提示“商用”更不用交订阅费。当然自建也有自建的代价你需要一台有公网IP的服务器需要给防火墙和安全组开口子需要偶尔看一眼服务器还活着没。这跟第三方软件双击就用的体验完全不一样。但如果你跟我一样对数据路径有执念那这笔投入完全值得。2. 连接链路拆解一次远控请求走完的路径2.1 三个核心角色hbbs、hbbr、客户端RustDesk的服务端不是一个大一统程序而是由两个独立组件配合工作理解这两个角色是接下来配置的基础。hbbs是ID/信令服务器可以理解成一本“通信录签到簿”。每一台安装了RustDesk客户端的设备启动后都会向hbbs报到告诉它“我是哪个ID、我现在在哪个网络地址”。当你想连某台机器时控制端也是先问hbbs“我要找的ID被控端现在在哪”hbbs会把它记录的地址信息交给你同时把控制端的地址也推给被控端。整个过程和打电话前先查号台一样hbbs只负责牵线搭桥不负责传输屏幕数据。hbbr是中继服务器负责真正的数据转发。当两端尝试直连失败下面会讲为什么失败hbbr就充当中间人控制端把鼠标键盘指令发给它它转给被控端被控端把屏幕画面发给它它转回控制端。这就像两个人打电话打不通只能通过人工总机转接一样总机本身不产生内容但负责把每一句话原样递到对面。客户端则分成控制端和被控端两个角色但从部署角度看它们用同一个安装包配置好同一个服务器地址和公钥就自动组成一个私有远程控制网络。2.2 从点击连接到画面出现的完整流程一次成功的远程连接背后经历了这样一串步骤控制端输入被控端ID向hbbs发起“寻址”请求。被控端上电后一直在和hbbs保持心跳连接hbbs拿到控制端和被控端两边的公网IP和端口信息并把它们互相交换给对方。两边拿到对方的公网地址后尝试建立UDP打洞连接。因为家里宽带普遍是NAT环境出口流量会形成一个临时映射双方同时向对方“最近使用的那个公网端口”发包就能把这条通道点着。打洞成功两端建立P2P加密直连屏幕数据不走服务器打洞失败客户端就自动找到hbbr走中继转发完成连接。连接建立后RustDesk会持续维护会话传输键盘鼠标事件和屏幕画面直到手动断开。那为什么打洞会失败这取决于两边NAT的类型。如果有一端是严格的对称NAT或者上游设备开启了严格的端口限制UDP打洞就很难成功。比如企业网关、部分运营商CGNAT环境这时候hbbr就派上用场了。所以“P2P优先、中继兜底”是这套架构最实用的设计它让大多数情况下不占服务器带宽又保证了极端情况下一定能连上。2.3 记住这些端口后面排查全靠它们服务器端涉及五个端口我直接整理成表端口协议所属组件作用21115TCPhbbsNAT类型探测打洞前的能力协商21116TCP和UDPhbbsID注册、心跳、设备寻址最核心的端口21117TCPhbbr中继数据转发所有走中继的屏幕数据都过它21118TCPhbbs浏览器Web客户端连接可选21119TCPhbbr浏览器Web客户端中继可选前三个端口必须同时放行而且21116要特别注意TCP和UDP都要开很多教程只开了TCP结果客户端永远提示“连接超时”其实就是UDP被防火墙吞了。21118和21119是给Web客户端用的如果你只打算用原生应用远程这两个端口完全可以不开少暴露两个端口总归是好事。3. 服务器部署实录脚本、Docker、编译三条路3.1 服务器选型与部署前准备部署RustDesk服务端对配置要求并不高1核1G内存的入门云服务器就能跑得很轻松。我用的就是一台1核1G的Debian 12机器装完系统后内存占用大约在200MB以内剩余资源完全够用。带宽是相对重要的指标。因为中继模式下屏幕画面的码率直接由服务器转发带宽决定如果你经常需要远程操作高分辨率屏幕建议选择5Mbps以上的带宽套餐。地域选择上离你主要活动区域越近延迟越低这个在云厂商控制台选地域时注意一下就行。部署前还建议做两件事。第一给服务器配置一个固定的公网IP云服务器默认就有没什么可操心的。第二如果你手里有域名提前把一条A记录解析到服务器IP之后所有客户端配置都填域名而不是IP这样哪天服务器IP变了只要改解析所有设备都不用重配。没有域名就填IP也不影响使用。3.2 官方脚本一分钟跑起来最省事的部署方式是直接跑官方脚本curl -L https://raw.githubusercontent.com/rustdesk/rustdesk-server-demo/master/install.sh | bash脚本会把hbbs和hbbr安装为系统服务自动创建工作目录并启动。执行完后检查服务状态systemctl status rustdesk-hbbs systemctl status rustdesk-hbbr看到activerunning就说明两个进程都起来了。这套方式的优点是省心程序文件和服务配置都由脚本管好适合第一次接触RustDesk、想快速验证效果的人。但它的缺点也很明显升级不方便。RustDesk服务端更新频率不算低每次升级要重新跑脚本或者手动覆盖二进制服务文件和工作目录得自己盯。另外脚本直接放在了系统层如果哪次手滑改了系统环境排查起来会比较费劲。所以我个人更推荐下一种方式。3.3 Docker Compose我推荐的生产级方式用Docker部署的好处有三个环境隔离、升级简单、迁移方便。以后服务端版本更新只要重新拉一次镜像、重启容器就行不会污染宿主机系统。在服务器上安装好Docker和Docker Compose插件后新建一个目录存放配置比如/opt/rustdesk在里面放一份docker-compose.ymlversion: 3 services: hbbs: image: rustdesk/rustdesk-server:latest container_name: hbbs command: hbbs -r 你的服务器公网IP或域名:21117 ports: - 21115:21115 - 21116:21116 - 21116:21116/udp volumes: - ./rustdesk-data:/data restart: unless-stopped hbbr: image: rustdesk/rustdesk-server:latest container_name: hbbr command: hbbr ports: - 21117:21117 volumes: - ./rustdesk-data:/data restart: unless-stopped注意command: hbbs -r 你的服务器公网IP或域名:21117这行-r参数的作用是告诉hbbs“中继服务器的地址在哪里”客户端以后只要配置了ID服务器地址就能自动发现中继服务器。如果填IP以后服务器换IP就要改客户端填域名就灵活得多。启动docker compose up -d首次创建数据目录后服务器身份密钥会生成在./rustdesk-data里这个目录一定要备份。查看公钥内容cat ./rustdesk-data/id_ed25519.pub这串字符串就是后面要给所有客户端填的Key先存到备忘录里。3.4 防火墙与安全组放行服务跑起来后第一件事是确认端口能从外部访问。Debian/Ubuntu一般默认开UFW先执行ufw allow 21115/tcp ufw allow 21116/tcp ufw allow 21116/udp ufw allow 21117/tcp然后最关键的一步去云厂商控制台的安全组里加同样的放行规则。我踩过这个坑服务器本地防火墙全部放开了客户端还是连不上检查到最后发现是云平台安全组压根没放行21117端口。安全组是云平台在虚拟机外面那道独立的防火墙两层都得开少一层都不行。3.5 服务自启与运行验证Docker Compose配置里的restart: unless-stopped已经保证了容器在宿主机重启后自动拉起脚本方式则需要执行systemctl enable rustdesk-hbbs systemctl enable rustdesk-hbbr都配置好后用以下命令确认服务真的在监听netstat -tlnp | grep -E 2111[5-9] ss -ulnp | grep 21116再从你的电脑测试端口可达性nc -vz 服务器IP 21115 nc -vz 服务器IP 21116 nc -vz 服务器IP 21117如果nc命令提示连接成功说明服务器端已经准备好接下来开始折腾客户端。4. 客户端接入把内网机器纳入中继网络4.1 客户端ID是怎么分配的很多人在配置RustDesk时会遇到一个迷惑明明我在官方服务器上见过的ID怎么填了自建服务器地址之后ID变了原因在于客户端ID不是“机器硬件出生的身份证”而是首次连接服务器时由服务器分配的临时标识。换成自建服务器之后等于换了一个新的“户籍系统”ID自然重新分配。理解了这一点就能接受一个经验法则配置好自建服务器之后就尽量别切回官方服务器来回切会导致你记不住哪台机器绑哪个ID。4.2 Windows客户端配置步骤从RustDesk官网下载Windows客户端安装后打开主界面右上角菜单里进入“设置”找到“网络”页。这里有两种填法。稳妥起见建议把三个字段都填上ID/中继服务器地址栏填你的域名或IP:21116中继服务器地址栏填你的域名或IP:21117Key栏粘贴之前备份的id_ed25519.pub内容填完点“应用”设置立即生效。回到主界面可以看到本机ID已经变成自建服务器分配的新ID。这时在另一台设备上配置同样的服务器地址和Key输入这台机器的ID就能互相连接。一个小提示客户端会记住服务器配置但不会自动重启连接链路。如果之前在官方服务器网络里填好新配置后最好完全退出RustDesk再重新打开避免旧连接残留。4.3 Android手机端配置与画面参数手机端是最常用的“兜底手段”出差路上没有电脑时全靠它。Android客户端在“设置”里有同样的ID/中继服务器和Key输入框照填就行。手机控制电脑时建议在连接界面把分辨率调到1280x720或者1366x768帧率控制在15fps左右。这样做的原因是手机屏幕本来就小分辨率太高不仅看不清细节反而白白消耗服务器带宽和电量。实测下来720p配合15fps在中继模式下操作远程终端非常跟手拖动窗口、敲命令基本没有可感知的延迟。4.4 内网机器的网络前提准备被控端那台内网机器还需要做一些基本设置否则远程起来会各种别扭。第一给被控机器在内网里设置一个固定的DHCP保留地址避免路由器重启后IP变化影响同网段直连。虽然外网远控走的是ID和中继不依赖内网IP但固定下来总是省心。第二如果机器可能关机需要在主板BIOS和网卡驱动里开启网络唤醒WOL配合智能插座远程开机才真正做到了“人不到场也能恢复服务”。第三关闭系统自动睡眠和休眠尤其是合盖动作Windows笔记本在设置里把“合上盖子”改成“不采取任何操作”。第四在RustDesk被控端设置一个高强度的访问密码默认的临时密码每次重启都会变长任务场景下不如固定密码配合强口令来得可靠。5. 安全加固中继服务器不能裸奔5.1 端口暴露后的攻击视角RustDesk服务端一旦部署在公网21115-21119这些端口就对全网可见。扫描工具每时每刻都在扫全网的开放端口只要发现开放端口就会尝试探测服务类型、跑弱口令、打已知漏洞。所以这类自建服务不能当“隐形设备”放着不管必须主动做几层防护。我的安全策略核心是“最小暴露面”能不给公网看到的端口就不给能给特定IP用的就限定IP必须对全网开放的端口则做连接数限制。先把21118和21119关掉因为它们对应Web客户端不用就直接不映射这两个端口。这样暴露给公网的就只剩21115、21116、21117三个必要端口。5.2 iptables限制与并发兜底对于21115这种只用于NAT探测的端口完全可以只允许自己的常用出口IP访问。加入如下规则# 只允许你的常用IP访问21115 iptables -A INPUT -p tcp --dport 21115 -s 你的常用公网IP -j ACCEPT iptables -A INPUT -p tcp --dport 21115 -j DROP21116和21117必须对全网开放无法按来源IP过滤但可以限流。我用两条规则做了基本保护# 限制中继端口单IP并发连接数超过即拒绝 iptables -A INPUT -p tcp --dport 21117 -m connlimit --connlimit-mask 32 --connlimit-above 30 -j REJECT # 限制21116端口的UDP接收速率上限 iptables -A INPUT -p udp --dport 21116 -m limit --limit 100/s --limit-burst 200 -j ACCEPT iptables -A INPUT -p udp --dport 21116 -j DROP这些规则直接用iptables命令添加重启后会消失需要安装iptables-persistent包把它固化成规则文件。操作时务必小心先放行自己的IP再执行丢弃规则不然容易把自己锁在门外。5.3 防暴力破解与日志巡检远程控制服务最容易被人盯上的攻击路径就是密码爆破。RustDesk客户端本身支持设置访问密码这里的密码务必用复杂口令不要和系统登录密码重复。服务端SSH登录则建议改用密钥认证并禁止root密码登录。通过对SSH这层加安全策略再配合RustDesk端的高强度密码两道防线基本能挡住绝大多数简单攻击。日志巡检也很重要。Docker方式查看日志很方便docker logs hbbs --tail 100 docker logs hbbr --tail 100脚本方式则用journalctl -u rustdesk-hbbs -n 100 journalctl -u rustdesk-hbbr -n 100我每周会花几分钟扫一遍日志重点看有没有大量来自同一IP的连接尝试。用脚本方式的话可以写一个简单的计数器脚本统计异常IP并输出告警。目前跑了一个月日志里没出现明显的爆破迹象但巡检这个习惯还是保留下来了。5.4 密码策略与访问习惯自建服务器的访问习惯也要立好规矩。我给不同设备设置了不同的RustDesk密码避免一台设备被攻破后所有机器都被拖下水。另外不要贪图方便把Key和密码贴在客户端界面上尤其是挂着公网的电脑。Key本身不是密码它是用于验证服务器的身份防止中间人伪装成你的服务器所以它泄漏的后果没有密码泄漏那么严重但也最好妥善保存。客户端版本要保持更新。RustDesk迭代比较快新版本会修复安全问题所以维护时注意跟进官方发布定期升级客户端和服务端镜像。服务器数据目录里那对id_ed25519和id_ed25519.pub密钥文件记得随备份存档一起保存丢了它们虽然不会造成数据损失但服务器重建后所有客户端都得重新配一遍Key麻烦得很。6. 故障排查对照与实测体验6.1 四个典型故障的完整排查链路我搭建和使用过程中遇到过几类典型问题记录下完整的排查思路比单纯贴答案有用得多。故障一连接一直停留在“连接中”然后超时这是我遇到的第一个问题。症状是客户端能正常显示ID输入对端ID后一直转圈最终提示连接失败。排查步骤# 1. 确认服务端进程在监听 ss -tlnp | grep 21117 # 2. 从本地机器测试端口是否可达 nc -vz 服务器IP 21117结果发现21117端口完全不通。再查云平台安全组发现只放行了21115和21116漏掉了21117。补齐放行规则后秒连。这类问题90%出在防火墙或安全组先从端口可达性开始排查。故障二连接成功但提示“密钥不匹配”这个症状出现说明客户端连上了服务器但服务器身份对不上。多半是Key没填对或者服务器数据目录换过导致公钥变了。排查时重新执行cat ./rustdesk-data/id_ed25519.pub逐字符核对客户端里填的Key重新粘贴保存后重启客户端。故障三手机端能连上但画面模糊卡顿这未必是故障而是参数不合理。先用手机端连接信息面板看当前是“直连”还是“中继”。如果是中继模式说明打洞没成功画面数据全部走服务器转发此时带宽决定体验上限。把分辨率降到1280x720、帧率降到15fps画面立刻流畅很多。如果直连还卡那就是两端网络或设备性能的问题和中继无关。故障四切换网络后时好时坏有时候在家能连上到酒店连不上原因通常是NAT类型变了。酒店、公司网络的NAT策略比家里的更严格P2P打洞时好时坏。这种情况下可以在客户端设置里勾选“总是通过中继服务器连接”牺牲一点延迟换来连接可靠。我实测中继模式的延迟大约比直连高几十毫秒日常敲命令、看脚本日志完全感觉不到差别。6.2 中继模式延迟与画质实测跑了一个月我记录了几组典型数据供参考实际数值受两端网络环境影响很大别当成绝对标准同运营商城域网P2P直连延迟大约在10ms以内中继模式大约50ms上下。跨运营商连接中继模式在80到150ms之间远控终端操作依然可用拖动窗口能感觉到轻微粘滞但在可接受范围。画质1080p桌面在中继模式约2Mbps码率下文字边缘略微发虚调到4Mbps后已经非常接近直连效果。手机上720p则完全够用。带宽占用方面中继模式单路会话大约吃掉2到4Mbps。所以5Mbps带宽的服务器大约能支撑一路较好画质如果你打算同时远程两台机器建议选10Mbps或以上。6.3 跑了一个月之后的优化建议这套自建中继跑了一个月整体非常省心只有一条经验值得单独拎出来说备份。我把docker-compose.yml、.env文件和rustdesk-data目录打包存了一份放到对象存储里还写了一个一键恢复脚本顺序是先安装Docker、解压备份、docker compose up -d完事。上周我故意拿一台新服务器做了恢复演练从空系统到中继服务全部恢复耗时五分钟内网那台机器的客户端配置完全不用动因为服务器的域名和Key都没变客户端只认域名Key不关心服务器物理机在哪。另外就是版本管理。我观察到大版本升级可能会改变客户端和服务端的握手协议所以养成了“先在一台测试机上升级客户端保持服务器端暂时不动”的习惯确认没问题再全量升级。这个习惯帮我避开了不少兼容性小坑。最后说一个小技巧如果你出差时需要看的机器多建议把常用设备在RustDesk里都备注好ID手机端和电脑端保持同步配置这样换设备登录时不用每次回忆ID。我把这套配置固化成了自己的部署清单下次再给其他机器接入照着清单五分钟搞定基本不用动脑。远程控制这件事自建方案和第三方工具的差别就像“自己家钥匙”和“托管在酒店的钥匙”。第三方省心但钥匙始终有一把放在别人手里自建费力但每一把钥匙都在自己兜里。这台中继服务器上线之后我最大的感受是踏实——从注册、心跳到屏幕数据整条链路都是自己的出任何问题都能查日志、能定位、能控制。如果你也想把内网机器彻底管起来照着这篇记录试一次应该能少走不少弯路。
