WireGuard vs Tailscale vs Headscale: co wybrać?

WireGuard a Tailscale: krótka odpowiedź

Wybór między WireGuard a Tailscale nie jest wyborem między dwoma protokołami, ponieważ Tailscale to WireGuard. Tailscale wykorzystuje to samo szyfrowanie i ten sam tunel, dodając do nich płaszczyznę sterowania: serwer koordynujący, który wymienia klucze publiczne, przydziela adresy, wykonuje NAT traversal (przebijanie się przez NAT) oraz egzekwuje polityki dostępu. Wybór dotyczy zakresu samodzielnej obsługi tej koordynacji.

Istnieją trzy rzetelne odpowiedzi. Należy użyć standardowego WireGuard, gdy dostępny jest jeden serwer i kilka klientów łączących się z nim. Należy wybrać Tailscale, gdy wymagane jest, aby każde urządzenie komunikowało się z każdym innym bez konieczności utrzymywania plików konfiguracyjnych. Należy wybrać Headscale, gdy wymagana jest taka topologia mesh, ale niepożądane jest powierzanie listy węzłów podmiotowi zewnętrznemu.

Co faktycznie zyskujesz dzięki płaszczyźnie sterowania (control plane)

Standardowy WireGuard nie posiada mechanizmu wykrywania węzłów. Każdy peer to blok tekstu wpisywany ręcznie: klucz publiczny, linia AllowedIPs oraz Endpoint, jeśli dany peer jest osiągalny. Dodanie jednej maszyny do sieci dziesięciu urządzeń oznacza edycję dziesięciu plików konfiguracyjnych, ponieważ każda ze stron musi znać klucz drugiej. Dlatego niemal każda samodzielnie utrzymywana konfiguracja WireGuard działa w modelu hub-and-spoke: jeden serwer z publicznym adresem IP oraz klienci, którzy komunikują się wyłącznie z nim.

Płaszczyzna sterowania eliminuje konieczność ręcznej edycji. Każdy węzeł rejestruje się jednorazowo, otrzymuje adres z zakresu 100.64.0.0/10 CGNAT (carrier grade NAT) i otrzymuje informacje o kluczach publicznych węzłów, z którymi może się łączyć. Tunel nadal stanowi bezpośrednie połączenie WireGuard między dwoma peerami, a ruch sieciowy nigdy nie przechodzi przez serwer koordynujący. Serwer przetwarza jedynie metadane: kto istnieje, jaki posiada klucz oraz kto ma uprawnienia do komunikacji z kim.

Wynikają z tego trzy konkretne korzyści.

Przechodzenie przez NAT (NAT traversal). Dwa laptopy za dwoma domowymi routerami nie posiadają publicznego adresu IP. Tailscale wykorzystuje STUN (session traversal utilities for NAT) do wykrycia zewnętrznego adresu i portu każdej ze stron, a następnie obie strony wysyłają pakiety w tym samym momencie, aby routery najpierw zarejestrowały przepływ wychodzący i zaakceptowały odpowiedź. Gdy to zawiedzie, ruch jest przekazywany przez przekaźnik DERP, czyli szyfrowany przekaźnik obsługiwany przez Tailscale. Dane pozostają szyfrowane end-to-end podczas przesyłu przez przekaźnik, ponieważ nie posiada on kluczy. Uruchom tailscale status, a każda linia peera wskaże direct lub relay. Uruchom tailscale netcheck, aby sprawdzić, który przekaźnik jest najbliżej i czy sieć zezwala na ruch UDP.

Rotacja kluczy z wygasaniem. Klucze WireGuard nigdy nie wygasają. Klucz wygenerowany trzy lata temu działa bezterminowo, dopóki ręcznie nie usuniesz bloku peera. Tailscale zamiast tego wygasza klucze węzłów, a od lipca 2026 domyślny okres ważności w nowej sieci tailnet wynosi 180 dni. Maszyna, która nie przeszła ponownej autentykacji, przestaje się łączyć. Możesz wyłączyć wygasanie dla poszczególnych urządzeń, takich jak serwer lub router podsieci, do których nikt nie będzie miał fizycznego dostępu w celu zalogowania.

Polityka zamiast routingu. W standardowym WireGuard AllowedIPs pełni jednocześnie rolę tablicy routingu i listy kontroli dostępu, więc reguła „alice może uzyskać dostęp do bazy danych” musi być wyrażona jako zakres adresów IP. Tailscale utrzymuje oddzielny plik polityki, w którym reguły operują na nazwach użytkowników, grupach i tagach. Reguła może określać, że tag:laptop może uzyskać dostęp do tag:db na porcie 5432 i niczego więcej; taka reguła pozostaje ważna nawet po otrzymaniu przez maszynę nowego adresu.

Koszt płaszczyzny sterowania

Serwer koordynujący posiada wiedzę o Twojej sieci. Przechowuje klucze publiczne każdego węzła, nazwy wszystkich węzłów, przydzielone adresy oraz polityki. W przypadku korzystania z hostowanej usługi Tailscale, jest to firma pozostająca poza Twoją kontrolą. Twoje pakiety są dla nich nieczytelne, ponieważ prywatne klucze WireGuard pozostają na Twoich maszynach, jednak struktura sieci jest dla nich widoczna, a możliwość nawiązywania połączeń zależy od dostępności ich usługi oraz statusu Twojego konta. Waga tego faktu zależy od tego, co skompromitowany serwer koordynujący lub przejęte konto mogłyby zrobić z posiadanymi informacjami, co stanowi punkt, w którym warto w całości zapoznać się z modelem zaufania Tailscale.

Istnieje drugi koszt, który łatwo przeoczyć. Tailscale to demon działający na każdej maszynie, więc jest to oprogramowanie, które musisz teraz aktualizować na każdym urządzeniu. Standardowy WireGuard w systemie Ubuntu 24.04 to moduł jądra, który jest dostarczany wraz z dystrybucją i aktualizuje się wraz z jądrem.

Trzecim kosztem są rozliczenia. Według stanu na lipiec 2026 plan Personal jest darmowy i oferuje nielimitowaną liczbę urządzeń dla maksymalnie 6 użytkowników, plan Standard kosztuje 8 USD za użytkownika miesięcznie, a plan Premium 18 USD za użytkownika miesięcznie. Gospodarstwo domowe pozostaje darmowe. Zespół dziesięcioosobowy już nie. To, czy przekroczysz tę granicę, zależy od liczby stanowisk, a nie urządzeń, dlatego przed zaproszeniem siódmego użytkownika warto przeczytać, co faktycznie obejmuje darmowy plan.

Kiedy czysty WireGuard jest właściwym rozwiązaniem

Wybierz czysty WireGuard, gdy topologia sieci to typowy model hub-and-spoke. Jeden serwer VPS z publicznym adresem IP, trzy lub cztery urządzenia łączące się z nim i brak wymagań, aby urządzenia te komunikowały się między sobą. Konfiguracja mieści się na jednym ekranie, nie ma demona do aktualizacji, konta do utraty ani zewnętrznej usługi pośredniczącej między użytkownikiem a serwerem.

Jest to również właściwy wybór, gdy chcesz zrozumieć warstwę, na której zbudowano wszystkie inne rozwiązania. Samodzielne hostowanie VPN WireGuard na VPS omawia generowanie kluczy, wg0.conf, przekazywanie IP, NAT oraz błędy uzgadniania połączenia (handshake). Wszystkie te mechanizmy działają również pod spodem sieci typu tailnet. Jeśli nadal rozważasz starszą opcję, WireGuard vs 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

Czysty WireGuard przestaje być wygodny w momencie, gdy każde urządzenie musi mieć możliwość połączenia z każdym innym. Pełna siatka (full mesh) złożona z N węzłów wymaga N razy N minus jeden bloków peer. Przy sześciu urządzeniach oznacza to trzydzieści bloków utrzymywanych ręcznie w synchronizacji, a zduplikowany wpis AllowedIPs powoduje ciche przejęcie ruchu od pierwszego peer'a, bez wyświetlenia jakiegokolwiek błędu.

Kiedy Tailscale jest właściwym rozwiązaniem

Wybierz Tailscale, gdy maszyny zmieniają lokalizację. Laptopy w sieciach hotelowych, telefon korzystający z danych mobilnych, serwer domowy za routerem, nad którym nie masz kontroli. To przypadki, w których standardowy WireGuard sprawdza się słabo, ponieważ żadna ze stron nie posiada stabilnego publicznego punktu końcowego, który można wpisać w Endpoint.

Instalacja klienta sprowadza się do jednego polecenia z oficjalnego instalatora:

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

tailscale up wyświetla adres URL. Otwórz go, zaloguj się, a maszyna zostanie dodana do sieci. Nie ma kluczy do kopiowania ani portów przychodzących do otwarcia, ponieważ demon nawiązuje połączenie wychodzące z serwerem koordynującym i utrzymuje je w stanie otwartym. Dlatego węzeł Tailscale działa w sieci, w której nie masz żadnej kontroli nad firewallem.

Dwa ustawienia wykonują większość użytecznej pracy po zakończeniu instalacji. Router podsieci (subnet router) ogłasza całą sieć LAN wewnątrz 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 momentu zatwierdzenia jej w konsoli administracyjnej, co jest celowym działaniem: węzeł nie może samodzielnie wstrzyknąć trasy do Twojej sieci. Klienci z systemem Linux wymagają również sudo tailscale set --accept-routes, ponieważ Linux domyślnie nie akceptuje ogłaszanych tras. Zatem trasa, która wygląda na zatwierdzoną po stronie serwera, nadal nie działa na laptopie z systemem Linux, dopóki nie zostanie to skonfigurowane. Jeśli jest to rozwiązanie, którego potrzebujesz, uruchomienie routera podsieci na VPS przeprowadzi Cię przez proces zatwierdzania oraz ustawienia przekazywania w kolejności, która pozwala uniknąć częściowo działającej trasy.

Węzeł wyjściowy (exit node) kieruje cały ruch klienta przez jedną maszynę, co odpowiada pełnemu tunelowaniu, które zazwyczaj rozumie się przez termin "VPN":

sudo tailscale set --advertise-exit-node

Ta flaga to najprostsza część, a przekształcenie VPS w węzeł wyjściowy opisuje dalsze kroki: zatwierdzenie trasy w konsoli administracyjnej oraz naprawienie zachowania DNS i IPv6, które w przeciwnym razie powodowałoby kierowanie ruchu niewłaściwą drogą. Jeśli celem jest dostęp do jednej usługi internetowej, a nie do całej sieci, serve i funnel pozwalają umieścić HTTPS przed pojedynczym portem lokalnym, ograniczając dostęp tylko do sieci tailnet lub udostępniając go publicznie w Internecie.

Kiedy Headscale jest właściwym rozwiązaniem

Headscale to otwartoźródłowa implementacja serwera koordynacyjnego, którą uruchamia się na własnym VPS. Oficjalne klienty Tailscale łączą się z nim zamiast z usługą hostowaną:

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

Ścieżka danych pozostaje niezmieniona. Nadal jest to WireGuard, nadal działający bezpośrednio między węzłami, o ile pozwala na to sieć. Zmienia się to, że lista węzłów, klucze oraz polityki znajdują się w pliku SQLite na posiadanym dysku. Nikt z zewnątrz nie ma wglądu w strukturę sieci, nie może dezaktywować konta ani naliczać opłat za użytkownika.

Ceną jest konieczność wykonania pracy. Uruchamiasz publiczną usługę HTTPS, co wymaga nazwy DNS, certyfikatu oraz reverse proxy, które poprawnie przekazuje aktualizacje WebSocket. Odpowiadasz za czas dostępności (uptime), a niedziałający serwer koordynacyjny oznacza, że nowe węzły nie mogą się zarejestrować, a istniejące nie otrzymają informacji o zmianach. Headscale znajduje się poniżej wersji 1.0, a wydania mniejsze zawierały zmiany powodujące niekompatybilność, dlatego przed każdą aktualizacją należy zapoznać się z changelog. Uruchamianie Headscale jako własnego serwera kontrolnego Tailscale opisuje instalację, config.yaml, klucze preauth oraz porty, które należy otworzyć.

Jedno zastrzeżenie często pojawia się z opóźnieniem. Headscale nie posiada globalnej sieci przekaźników (relay) Tailscale. W sytuacjach, gdy dwa węzły nie mogą połączyć się bezpośrednio, należy włączyć wbudowany przekaźnik na własnym serwerze lub wskazać w konfiguracji inny, a taki przekaźnik jest pojedynczą maszyną w jednym regionie, a nie światową infrastrukturą. Węzły znajdujące się po drugiej stronie globu odczują tę różnicę. Jeśli wolisz nie konfigurować tego elementu samodzielnie, samodzielne hostowanie NetBird jest alternatywnym sposobem na utrzymanie płaszczyzny sterowania (control plane) we własnym zakresie, ponieważ jego quickstart uruchamia usługi zarządzania, sygnalizacji i przekaźnika jednocześnie na jednym VPS.

Jak podjąć decyzję w jednym kroku

Należy ustalić, ile maszyn musi się ze sobą komunikować. Jeśli wszystkie urządzenia łączą się wyłącznie z serwerem, standardowy WireGuard stanowi prostsze rozwiązanie, zapewniające ten sam rezultat.

Należy sprawdzić, czy maszyny posiadają stałe publiczne adresy IP. Jeśli większość z nich znajduje się za NAT-em, nad którym nie sprawuje się kontroli, niezbędny jest płaszczyzna sterowania (control plane). Mechanizm hole punching jest złożony i nie warto wdrażać go samodzielnie.

Należy określić, kto ma dostęp do informacji o topologii sieci. Jeśli polityka bezpieczeństwa wyklucza podmioty zewnętrzne lub koszty licencji na użytkownika są zbyt wysokie, należy uruchomić Headscale, akceptując konieczność samodzielnego utrzymywania serwera sterującego. Jeśli kluczowym czynnikiem są koszty, przed migracją należy wykonać obliczenia, ponieważ rzeczywiste koszty dla zespołu danej wielkości zależą od liczby kont użytkowników, a nie od liczby obsługiwanych maszyn, a wartości te rzadko są zbliżone.

Zmiana decyzji nie wiąże się z wysokimi kosztami. Ponieważ płaszczyzna danych (data plane) wykorzystuje ten sam protokół we wszystkich trzech przypadkach, przejście ze standardowego WireGuard na sieć typu mesh wymaga jedynie instalacji oprogramowania klienckiego, a nie przebudowy architektury. Przejście z Tailscale na Headscale ogranicza się do ponownej rejestracji każdego węzła w nowym serwerze logowania.

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

Żadne z nich nie jest firewallem. Tunel decyduje jedynie o tym, które pakiety są przesyłane, a nie o tym, które usługi nasłuchują na portach. Serwer dostępny przez tunel pozostaje widoczny z Internetu na każdym otwartym porcie, dlatego należy zadbać, aby reguły firewalla UFW na VPS nadal spełniały swoją funkcję. Plik polityki Tailscale ogranicza dostęp dla innych węzłów, ale nie wpływa na interfejs publiczny.

Żadne z tych rozwiązań nie zapewnia uwierzytelniania dla poszczególnych usług ani ścieżki audytu działań użytkownika po nawiązaniu połączenia. Wszystkie trzy należy traktować wyłącznie jako warstwę transportową, a mechanizmy logowania implementować bezpośrednio w aplikacjach.

FAQ

Czy Tailscale to tylko WireGuard z dodatkowymi krokami?

Tailscale wykorzystuje protokół WireGuard do przesyłania danych, więc szyfrowanie i tunel są identyczne. Dodatkową wartością jest koordynacja: wymiana kluczy, przydzielanie adresów, przechodzenie przez NAT za pomocą STUN i przekaźników DERP, wygaszanie kluczy oraz plik polityk, który operuje na nazwach użytkowników, a nie na zakresach adresów IP. Są to elementy, którymi w czystym WireGuard trzeba zarządzać samodzielnie, co staje się trudne, gdy urządzenia zmieniają sieci.

Czy mój ruch przechodzi przez serwery Tailscale?

Zazwyczaj nie. Węzły łączą się bezpośrednio po tym, jak serwer koordynujący je ze sobą skontaktuje, a tailscale status pokazuje direct w wierszach dotyczących tych połączeń. Gdy nawiązanie bezpośredniej ścieżki jest niemożliwe, ruch jest przekierowywany przez przekaźnik DERP, a wiersz przyjmuje postać relay. Nawet wtedy przekaźnik przenosi zaszyfrowane pakiety i nie posiada prywatnych kluczy WireGuard, więc nie może odczytać zawartości przesyłanych danych. Uruchom tailscale netcheck, aby sprawdzić, czy sieć blokuje ruch UDP wymagany do połączeń bezpośrednich.

Czy mogę używać Headscale z oficjalnymi aplikacjami Tailscale?

Tak. Headscale obsługuje ten sam protokół kontrolny, więc oficjalni klienci łączą się za pomocą sudo tailscale up --login-server https://headscale.example.com. Aplikacje desktopowe i mobilne można również skierować na własny serwer logowania, choć ustawienie to znajduje się w innym miejscu na każdej platformie, a aplikacje mobilne najczęściej wymagają konkretnej wersji. Przetestuj jedno urządzenie mobilne przed migracją całej sieci.

Czy nadal muszę otwierać porty dla Tailscale lub Headscale?

Klient Tailscale nie wymaga otwierania portów przychodzących, ponieważ inicjuje połączenie wychodzące do serwera koordynującego i utrzymuje je otwarte. Własny serwer Headscale wymaga otwartych portów przychodzących: 443 dla protokołu kontrolnego, 80 w przypadku korzystania z wyzwania certyfikatu HTTP-01 oraz 3478/udp tylko po włączeniu wbudowanego przekaźnika. Czysty WireGuard wymaga otwarcia portu nasłuchiwania UDP, zazwyczaj 51820, na serwerze oraz na każdej zewnętrznej zaporze sieciowej dostawcy.

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

Przepustowość jest taka sama, ponieważ wszystkie trzy przesyłają pakiety za pomocą WireGuard. Różnica uwidacznia się w czasie nawiązywania połączenia i jakości ścieżki. Czysty WireGuard z poprawnym Endpoint łączy się bezpośrednio za każdym razem. Tailscale i Headscale łączą się bezpośrednio w większości przypadków, a w razie blokowania przez sieć mechanizmu hole punching, przełączają się na przekaźnik, co zwiększa opóźnienia. Zmierz własną ścieżkę za pomocą tailscale ping <node>, które informuje, czy trasa jest bezpośrednia czy przekaźnikowa, lub za pomocą iperf3 wewnątrz tunelu. Jeśli wynik jest znacznie niższy niż przepustowość łącza przy bezpośrednim połączeniu, przyczyną nie jest wybór między tymi trzema rozwiązaniami, a typowa niezgodność MTU ścieżki, która objawia się tak samo z płaszczyzną kontrolną, jak i bez niej.