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 daje płaszczyzna sterowania

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 złożonej z dziesięciu wymaga edycji dziesięciu plików konfiguracyjnych, ponieważ każda ze stron musi znać klucz drugiej. Dlatego niemal każda samodzielnie hostowana 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 jest jego klucz oraz kto ma uprawnienia do komunikacji z kim.

Wynikają z tego trzy konkretne korzyści.

Przechodzenie przez NAT. 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 zarejestrowały przepływ wychodzący i zaakceptowały odpowiedź. Gdy to zawiedzie, ruch jest przekierowywany przez przekaźnik DERP, czyli szyfrowany przekaźnik obsługiwany przez Tailscale. Dane pozostają zaszyfrowane metodą end-to-end podczas przesyłu przez przekaźnik, ponieważ nie posiada on kluczy deszyfrujących. Po uruchomieniu tailscale status każda linia peera wskazuje direct lub relay. Uruchomienie tailscale netcheck pozwala sprawdzić, który przekaźnik jest najbliżej i czy sieć zezwala na ruch UDP.

Rotacja kluczy z wygasaniem. Klucze WireGuard nie wygasają. Klucz wygenerowany trzy lata temu działa bezterminowo, chyba że blok peera zostanie usunięty ręcznie. Tailscale wygasza klucze węzłów, a od października 2026 domyślny okres ważności w nowej sieci tailnet wynosi 180 dni. Maszyna, która nie przeszła ponownej autentykacji, traci łączność. Wygasanie można wyłączyć dla poszczególnych urządzeń, takich jak serwery lub routery podsieci, do których nikt nie ma fizycznego dostępu w celu zalogowania.

Polityka zamiast routingu. W standardowym WireGuard AllowedIPs pełni jednocześnie funkcję tablicy routingu i listy kontroli dostępu, więc regułę „alice może uzyskać dostęp do bazy danych” trzeba wyrazić za pomocą zakresu 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; reguła ta pozostaje aktualna nawet po zmianie adresu IP maszyny.

Koszty związane z płaszczyzną sterowania

Serwer koordynujący posiada wiedzę o sieci. Przechowuje klucze publiczne każdego węzła, nazwy węzłów, przydzielone adresy oraz polityki. W przypadku hostowanej usługi Tailscale jest to podmiot zewnętrzny, nad którym użytkownik nie ma kontroli. Pakiety nie są dla nich czytelne, ponieważ klucze prywatne WireGuard pozostają na 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 konta. Ocena wagi tego faktu zależy od tego, co skompromitowany serwer koordynujący lub przejęte konto mogłyby zrobić z posiadanymi danymi, co wyjaśnia pełny opis modelu 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 należy aktualizować na każdym urządzeniu. Standardowy WireGuard w systemie Ubuntu 24.04 jest modułem jądra, który jest dostarczany wraz z dystrybucją i aktualizuje się wraz z jądrem.

Trzecim kosztem są opłaty. Według stanu na październik 2026 plan Personal jest darmowy i oferuje nielimitowaną liczbę urządzeń użytkownika dla maksymalnie 6 osób, plan Standard kosztuje 8 USD za użytkownika miesięcznie, a plan Premium 18 USD za użytkownika miesięcznie. Gospodarstwa domowe pozostają w darmowym planie. Zespół dziesięcioosobowy już nie. Przekroczenie tego progu zależy głównie od liczby stanowisk, a nie urządzeń, z jednym wyjątkiem: serwery i inne otagowane urządzenia mają własny limit. Każdy plan obejmuje 50 otagowanych zasobów, a według strony z cennikiem z października 2026, każdy kolejny kosztuje 1 USD miesięcznie. Warto zapoznać się z informacją o tym, co faktycznie obejmuje darmowy plan, przed zaproszeniem siódmego użytkownika lub otagowaniem pięćdziesiątego pierwszego serwera.

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

Wybierz czysty WireGuard, gdy topologia to typowy model hub-and-spoke. Jeden VPS z publicznym adresem IP, trzy lub cztery urządzenia łączące się z nim i brak wymogu, 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 wszystko inne. Samodzielne hostowanie VPN WireGuard na VPS przeprowadza przez proces generowania kluczy, wg0.conf, przekazywania IP (IP forwarding), NAT oraz błędów uzgadniania (handshake). Klucze i proces uzgadniania nadal działają pod każdą siecią typu tailnet, a przekazywanie IP staje się niezbędne w momencie, gdy węzeł tailnet pełni rolę routera podsieci lub węzła wyjściowego (exit node). Jeśli nadal rozważasz starszą opcję, WireGuard vs OpenVPN omawia 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 jest to trzydzieści bloków utrzymywanych ręcznie w synchronizacji, a zduplikowany wpis AllowedIPs po cichu przejmuje ruch od peera, który miał go jako pierwszy, nie generując przy tym żadnego błędu.

Kiedy Tailscale jest właściwym rozwiązaniem

Wybierz Tailscale, gdy urządzenia 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 urządzenie dołączy do sieci. Nie ma kluczy do kopiowania ani portów przychodzących do otwarcia, ponieważ demon nawiązuje połączenie wychodzące do serwera koordynującego 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 instalacji. Router podsieci (subnet router) ogłasza całą sieć LAN wewnątrz sieci VPN, 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 działaniem celowym: 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. Trasa zatwierdzona po stronie serwera nie zadziała na laptopie z systemem Linux, dopóki to ustawienie nie zostanie skonfigurowane. Jeśli taki jest cel, uruchomienie routera podsieci na VPS przeprowadzi przez proces zatwierdzania oraz ustawienia przekierowania w kolejności, która pozwala uniknąć częściowo działającej trasy.

Węzeł wyjściowy (exit node) przesyła zwykły ruch internetowy klienta – czyli wszystko, co nie jest kierowane do innego urządzenia w sieci tailnet lub do zatwierdzonej trasy podsieci – przez jedną maszynę. Jest to zachowanie pełnego tunelu, które zazwyczaj rozumie się przez termin "VPN". W systemie Linux wymaga to tych samych ustawień przekierowania IP, co powyżej, przed ogłoszeniem węzła:

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 naprawę 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 lokalnym portem, ograniczając dostęp tylko do sieci tailnet lub udostępniając usługę 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ć.

Jedna kwestia często wychodzi na jaw dopiero później. Headscale nie korzysta z globalnej sieci przekaźników Tailscale. Gdy dwóch równorzędnych uczestników nie może połączyć się bezpośrednio, należy włączyć wbudowany przekaźnik na własnym serwerze albo wskazać w konfiguracji inny przekaźnik. Taki przekaźnik jest pojedynczym serwerem w jednym regionie, a nie ogólnoświatową flotą. Uczestnicy znajdujący się po drugiej stronie globu odczują tę różnicę. Jeśli nie chcesz tworzyć tego elementu samodzielnie, samodzielne hostowanie NetBird jest alternatywnym sposobem na utrzymanie płaszczyzny sterowania we własnej infrastrukturze, ponieważ quickstart uruchamia razem usługi zarządzania, sygnalizacji i przekaźnika na jednym VPS. NetBird nie jest jednak serwerem Tailscale typu drop-in, tak jak Headscale. Udostępnia własne klienty i własny model zasad. Przed wyborem NetBird zamiast Headscale zapoznaj się z informacjami czym NetBird i Tailscale różnią się w zakresie reguł dostępu i przekaźników.

Jak podjąć decyzję w jednym kroku

Należy ustalić, ile maszyn musi się ze sobą komunikować. Jeśli wszystkie łączą się wyłącznie z serwerem, standardowy WireGuard zapewnia ten sam rezultat przy mniejszej liczbie oprogramowania.

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, warto rozważyć płaszczyznę sterowania (control plane), ponieważ przebijanie się przez NAT (hole punching) jest złożonym procesem, którego nie warto wdrażać samodzielnie.

Należy określić, kto ma mieć wgląd w strukturę sieci. Jeśli dostęp podmiotów zewnętrznych jest wykluczony lub liczba użytkowników sprawia, że model rozliczeń za stanowisko staje się nieopłacalny, należy uruchomić Headscale i zaakceptować konieczność samodzielnego utrzymywania serwera sterującego. Jeśli głównym czynnikiem jest koszt, należy wykonać obliczenia przed migracją, ponieważ ile faktycznie płaci zespół danej wielkości zależy głównie od liczby kont użytkowników, a nie od liczby obsługiwanych maszyn, dopóki liczba otagowanych serwerów nie przekroczy 50 sztuk zawartych w każdym planie, a te dwie wartości rzadko są zbliżone.

Decyzję można zmienić niskim kosztem. Ponieważ płaszczyzna danych (data plane) opiera się na tym samym protokole we wszystkich trzech przypadkach, przejście ze standardowego WireGuard na skoordynowaną sieć mesh wymaga jedynie instalacji klienta, a nie przebudowy architektury. Przejście z Tailscale na Headscale polega natomiast na ponownej rejestracji każdego węzła w innym 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.