WireGuard, Tailscale czy Headscale: co wybrać?

WireGuard a Tailscale: krótka odpowiedź

WireGuard a Tailscale nie oznacza wyboru między dwoma protokołami, ponieważ Tailscale jest WireGuard. Tailscale korzysta z tego samego szyfrowania i tego samego tunelu, a następnie dodaje płaszczyznę sterowania: serwer koordynacji, który wymienia klucze publiczne, przydziela adresy, przebija się przez NAT (translację adresów sieciowych) i stosuje zasady dostępu. Wybór dotyczy zakresu koordynacji, który ma być utrzymywany samodzielnie.

Istnieją trzy rzetelne odpowiedzi. Należy użyć standardowego WireGuard, gdy dostępny jest jeden serwer i kilka klientów, które łączą się z nim. Należy użyć Tailscale, gdy wymagany jest dostęp każdej maszyny do każdej innej bez konieczności utrzymywania pliku konfiguracyjnego. Należy użyć Headscale, gdy wymagane jest takie połączenie kratowe, ale lista węzłów nie ma być przechowywana przez zewnętrznego dostawcę.

Co faktycznie zapewnia control plane

Czysty WireGuard nie zapewnia mechanizmu wykrywania. Każdy peer jest blokiem tekstu tworzonym ręcznie: kluczem publicznym, wierszem AllowedIPs oraz wpisem Endpoint, jeśli dany peer jest osiągalny. Dodanie jednego komputera do sieci złożonej z dziesięciu komputerów oznacza edycję dziesięciu plików konfiguracyjnych, ponieważ każda strona potrzebuje klucza drugiej strony. Dlatego niemal każda samodzielnie utrzymywana konfiguracja WireGuard ma topologię hub-and-spoke: jeden serwer z publicznym adresem IP oraz klienci, którzy komunikują się wyłącznie z tym serwerem.

Control plane eliminuje konieczność ręcznej edycji. Każdy węzeł rejestruje się raz, otrzymuje adres z zakresu 100.64.0.0/10 CGNAT (carrier grade NAT), a następnie otrzymuje klucze publiczne węzłów, z którymi może się komunikować. Tunel nadal jest bezpośrednim połączeniem WireGuard między dwoma peerami, a ruch nigdy nie przechodzi przez serwer koordynujący. Serwer przechowuje metadane: informacje o istniejących węzłach, przypisanych im kluczach oraz dozwolonych relacjach komunikacyjnych.

Wynikają z tego trzy konkretne korzyści.

Przechodzenie przez NAT. Dwa laptopy znajdujące się za dwoma domowymi routerami nie mają między sobą publicznych adresów IP. Tailscale używa STUN (session traversal utilities for NAT) do wykrycia zewnętrznego adresu i portu każdej strony. Następnie obie strony wysyłają pakiety w tym samym momencie, aby każdy router najpierw zobaczył ruch wychodzący i zaakceptował odpowiedź. Gdy to zawiedzie, ruch jest przekierowywany przez przekaźnik DERP, czyli szyfrowany przekaźnik obsługiwany przez Tailscale. Dane pozostają szyfrowane end-to-end podczas przechodzenia przez przekaźnik, ponieważ przekaźnik nie ma kluczy. Uruchomienie tailscale status powoduje, że każda linia peera zawiera direct lub relay. Uruchomienie tailscale netcheck pozwala sprawdzić, który przekaźnik znajduje się najbliżej oraz czy sieć w ogóle zezwala na UDP.

Rotacja kluczy z terminem ważności. Klucze WireGuard nigdy nie tracą ważności. Klucz wydany trzy lata temu działa bezterminowo, chyba że blok peera zostanie ręcznie usunięty. Tailscale zamiast tego wygasza klucze węzłów. Od lipca 2026 domyślny okres ważności w nowym tailnecie wynosi 180 dni. Komputer, który nie przeprowadzi ponownego uwierzytelnienia, przestaje się łączyć. Można wyłączyć wygasanie dla pojedynczego urządzenia, na przykład serwera lub routera podsieci, na którym nikt nie będzie logować się interaktywnie.

Zasady zamiast routingu. W czystym WireGuard AllowedIPs jest jednocześnie tablicą routingu i listą kontroli dostępu. Dlatego regułę „alice może uzyskać dostęp do bazy danych” trzeba wyrazić jako zakres adresów IP. Tailscale przechowuje osobny plik zasad, w którym reguły wskazują użytkowników, grupy i tagi. Reguła może określać, że tag:laptop może uzyskać dostęp do tag:db na porcie 5432 i do niczego więcej. Taka reguła pozostaje skuteczna po przydzieleniu komputerowi nowego adresu.

Koszt ponoszony za płaszczyznę sterowania

Serwer koordynacyjny zna sieć. Przechowuje klucz publiczny każdego węzła, nazwę każdego węzła, przydzielone adresy oraz zasady. W przypadku hostowanej usługi Tailscale jest to firma pozostająca poza kontrolą użytkownika. Firma ta nie może odczytać pakietów, ponieważ klucze prywatne WireGuard pozostają na komputerach użytkownika. Może jednak obserwować topologię sieci. Możliwość nawiązywania połączeń zależy również od dostępności jej usługi oraz od prawidłowego stanu konta.

Istnieje także drugi, łatwy do przeoczenia koszt. Tailscale działa jako daemon na każdym komputerze. Oznacza to konieczność instalowania poprawek na każdym komputerze. Zwykły WireGuard w Ubuntu 24.04 jest modułem jądra dostarczanym wraz z dystrybucją i aktualizowanym razem z jądrem.

Trzecim kosztem jest rozliczanie. W lipcu 2026 plan Personal jest bezpłatny i obejmuje nieograniczoną liczbę urządzeń dla maksymalnie 6 użytkowników. Plan Standard kosztuje $8 za użytkownika miesięcznie, a plan Premium $18 za użytkownika miesięcznie. Konto gospodarstwa domowego pozostaje bezpłatne. Zespół składający się z 10 osób już nie.

Kiedy zwykły WireGuard jest właściwym rozwiązaniem

Zwykły WireGuard należy wybrać, gdy topologia rzeczywiście ma układ hub-and-spoke. Jeden VPS z publicznym adresem IP, trzy lub cztery urządzenia, które łączą się z tym VPS-em, oraz brak wymagania, aby urządzenia komunikowały się między sobą. Konfiguracja mieści się na jednym ekranie. Nie ma demona do aktualizowania, konta, do którego można utracić dostęp, ani zewnętrznej usługi między użytkownikiem a serwerem.

Jest to również właściwe rozwiązanie, gdy wymagane jest zrozumienie warstwy, na której opiera się cała reszta. Samodzielne hostowanie VPN WireGuard na VPS opisuje generowanie kluczy, wg0.conf, przekazywanie IP, NAT oraz błędy uzgadniania. Każdy z tych mechanizmów nadal działa pod tailnetem. Jeśli nadal rozważana jest starsza opcja, WireGuard a OpenVPN opisuje cztery przypadki, w których OpenVPN zachowuje przewagę.

Instalacja jest krótka:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

Zwykły WireGuard przestaje być wygodny, gdy każde urządzenie musi mieć dostęp do każdego innego urządzenia. Pełna siatka N węzłów wymaga N razy N minus jeden bloków peer. Przy sześciu urządzeniach daje to trzydzieści bloków utrzymywanych ręcznie w synchronizacji. Zduplikowany wpis AllowedIPs po cichu przejmuje ruch od peera, który miał go wcześniej. W żadnym miejscu nie jest wyświetlany błąd.

Kiedy Tailscale jest właściwym rozwiązaniem

Tailscale należy wybrać, gdy urządzenia zmieniają sieci. Dotyczy to laptopów w sieciach hotelowych, telefonu korzystającego z transmisji danych oraz serwera domowego znajdującego się za routerem, nad którym nie ma kontroli. Są to dokładnie te przypadki, z którymi zwykły WireGuard radzi sobie słabo, ponieważ żadna ze stron nie ma stabilnego publicznego punktu końcowego, który można wpisać w Endpoint.

Instalację klienta wykonuje się za pomocą jednej komendy z oficjalnego instalatora:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up wyświetla adres URL. Należy go otworzyć, zalogować się, a następnie dołączyć maszynę. Nie trzeba kopiować klucza ani otwierać portu przychodzącego, ponieważ demon nawiązuje połączenie wychodzące z serwerem koordynującym i utrzymuje je. Dlatego węzeł Tailscale działa również w sieci, w której nie ma kontroli nad żadną zaporą sieciową.

Po wykonaniu tych czynności większość zadań realizują dwa ustawienia. Router podsieci rozgłasza całą sieć LAN w sieci Tailscale, dzięki czemu nie trzeba instalować klienta na każdym urządzeniu:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

Trasa pozostaje nieaktywna do czasu zatwierdzenia jej w konsoli administracyjnej. Jest to działanie zamierzone: węzeł nie może samodzielnie wprowadzić trasy do sieci. Klienci Linux wymagają również ustawienia sudo tailscale set --accept-routes, ponieważ system Linux domyślnie nie akceptuje rozgłaszanych tras. Dlatego trasa, która po stronie serwera wygląda na zatwierdzoną, nadal nie działa na laptopie z systemem Linux do czasu ustawienia tej opcji.

Węzeł wyjściowy przesyła cały ruch klienta przez jedną maszynę. Jest to działanie pełnego tunelu, które zwykle oznacza się określeniem „VPN”:

sudo tailscale set --advertise-exit-node

Kiedy Headscale jest właściwym rozwiązaniem

Headscale to implementacja serwera koordynacyjnego typu open source, uruchamiana na należącym do użytkownika VPS. Oficjalne klienty Tailscale łączą się z nim zamiast z usługą hostowaną:

sudo tailscale up --login-server https://headscale.example.com

Ścieżka transmisji danych pozostaje bez zmian. Nadal jest używany WireGuard, a połączenia między peerami nadal są bezpośrednie, jeśli pozwala na to sieć. Zmienia się tylko miejsce przechowywania listy węzłów, kluczy i zasad: znajdują się one w pliku SQLite na należącym do użytkownika dysku. Podmioty zewnętrzne nie mogą zobaczyć topologii sieci, wyłączyć konta ani naliczać opłat za użytkowników.

Wymaga to jednak dodatkowej pracy. Uruchamiana jest publiczna usługa HTTPS, co oznacza konieczność skonfigurowania nazwy DNS, certyfikatu i reverse proxy, które prawidłowo przekazuje uaktualnienia WebSocket. Użytkownik odpowiada za jej dostępność. Niedostępność serwera koordynacyjnego uniemożliwia rejestrowanie nowych węzłów i przekazywanie istniejącym węzłom informacji o zmianach. Headscale jest również dostępny w wersji niższej niż 1.0, a wydania minor zawierały zmiany niezgodne wstecznie. Przed każdą aktualizacją należy przeczytać changelog. Uruchamianie Headscale jako własnego serwera sterującego Tailscale obejmuje instalację, config.yaml, klucze preauth i porty, które należy otworzyć.

Istnieje jeszcze jedno ograniczenie, które często ujawnia się dopiero później. Headscale nie zawiera globalnej sieci relay Tailscale. Jeśli dwa peery nie mogą połączyć się bezpośrednio, należy włączyć wbudowany relay na własnym serwerze albo wskazać w konfiguracji inny serwer. Taki relay jest pojedynczym serwerem w jednym regionie, a nie globalną flotą serwerów. Peery znajdujące się po drugiej stronie globu odczują tę różnicę.

Jak podjąć decyzję za jednym razem

Należy ustalić, ile maszyn musi komunikować się ze sobą. Jeśli wszystkie komunikują się wyłącznie z serwerem, zwykły WireGuard wymaga mniejszej liczby komponentów przy takim samym rezultacie.

Należy sprawdzić, czy maszyny mają stałe adresy publiczne. Jeśli większość z nich znajduje się za kontrolowanym przez inne osoby NAT, potrzebna jest płaszczyzna sterowania, ponieważ przebijanie przez NAT jest najtrudniejszą częścią i nie warto implementować go ponownie.

Należy ustalić, kto może znać topologię sieci. Jeśli nie mogą to być firmy zewnętrzne albo liczba użytkowników sprawia, że rozliczanie za każde stanowisko jest zbyt kosztowne, należy uruchomić Headscale i zaakceptować konieczność samodzielnego utrzymywania serwera sterowania.

Decyzję można później łatwo zmienić. Ponieważ płaszczyzna danych wykorzystuje ten sam protokół we wszystkich trzech rozwiązaniach, przejście ze zwykłego WireGuard na koordynowaną sieć mesh wymaga zainstalowania klienta, a nie przeprojektowania rozwiązania. Przejście z Tailscale na Headscale polega na ponownej rejestracji każdego węzła w innym serwerze logowania.

Czego nie zapewnia żadne z tych trzech rozwiązań

Żadne z tych rozwiązań nie jest zaporą sieciową. Tunel określa, które pakiety są przesyłane, a nie które usługi nasłuchują. Serwer dostępny przez tunel nadal jest dostępny z Internetu na każdym pozostawionym otwartym porcie, dlatego należy nadal stosować reguły zapory UFW na VPS.

Plik zasad Tailscale ogranicza dostęp innych węzłów. Nie wpływa na interfejs publiczny.

Żadne z tych rozwiązań nie zapewnia uwierzytelniania dla poszczególnych usług ani rejestrowania działań użytkownika po nawiązaniu połączenia. Wszystkie trzy rozwiązania należy traktować jako mechanizmy transportowe, a kontrole logowania umieścić w aplikacji.

FAQ

Czy Tailscale to po prostu WireGuard z dodatkowymi krokami?

Tailscale używa protokołu WireGuard dla ścieżki danych, dlatego szyfrowanie i tunel działają tak samo. Dodaje jednak warstwę koordynacji: wymianę kluczy, przypisywanie adresów, przechodzenie przez NAT z użyciem STUN i przekaźników DERP, wygasanie kluczy oraz plik zasad, w którym określa się użytkowników zamiast zakresów adresów IP. W przypadku zwykłego WireGuard te zadania pozostają po stronie administratora. Stają się trudne, gdy urządzenia przemieszczają się między sieciami.

Czy mój ruch przechodzi przez serwery Tailscale?

Zwykle nie. Po wprowadzeniu peerów przez serwer koordynacji łączą się one bezpośrednio, a tailscale status pokazuje direct w wierszach tych peerów. Gdy nie można ustanowić ścieżki bezpośredniej, ruch jest kierowany przez przekaźnik DERP, a wiersz zawiera relay. Przekaźnik nadal przekazuje zaszyfrowane pakiety i nie przechowuje prywatnych kluczy WireGuard, dlatego nie może odczytać ich zawartości. Uruchom tailscale netcheck, aby sprawdzić, czy sieć blokuje protokół UDP wymagany przez połączenia bezpośrednie.

Czy można używać Headscale z oficjalnymi aplikacjami Tailscale?

Tak. Headscale obsługuje ten sam protokół sterowania, dlatego oficjalni klienci łączą się za pomocą sudo tailscale up --login-server https://headscale.example.com. W aplikacjach na komputery i urządzenia mobilne można również wskazać niestandardowy serwer logowania. Ustawienie znajduje się jednak w innym miejscu na każdej platformie, a aplikacje mobilne najczęściej wymagają określonej wersji. Przed migracją całej sieci należy przetestować jedno urządzenie mobilne.

Czy nadal trzeba otwierać porty dla Tailscale lub Headscale?

Klient Tailscale nie wymaga portu przychodzącego, ponieważ nawiązuje połączenie wychodzące z serwerem koordynacji i utrzymuje je otwarte. Samodzielnie hostowany serwer Headscale wymaga jednak portów przychodzących: 443 dla protokołu sterowania, 80 w przypadku użycia wyzwania certyfikacyjnego HTTP-01 oraz 3478/udp tylko po włączeniu wbudowanego przekaźnika. Zwykły WireGuard wymaga otwarcia portu nasłuchu UDP, zazwyczaj 51820, na serwerze oraz w każdej oddzielnej zaporze sieciowej zarządzanej przez dostawcę.

Które z tych trzech rozwiązań jest najszybsze?

Przepustowość jest taka sama, ponieważ wszystkie trzy rozwiązania przesyłają pakiety za pomocą WireGuard. Różnice dotyczą ustanawiania połączenia i jakości ścieżki. Zwykły WireGuard z poprawnie skonfigurowanym Endpoint łączy się bezpośrednio za każdym razem. Tailscale i Headscale łączą się bezpośrednio przez większość czasu i korzystają z przekaźnika, gdy sieć blokuje przebijanie NAT. Ścieżka przez przekaźnik zwiększa opóźnienie. Własną ścieżkę można zmierzyć za pomocą tailscale ping <node>, które wskazuje, czy trasa jest bezpośrednia, czy przebiega przez przekaźnik, albo za pomocą iperf3 przez tunel.