Linux 远程桌面服务器：X11VNC 与 RustDesk 设置

你需要远程管理或支持 Linux 机器，并厌倦了脆弱的临时方案——用 SSH 仅获取 shell、手动复制大文件，或每次都让别人打开一个 TeamViewer 链接。若想在 Linux 上部署一个在启动时自动启动、能在重启后存活且可自托管在你控制下的服务器端远程桌面，本文介绍两种实用的服务器端方案：用于经典 X11 会话的 X11VNC，以及用于现代自托管信令/中继的 RustDesk 服务器守护进程。

何时运行专用的 linux 远程桌面服务器（以及原因）

判断是否适合服务器端远程桌面的快速清单：

• 需要无人值守或无头访问机器（实验室服务器、办公桌面、信息亭）。
• 希望有一个单一、始终在线的终端，可以在不让他人先启动客户端的情况下直接连接。
• 偏好自托管（无第三方云），或希望通过本地中继避免直接暴露 RDP/VNC 端口。
• 想将经典的 X11 VNC 访问与现代的 NAT 穿透/中继结合，提升客户端使用便利性。

X11VNC 是一个小巧、成熟的服务器端 VNC 守护进程，会导出 X11 显示器上当前的内容（通常为 :0）。RustDesk 的服务器组件（hbbs + hbbr）提供信令（rendezvous）和可选中继，用于在客户端位于 NAT 后时建立连接。这两者可以共存：X11VNC 提供始终在线的 VNC 端点，RustDesk 则提供无需端口转发即可让远程客户端找到主机的托管方式。

选项 A — X11VNC：稳定、简单的服务器端 X11 访问

当机器运行基于 X11 的桌面，且你希望有一个开机启动的简单 VNC 服务器时，使用 X11VNC。X11VNC 经受时间考验（很多仓库中的常见稳定版本：x11vnc 0.9.16），并能很好地与 systemd 集成。

安装并保护 x11vnc

在 Debian/Ubuntu 上：

sudo apt update
sudo apt install -y x11vnc

创建一个密码文件（使用强口令）。将 'remote' 替换为远程用户的主目录所有者。

sudo -u remote mkdir -p /home/remote/.vnc
sudo -u remote x11vnc -storepasswd /home/remote/.vnc/passwd
sudo chown -R remote:remote /home/remote/.vnc

查找与你的显示管理器对应的 X authority 文件。常见位置：

• LightDM：/var/run/lightdm/root/:0
• GDM (GNOME)：/run/user/1000/gdm/Xauthority 或检查 /home/<username>/.Xauthority

手动启动 x11vnc 一次以验证配置：

sudo -u remote x11vnc -display :0 -auth /home/remote/.Xauthority -rfbauth /home/remote/.vnc/passwd -forever -shared -noxdamage -o /var/log/x11vnc.log

用于始终在线服务的 systemd 单元

将此文件放在 /etc/systemd/system/x11vnc.service — 编辑 User、Group 和 -auth 路径以匹配你的发行版/显示管理器。

[Unit]
Description=x11vnc server for display :0
After=graphical.target

[Service]
Type=simple
User=remote
Group=remote
ExecStart=/usr/bin/x11vnc -display :0 -auth /home/remote/.Xauthority -rfbauth /home/remote/.vnc/passwd -forever -shared -noxdamage -repeat -o /var/log/x11vnc.log
Restart=on-failure

[Install]
WantedBy=graphical.target

启用并启动：

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo journalctl -u x11vnc -f

网络与安全注意事项

VNC 默认不加密。强化服务器端 VNC 端点的选项：

• 绑定到 localhost 并要求通过 SSH 隧道访问：以 -rfbport 5901 运行 x11vnc，并在 systemd 中只监听 127.0.0.1，然后使用 SSH -L 5901:localhost:5901 进行转发。
• 使用 VPN 访问主机所在的局域网。
• 用防火墙限制访问（下面有 ufw 示例）。
• 如果需要直接让远程客户端在没有 SSH 的情况下访问，可将 VNC 放在 stunnel/NGINX TLS 代理后面（会增加 CPU 与复杂性）。

# Basic UFW rule to allow local-network VNC only
sudo ufw allow from 192.168.0.0/16 to any port 5900 proto tcp
# Or bind to localhost and tunnel via SSH for remote access

说明：X11VNC 需要 X11 会话。在 Wayland（某些发行版上的 GNOME）上，可使用兼容 Wayland 的服务器（例如 wayvnc）或使用桌面自带的远程桌面功能（通常为 RDP）。

选项 B — RustDesk 服务器守护进程：自托管的 rendezvous 与 中继

RustDesk 允许你自托管信令（hbbs）和中继服务器（hbbr），使客户端在不暴露原始 VNC/RDP 端口的情况下找到并到达主机。如果你已经为桌面会话运行 X11VNC，可以在其前端使用 RustDesk 以实现 NAT 穿透并提升客户端体验。RustDesk 的服务器组件通常以 docker 镜像形式发布；查阅项目发布页 — 示例服务器标签可能包含 v1.2.0（部署前请在 RustDesk 仓库核实当前标签）。

简单的 Docker Compose 示例

该 compose 会启动 hbbs（rendezvous）和 hbbr（可选中继）。示例中显示的端口为社区文档常用默认端口（若上游更改请相应调整）。

version: '3.7'
services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    restart: unless-stopped
    ports:
      - '21112:21112/tcp'   # rendezvous
    environment:
      - HBBS_KEY=your_secret_key_here

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    restart: unless-stopped
    ports:
      - '21113:21113/udp'   # relay

注意：

• 将 HBBS_KEY（或按当前 RustDesk 文档要求的其他环境变量）替换为安全的值。
• RustDesk 的官方镜像名和环境变量在不同发行版间可能会变动——在生产环境中部署前请查阅 RustDesk 服务器仓库的说明。

连接客户端

在客户端（RustDesk 桌面/移动端）上，将客户端指向你的 hbbs 服务器地址（域名或公网 IP）：例如 1.2.3.4:21112。如果 hbbr 中继可用且需要，客户端在直连（P2P）失败时会使用中继来转发流量。你可以配置客户端远程控制运行在主机上的 RustDesk agent，或把 RustDesk 作为中介连接到主机上已存在的 VNC 服务（通常在主机上运行 RustDesk agent，再由 agent 转发到 X11VNC 会话）。

不使用 Docker 的 systemd 方案

如果不希望使用 Docker，可按项目文档构建 rustdesk-server 二进制并将 hbbs 与 hbbr 安装为 systemd 服务。打包方式随发布而异；Docker 方法是最快的可复现部署手段。

安全、NAT 穿透，以及何时避免暴露端口

两种避免直接暴露桌面端口的高层策略：

1. 将 VNC/RDP 绑定到 localhost；要求通过 SSH/VPN 达到主机。这是单管理员环境下最简单、最易审计的选项。
2. 自托管中继/信令（RustDesk），并使用 TLS + 认证。这样可减少主机上开放端口，但需运行并保护中继服务器。

防火墙片段（UFW）：

# Allow only SSH from your office and block the rest
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw deny 5900/tcp

# If running RustDesk server on the relay box (example)
sudo ufw allow 21112/tcp
sudo ufw allow 21113/udp

实用的安全检查清单：

• 为 VNC 或 RustDesk agent 帐户使用强认证。
• 轮换或保护服务器密钥（RustDesk HBBS key），并保持镜像为最新。
• 使用 IDS/监控以在端口扫描和登陆失败时告警。
• 如需加密的桌面会话，可在中继前使用反向代理（Nginx/Caddy）终止 TLS，并强制使用 TLS 1.2+ 及强加密套件。

运维提示、故障排查与维护

常见问题与解决方法：

• VNC 上没有可见桌面：确认 X 显示为 :0（ps aux | grep X），并且 x11vnc 使用了正确的 -auth 文件。
• 服务在启动时不运行：将 systemd 的 WantedBy 设置为 graphical.target，并确认显示管理器在 x11vnc 之前启动。
• RustDesk 客户端无法访问服务器：确认 DNS 与防火墙；使用 telnet/IP 工具测试，并检查容器日志（docker-compose logs -f）。
• 性能差：为 x11vnc 启用 -noxdamage（在某些工作负载中可减少撕裂并降低 CPU），并在客户端可用时考虑调整压缩/编码设置。

维护清单：

• 每周应用操作系统安全更新。在 Debian/Ubuntu 上可通过 unattended-upgrades 自动化小范围补丁。
• 跟踪 RustDesk 或 x11vnc 的上游仓库以获取安全修复。如果使用 docker 镜像，应安排镜像刷新与重部署流程。
• 备份配置文件和任何 TLS 证书；尽可能将 HBBS 密钥存储在机密管理器中。

何时商业工具或 RDP 更合适

诚实的权衡：

• TeamViewer / AnyDesk：在对非技术用户的极致易用性、普遍的 NAT 穿透能力和精良的移动端体验方面更占优。如果需要对数百个非技术终端提供即时、零运维支持，商业 SaaS 服务可能物有所值。参见我们在 rustdesk-vs-anydesk 的对比说明。
• RDP (Microsoft Remote Desktop)：在 Windows 服务器和桌面上，原生 RDP 通常在性能和功能（剪贴板、文件传输、声音）上更好。但若不通过 VPN 或堡垒机保护，RDP 会暴露更高风险的攻击面。

如果你的主要目标是自托管和隐私，且能接受更多的初始设置与持续维护，X11VNC + RustDesk 服务器的组合是一个稳健且实用的方案。

延伸阅读与内部资源

如果想完全避免端口转发，请阅读我们的操作指南： Remote desktop without port forwarding。如需更高层次的部署方案，请参见 Self-hosted remote desktop guide。关于安全加固最佳实践，查看 Remote desktop security。

最后，Tenvo 专注于开源、自托管的远程桌面工具集——如果你需要一个为自托管和跨平台使用设计的替代客户端/服务器，请查看我们的下载或定价页面以开始： /download 和 /pricing。我们在其他文章中也描述了类似的部署模式并保持示例更新。

如果你需要针对特定发行版、显示管理器，或要为特定环境调优 systemd 启动配置，请告诉我发行版和显示管理器（例如 Ubuntu 22.04 with GDM），我会为你提供定制的单元文件和 auth 路径命令。准备好后，可下载 Tenvo 或尝试构建上文描述的栈——起点： /download。