Jak używać RustDesk, aby obejść CGNAT i uzyskać zdalny dostęp bez stałego adresu IP

Mam prosty pulpit Linux w domu, którego używam jako serwer przeskokowy, aby uzyskać dostęp do innych maszyn za zaporą sieciową mojego routera. Kiedy niedawno się przeprowadziłem, mój dostawca internetu niestety ustawił moje połączenie za Carrier-Grade NAT, czyli CGNAT. Krótko mówiąc, sposób, w jaki mój dostawca przydzielił mi publiczny adres IP, sprawił, że przekierowanie portów dla zdalnego dostępu do mojego serwera przeskokowego nie było już możliwe.

Płacenie dodatkowo za statyczny adres IP też nie wchodziło w grę, a także nie było opcją wystawianie wielu usług bezpośrednio do internetu, aby umożliwić zdalny dostęp. Więc przestałem próbować sprawić, by moje domowe połączenie było osiągalne. Zamiast tego stworzyłem mały VPS, który miał pełnić rolę osiągalnej części i używałem go jako przekaźnika RustDesk.

Ustawienia mojego routera i zapory sieciowej nie były problemem

Kiedy CGNAT stoi na drodze, przekierowanie portów mi nie pomoże

Zacząłem tam, gdzie większość osób zajmujących się homelabami zaczyna, gdy coś, co wcześniej działało, przestaje działać. Otworzyłem ustawienia routera, znalazłem ustawienia przekierowania portów i sprawdziłem adres WAN. Rzeczywiście, był w zakresie 10.x, co oznaczało, że otrzymałem współdzielony publiczny adres IP.

Było to zaskoczeniem, ponieważ korzystałem z tego samego dostawcy internetu, ale w mojej nowej lokalizacji użycie sieci szkieletowej do obsługi Punktów Interkonektu (POI) oznaczało, że mój router nie znajdował się już na krawędzi mojego połączenia internetowego. Mogłem tworzyć reguły przekierowania portów przez cały dzień, ale już nie miały zastosowania.

Ponieważ mój serwer przeskokowy Linux mógł nadal łączyć się na zewnątrz, zdecydowałem się wypróbować oprogramowanie do zdalnego dostępu RustDesk, ale z przekaźnikiem zbudowanym na VPS działającym jako swojego rodzaju publiczny punkt spotkań pomiędzy moim serwerem domowym a urządzeniem, którego używałem do łączenia się z nim. W ten sposób zdalny laptop łączy się z VPS, a serwer przeskokowy Linux również łączy się z VPS, a przekaźnik hostowany na nim wypełnia lukę.

Relay VPS RustDesk nie musi być niczym wymyślnym

Musiałem tylko załatać to, zabezpieczyć i utrzymać prosto

Dokumentacja RustDesk stwierdza, że hosty relays nie muszą być efektowne. Wybrałem tani VPS z jednym vCPU i 2 GB pamięci, a co najważniejsze, z publicznym adresem IPv4. Nawet to było przesadą w stosunku do moich potrzeb.

Wybrałem Debiana 12 jako system operacyjny, ponieważ jest on wciąż stabilny, przewidywalny i na tyle wspierany, że można zainstalować i uruchomić to, czego potrzebuję. Przed zainstalowaniem RustDesk wykonałem zwykłe zadania po instalacji Debiana, takie jak tworzenie administratora, przyznawanie mu uprawnień sudo, przejście na klucz SSH oraz wyłączenie logowania root.

Następnie przygotowałem zaporę UFW, włączyłem ją i pozwoliłem na następujące porty:

sudo ufw allow OpenSSH
sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp

Zainstalowałem również fail2ban i włączyłem automatyczne aktualizacje, ponieważ potrzebowałem, aby przekaźnik był projektem typu „ustaw i zapomnij”, o którym naprawdę nie musiałem myśleć:

sudo apt install -y fail2ban unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
sudo systemctl enable --now fail2ban 

Wybrałem natywną instalację RustDesk relay zamiast Dockera

Problemy z Dockerem i zaporą sieciową sprawiły, że był to łatwy wybór

Dokumentacja RustDesk zaleca używanie Dockera do instalacji ze względu na łatwość aktualizacji i przenośność. Dzięki Dockerowi możesz po prostu przebudować VPS, ponownie uruchomić kontenery i kontynuować pracę. Dla większości projektów hostowanych samodzielnie, to w zasadzie dokładnie to, czego bym potrzebował.

Tym razem jednak chciałem budowę, której mógłbym zaufać, zostawić w spokoju i o niej nie myśleć. Docker może tworzyć własne zasady sieciowe, co niekoniecznie jest niebezpieczne, ale utrudnia sprawy z zaporą UFW, ponieważ tworzy własne zasady iptables. Dla przekaźnika, którego jedynym zadaniem jest udostępnianie garści portów, wolałem nudną i przewidywalną metodę natywnej instalacji.

Nattywna instalacja była nieco łatwiejsza do sprawdzenia:

• hbbs i hbbr znajdują się w /usr/bin
• Systemd utrzymuje oba serwisy w stanie włączonym i działającym
• UFW kontroluje otwarte porty
• Klucze serwera są przechowywane w /opt/rustdesk-server

Pobrałem pakiety hbbs (serwer ID) i hbbr (serwer przekaźnikowy) dla obu komponentów serwera RustDesk, a następnie zainstalowałem je za pomocą apt:

sudo apt install ./rustdesk-server-hbbr_1.1.15_amd64.deb
sudo apt install ./rustdesk-server-hbbs_1.1.15_amd64.deb

Napotkałem jeden bardzo głupi i możliwy do uniknięcia problem, myśląc, że pojedynczy pakiet zawiera zarówno komponenty hbbr, jak i hbbs. Przypadkowo pobrałem tylko pakiet przekaźnika i byłem zdziwiony, dlaczego to nie działa. Polecenie „which” nie zwracało nic dla hbbs, ale which hbbr zwracało. Szybko zrozumiałem problem, pobrałem komponent hbbr i w końcu otrzymałem działającą konfigurację:

• /usr/bin/hbbs
• /usr/bin/hbbr

Musiałem powiedzieć RustDesk dokładnie, gdzie wysyłać ruch przekaźnikowy

Domyślna usługa działała, ale ustawienie przekaźnika musiało być wyczyszczone

Zainstalowanie obu pakietów Debian RustDesk od razu dało mi działające usługi systemd, co było miłą niespodzianką. rustdesk-hbbs i rustdesk-hbbr były aktywne, a serwer był gotowy do przyjmowania połączeń.

Był tylko problem, który trzeba było rozwiązać. Serwer ID, hbbs, uruchamia się jako zwykły /usr/bin/hbbs. To w porządku dla podstawowej konfiguracji, ale aby rozwiązać problem CGNAT, potrzebowałem, aby hbbs wyraźnie powiedział klientom, gdzie znajduje się przekaźnik. Wymagało to nadpisania usług systemd, a utworzono subdomenę, aby nadać rozwiązywalny adres:

Przekaźnik działa z:

/usr/bin/hbbr -k _

A serwer ID działa z:

/usr/bin/hbbs -r rd.ggcontentlabs.com:21117 -k _

Flaga -r jest ważną częścią, ponieważ informuje serwer ID, gdzie znajduje się serwer pośredniczący. Część -k _ włącza konfigurację klucza RustDesk, więc klienci potrzebują publicznego klucza serwera zamiast bezmyślnie ufać dowolnemu serwerowi, który przypadkowo ma ten sam adres.

Ustawiłem również ENCRYPTED_ONLY=1 bezpośrednio na usłudze przekaźnikowej, aby upewnić się, że połączenia są domyślnie szyfrowane. Dokumentacja Docker Compose to zaleca, ale ponieważ działa to również jako normalna zmienna środowiskowa systemd, a hbbr przenosi ruch sesji przekaźnikowej, miało sens jej włączenie:

sudo systemctl edit --full rustdesk-hbbr 

[Service]
Type=simple
WorkingDirectory=/opt/rustdesk-server
Environment=ENCRYPTED_ONLY=1
ExecStart=/usr/bin/hbbr -k _
Restart=always
RestartSec=10 

Gdy ponownie uruchomiłem usługi, w logach w końcu pojawiła się linia, którą potrzebowałem zobaczyć:

relay-servers=["rd.ggcontentlabs.com:21117"]

Ostatnim zadaniem konfiguracyjnym było wyodrębnienie klucza publicznego, który kończy się na „=”, do wykorzystania przy konfiguracji klientów RustDesk zarówno na moim zdalnym laptopie, jak i na moim serwerze pośrednim Linux:

sudo cat /opt/rustdesk-server/id_ed25519.pub; echo

Prawdziwym dowodem było połączenie się spoza własnej sieci

Ponieważ testowanie w mojej sieci LAN niczego absolutnie nie udowadnia

Gdy serwer był już uruchomiony i działał, prawdziwy test musiał pochodzić z maszyny spoza mojej sieci. Dzieje się tak, ponieważ RustDesk jest zaprojektowany tak, aby priorytetowo traktować bezpośrednie połączenia peer-to-peer (P2P), gdy są dostępne.

Więc skonfigurowałem RustDesk zarówno na serwerze pośrednim, jak i na zdalnych laptopach-klientach, aby używały serwera przekaźnikowego jako serwera ID i serwera przekaźnikowego, i wkleiłem klucz wygenerowany podczas instalacji. Doświadczenie z klientami RustDesk nauczyło mnie, że muszą zostać one ponownie uruchomione po załadowaniu nowej konfiguracji.

Prawdziwy test wciąż mógł zostać przeprowadzony w wygodzie mojego własnego domu. To tylko oznaczało, że musiałem podłączyć pulpit zdalny do mobilnego hotspotu na moim telefonie z Androidem. Połączenie nastąpiło szybko, prawie zbyt szybko. I sprawiło, że zastanawiałem się, czy użyto przekaźnika VPS, czy RustDesk korzystał ze swojego oficjalnego publicznego przekaźnika.

Połączyłem się po raz drugi, a tym razem obserwowałem logi na serwerze przekaźnikowym:

sudo journalctl -u rustdesk-hbbs -u rustdesk-hbbr -n 30 -f

To dało mi wynik, którego szukałem. Aktywność logu hbbs pokazała, że przekaźnik przenosił ruch, weryfikację kluczy i uzgodnienia połączenia.

CGNAT zostaje na stałe, ale przynajmniej mam dostęp zdalny

Mój dostawca internetu mówi, że dedykowany adres IP jest wciąż kilka miesięcy od teraz, ale już nie budzi takiego niepokoju

Zła wiadomość jest taka, że mój dostawca internetu mówi, iż możliwość posiadania dedykowanego adresu IP jest jeszcze oddalona o kilka miesięcy. Dobra wiadomość jest taka, że mam doskonale działający serwer pośredniczący RustDesk i szybki dostęp do mojego serwera skokowego Linux.

Maszyna z Linuxem jest teraz bezpiecznie za moim routerem, ale również za CGNAT, ale w pełni osiągalna z zewnątrz dzięki przekaźnikowi RustDesk. Mogłem nadal korzystać z publicznych serwerów przekaźnikowych RustDesk i w większości byłoby to w porządku. Ale homelab jest mój, podobnie jak serwer pośredniczący, więc chciałem, aby ścieżka przekaźnika również pozostała moja.

Ostatecznie wciąż jest to kolejny serwer, który wymaga podstawowej opieki. Muszę go aktualizować, tworzyć kopie zapasowe kluczy i naprawdę starać się unikać zamieniania go w kolejny magazyn na testowanie innych projektów. Ale podczas gdy cierpliwie czekam, aż mój dostawca internetu przydzieli mi routowalny adres IP, jako tymczasowe rozwiązanie do zdalnego dostępu, jestem z niego całkiem zadowolony.