RustDesk self hosted setup — pełny przewodnik Docker + Caddy TLS

Próbujesz samodzielnie hostować RustDesk, ale napotykasz te same blokery: NAT i zapory, złożone składniki serwera oraz wątpliwość, czy potrzebujesz TLS oprócz wbudowanego szyfrowania RustDesk. Ten przewodnik krok po kroku pokazuje kompletne, powtarzalne ustawienie na pojedynczym VPS z Docker Compose i Caddy TLS.
Próbujesz samodzielnie hostować RustDesk, ale napotykasz te same blokery: NAT i zapory, złożone składniki serwera oraz uporczywe pytanie, czy potrzebujesz TLS ponad wbudowane szyfrowanie RustDesk. Ten przewodnik prowadzi technicznie zorientowanego czytelnika przez kompletną, powtarzalną konfigurację RustDesk self-hosted na pojedynczym VPS — Docker Compose dla hbbs/hbbr oraz TLS realizowany przez Caddy, tak aby klienci mogli łączyć się na 443 z restrykcyjnych sieci.
Co budujemy i dlaczego
Cel: pojedynczy VPS pełniący rolę rendezvous i relay RustDesk, do którego klienci będą kierować się po nazwie DNS. Składniki w grze:
- komponenty serwera rustdesk (hbbs i hbbr) uruchomione w Dockerze — przetestowane tutaj z obrazami rustdesk-server w wersji v1.2.1.
- Caddy v2 (zarządzanie certyfikatami przez Let's Encrypt) jako bramka TLS na porcie 443, dzięki czemu klienci mogą dotrzeć do twojego relay nawet gdy outbound 21115 jest zablokowany.
- Opcjonalne przekazywanie UDP lub dodatkowe relay dla skalowania (omówione w notatkach).
Dlaczego to robić? Protokół RustDesk już zapewnia end-to-end szyfrowanie sesji pulpitu, ale wiele sieci zezwala tylko na wychodzący ruch na 443/80. Terminowanie TLS na VPS (i pozwolenie Caddy na pozyskiwanie oraz automatyczne odnawianie certyfikatów) to praktyczny sposób, by usługa była osiągalna bez otwierania niestandardowych portów. Jeśli potrzebujesz tylko dostępu w LAN lub kontroli NAT przez reverse tunneling, zobacz nasz artykuł o zdalny pulpit bez przekierowania portów.
Wymagania wstępne i wybory
Czego użyłem podczas pisania tego przewodnika:
- Ubuntu 22.04 LTS na publicznym VPS (1 vCPU / 2 GB RAM wystarczy do testów; przy wielu klientach skaluj do 4+ CPU i monitoruj CPU/RAM).
- Docker 24.x i Docker Compose v2 (składnia CLI compose V2).
- obraz Docker rustdesk-server (tag v1.2.1 w tym przewodniku) — dostosuj, jeśli istnieją nowsze stabilne wydania.
- Caddy v2.6+ (automatyczne ACME w Caddy upraszcza odnawianie certyfikatów).
- rekord DNS A typu rustdesk.example.com wskazujący na publiczne IP VPS oraz otwarte porty 80/443 (Caddy potrzebuje 80/443 do walidacji).
Uwaga kiedy produkt komercyjny może być lepszy: jeśli potrzebujesz SLA klasy enterprise, zaawansowanego audytu sesji lub komercyjnego wsparcia, TeamViewer/AnyDesk mogą być lepszym wyborem — zobacz porównanie RustDesk z AnyDesk i nasze materiały porównawcze cen. Samodzielne hostowanie ma sens gdy chcesz kontroli, niższych kosztów cyklicznych lub unikać serwerów stron trzecich.
Krok 1 — Wdrożenie rustdesk server z użyciem Docker Compose
Utwórz katalog projektu na VPS i wklej poniższy plik docker-compose.yml. Ten przykład udostępnia typowe porty serwera RustDesk na hoście. Zastąp zmienne środowiskowe i tagi obrazów zgodnie z Twoim środowiskiem.
mkdir -p ~/rustdesk-server
cd ~/rustdesk-server
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
rustdesk-server:
image: rustdesk/rustdesk-server:1.2.1
container_name: rustdesk-server
restart: unless-stopped
ports:
- "21115:21115/tcp" # rendezvous / TCP relay
- "21115:21115/udp" # optional UDP relay (if your image supports it)
- "21116:21116/udp" # additional UDP (some builds use multiple UDP ports)
volumes:
- ./data:/root/.config/rustdesk-server
environment:
- RUSTDESK_RELAY_IPV4=0.0.0.0
- RUSTDESK_RELAY_PORT=21115
EOF
Uruchom:
docker compose up -d # watch logs docker compose logs -f rustdesk-server
Potwierdź, że kontener wystartował i nasłuchuje na 21115. Na VPS uruchom:
ss -tuln | grep 21115
Jeśli używany obraz eksponuje inne porty lub ma inny styl konfiguracji, sprawdź README tego obrazu. Niektórzy operatorzy kompilują hbbs/hbbr ręcznie i używają niestandardowych portów; dostosuj kroki do swojej sytuacji.
Krok 2 — Użycie Caddy, aby dodać TLS nad relay (443)
Są dwa powszechne wzorce, aby RustDesk był osiągalny na 443:
- Terminacja TLS dla TCP za pomocą Caddy 2.6+ (Caddy terminuję TLS i przekazuje surowy TCP do relay RustDesk). Caddy dodał ulepszone funkcje TCP w v2.6; korzystając z tego podejścia otrzymujesz automatyczne certyfikaty ACME i ich odnawianie.
- Pozwól Caddy zarządzać tylko certyfikatami, a użyj TCP proxy (stunnel, HAProxy lub Nginx stream) do wykorzystania tych plików certyfikatu. To rozwiązanie zapasowe, jeśli Twoja wersja Caddy lub środowisko nie obsługuje potrzebnych funkcji proxy TCP.
Poniżej minimalna, pragmatyczna konfiguracja Caddy, która używa Caddy do obsługi TLS na porcie 443 i przekazuje surowe połączenie TCP do relay RustDesk pod localhost:21115. Wymaga to Caddy v2.6+ (sprawdź za pomocą caddy version).
# Caddyfile (save as ./Caddyfile in the same folder as docker-compose.yml)
rustdesk.example.com:443 {
# Caddy will obtain/renew certificates automatically
reverse_proxy 127.0.0.1:21115 {
# Use plain TCP transport; Caddy will accept TLS from clients and connect to the backend via TCP
transport http {
# We don't speak HTTP to the backend; keep minimal transport settings
}
}
}
Fragment docker-compose do uruchomienia Caddy obok serwera rustdesk (ten sam projekt):
cat >> docker-compose.yml <<'EOF'
caddy:
image: caddy:2.6.4
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
EOF
docker compose up -d caddy
Ważne zastrzeżenie: wbudowane reverse_proxy w Caddy jest zorientowane na HTTP, więc zachowanie przy proxy'owaniu surowego TCP zależy od wersji Caddy i opcji transportu. W praktyce wielu operatorów używa funkcji proxy TCP wprowadzonych w 2.6 do terminowania TLS dla dowolnych backendów TCP. Jeśli napotkasz problemy protokołowe, użyj opcji (2) powyżej: pozwól Caddy obsługiwać certyfikaty i przekaż pliki certyfikatów do małej warstwy TLS (stunnel lub HAProxy stream), która następnie proxy'uje plain TCP do rustdesk.
Przykład: Caddy jako menedżer certyfikatów + stunnel do terminacji TLS (szybki przegląd).
# 1) Ensure Caddy is running and has issued certs for rustdesk.example.com # 2) Copy cert/key from Caddy storage into a place stunnel can read, or mount the same volume. # 3) Run stunnel with a config that points TLS 443 -> 127.0.0.1:21115 # stunnel.conf snippet [rustdesk] accept = 443 connect = 127.0.0.1:21115 cert = /etc/stunnel/fullchain.pem key = /etc/stunnel/privkey.pem # In Docker world, mount Caddy's certificate files into the stunnel container path above.
Oba podejścia dają hostname (rustdesk.example.com) i port 443 dla klientów. Przetestuj łączność z innej maszyny poleceniem: nc -vz rustdesk.example.com 443 — powinieneś nawiązać handshake TLS jeśli Caddy/stunnel są poprawnie skonfigurowane.
Krok 3 — Skieruj klientów na swój samodzielnie hostowany serwer
Klienci RustDesk pozwalają na niestandardowe serwery ID/relay w ustawieniach. Dokładne UI zależy od platformy i wersji, ale zasadnicze wartości to:
- ID Server / Rendezvous: rustdesk.example.com:443 (lub Twój domena i port)
- Relay Server: rustdesk.example.com:443
Na Windows: otwórz RustDesk > Settings > ID/Server i ustaw Id server oraz Relay server na rustdesk.example.com:443. Na Linux i macOS te same ustawienia są w Preferencjach. Dla instalacji bez GUI klienta, czasami można podać flagi w wierszu poleceń lub plik konfiguracyjny — sprawdź repo klienta po szczegóły.
Upewnij się, że klienci są aktualni (1.2.x lub nowsze w czasie pisania). Nowsze wersje mają poprawki protokołu i lepsze przebijanie NAT. Przy użyciu znacznie starszych klientów zachowanie może się różnić.
Rozwiązywanie problemów i utwardzanie
Typowe problemy i jak je debugować:
- Zapora: potwierdź, że zapora VPS (ufw/iptables/dostawca chmury) pozwala na ruch przychodzący na 80/443. Dla serwera RustDesk w kontenerze nasłuchującego lokalnie na 21115, upewnij się, że socket TCP istnieje (ss/netstat).
- Wydawanie certyfikatów: jeśli Let's Encrypt nie może zweryfikować, Caddy zaloguje błąd. Sprawdź, czy rekord DNS A wskazuje na VPS i czy port 80 jest osiągalny podczas początkowej emisji certyfikatu.
- Niezgodność protokołu: jeśli widzisz udany handshake TLS, ale klient zgłasza błędy połączenia, możliwe że omyłkowo proxy'ujesz tylko HTTP z Caddy. W takich przypadkach użyj podejścia ze stunnel.
- UDP relay: wydajność RustDesk poprawia się przy użyciu UDP do ramek ekranu; jeśli ścieżka sieciowa blokuje UDP, nastąpi fallback do TCP relay. Otwieraj/przekierowuj porty UDP tylko jeśli kontrolujesz sieć i wiesz, co robisz.
Wskazówki dotyczące utwardzania bezpieczeństwa:
- Uruchamiaj rustdesk server pod dedykowanym użytkownikiem bez uprawnień root i utrzymuj obrazy Docker aktualne.
- Włącz fail2ban lub podobne narzędzie do ograniczania powtarzających się nieudanych prób połączeń i monitoruj logi (
docker compose logs -f rustdesk-server). - Regularnie twórz kopie zapasowe katalogu danych rustdesk server (w przykładzie to ./data).
- Rozważ umieszczenie relay za prywatną siecią lub VPC jeśli operujesz wieloma relayami.
Notatki dotyczące skalowania: pojedynczy relay wystarczy dla małych zespołów. Dla większych wdrożeń uruchom wiele procesów hbbr na osobnych maszynach i użyj DNS load-balancing lub właściwego L4 load balancera. Jeśli potrzebujesz scentralizowanych funkcji enterprise jak audyt, tu przewagę mają rozwiązania komercyjne. Zobacz nasze artykuły o self-hosted-remote-desktop i rustdesk-vs-anydesk dla omówienia kompromisów.
Konserwacja, koszty i ostateczne rekomendacje
Koszty operacyjne to głównie opłaty VPS i Twój czas. Typowy mały VPS (1–2 CPU, 2–4 GB) można znaleźć za $5–10/month (DigitalOcean, Vultr, Hetzner). Caddy i RustDesk server są open-source; główny koszt cykliczny to hosting. Jeśli potrzebujesz GUI do rozliczeń lub wsparcia enterprise, dostawcy komercyjni naliczają opłaty per-seat lub per-session — zobacz porównania cen, np. anydesk-pricing-explained i godeskflow-vs-teamviewer-pricing dla kontekstu.
Rekomendacje:
- Zacznij od pojedynczego VPS i układu Docker Compose powyżej. Przetestuj połączenia z dokładnie tych sieci, z których będą korzystać Twoi użytkownicy (ISP domowi, zapory korporacyjne).
- Jeśli klienci często są za bardzo restrykcyjnymi zaporami, umieść relay na 443 i zweryfikuj, że terminacja TLS działa stabilnie; użyj kombinacji Caddy+stunnel jeśli same funkcje proxy TCP w Caddy powodują problemy.
- Zautomatyzuj backupy katalogu danych serwera i śledź aktualizacje obrazów. Wydania RustDesk server się zmieniają; testuj aktualizacje w środowisku staging jeśli zależy Ci na dostępności produkcyjnej.
Jeśli chcesz krótszy przewodnik dotyczący wzorców zdalnego dostępu lub alternatyw, przeczytaj nasze powiązane artykuły: remote-access-setup-guide i remote-desktop-security.
Przeczytałeś do końca? Jeśli chcesz wypróbować w pełni open-source'owy pulpit zdalny dobrze nadający się do self-hostingu, pobierz GoDesk lub porównaj jego ceny — zobacz pobierz i GoDesk pricing. Jeśli jesteś gotów wdrożyć to ustawienie RustDesk, zacznij od utworzenia docker-compose.yml i Caddyfile powyżej i uruchom docker compose up -d. Dla szybkiego startu przejdź do pobierz, aby pobrać klienty i połączyć się.
More articles
Zdalny pulpit bez przekierowywania portów: jak to naprawdę działa
9 min czytania
Czy zdalny pulpit jest bezpieczny? Szczery model zagrożeń
10 min czytania
RustDesk vs AnyDesk: Przewodnik zakupowy na 2026 rok (i trzecia opcja, którą pominęły większość recenzji)
11 min czytania