Własny serwer przekaźnikowy RustDesk na VPS

Czym jest własny serwer przekaźnikowy RustDesk

Własny serwer przekaźnikowy RustDesk to dwa demony działające na jednym VPS. hbbs to serwer identyfikatorów i pośrednictwa (rendezvous): rejestruje on identyfikator każdego klienta i umożliwia nawiązanie połączenia między dwoma klientami. hbbr to serwer przekaźnikowy: przenosi on bajty sesji, ale tylko w przypadku sesji, których nie udało się zestawić bezpośrednio. Większość poradników opisuje instalację obu komponentów, parowanie i na tym kończy. Poniżej znajduje się reszta niezbędnych czynności: klucz stanowiący kontrolę dostępu, porty, aktualizacja oraz kwestia przepustowości.

Oba demony są dostarczane w tym samym obrazie rustdesk/rustdesk-server i oba odczytują tę samą parę kluczy Ed25519 z tego samego katalogu. Ed25519 to schemat podpisu kluczem publicznym. Ta para kluczy decyduje o tym, z którymi klientami serwer będzie się komunikował; w systemie nie istnieje żadna baza danych użytkowników.

hbbs i hbbr: który demon zużywa transfer

Ruch generowany przez hbbs jest niewielki i stały: obejmuje rejestrację identyfikatorów, sygnały kontrolne (heartbeats) oraz krótką wymianę danych inicjującą połączenie między dwoma klientami. Proces ten działa w tle i zużywa znikomą ilość zasobów.

Ruch generowany przez hbbr to właściwa sesja. Ramki obrazu przesyłane są w jedną stronę, a sygnały klawiatury i myszy w drugą. Każdy bajt przekazany przez przekaźnik trafia na serwer VPS, a następnie go opuszcza. Jeśli dostawca rozlicza tylko ruch wychodzący (egress), koszt sesji odpowiada ilości przesłanych danych. Jeśli rozliczany jest całkowity transfer, koszt ten jest dwukrotnie wyższy.

Przekaźnik stanowi rozwiązanie awaryjne, a nie domyślną ścieżkę połączenia. hbbs najpierw podejmuje próbę bezpośredniego połączenia klientów, wykorzystując technikę hole punching przez dowolny NAT (network address translation) znajdujący się przed każdym z nich. Gdy to się powiedzie, sesja nie obciąża hbbr, a limit transferu pozostaje nienaruszony. Gdy jedna ze stron znajduje się za NAT-em przypisującym nowy port dla każdego miejsca docelowego lub za firewallem blokującym wynegocjowaną ścieżkę, sesja przełącza się na hbbr i każda ramka przechodzi przez serwer VPS.

Jedna zmienna środowiskowa usuwa ten wybór. ALWAYS_USE_RELAY=Y w hbbs wymusza przesyłanie każdej sesji przez hbbr. Dokumentacja RustDesk prezentuje to ustawienie w jednym z przykładów Compose, przez co jest ono często kopiowane. Sprawia to, że połączenia są bardziej przewidywalne, ale generuje realne zużycie transferu wychodzącego. Należy stosować to ustawienie świadomie, a nie poprzez bezmyślne kopiowanie konfiguracji.

Które porty są wymagane przez samodzielnie hostowany serwer RustDesk

Poniższe numery portów zostały zweryfikowane zgodnie z dokumentacją serwera RustDesk oraz repozytorium rustdesk-server w dniu 17 sierpnia 2026.

• TCP 21115, na hbbs: test typu NAT.
• UDP 21116, na hbbs: rejestracja ID oraz sygnał heartbeat. Bez tego klient nigdy nie uzyska statusu online, niezależnie od innych otwartych portów.
• TCP 21116, na hbbs: TCP hole punching oraz usługa połączeń.
• TCP 21117, na hbbr: przekaźnik (relay). Jest to port, przez który przesyłane są dane sesji, zatem to on generuje zużycie transferu.
• TCP 21118 na hbbs oraz TCP 21119 na hbbr: WebSocket, używany przez klienta przeglądarkowego. Pozostaw oba porty zamknięte, jeśli nie korzystasz z tej funkcji.
• TCP 21114 to konsola webowa w RustDesk Server Pro. Wersja open source nie nasłuchuje na tym porcie.

Instalacja hbbs i hbbr z przypiętą wersją obrazu

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

mkdir -p ~/rustdesk
cd ~/rustdesk
# save the block above as ~/rustdesk/compose.yml before this line
sudo docker compose up -d
sudo docker compose ps

Obie usługi powinny odczytywać running. Przed konfiguracją firewalla należy potwierdzić, że porty nasłuchujące są aktywne.

sudo ss -tlnp | grep -E ':2111[5-7]'
sudo ss -ulnp | grep ':21116'

Powinny być widoczne porty nasłuchujące TCP 21115, 21116 oraz 21117, a także port UDP 21116. Brak linii UDP oznacza, że hbbs nie działa, ponieważ to właśnie na tym porcie rejestrują się klienci.

Cztery elementy w tym pliku są zamierzone. Użyto tagu 1.1.16, czyli aktualnego wydania na sierpień 2026, opublikowanego 20 lipca 2026, zamiast latest. Użycie latest oznacza pobranie najnowszej wersji, a docker compose pull za pół roku może skutkować uruchomieniem serwera, którego nie przetestowano. network_mode: "host" wiąże interfejsy hosta bezpośrednio, co jest zalecane w dokumentacji RustDesk i determinuje zachowanie firewalla. ./data:/root mapuje katalog roboczy obrazu na system plików hosta, dzięki czemu para kluczy jest zapisywana w miejscu dostępnym do wykonania kopii zapasowej. hbbr -k _ to jedyna zmiana względem przykładu producenta, ponieważ konfiguracja domyślna pozostawia przekaźnik otwarty dla każdego. Jeśli Compose jest nowym narzędziem, uruchamianie Docker Compose na VPS wyjaśnia format pliku oraz cykl życia kontenerów.

Jeśli hbbr zostanie przeniesiony na drugi serwer, hbbs musi otrzymać informację o nowej lokalizacji: należy przekazać -r relay.example.com:21117 lub ustawić zmienną środowiskową RELAY-SERVERS. W przypadku pojedynczej maszyny nie jest to wymagane.

Para kluczy Ed25519 stanowi kontrolę dostępu

Przy pierwszym uruchomieniu hbbs generuje id_ed25519 oraz id_ed25519.pub w swoim katalogu roboczym. Dzięki powyższemu montowaniu, oba pliki pojawiają się na hoście.

ls -l ~/rustdesk/data/
sudo cat ~/rustdesk/data/id_ed25519.pub

id_ed25519.pub zawiera jeden ciąg base64. Ten ciąg należy wprowadzić w polu Key na każdym kliencie. id_ed25519 to część prywatna, która nigdy nie opuszcza serwera. Klucz publiczny nie jest tajemnicą, ponieważ i tak jest kopiowany do konfiguracji każdego klienta. Klucz prywatny jest poufny: każdy, kto go posiada, może uruchomić serwer, któremu klienci będą ufać.

Wykonaj kopię zapasową obu plików teraz, zanim skonfigurujesz dwudziestu klientów.

sudo tar czf ~/rustdesk-keys.tgz -C ~/rustdesk/data id_ed25519 id_ed25519.pub
sudo chmod 600 ~/rustdesk-keys.tgz

Skopiuj to archiwum poza serwer. Oto dlaczego ten krok jest ważniejszy niż jakikolwiek inny. Jeśli usuniesz ~/rustdesk/data lub przeprowadzisz reinstalację na nowym VPS bez skopiowania tego pliku, hbbs wygeneruje nową parę kluczy przy następnym uruchomieniu. Każdy klient nadal posiada stary klucz publiczny, więc hbbs odrzuci połączenie, a klient przejdzie w tryb offline. Uruchom sudo cat ~/rustdesk/data/id_ed25519.pub i porównaj wynik z polem Key na dowolnym kliencie: oba ciągi nie będą już zgodne, a ta niezgodność jest jedyną przyczyną awarii. Naprawa wymaga ręcznej edycji ustawień na każdej maszynie, w tym na tych, do których dostęp uzyskiwałeś za pomocą RustDesk.

Klucz nie jest hasłem sesji, a mylenie tych dwóch pojęć prowadzi do pominięcia jednego z nich. Klucz decyduje o tym, z którymi klientami będzie komunikował się serwer. Stałe hasło lub kod jednorazowy na maszynie zdalnej decyduje o tym, kto może otworzyć sesję na tej maszynie. Potrzebujesz obu zabezpieczeń, a posiadanie jednego nie rekompensuje słabości drugiego.

Dlaczego niezauwierzytelniony przekaźnik stanowi problem

Domyślnie hbbr nie przeprowadza żadnej weryfikacji. Dokumentacja konfiguracji RustDesk stwierdza to wprost: pusty klucz pozwala klientom bez pasującego klucza na korzystanie z przekaźnika. Pusta wartość domyślna istnieje po to, aby nowi użytkownicy nie napotykali błędów niezgodności kluczy przy pierwszym uruchomieniu. Kosztem tego jest fakt, że każdy, kto znajdzie Twój adres na porcie TCP 21117, może przesyłać swój ruch sesyjny przez Twój VPS, wykorzystując Twój limit transferu i Twój adres IP.

command: hbbr -k _ rozwiązuje ten problem. Argument _ nakazuje hbbr wczytanie pary kluczy z katalogu roboczego, a ponieważ oba kontenery montują ten sam ./data, jest to ta sama para, którą wygenerował już hbbs. Nic nie jest kopiowane ręcznie, więc konfiguracje nie mogą się rozbiec.

Współdzielony wolumen to element, w którym użytkownicy najczęściej popełniają błędy. Jeśli nadasz hbbr własny katalog, wygeneruje on inną parę kluczy. Wtedy hbbs i hbbr nie będą ze sobą zgodne, każda sesja przekaźnikowa zakończy się niepowodzeniem, a sesje bezpośrednie będą nadal działać. Objaw jest mylący: RustDesk łączy się z niektórymi węzłami, a z innymi nie, w zależności od tego, czy przebijanie dziur (hole punching) zakończyło się powodzeniem. Jedno polecenie ls -l ~/rustdesk/data/ pokazujące pojedynczą parę id_ed25519 pozwala wykluczyć ten problem.

Skierowanie klientów na własny serwer

Na każdej maszynie otwórz RustDesk, przejdź do Settings, następnie Network, a potem ID/Relay Server.

• ID Server: nazwa hosta, na przykład rustdesk.example.com. Klient używa portu 21116, chyba że podano inny.
• Relay Server: pozostaw puste, gdy hbbr działa na tym samym hoście co hbbs.
• API Server: pozostaw puste. Wersja open source nie udostępnia tego interfejsu.
• Key: ciąg base64 z id_ed25519.pub, wklejony dokładnie, bez spacji na końcu.

Główne okno powinno poinformować, że klient jest gotowy. Jeśli tak się nie dzieje, ruch UDP 21116 nie dociera do hbbs, ponieważ rejestracja i sygnał heartbeat odbywają się wyłącznie przez UDP i tylko to pozwala na przejście ID w stan online.

Ograniczenie portów w celu uniknięcia otwartej usługi przekaźnika

Ponieważ kontenery korzystają z sieci hosta (host networking), przed nimi nie ma reguły Docker NAT, więc reguły ufw działają zgodnie z oczekiwaniami.

sudo ufw allow 22/tcp
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enable
sudo ufw status numbered

Dodaj 21118:21119/tcp tylko wtedy, gdy uruchamiasz klienta przeglądarkowego. Pozostaw otwartą drugą sesję SSH podczas włączania ufw, aby błąd w regule SSH nie spowodował utraty dostępu do serwera. Podstawy zapory sieciowej ufw dla VPS omawiają domyślne polityki oraz kolejność reguł.

Oto pułapka. Jeśli przejdziesz na publikowanie portów za pomocą bloku ports:, co wykorzystuje alternatywny przykład obrazu nadzorcy RustDesk, Docker zapisuje własne reguły DNAT, a pakiety docierają do kontenera z pominięciem łańcucha, w którym znajdują się reguły ufw. W takim przypadku polecenie ufw deny dla portu 21117 nie przynosi efektu, a przekaźnik pozostaje otwarty na świat, mimo że ufw status twierdzi inaczej. Publikowanie portów w Dockerze omija ufw wyjaśnia kolejność łańcuchów. Sieć hosta całkowicie eliminuje ten problem. Jeśli publikujesz port, powiąż go z jednym adresem, tak jak w "127.0.0.1:21118:21118" za reverse proxy.

Ograniczanie dostępu według adresu źródłowego działa tylko wtedy, gdy klienci posiadają stałe adresy.

sudo ufw allow from 203.0.113.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 21116 proto udp

Laptopy w sieciach hotelowych nie mają stałych adresów, dlatego klucz na hbbr wykonuje tutaj znacznie ważniejszą pracę niż zapora sieciowa.

Upgrading a stack that holds your key

The key lives in the bind mount, not inside the container, so an upgrade is safe as long as you leave ./data alone.

1. Back up the data directory first: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Read the release notes for the new tag on the rustdesk-server releases page.
3. Edit compose.yml and change both image: lines to the new tag.
4. Run sudo docker compose pull, then sudo docker compose up -d.
5. Run sudo cat ~/rustdesk/data/id_ed25519.pub and confirm the string is the one your clients already hold.

Step 5 is the check that matters, because a changed key is silent on the server and breaks every client at the same moment. Rolling back is putting the old tag back and running up -d again, and that only works because you pinned it: with latest, docker compose pull moved the name onto the new image, so there is no tag left that names the old one.

The usual way to lose the key is not docker compose down, which leaves a bind mount alone. It is migrating to a new VPS and copying only compose.yml. Copy ./data with it.

Monitorowanie ruchu wychodzącego w planach z limitem transferu

hbbr jest jedynym elementem tego stosu, który może zużywać limit transferu. FAQ RustDesk określa zużycie dla jednego połączenia przekaźnikowego przy ekranie 1920x1080 na poziomie od 30 KB/s do 3 MB/s, a typową pracę biurową na około 100 KB/s. Są to wartości publikowane dla pojedynczej sesji, a nie pomiar konkretnej konfiguracji. W przeliczeniu na sześćdziesiąt godzin w miesiącu, czyli dwie godziny dziennie, wartości te prezentują się następująco.

[
  {
    "label": "Low end, 30 KB/s",
    "gb_per_month": 6.5
  },
  {
    "label": "Office work, 100 KB/s",
    "gb_per_month": 21.6
  },
  {
    "label": "High end, 3 MB/s",
    "gb_per_month": 648
  }
]

Przy tempie pracy biurowej jedna sesja zużywa około 21.6 GB miesięcznie, co jest wartością pomijalną dla większości planów. Przy górnej granicy publikowanego zakresu te same sześćdziesiąt godzin kosztuje 648 GB, a dwie jednoczesne sesje przy takim obciążeniu wyczerpują limit 1 TB w ciągu miesiąca. Dolna granica wynosi 6.5 GB. Gigabajty w tym kontekście to 1000 MB, zgodnie ze standardowym sposobem rozliczania limitów transferu.

docker stats nie przedstawi szczegółowego zestawienia, ponieważ kontener korzystający z host networking współdzieli przestrzeń nazw sieci hosta, więc jego liczniki są licznikami całego systemu. Działają natomiast dwa inne narzędzia. vnstat mierzy ruch całego serwera:

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

Cały serwer oznacza cały serwer: jeśli na tym VPS działa również usługa przesyłająca duże ilości danych, na przykład jeden z własnych serwerów zdjęć, który każdej nocy pobiera biblioteki z telefonów, jego wysyłanie danych trafia do tego samego miesięcznego zestawienia co ruch przekaźnika. Podobnie wygląda sytuacja z serwerem multimediów, ponieważ rozwiązanie takie jak Halcyon, zmieniające bibliotekę Jellyfin w przeglądalną wypożyczalnię wideo z lat 90. przesyła dane do każdego widza, a ten ruch wychodzący obciąża ten sam limit, z którego korzysta przekaźnik.

Licznik nftables pozwala zmierzyć ruch konkretnie dla przekaźnika:

sudo nft add table inet relaymeter
sudo nft add chain inet relaymeter out '{ type filter hook output priority 0 ; }'
sudo nft add rule inet relaymeter out tcp sport 21117 counter
sudo nft list table inet relaymeter

Reguła ta nie zawiera werdyktu, więc zlicza pakiety i bajty bez zmiany uprawnień, a umieszczenie jej we własnej tablicy sprawia, że nie koliduje ona z ufw. Nie jest ona trwała: należy umieścić te same linie w /etc/nftables.conf, aby zachować je po restarcie. Licznik rośnie tylko wtedy, gdy sesja jest faktycznie przekaźnikowana. Licznik, który stale rośnie, mimo że żadne z Twoich urządzeń nie jest połączone, oznacza, że ktoś inny znalazł Twój przekaźnik, co jest sytuacją, której ma zapobiegać hbbr -k _. Ponieważ nie będziesz codziennie sprawdzać nft list, skonfiguruj zadanie cron, które porówna liczbę bajtów z progiem i wyśle powiadomienie push po jego przekroczeniu, co można zrealizować za pomocą własnego serwera ntfy.

hbbr posiada również limity prędkości, które można obniżyć. SINGLE_BANDWIDTH domyślnie ustawia 128 Mb/s na połączenie przekaźnikowe, a TOTAL_BANDWIDTH 1024 Mb/s dla wszystkich połączeń łącznie. Ustawienie SINGLE_BANDWIDTH=8 ogranicza jedną sesję do około 1 MB/s. Ogranicza to prędkość, a nie miesięczną sumę, więc należy traktować to jako sposób na zapobieżenie wysyceniu łącza przez jedną sesję, a nie jako narzędzie kontroli budżetu.

Kiedy przekaźnik nie jest w ogóle potrzebny

W przypadku konfiguracji osobistej szczera odpowiedź brzmi: być może nic z tego nie jest potrzebne. Umieść obie maszyny w sieci mesh VPN i łącz się bezpośrednio z adresem tunelu. Nie ma wtedy potrzeby używania hbbs, hbbr, wyjścia przekaźnika ani aktualizowania kontenera na VPS.

Na maszynie, którą chcesz kontrolować, włącz bezpośredni dostęp przez IP w ustawieniach bezpieczeństwa RustDesk. Pole portu domyślnie przyjmuje wartość 21118. Przed próbą połączenia sprawdź, czy usługa nasłuchuje na tym porcie:

ss -tlnp | grep 21118

Następnie połącz się z adresem VPN tego węzła zamiast z jego ID. FAQ RustDesk podaje, że w tym trybie połączenie jest niezaszyfrowane, dlatego należy uruchamiać je wewnątrz tunelu i nigdy przez otwarty Internet. To tunel zapewnia szyfrowanie.

Wybór zależy od tego, kto jest właścicielem maszyn. Własna instancja hbbs i hbbr jest właściwym rozwiązaniem, gdy obsługujesz maszyny, które nie należą do Ciebie, lub osoby, które nigdy nie zainstalują klienta VPN, ponieważ po ich stronie konfiguracja sprowadza się do ID i hasła. Sieć mesh VPN z bezpośrednim dostępem przez IP jest właściwa, gdy każda maszyna należy do Ciebie i może przechowywać klucz. Porównanie WireGuard i Tailscale omawia dwa typowe sposoby budowy takiej sieci, a uruchamianie pulpitu zdalnego na Linux VPS opisuje drugi przypadek, w którym maszyna, do której chcesz uzyskać dostęp, jest samym serwerem.

FAQ

Czy każda sesja RustDesk przechodzi przez mój przekaźnik?

Nie. hbbs najpierw próbuje połączyć klientów bezpośrednio, wykorzystując technikę hole punching przez NAT znajdujący się przed każdym z nich. Tylko sesje, w których ta metoda zawiedzie, korzystają z hbbr i tylko one generują zużycie pasma. Wyjątkiem jest ALWAYS_USE_RELAY=Y w hbbs, która wymusza przesyłanie każdej sesji przez hbbr, niezależnie od dostępności bezpośredniego połączenia. Jeśli ta zmienna jest ustawiona w pliku Compose, każdy bajt każdej sesji obciąża limit transferu.

Gdzie przechowywany jest klucz serwera RustDesk i co się stanie, jeśli go utracę?

hbbs generuje id_ed25519 oraz id_ed25519.pub w swoim katalogu roboczym przy pierwszym uruchomieniu. W oficjalnym obrazie katalog ten to /root, więc przy użyciu wskazanego wyżej montowania wolumenu pliki pojawiają się w ./data na hoście. Należy wykonać kopię zapasową obu plików poza serwerem. W przypadku ich utraty hbbs przy kolejnym starcie wygeneruje nową parę, a każdy klient posiadający stary klucz publiczny zostanie odrzucony. Nie ma innej metody odzyskania dostępu niż ręczna edycja pola Key na każdym kliencie.

Które porty należy otworzyć dla własnego serwera RustDesk?

TCP 21115, 21116 oraz 21117, a także UDP 21116. hbbs używa portu 21115 do testu typu NAT, a 21116 do rejestracji ID i sygnału heartbeat przez UDP oraz do hole punching przez TCP. hbbr używa portu 21117 do przekaźnika. Porty TCP 21118 oraz 21119 to porty WebSocket dla klienta przeglądarkowego, więc należy je pozostawić zamknięte, jeśli nie są używane. Port TCP 21114 należy do konsoli webowej wersji Pro i nie jest wymagany w wersji open source.

Czy osoby niepowołane mogą korzystać z mojego przekaźnika RustDesk?

Tak, jeśli hbbr zostanie uruchomiony z domyślną konfiguracją. Dokumentacja RustDesk wskazuje, że pusty klucz pozwala klientom bez pasującego klucza na korzystanie z przekaźnika, więc każdy, kto pozna nazwę hosta i port 21117, może przesyłać ruch przez serwer. Należy uruchomić hbbr z flagą -k _, aby wczytał tę samą parę kluczy, którą hbbs wygenerował w udostępnionym wolumenie ./data. Po tym zabiegu tylko klienci skonfigurowani z użyciem klucza publicznego będą mogli korzystać z przekaźnika.