Tailscale bez przekierowania portów: prywatny zdalny pulpit do własnego komputera

Masz w domu komputer, do którego chciałbyś sięgnąć z pracy albo z wakacji. Klasyczna rada z internetu brzmi: "przekieruj port na routerze" - i wystawia Twój komputer na skanowanie przez cały internet. Jest inna droga: prywatna sieć między Twoimi własnymi urządzeniami, bez otwierania czegokolwiek na świat. Tailscale jest jednym z narzędzi, które to umożliwiają.

Dla kogo jest ten poradnik i co dokładnie zbudujemy

Piszemy dla osoby, która nie administruje sieciami zawodowo, ale potrafi zainstalować program i wejść w Ustawienia Windows. Zbudujemy jedną konkretną rzecz: zdalny pulpit (RDP) do jednego domowego komputera z Windows, dostępny z jednego Twojego drugiego urządzenia. Nie budujemy udostępniania plików ani dostępu dla rodziny - im mniej otwierasz, tym mniej trzeba pilnować.

Trzy pojęcia, które będą się powtarzać:

Tailnet - nazwa Twojej prywatnej sieci w Tailscale; zakładasz ją, logując się po raz pierwszy.
Węzeł (machine) - pojedyncze urządzenie dodane do tailnetu.
MagicDNS - funkcja, dzięki której zamiast adresu IP wpisujesz nazwę urządzenia. Jest domyślnie włączona i producent zaleca jej pozostawienie (Tailscale quickstart).

Krok 0: sprawdź to PRZED instalacją czegokolwiek

Zanim cokolwiek pobierzesz, sprawdź na komputerze domowym Ustawienia > System > Informacje i odczytaj edycję Windows. Hostem zdalnego pulpitu mogą być wyłącznie edycje Professional, Enterprise, Education oraz serwerowe. Microsoft pisze wprost, że edycje Home nie mogą pełnić roli hosta - mogą być tylko klientem, czyli łączyć się z innymi komputerami (Enable Remote Desktop on your PC).

Jeśli masz Windows Home, ten scenariusz jest dla Ciebie zamknięty i kończymy w tym miejscu. Nie podamy obejścia - narzędzia "odblokowujące RDP w Home" modyfikują komponenty systemowe, nie są wspierane przez Microsoft i nie polecamy ich. Sensowne wyjścia są dwa: dedykowany program do zdalnego pulpitu innego producenta albo udostępnienie folderu po SMB przez tailnet. Każde ma własny komplet ustawień bezpieczeństwa i zasługuje na osobny poradnik; nie chcemy zostawiać Cię z półtora krokiem i niedokończoną konfiguracją.

Potrzebujesz jeszcze uprawnień administratora na komputerze domowym (Microsoft wymaga ich do włączenia zdalnego pulpitu), drugiego urządzenia oraz konta u dostawcy tożsamości - Tailscale nie prowadzi własnych haseł, logujesz się kontem Google, Microsoft, Apple lub innego obsługiwanego dostawcy (Tailscale quickstart). Klient dla Windows wymaga Windows 10 lub nowszego albo Windows Server 2016 lub nowszego (Install Tailscale on Windows).

Krok 1: najpierw zabezpiecz konto, potem dodawaj urządzenia

Kolejność ma tu znaczenie i większość poradników robi ją odwrotnie. Bezpieczeństwo całego tailnetu jest dokładnie tak dobre, jak bezpieczeństwo konta, którym się logujesz: Tailscale polega na Twoim dostawcy tożsamości, a ustawienia uwierzytelniania tego dostawcy, w tym MFA, są automatycznie wykorzystywane (Enable two-factor and multifactor authentication).

Włącz uwierzytelnianie dwuskładnikowe (MFA) w koncie, którego użyjesz do Tailscale. Teraz, nie "kiedyś potem" - bez tego reszta konfiguracji jest kosmetyką.
Zaloguj się do konsoli administracyjnej Tailscale i na stronie Device management włącz zatwierdzanie urządzeń (device approval). To pierwsze logowanie zakłada od razu Twój tailnet - konsola pokaże pustą listę urządzeń. Urządzenie oczekujące na zatwierdzenie nie może wysyłać ani odbierać ruchu, dopóki administrator go nie zaakceptuje (Device approval). Dzięki temu cudze zalogowanie się na Twoje konto nie kończy się od razu obcym urządzeniem w Twojej sieci.

Krok 2: dodaj oba urządzenia

Na komputerze domowym:

Pobierz instalator .exe ze strony pobierania klienta dla Windows. Ten sam plik obsługuje wersje 32- i 64-bitowe i sam dobiera właściwą (Install Tailscale on Windows).
Uruchom instalator. Po zakończeniu w zasobniku systemowym pojawi się ikona Tailscale; jeśli jej nie widzisz, kliknij strzałkę rozwijającą ukryte ikony.
Kliknij ikonę prawym przyciskiem, wybierz Log in i zaloguj się w przeglądarce - tym samym kontem, którym logowałeś się do konsoli w kroku 1. Urządzenie dołącza do tailnetu założonego wtedy; jeśli jednak robisz to naprawdę po raz pierwszy, Tailscale poprowadzi Cię przez utworzenie sieci.
Zatwierdź urządzenie w konsoli.

Na drugim urządzeniu zainstaluj aplikację Tailscale ze sklepu właściwego dla systemu, zaloguj się tym samym kontem i również je zatwierdź.

Weryfikacja: na stronie Machines w konsoli widzisz dwa urządzenia, każde z własnym adresem z zakresu 100.x.y.z, który Tailscale przydziela automatycznie (Tailscale quickstart). Zanotuj nazwę MagicDNS komputera domowego oraz oba adresy - przydadzą się w następnym kroku. Jeśli przeglądarka nie otworzyła się sama, kliknij ikonę ponownie i wybierz Log in.

Krok 3: zawęź dostęp, ZANIM włączysz usługę

Dokumentacja Tailscale mówi wprost: przy tworzeniu nowego tailnetu domyślny plik polityki umożliwia komunikację między wszystkimi urządzeniami w tailnecie, a w braku sekcji acls stosowana jest domyślna reguła "allow all" (Manage permissions using ACLs). W praktyce: dopóki niczego nie zmienisz, każde urządzenie w Twojej sieci może próbować łączyć się z każdym innym na dowolnym porcie.

Skoro budujemy jedną usługę dla jednego klienta, zamieńmy to na regułę minimalną. W konsoli otwórz stronę Access controls. Struktura reguły ACL jest prosta: action (jedyną możliwą wartością jest accept, bo Tailscale odmawia domyślnie), src (źródła) i dst w formacie <host>:<porty>; opcjonalne pole proto ogranicza protokół, a bez niego reguła obejmuje TCP i UDP (Syntax reference for the tailnet policy file). Zarówno w src, jak i w dst możesz podać konkretny adres Tailscale urządzenia (dokumentacja wymienia typ "Tailscale IP" z przykładem 100.100.123.123), a zdalny pulpit nasłuchuje domyślnie na porcie 3389 - Microsoft podaje go dla RDP zarówno w TCP, jak i w UDP (Ports that are used by Remote Desktop Services). Nam wystarczy TCP. Jeśli kiedyś zmieniłeś port nasłuchu w rejestrze (Change the Remote Desktop listening port), w regule ACL i w regule zapory użyj swojego numeru zamiast 3389.

Reguła sprowadza się do jednego zdania: pozwól TYLKO adresowi mojego klienta łączyć się TYLKO z adresem komputera domowego i TYLKO na porcie 3389 po TCP. Świadomie nie podajemy gotowego bloku JSON do przeklejenia - składnia i selektory bywają aktualizowane (Tailscale rekomenduje dziś nowszą składnię grants, zachowując wsparcie dla ACL bezterminowo), a polityka wklejona bez zrozumienia to najlepszy sposób na odcięcie sobie dostępu. Przepisz strukturę z dokumentacji składni i z przykładów polityk, podstawiając swoje dwa adresy i port. Konsola ma też edytor wizualny.

Trzy rzeczy, o których trzeba wiedzieć, zanim klikniesz zapis:

Domyślną szeroką regułę trzeba usunąć świadomie. Dopisanie własnej reguły obok pozostawionej "allow all" niczego nie zawęża. Zanim ją usuniesz, upewnij się, że masz fizyczny dostęp do komputera domowego - pomyłka w polityce potrafi odciąć zdalny dostęp. Przed zmianą skopiuj dotychczasową treść pliku polityki do własnych notatek; to Twoja kopia zapasowa. Ścieżka wycofania: jeśli po zapisie stracisz połączenie RDP, otwórz konsolę administracyjną w przeglądarce z dowolnego urządzenia - dostęp do niej idzie przez logowanie u dostawcy tożsamości i nie zależy od pliku polityki - wklej zapisaną kopię i zapisz; dostęp wróci. Pełne wycofanie całej konfiguracji to wyłączenie przełącznika Pulpitu zdalnego i usunięcie urządzeń ze strony Machines. Nie przenoś polityk z cudzego tailnetu - selektory, tagi i adresy odnoszą się do konkretnej sieci i u Ciebie znaczą co innego.
Reguły są kierunkowe. Dokumentacja formułuje to tak: zezwolenie źródłu na połączenie z celem nie oznacza, że cel może połączyć się ze źródłem (Manage permissions using ACLs). Uwaga na częste nieporozumienie: to dotyczy inicjowania nowego połączenia w drugą stronę, a nie odpowiedzi w ramach połączenia już dozwolonego. Tailscale dokumentuje scenariusz RDP przez tailnet jako działający (Access remote desktops using Windows RDP), więc jedna reguła "klient do hosta na 3389" wystarcza; nie dopisuj reguły odwrotnej. Sami tej konfiguracji nie uruchamialiśmy - to wniosek z dokumentacji, nie z naszego testu.
ACL nie są zaporą dla Twojego domowego LAN-u. Ta sama dokumentacja zaznacza, że reguły nie wpływają na to, co urządzenie może osiągnąć w swojej sieci lokalnej.

Krok 4: włącz zdalny pulpit - i tylko dla właściwego konta

Zanim przestawisz przełącznik, przeczytaj ostrzeżenie: włączenie zdalnego pulpitu otwiera port na komputerze i czyni go osiągalnym dla urządzeń w Twojej sieci lokalnej. Microsoft mówi to wprost i zaleca włączanie tej funkcji wyłącznie w sieciach zaufanych oraz zadbanie o to, by wszystkie konta z dostępem zdalnym miały silne, unikalne hasła (Enable Remote Desktop on your PC). Tailnet chroni Cię przed internetem; nie chroni przed kimś w tej samej sieci lokalnej ani przed kimś, kto już jest w Twoim tailnecie.

Dlatego kolejność jest taka:

Ustaw prawdziwe, silne hasło na koncie Windows, którego będziesz używać zdalnie. Nie wystarczy PIN Windows Hello - PIN działa lokalnie na tym urządzeniu, a przy logowaniu przez zdalny pulpit podajesz nazwę użytkownika i hasło konta.
Dopiero teraz otwórz Ustawienia > System > Pulpit zdalny, przestaw przełącznik na Włączone i potwierdź w okienku dialogowym. W tym samym miejscu Microsoft zaznacza, że opcja "Spraw, aby mój komputer był wykrywalny w sieciach prywatnych, aby umożliwić automatyczne połączenie z urządzenia zdalnego" ("Make my PC discoverable on private networks...") jest domyślnie zaznaczona. Skoro łączysz się wyłącznie po adresie tailnetowym, odznacz ją - nie potrzebujesz rozgłaszania komputera w domowej sieci.
Zostaw włączone uwierzytelnianie na poziomie sieci (NLA). Microsoft opisuje je jako dodatkową warstwę: użytkownik musi uwierzytelnić się, zanim sesja zdalna zostanie zestawiona, i zaleca pozostawienie NLA wszędzie, gdzie to możliwe.
Jeśli dostęp ma mieć konto inne niż administrator, dodaj je punktowo w Użytkownicy pulpitu zdalnego. Jedno konto, nie grupa.

Zawęź regułę zapory Windows

Po włączeniu zdalnego pulpitu Windows dopuszcza połączenia na porcie 3389 w profilu sieci prywatnej - czyli także z całego domowego LAN-u. Skoro łączysz się przez tailnet, ten dostęp jest zbędny.

Otwórz konsolę Zapora Windows Defender z zabezpieczeniami zaawansowanymi (Win+R, wpisz wf.msc, Enter - wymaga uprawnień administratora) i przejdź do Reguły przychodzące. Ważne: włączenie Pulpitu zdalnego nie tworzy jednej reguły, tylko grupę reguł "Pulpit zdalny" (Remote Desktop), a RDP korzysta z portu 3389 zarówno w TCP, jak i w UDP (Ports that are used by Remote Desktop Services). Zawężenie samej reguły TCP zostawiłoby regułę UDP otwartą na cały LAN, więc zrób to dla obu:

Posortuj listę po kolumnie Grupa i znajdź grupę Pulpit zdalny. Interesują Cię pozycje Pulpit zdalny - tryb użytkownika (TCP-In) i Pulpit zdalny - tryb użytkownika (UDP-In) (w angielskiej wersji: Remote Desktop - User Mode (TCP-In) i (UDP-In)). Jeśli nazwy wyglądają inaczej, posortuj po porcie lokalnym i szukaj 3389.
Dla każdej z tych dwóch reguł: kliknij dwukrotnie, otwórz kartę Zakres ("Scope") i w sekcji Zdalne adresy IP przełącz z "dowolny adres IP" na "Te adresy IP", a następnie dodaj adres 100.x.y.z swojego klienta (Configure rules with group policy).
Alternatywnie regułę UDP-In możesz po prostu wyłączyć (prawy przycisk > Wyłącz regułę). W naszej polityce Tailscale dopuściliśmy wyłącznie TCP, a Microsoft opisuje 3389/TCP jako standardowy port sesji RDP, więc połączenie powinno zestawić się bez reguły UDP. Jeśli po tej zmianie coś nie działa, włącz regułę UDP-In z powrotem i zamiast wyłączać ją, zawęź jej Zakres jak w punkcie 2 - to wariant mniej inwazyjny i domyślnie zalecany.
Sprawdź, czy w grupie nie zostały włączone inne reguły z portem 3389 dla profilu prywatnego lub publicznego (Windows tworzy warianty per profil). Każda pozostawiona z zakresem "dowolny adres IP" psuje efekt.

Microsoft przypomina zasadę pierwszeństwa: reguły bardziej szczegółowe wygrywają z ogólniejszymi, a jawne reguły blokujące z zezwalającymi (Windows Firewall rules). Nazwy pozycji w tej konsoli różnią się między wersjami Windows.

Zanim zapiszesz zmianę w regułach zapory, upewnij się, że masz fizyczny dostęp do tego komputera albo drugą drogę wejścia. Wpisanie złego adresu w karcie Zakres odcina RDP w momencie zapisania reguły. Wycofanie jest proste, ale wymaga dostępu lokalnego: w tych samych właściwościach wróć w karcie Zakres do opcji "dowolny adres IP" (albo ponownie włącz wyłączoną regułę).

Czego nie robimy: nie przekierowujemy portu 3389 na routerze. Ani "tymczasowo", ani "na chwilę do testów". Cały sens tej konfiguracji polega na tym, że usługa nie jest widoczna z internetu.

Krok 5: połącz się i sprawdź, że to naprawdę działa przez tailnet

Z drugiego urządzenia, będąc zalogowanym w Tailscale:

Otwórz Podłączanie pulpitu zdalnego (Windows) albo aplikację zdalnego pulpitu swojej platformy - Tailscale wymienia rekomendowane aplikacje dla macOS, Linuksa, iOS i Androida w poradniku Access remote desktops using Windows RDP.
W polu nazwy komputera wpisz nazwę MagicDNS albo adres 100.x.y.z komputera domowego, nigdy publiczny adres IP swojego łącza.
Zaloguj się nazwą i hasłem konta z komputera domowego.

Przy pierwszym połączeniu aplikacja może pokazać ostrzeżenie o certyfikacie komputera docelowego; Tailscale zaznacza, że dla własnego, zaufanego komputera można je zaakceptować.

Test, który potwierdza, że zbudowałeś to, co chciałeś. Połączenie z domowej kanapy niczego nie dowodzi - mogłeś połączyć się po zwykłym LAN-ie. Zrób dwie rzeczy:

Przełącz klienta na inną sieć: hotspot z telefonu albo Wi-Fi u znajomego. Połączenie po nazwie MagicDNS powinno działać tak samo - to dowód, że tailnet faktycznie robi swoją robotę.
Zajrzyj do konfiguracji routera i upewnij się, że nie ma tam przekierowania portu 3389 ani włączonego UPnP, które mogło je utworzyć automatycznie. Ta konfiguracja ma działać bez ani jednego otwartego portu.

Jeśli się nie łączy - kolejność sprawdzania: czy oba urządzenia są zalogowane i aktywne w konsoli (rozłączony klient to najczęstsza przyczyna); czy komputer domowy nie usnął; czy urządzenie nie ma oznaczenia wygaśnięcia klucza; czy używasz adresu z tailnetu, a nie z domowego LAN-u; czy w ACL nie zawęziłeś dostępu do innego adresu, niż ma teraz Twój klient; czy hasło konta Windows jest poprawne i czy to konto ma prawo do zdalnego pulpitu.

Krok 6: rzeczy, które trzeba wiedzieć, zanim to zostawisz

Klucze urządzeń wygasają

Tailscale wymaga okresowego ponownego uwierzytelnienia; domyślny okres wygaśnięcia dla nowych domen to 180 dni, a po wygaśnięciu połączenia do i od urządzenia przestają działać (Key expiry). Dla komputera stojącego w domu, do którego akurat nie masz jak podejść, to realny problem. Możesz wyłączyć wygasanie klucza dla wybranego urządzenia: Machines, menu wielokropka, Disable Key Expiry. Traktuj to jako świadomy kompromis - dokumentacja ostrzega, że obniża to poziom bezpieczeństwa i może narazić sieć, jeśli urządzenie lub klucz zostaną przejęte. Gdy klucz już wygasł, administrator może go z konsoli tymczasowo przedłużyć o 30 minut (Temporarily extend key).

Praktyczne ostrzeżenie z tej samej dokumentacji: polecenie tailscale up --force-reauth, którym odnawia się klucze, może zerwać połączenie z tailnetem, więc nie uruchamiaj go zdalnie przez RDP ani SSH, jeśli nie masz innej drogi dostania się do maszyny.

Jak usunąć urządzenie

Zgubiony telefon albo sprzedany laptop trzeba wyrzucić z tailnetu. W konsoli otwórz Machines, znajdź urządzenie, kliknij menu wielokropka, wybierz Remove, a potem Remove machine. Urządzenie natychmiast traci połączenie z zasobami tailnetu (Remove a device). Dwie rzeczy z tej samej dokumentacji: odinstalowanie klienta nie usuwa urządzenia z tailnetu, a bez włączonego zatwierdzania urządzeń usunięte urządzenie może dołączyć ponownie bez zgody administratora - dlatego device approval włączyliśmy w kroku 1.

Zależność od usługi zewnętrznej

Tailscale to nakładka na WireGuard: ruch między Twoimi urządzeniami jest szyfrowany, a wymiana kluczy i informacja o tym, gdzie kogo szukać, przechodzi przez infrastrukturę firmy Tailscale. W typowym przypadku dane idą bezpośrednio między urządzeniami, ale gdy połączenie bezpośrednie nie dochodzi do skutku (np. za CGNAT-em albo restrykcyjnym NAT-em), ruch jest przekazywany przez serwery przekaźnikowe DERP producenta. Pozostaje wtedy zaszyfrowany end-to-end - klucze prywatne nie opuszczają urządzeń, więc, jak pisze Tailscale, serwer DERP nie jest w stanie odszyfrować ruchu (DERP servers) - ale opóźnienia rosną, a zależność od infrastruktury dostawcy jest wtedy większa, niż sugeruje słowo "bezpośrednio". Awaria po stronie usługi albo problem z kontem u dostawcy tożsamości mogą utrudnić zestawienie nowych połączeń. Jeśli budujesz coś, od czego zależy Twoja praca, miej plan B.

Czego ta konfiguracja nie robi

Nie chroni urządzeń przed złośliwym oprogramowaniem ani przed kimś, kto zna Twoje hasło do Windows, i nie zastępuje kopii zapasowej.
Nie działa, gdy komputer docelowy jest wyłączony lub uśpiony.
Nie zapewnia anonimowości i nie jest VPN-em do internetu. Domyślnie przez tailnet idzie wyłącznie ruch do Twoich własnych węzłów, a zwykłe przeglądanie stron nadal wychodzi przez lokalne łącze i dostawcę internetu - Tailscale nie ukrywa Twojej aktywności ani nie zmienia Twojego adresu publicznego. Kierowanie całego ruchu przez wybrane urządzenie to osobna funkcja (exit node), której tu nie włączamy.
Nie usuwa zależności od zewnętrznej usługi koordynującej.

Nie publikuj też nigdzie kluczy autoryzacyjnych ani zrzutów z konsoli, na których widać adresy i nazwy Twoich urządzeń.

Lista kontrolna

Sprawdziłem edycję Windows przed instalacją; host to Pro, Enterprise, Education lub edycja serwerowa
MFA włączone w koncie dostawcy tożsamości - przed dodaniem urządzeń
Device approval włączone w konsoli - przed dodaniem urządzeń
Oba urządzenia widoczne i zatwierdzone na stronie Machines
Kopia dotychczasowego pliku polityki zapisana w moich notatkach
Domyślna szeroka reguła usunięta świadomie, w miejscu, z którego mam fizyczny dostęp do hosta
ACL zawężone: źródło = adres mojego klienta, cel = adres hosta, port TCP 3389
Konto Windows używane zdalnie ma prawdziwe, silne hasło (nie sam PIN Windows Hello)
NLA pozostawione włączone
Odznaczona opcja wykrywalności komputera w sieciach prywatnych ("Make my PC discoverable on private networks")
Reguły zapory dla portu 3389 - zarówno TCP-In, jak i UDP-In - ograniczone w karcie Zakres do adresu tailnetowego klienta (albo reguła UDP-In wyłączona)
Znam ścieżkę wycofania: konsola administracyjna w przeglądarce nie zależy od pliku polityki, więc kopię ACL mogę przywrócić zdalnie; zakres reguły zapory cofam lokalnie
Zero przekierowań portów na routerze; UPnP sprawdzone
Połączenie przetestowane z innej sieci niż domowa
Świadoma decyzja w sprawie wygasania klucza dla komputera domowego
Znam ścieżkę usunięcia urządzenia: Machines > wielokropek > Remove

Źródła

Tailscale, Tailscale quickstart - zakładanie tailnetu, logowanie dostawcą tożsamości, MagicDNS, adresacja 100.x.y.z
Tailscale, Install Tailscale on Windows - wymagania systemowe klienta i przebieg instalacji
Tailscale, Access remote desktops using Windows RDP - wymagania wstępne, aplikacje klienckie, ostrzeżenie o certyfikacie
Tailscale, Manage permissions using ACLs - domyślna polityka allow all, deny-by-default, kierunkowość reguł, brak wpływu na LAN
Tailscale, Syntax reference for the tailnet policy file - pola action/src/proto/dst, adres Tailscale jako selektor, format host:port
Tailscale, ACL policy examples - gotowe przykłady polityk, w tym domyślna allow all i deny all
Tailscale, Key expiry - domyślne 180 dni, wyłączanie wygasania, tymczasowe przedłużenie, ostrzeżenie o --force-reauth
Tailscale, Remove a device - usuwanie urządzenia i skutki odinstalowania klienta
Tailscale, Device approval - zatwierdzanie nowych urządzeń
Tailscale, Enable two-factor and multifactor authentication - MFA po stronie dostawcy tożsamości
Tailscale, DERP servers - przekazywanie ruchu, gdy połączenie bezpośrednie nie dochodzi do skutku, i brak możliwości odszyfrowania go przez serwer przekaźnikowy
Microsoft, Enable Remote Desktop on your PC - obsługiwane edycje, Home tylko jako klient, otwarcie portu i osiągalność w LAN, silne hasła, NLA, domyślnie zaznaczona opcja wykrywalności w sieciach prywatnych
Microsoft, Ports that are used by Remote Desktop Services - RDP na porcie 3389 w TCP i UDP, możliwość zmiany numeru portu
Microsoft, Change the Remote Desktop listening port - zmiana portu nasłuchu i konsekwencje dla reguł zapory
Microsoft, Windows Firewall rules - pierwszeństwo reguł, domyślne blokowanie ruchu przychodzącego
Microsoft, Configure rules with group policy - konsola wf.msc, reguły przychodzące i strona Zakres ograniczająca regułę do wskazanych adresów