Samodzielnie hostowany pulpit zdalny: dlaczego, jak i co może pójść nie tak

„Samodzielnie hostowany pulpit zdalny” zwykle oznacza jedno z dwóch: uruchomienie własnej infrastruktury relay/rendezvous dla narzędzia takiego jak RustDesk albo postawienie kompletnej webowej platformy dostępu zdalnego, takiej jak Apache Guacamole albo MeshCentral. Oba podejścia są poprawne; wiążą się z różnymi kompromisami. Ten artykuł opisuje, dlaczego możesz chcieć hostować samodzielnie, trzy poważne narzędzia w tej przestrzeni, jak wygląda rzeczywisty narzut operacyjny i kiedy samodzielne hostowanie naprawdę ma sens w porównaniu z usługą zarządzaną.

TL;DR: Hostuj samodzielnie, jeśli masz twarde wymagania dotyczące suwerenności danych (GDPR, branże regulowane, wdrożenia tylko wewnętrzne), jeśli chcesz zerowych stałych kosztów licencyjnych w skali, albo jeśli po prostu wolisz prowadzić własną infrastrukturę. Nie hostuj samodzielnie, jeśli jesteś małym zespołem bez dedykowanego DevOps, jeśli potrzebujesz certyfikatów do procesów zakupowych, albo jeśli wolisz zapłacić $7.99/mo i pozbyć się problemu.

Dlaczego samodzielne hostowanie?

Suwerenność danych

Główny powód, dla którego organizacje decydują się na samodzielne hostowanie. Jeśli podlegasz GDPR, HIPAA lub regulacjom branżowym (niemiecki sektor bankowy, administracja francuska, kontrahenci obronni), kierowanie sesji pulpitu zdalnego przez zewnętrzne SaaS, nawet z silnym szyfrowaniem, może nie spełniać wymagań audytorów. Samodzielne hostowanie na infrastrukturze, którą kontrolujesz (własnej albo wynajmowanej w regionie, który kontrolujesz), eliminuje zależność od strony trzeciej. Nasz zarządzany relay kończy TLS, więc stwierdzenie "relay jest nasz" daje materialnie silniejszą pozycję zgodności niż powierzenie tej roli komuś innemu.

Wdrożenia tylko wewnętrzne

Jeśli ruch pulpitu zdalnego nigdy nie powinien opuszczać twojej sieci — np. systemy sterowania przemysłowego w air‑gapped sieci lub szpitalna LAN z restrykcyjnym filtrowaniem egress — usługa chmurowa jest strukturalnie niewłaściwa. Potrzebujesz relay, który działa w LAN, dostępnego tylko dla uprawnionych urządzeń.

Koszt w skali

Dla bardzo dużych wdrożeń (1000+ punktów końcowych) model płatności za miejsce użytkownika szybko rośnie. Self-hostowany relay działający na $40/month VPS może obsługiwać tysiące równoczesnych sesji, jeśli masz wystarczającą przepustowość. Punkt równowagi w porównaniu z ceną zarządzaną zależy od narzędzia, ale na poziomie MSP i enterprise self-hosting wygrywa pod względem kosztu surowego.

Dostosowanie i kontrola

Samodzielne hostowanie pozwala modyfikować źródła (zgodnie z obowiązkami AGPL-3.0), dostosować branding bez konieczności płacenia za white‑label, oraz stroić zachowanie relaya pod konkretną topologię sieciową.

Konsekwencje i kompromisy

Samodzielne hostowanie nie jest darmowe. Rachunek przychodzi w postaci nakładu pracy DevOps, a nie tylko opłat miesięcznych. Konkretnie:

• Provisioning i utrzymanie serwera: Potrzebujesz serwera Linux z publicznym IP (dla osiągalności relaya), monitoringu, rotacji logów, patchowania systemu operacyjnego i prawdopodobnie infrastruktury kopii zapasowych. Przyjmij 2–4 godziny/miesiąc pracy w stanie stabilnym, więcej podczas incydentów.
• Konfiguracja NAT i firewall: Relay musi być osiągalny z internetu na konkretnych portach (21115-21119 dla domyślnej konfiguracji RustDesk). Jeśli działasz za NAT, potrzebne będzie przekierowanie portów z krawędzi sieci do hosta relay.
• Zarządzanie certyfikatami: Jeśli chcesz TLS na interfejsie zarządzającym (powinieneś), potrzebujesz certbota Let's Encrypt lub podobnego. Odnawianie co 60–90 dni, zautomatyzowane cronem.
• Planowanie pojemności: Pojedynczy relay może obsłużyć dużo ruchu, ale w pewnym momencie potrzebujesz drugiego, potem load balancing. Stajesz się zespołem infrastruktury.
• Brak wsparcia od dostawcy: Gdy coś padnie o 2:00 w nocy, nie ma linii wsparcia. Debugujesz samodzielnie albo czekasz, aż społeczność odpowie.

Trzy poważne narzędzia

RustDesk (i forki takie jak Tenvo)

Architektonicznie najprostsze z trzech. Dwa binaria: hbbs (rendezvous server, ~30 MB RAM) i hbbr (relay, ~50 MB RAM). Oba są statycznymi binariami Rust bez zewnętrznych zależności. Ustawienie wyglądają mniej więcej tak:

# On a Linux VPS with a public IP
wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip

# Start hbbs (rendezvous) and hbbr (relay) as services
sudo ./hbbs -r your.public.ip
sudo ./hbbr

# Open ports 21115/tcp, 21116/tcp+udp, 21117/tcp, 21118/tcp, 21119/tcp
sudo ufw allow 21115:21119/tcp
sudo ufw allow 21116/udp

# Point clients at your server: in client settings,
# ID Server = your.public.ip, Relay Server = your.public.ip,
# Public Key = (printed by hbbs on first start, or check id_ed25519.pub)

Ślad zasobów jest minimalny — $5/month DigitalOcean droplet obsłuży dziesiątki równoczesnych sesji. Oficjalny RustDesk Pro server (płatny) dodaje webowy panel administracyjny, logi audytowe, LDAP/OIDC i funkcje brokerskie dla większych wdrożeń.

Apache Guacamole

Inna architektura: Guacamole to klientless aplikacja HTML5. Użytkownicy łączą się przez przeglądarkę; backend Guacamole (guacd) tłumaczy RDP, VNC i SSH na strumienie HTML5 canvas/WebSocket. Brak natywnego klienta po stronie kontrolującej jest przydatny w scenariuszach wsparcia, gdzie nie można instalować oprogramowania na stacji kontrolującej.

Kompleksowość operacyjna jest większa niż w RustDesk: Guacamole działa jako Java + Tomcat z bazą danych (MySQL lub Postgres) do zarządzania użytkownikami/połączeniami, plus demon guacd. Docker Compose znacznie to upraszcza, ale uruchamiasz 3–4 kontenery zamiast 2 binariów.

Guacamole jest właściwym wyborem, jeśli potrzebujesz dostępu przez przeglądarkę bez instalacji klienta. Jest złym wyborem, jeśli oczekujesz, że narzędzie samo rozwiąże NAT traversal między dwoma endpointami — Guacamole zakłada, że serwer Guacamole może już osiągnąć docelowy host przez RDP/VNC/SSH.

MeshCentral

MeshCentral to oparta na Node.js platforma do zarządzania zdalnego autorstwa Yliana Saint‑Hilaire (wcześniej w Intel). Wspiera pulpit zdalny, transfer plików, terminal, web console i UI do zarządzania flotą. Architektonicznie jest to pojedyncza aplikacja Node + baza danych (domyślnie NeDB, opcjonalnie Postgres), dostępna przez HTTPS.

MeshCentral to bardziej narzędzie do zarządzania flotą niż czysty relay pulpitu zdalnego — pomyśl o nim jak o RustDesk + inwentarz urządzeń + webowy panel administracyjny. Instalacja jest prosta (pojedyncze npm install + plik konfiguracyjny) i była wdrażana w produkcji przez niektóre większe organizacje, w tym Intel.

Gdzie MeshCentral odstaje: UI jest zagęszczone i niezbyt dopracowane, klienci mobilni są słabsi niż w RustDesk, a kodek/wydajność streamingu pulpitu nie jest tak zoptymalizowana jak w RustDesk czy AnyDesk. Najlepszy, gdy chcesz zunifikowany webowy panel do zarządzania flotą; mniej atrakcyjny jako narzędzie jednofunkcyjne do pulpitu zdalnego.

Jak naprawdę wygląda self-hostowany relay RustDesk

Krok po kroku na Hetzner CX11 ($4/month) Ubuntu 24.04 VPS:

1. Provision VPS z publicznym IPv4. Ustaw silne hasło roota i włącz uwierzytelnianie kluczem SSH.
2. Otwórz zaporę:

   sudo ufw allow OpenSSH
   sudo ufw allow 21115:21119/tcp
   sudo ufw allow 21116/udp
   sudo ufw enable

3. Zainstaluj binaria serwera RustDesk z strony wydań GitHub. Umieść je w /opt/rustdesk-server/.
4. Utwórz pliki jednostek systemd dla hbbs i hbbr, aby uruchamiały się po restarcie. Wiki RustDesk ma przykładowe jednostki; my utrzymujemy sprawdzoną kopię w naszym help center.
5. Pobierz klucz publiczny wydrukowany przez hbbs przy pierwszym uruchomieniu. Rozdystrybuuj go do klientów wraz z nazwą hosta serwera.
6. Skonfiguruj klientów: w ustawieniach klienta Tenvo ustaw ID Server, Relay Server i Public Key. Klient zacznie używać twojego relay zamiast naszego.
7. Opcjonalnie: terminacja TLS przez Caddy jeśli chcesz serwować webowy panel administracyjny (RustDesk Pro) na 443 z automatycznym odnawianiem certyfikatów Let's Encrypt.

Całkowity czas na świeżym VPS: około 30 minut przy pierwszym razie, ~10 minut jeśli masz doświadczenie. Bieżące utrzymanie: apt update && apt upgrade co tydzień, obserwacja logów relay, restart jeśli pojawią się wycieki pamięci (rzadkie). Szczegóły wdrożenia na Linuxie znajdziesz na naszej stronie platformy Linux.

Stanowisko Tenvo w kwestii samodzielnego hostowania

Pozwalamy na samodzielne hostowanie relay nawet w płatnych planach, jeśli chcesz. Klient Pro jest domyślnie skonfigurowany do komunikacji z naszym zarządzanym relayem, ale możesz w każdej chwili przełączyć go na własny relay w ustawieniach. Nie ma żadnej bramki "enterprise on‑prem add‑on". To celowe: licencja AGPL-3.0 daje prawo do samodzielnego hostowania i chcemy, by to prawo było realne.

Większość użytkowników tego nie robi. Nasz zarządzany relay po prostu działa, ma globalne PoP i jest wliczony w podstawową subskrypcję. Jeśli twoja historia suwerenności danych wymaga "braku strony trzeciej w ścieżce", hostuj samodzielnie. W przeciwnym razie oszczędź czas DevOps i korzystaj z zarządzanego relaya — za to płaci subskrypcja. Pełną architekturę bezpieczeństwa, która działa pod obydwoma wdrożeniami, opisujemy na naszej stronie bezpieczeństwa.

Kiedy samodzielne hostowanie to zły wybór

• Jesteś małym zespołem bez zasobów DevOps. Nakład utrzymania jest realny. Jeśli nie masz osoby, której opis stanowiska zawiera "patchuje serwery Linux", samodzielne hostowanie to stały koszt.
• Potrzebujesz dokumentów do zakupów. Audytorzy żądający raportów SOC 2 nie przyjmą odpowiedzi "uruchamiamy własny serwer". Usługi zarządzane z formalnymi certyfikatami są tu łatwiejsze.
• Masz tylko 5–20 punktów końcowych. Punkt równowagi względem $7.99/mo planu zarządzanego to setki dolarów rocznie oszczędzonego czasu DevOps. Przy 20 endpointach zarządzany plan jest jednoznacznie tańszy.
• Robisz to dla oszczędności na pojedynczym miejscu. VPS za $5/mo plus 2 godziny/miesiąc administracji przy rozsądnej stawce godzinowej już kosztuje więcej niż pojedyncze miejsce w planie zarządzanym.

Wnioski

Samodzielnie hostowany pulpit zdalny to realna opcja i dla niektórych organizacji właściwy wybór. RustDesk (i forki takie jak Tenvo) to najprostsza poważna ścieżka self‑host; Guacamole jest właściwy do dostępu przez przeglądarkę; MeshCentral to generalista do zarządzania flotą. Kompromis zawsze sprowadza się do czasu DevOps kontra wydatków. Jeśli masz wymagania suwerenności danych — hostuj samodzielnie. Jeśli masz $7.99/month i wolisz budować produkt zamiast operacji — użyj zarządzanego relaya. Zobacz ceny lub pobierz Tenvo i najpierw wypróbuj flow zarządzany — zawsze możesz przejść na self‑host, zmieniając jedną linię konfiguracji.

FAQ

Czy mogę hostować relay samodzielnie i nadal używać interfejsu klienta / kont Tenvo?
Tak. Wskaż klienta na swój relay w ustawieniach. Funkcje kont zależne od Tenvo control plane (billing, team management) nadal działają; tylko ruch sesji przechodzi przez twój relay.

Jakiego sprzętu potrzebuję dla self‑hostowanego relaya RustDesk?
Mały VPS: 1 vCPU, 1 GB RAM, 1 TB/miesiąc transferu wystarczy dla dziesiątek równoczesnych sesji. Hetzner CX11, DigitalOcean basic lub AWS t4g.nano będą działać. W skali ograniczeniem zwykle jest przepustowość, nie CPU.

Czy self‑hostowany RustDesk obsługuje 2FA / SSO?
Darmowy, open‑source'owy serwer (hbbs/hbbr) tego nie oferuje. RustDesk Pro server (płatny, osobna licencja) dodaje webowy konsolę, OIDC i logi audytowe. W zarządzanym Tenvo Pro 2FA jest dostępne od ręki.

Czy mogę hostować relay na AWS Lightsail / Cloudflare / itp.?
Każdy dostawca z publicznym IPv4 i możliwością otwarcia niestandardowych portów UDP/TCP zadziała. Standardowy proxy Cloudflare terminuje TCP tylko na porcie 443; potrzebowałbyś Cloudflare Spectrum (płatne) lub dedykowanego listenera TCP dla portów RustDesk.

Jak samodzielne hostowanie wpływa na GDPR?
Jeśli twój relay znajduje się w UE i dane nigdy jej nie opuszczają, zasady transferów transgranicznych GDPR nie mają zastosowania. To główny powód, dla którego instytucje publiczne i służba zdrowia w UE wybierają self‑host.