Serwer zdalnego pulpitu na Linuksie: X11VNC i RustDesk

Próbujesz zarządzać lub wspierać zdalnie maszyny Linux i masz dość zawodnych, ad-hoc rozwiązań — SSH do powłoki, ręczne kopiowanie dużych plików lub wysyłanie linku TeamViewer za każdym razem. Jeśli chcesz trwałego, serwerowego pulpitu zdalnego na Linuxie, który uruchamia się przy starcie, przetrwa rebooty i może być hostowany samodzielnie pod twoją kontrolą, ten poradnik przeprowadzi przez dwa praktyczne podejścia po stronie serwera: X11VNC dla klasycznych sesji X11 oraz demon serwera RustDesk jako nowoczesna, samodzielnie hostowana opcja rendezvous/relay.

Kiedy uruchomić dedykowany serwer pulpitu zdalnego na Linuxie (i dlaczego)

Krótka lista kontrolna, żeby ocenić, czy sens ma serwerowy pulpit zdalny:

• Potrzebujesz bezgłowego lub bezobsługowego dostępu do maszyny (serwery w laboratorium, stacje robocze w biurze, kioski).
• Chcesz pojedynczy, zawsze dostępny endpoint, do którego możesz się podłączyć bez proszenia kogoś o uruchomienie klienta.
• Wolisz self-hosting (bez zewnętrznej chmury) lub chcesz lokalny relay, aby uniknąć wystawiania portów RDP/VNC bezpośrednio.
• Chcesz połączyć klasyczny dostęp VNC do X11 z nowoczesnym przechodzeniem przez NAT/relay dla wygody klientów.

X11VNC to lekki, dojrzały daemon VNC po stronie serwera, który eksportuje to, co jest na wyświetlaczu X11 (zazwyczaj :0). Komponenty serwera RustDesk (hbbs + hbbr) zapewniają rendezvous i opcjonalny relay dla połączeń peer-to-peer — przydatne, gdy klienci znajdują się za NAT. Oba rozwiązania mogą współistnieć: X11VNC daje zawsze-on punkt końcowy VNC, a RustDesk oferuje zarządzany sposób, aby klienci odnaleźli hosta bez przekierowań portów.

Opcja A — X11VNC: stabilny, prosty dostęp X11 po stronie serwera

Użyj X11VNC, gdy maszyny uruchamiają środowisko oparte na X11 i chcesz prosty serwer VNC startujący przy boocie. X11VNC jest dobrze przetestowany (powszechny stabilny release: x11vnc 0.9.16 w wielu repozytoriach) i dobrze integruje się z systemd.

Zainstaluj i zabezpiecz x11vnc

Na Debianie/Ubuntu:

sudo apt update
sudo apt install -y x11vnc

Utwórz plik z hasłem (użyj silnej frazy). Zastąp 'remote' właścicielem katalogu domowego zdalnego użytkownika.

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

Znajdź poprawny plik X authority dla twojego display managera. Typowe lokalizacje:

• LightDM: /var/run/lightdm/root/:0
• GDM (GNOME): /run/user/1000/gdm/Xauthority lub sprawdź /home//.Xauthority

Uruchom x11vnc ręcznie raz, aby zweryfikować działanie:

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

Unit systemd dla usługi zawsze włączonej

Umieść ten plik w /etc/systemd/system/x11vnc.service — edytuj User, Group i ścieżkę -auth, aby pasowały do twojej dystrybucji/menedżera wyświetlania.

[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

Włącz i uruchom:

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

Rozważania sieciowe i dotyczące bezpieczeństwa

Domyślnie VNC jest niezaszyfrowane. Opcje utwardzenia serwerowego punktu końcowego VNC:

• Powiąż nasłuch z localhost i wymuś tunelowanie SSH: uruchom x11vnc z -rfbport 5901 i skonfiguruj systemd, aby nasłuchiwał tylko na 127.0.0.1, potem użyj SSH -L 5901:localhost:5901.
• Użyj VPN, aby dostać się do sieci hosta.
• Ogranicz dostęp zaporą (przykład ufw niżej).
• Jeśli potrzebujesz bezpośrednich klientów bez SSH, umieść VNC za stunnel/NGINX TLS proxy (dodaje obciążenie CPU i złożoność).

# 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

Uwaga: X11VNC wymaga sesji X11. Na Waylandzie (GNOME w niektórych dystrybucjach) użyj serwerów zgodnych z Wayland (np. wayvnc) lub wbudowanego pulpitu zdalnego (często RDP).

Opcja B — demon serwera RustDesk: samodzielnie hostowany rendezvous i relay

RustDesk pozwala na self-hosting sygnalizacji (hbbs) i serwera relay (hbbr), dzięki czemu klienci mogą odnaleźć i osiągnąć hosty bez wystawiania surowych portów VNC/RDP. Jeśli już uruchamiasz X11VNC dla sesji pulpitu, możesz postawić RustDesk przed nim, aby uzyskać NAT traversal i prostsze doświadczenie klienta. Komponenty serwera RustDesk są często dystrybuowane jako obrazy docker; sprawdź wydania projektu — przykładowe tagi serwera to v1.2.0 (zweryfikuj aktualny tag w repo RustDesk).

Prosty przykład Docker Compose

Ten compose uruchamia hbbs (rendezvous) i hbbr (opcjonalny relay). Pokazane porty to typowe domyślne wartości używane w dokumentacji społecznościowej (dostosuj, jeśli upstream zmieni porty).

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

Uwaga:

• Zastąp HBBS_KEY (lub inne zmienne środowiskowe zgodnie z aktualnymi instrukcjami RustDesk) bezpieczną wartością.
• Oficjalne obrazy RustDesk i nazwy zmiennych środowiskowych mogą się zmieniać między wydaniami — przed wdrożeniem sprawdź repo serwera RustDesk.

Łączenie klientów

Po stronie klienta (RustDesk desktop/mobile) wskaż adres serwera hbbs (DNS lub publiczne IP): np. 1.2.3.4:21112. Jeśli relay hbbr jest dostępny i potrzebny, klient użyje go do przekazywania ruchu, gdy bezpośrednie (P2P) połączenie nie będzie możliwe. Możesz skonfigurować klienta do zdalnego sterowania agentem RustDesk uruchomionym na hoście albo użyć RustDesk jako brokera, który łączy się z istniejącą usługą VNC na hoście (zwykle uruchamiasz agenta RustDesk na hoście, który może przekierować do sesji X11VNC).

Alternatywa systemd zamiast Dockera

Jeśli wolisz nie używać Dockera, zbuduj binaria rustdesk-server zgodnie z dokumentacją projektu i zainstaluj je jako usługi systemd (hbbs i hbbr). Pakowanie zmienia się między wydaniami; podejście z Dockerem jest najszybszym sposobem na uzyskanie powtarzalnego środowiska serwera.

Bezpieczeństwo, przechodzenie przez NAT i kiedy unikać wystawiania portów

Dwa główne podejścia, aby uniknąć bezpośredniego wystawiania portów pulpitu:

1. Trzymaj VNC/RDP związane z localhost; wymagaj SSH/VPN, aby dostać się do hosta. To najprostsza, najbardziej audytowalna opcja dla konfiguracji z jednym administratorem.
2. Samodzielnie hostuj relay/rendezvous (RustDesk) i użyj TLS + uwierzytelniania. To zmniejsza liczbę otwartych portów na hoście, ale wymaga uruchomienia i zabezpieczenia serwerów relay.

Fragmenty zapory (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

Praktyczna lista kontrolna bezpieczeństwa:

• Używaj silnego uwierzytelniania dla konta agenta VNC lub RustDesk.
• Rotuj lub chroń klucze serwera (klucz HBBS RustDesk) i utrzymuj obrazy na bieżąco.
• Używaj IDS/monitoringu, aby alarmować o skanowaniu portów i nieudanych logowaniach.
• Jeśli wymagane są szyfrowane sesje pulpitu, terminuj TLS na reverse proxy (Nginx/Caddy) przed relayem i wymuszaj TLS 1.2+ oraz silne szyfry.

Wskazówki operacyjne, rozwiązywanie problemów i utrzymanie

Typowe problemy i rozwiązania:

• Brak pulpitu w VNC: potwierdź, że display X to :0 (ps aux | grep X) i że x11vnc używa poprawnego pliku -auth.
• Usługa nie startuje przy boocie: ustaw WantedBy na graphical.target i potwierdź, że menedżer wyświetlania uruchamia się przed x11vnc.
• Klienci RustDesk nie mogą dotrzeć do serwera: sprawdź DNS i zaporę; testuj za pomocą narzędzi telnet/IP i przejrzyj logi kontenerów (docker-compose logs -f).
• Niska wydajność: włącz -noxdamage dla x11vnc (mniej tearingu, niższe obciążenie CPU w niektórych scenariuszach) oraz rozważ dostosowanie kompresji/kodowań po stronie klienta, jeśli dostępne.

Playbook utrzymaniowy:

• Stosuj aktualizacje bezpieczeństwa systemu co tydzień. Na Debianie/Ubuntu możesz zautomatyzować unattended-upgrades dla drobnych poprawek.
• Śledź upstreamy RustDesk i x11vnc pod kątem poprawek bezpieczeństwa. Jeśli używasz obrazów docker, zaplanuj odświeżanie obrazów i pipeline redeploy.
• Twórz kopie zapasowe plików konfiguracyjnych i certyfikatów TLS; przechowuj klucze HBBS w managerze sekretów, jeśli to możliwe.

Kiedy narzędzie komercyjne lub RDP może być lepszym wyborem

Szczerze o kompromisach:

• TeamViewer / AnyDesk: Wygrywają pod względem ekstremalnej prostoty obsługi dla użytkowników nietechnicznych, uniwersalnego przechodzenia przez NAT oraz dopracowanych aplikacji mobilnych. Jeśli potrzebujesz natychmiastowego, zero-ops wsparcia dla setek nietechnicznych punktów końcowych, komercyjne SaaS może być warte kosztu. Zobacz nasze porównanie na rustdesk-vs-anydesk dla szczegółów.
• RDP (Microsoft Remote Desktop): Na serwerach i desktopach Windows natywne RDP zwykle zapewnia lepszą wydajność i funkcje (schowek, transfer plików, dźwięk). Jednak RDP zwiększa powierzchnię ataku, jeśli nie stoi za VPN lub bastionem.

Jeśli twoim głównym celem jest self-hosting i prywatność — i akceptujesz trochę więcej początkowej konfiguracji oraz bieżącego utrzymania — kombinacja X11VNC + serwera RustDesk jest solidnym, praktycznym rozwiązaniem.

Dalsza lektura i zasoby wewnętrzne

Jeśli chcesz całkowicie uniknąć przekierowań portów, przeczytaj nasz przewodnik: Pulpit zdalny bez przekierowania portów. Dla bardziej ogólnego widoku wdrożenia własnego rozwiązania zobacz Przewodnik po self-hosted remote desktop. W kwestii utwardzania bezpieczeństwa sprawdź Bezpieczeństwo pulpitu zdalnego.

Na koniec, Tenvo koncentruje się na otwartym, self-hosted toolingu do pulpitu zdalnego — jeśli chcesz alternatywnego klienta/serwera zaprojektowanego pod self-hosting i użycie cross-platform, sprawdź nasze strony pobrań i cennika, aby zacząć: /download i /pricing. Opisujemy podobne wzorce wdrożeniowe w innych wpisach i utrzymujemy przykłady aktualne.

Jeśli chcesz pomocy z konkretną dystrybucją, menedżerem wyświetlania lub dostrojenia systemd dla konkretnego środowiska, podaj dystrybucję i menedżera wyświetlania (np. Ubuntu 22.04 z GDM), a przygotuję dopasowany plik unit i polecenia do ścieżek auth. Gdy będziesz gotowy, pobierz Tenvo lub spróbuj zbudować opisaną powyżej infrastrukturę — zacznij od /download.