摘要
本文记录了一次 RustDesk 自托管服务器 的完整部署实践，采用 Docker + host 网络模式，并结合 宿主机防火墙 与 边界路由器端口转发，在家庭网络环境中实现了稳定可用的远程桌面服务。
出于安全考虑，本文 对所有本地路径、端口号与网络细节进行抽象处理，仅保留架构思路、配置原则与验证方法，确保内容可理解、可复现，但不暴露任何可被直接利用的信息。
一、整体架构思路
RustDesk 官方在 Docker 场景中推荐使用 host 网络模式运行服务，其核心特征包括：
- 容器直接使用宿主机网络栈
- 服务端口直接监听在宿主机
- 不再使用 Docker 的端口映射机制
- UDP 穿透与来源地址识别更加稳定
因此，网络安全边界主要由两部分构成：
- 宿主机防火墙（如 UFW / nftables）
- 上游路由器的端口转发与访问控制
二、Docker 服务的统一目录管理（路径脱敏）
所有 Docker 服务均集中放置在一个 统一的服务根目录 下，每个应用使用独立子目录管理自身配置与数据，例如：
/path/to/docker-services/
└── rustdesk/
├── compose.yml
└── data/
这种结构的优点在于：
- 服务之间完全隔离
- 便于整体迁移与备份
- 不暴露任何用户真实目录结构
三、Docker Compose 配置（原则级描述）
RustDesk 由两个核心组件组成：
- ID / 协调服务
- 中继服务
二者均以 Docker 容器形式运行，并共享数据目录。
配置原则如下：
- 使用同一官方镜像
- 使用 host 网络模式
- 不配置任何端口映射
- 设置容器自动重启
示意结构（非可直接复制配置）：
services:
id-service:
image: official-image
command: start-id-service
volumes:
- data-dir:/container-data
network_mode: host
restart: unless-stopped
relay-service:
image: official-image
command: start-relay-service
volumes:
- data-dir:/container-data
network_mode: host
restart: unless-stopped
上述示例为结构示意，刻意省略所有具体参数与数值。
四、端口设计原则（不公开端口号）
RustDesk 服务需要若干 固定职责端口，但在公开文档中应避免直接暴露数值。
其功能层级可抽象为：
核心通信端口
- NAT 类型探测
- 客户端注册与心跳
- TCP / UDP 打洞通信
- 中继转发服务
可选功能端口
- Web 客户端支持
- Web 控制台（高级版本）
在实际部署中应遵循：
- TCP 与 UDP 分别配置
- 不同职责的端口独立管理
- 不使用端口范围一次性放行
五、宿主机防火墙配置原则（以 UFW 为例）
在 host 网络模式下，防火墙规则只需关注 宿主机本身。
通用原则：
- 仅放行 RustDesk 所需的最小端口集合
- TCP 与 UDP 明确区分
- 禁止“全部放行”或宽泛规则
- 所有规则应有清晰描述名称
防火墙配置完成后，应通过系统工具确认监听状态，而不是仅凭配置判断。
六、路由器端口转发配置原则（OpenWrt）
若 RustDesk 服务器位于内网，需要在边界路由器进行端口转发。
配置要点：
- 每个端口单独一条转发规则
- 不使用端口范围
- 明确区分 TCP / UDP
- 目标为单一内网主机
- 规则名称清晰反映服务职责
示例命名方式（抽象）：
- rustdesk-id-nat-test
- rustdesk-id-tcp
- rustdesk-id-udp
- rustdesk-relay
七、验证方法（避免“假通”）
部署完成后，必须进行 真实外网验证：
- 在服务器上确认对应服务正在监听
- 使用非局域网环境进行客户端连接测试
- 验证直连与中继路径是否可正常建立
仅在外网验证成功后，部署才算完成。
八、常见问题与经验总结
- host 网络模式下 不应使用 Docker 端口映射
- UDP 通信是最容易遗漏、但最关键的部分
- 防火墙与路由器规则缺一不可
- 公网 IP ≠ 一定可入站（需警惕 CGNAT / MAP-E）
- 博客公开内容应避免暴露可直接扫描的信息
结论
通过 Docker 的 host 网络模式运行 RustDesk，并配合最小化的防火墙放行与精确的路由器转发，可以在家庭网络环境中构建一个 稳定、可控、自托管的远程桌面服务。