Jak skonfigurować VPS jako exit node w Tailscale

Czym jest węzeł wyjściowy Tailscale

Węzeł wyjściowy (exit node) Tailscale to urządzenie wewnątrz Twojej sieci tailnet, które obsługuje cały ruch internetowy dla pozostałych Twoich urządzeń. Serwer VPS (virtual private server) sprawdza się w tej roli doskonale, ponieważ posiada stały publiczny adres IP i działa w trybie ciągłym. Konfiguracja obejmuje pięć kroków: instalację Tailscale na serwerze, ogłoszenie węzła wyjściowego, włączenie przekazywania pakietów IP, zatwierdzenie trasy w konsoli administracyjnej oraz wybór węzła na laptopie. Czwarty krok wymaga użycia przełącznika w panelu WWW, a nie polecenia w terminalu; to właśnie w tym miejscu większość użytkowników napotyka trudności.

Po aktywacji laptop szyfruje każdy pakiet i przesyła go do VPS. Serwer VPS stosuje mechanizm source NAT (network address translation) i wysyła pakiet dalej, używając własnego publicznego adresu IP. Witryny internetowe widzą jedynie VPS. Sieć Wi-Fi w kawiarni widzi tylko jeden zaszyfrowany strumień UDP skierowany do VPS i nic więcej.

Tailscale to protokół WireGuard w warstwie przesyłu danych oraz serwer koordynujący, który dystrybuuje klucze i pomaga urządzeniom odnaleźć się nawzajem przez NAT. Dzięki serwerowi koordynującemu nie ma potrzeby ręcznego kopiowania kluczy. Aby zapoznać się ze szczegółowym zestawieniem wad i zalet, przeczytaj porównanie Tailscale i standardowego WireGuard. Jeśli wolisz samodzielnie zarządzać każdym elementem tunelu, wybierz samodzielną instalację VPN WireGuard na serwerze VPS.

Poniższe kroki zakładają, że Tailscale jest już uruchomiony na Twoim laptopie, a oba urządzenia są zalogowane do tej samej sieci tailnet. Tailnet to Twoja prywatna sieć Tailscale, w której każde urządzenie otrzymuje stabilny adres wewnątrz 100.64.0.0/10.

Instalacja Tailscale na VPS

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

Skrypt instalacyjny wybiera repozytorium pakietów dla danej dystrybucji i instaluje demona tailscaled. Następnie tailscale up wyświetla adres URL uwierzytelniania. Należy otworzyć go w przeglądarce i zalogować się na to samo konto, którego używa laptop, ponieważ VPS zalogowany do innej sieci tailnet nie będzie w stanie obsłużyć połączenia z laptopem.

tailscale status
tailscale ip -4

tailscale status powinno teraz wyświetlić oba urządzenia. tailscale ip -4 wypisuje adres tailnet serwera VPS, który należy później przekazać klientowi.

Tailscale wymaga urządzenia TUN do zestawienia tunelu. Na serwerach VPS typu KVM urządzenie to jest dostępne. W planach opartych na wirtualizacji kontenerowej, które współdzielą jądro systemu hosta, /dev/net/tun bywa niedostępne, przez co tailscaled nie może utworzyć interfejsu tailscale0. Przed kontynuowaniem należy uruchomić ls -l /dev/net/tun.

Włączenie przekazywania IP, w przeciwnym razie VPS odrzuci każdy pakiet

Maszyna z systemem Linux odrzuca każdy pakiet, który nie jest zaadresowany bezpośrednio do niej, ponieważ net.ipv4.ip_forward domyślnie wynosi 0. Węzeł wyjściowy (exit node) przyjąłby ruch, odszyfrował go, a następnie odrzucił. Zapisz to ustawienie w pliku, aby przetrwało restart systemu.

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

tee -a dopisuje dane do pliku, więc ponowne uruchomienie tych poleceń spowoduje dwukrotny zapis ustawień. Wynik nadal będzie poprawny, ale zawartość cat /etc/sysctl.d/99-tailscale.conf będzie wyglądać nieczytelnie. Zweryfikuj bieżącą wartość zamiast polegać wyłącznie na pliku:

sysctl net.ipv4.ip_forward

Polecenie musi zwrócić net.ipv4.ip_forward = 1. Jeśli pominiesz ten krok i użyjesz tailscale up --advertise-exit-node, klient wyświetli komunikat:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node nie wykonuje tej kontroli, więc brak komunikatów ze strony set nie jest dowodem na to, że przekazywanie jest włączone. Sprawdź wartość sysctl samodzielnie.

Nie ma potrzeby ręcznego tworzenia reguły maskarady. tailscaled instaluje własne łańcuchy zapory sieciowej o nazwach ts-input, ts-forward oraz ts-postrouting, a reguła NAT dla ruchu węzła wyjściowego znajduje się w ts-postrouting. Wyświetl je za pomocą sudo iptables-save | grep ts- lub sudo nft list ruleset w systemach korzystających z nftables.

Udostępnianie serwera VPS jako węzła wyjściowego (exit node)

sudo tailscale set --advertise-exit-node

tailscale set zmienia jedno ustawienie, pozostawiając pozostałe bez zmian. tailscale up --advertise-exit-node również ogłasza węzeł, ale ma efekt uboczny: up traktuje flagi podane w wierszu poleceń jako kompletny zestaw ustawień niestandardowych, więc późniejsze wywołanie samego sudo tailscale up kończy się odmową uruchomienia i wyświetleniem komunikatu

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Należy używać set do bieżących zmian, aby uniknąć tego komunikatu.

Ogłoszenie jest jedynie ofertą. Serwer VPS informuje teraz serwer koordynujący, że jest gotowy pełnić funkcję węzła wyjściowego. Żaden klient nie może jeszcze z niego korzystać.

Zatwierdzenie węzła wyjściowego Tailscale w konsoli administracyjnej

Ten krok nie wymaga użycia żadnego polecenia. Należy otworzyć stronę Machines w konsoli administracyjnej, odnaleźć serwer VPS, otworzyć menu z trzema kropkami na końcu wiersza, wybrać Edit route settings i włączyć opcję Use as exit node.

Dopóki przełącznik nie zostanie włączony, płaszczyzna sterowania (control plane) wstrzymuje ofertę i nie przekazuje jej do żadnego urządzenia. Polecenie tailscale exit-node list na laptopie nie zwraca żadnych wyników, a ruch sieciowy nadal korzysta z domyślnej trasy. Na żadnym z urządzeń nie pojawia się komunikat o błędzie. Węzeł wyjściowy po prostu nie staje się dostępny.

Węzły wyjściowe można zatwierdzać automatycznie za pomocą wpisu w pliku polityki tailnet:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

Urządzenie uruchomione z flagą --advertise-tags=tag:exit zostaje automatycznie zatwierdzone, pod warunkiem że w tym samym pliku polityki zdefiniowano tag:exit w sekcji tagOwners. Nadanie tagów zmienia właściciela: otagowane urządzenie należy do sieci tailnet, a nie do konta użytkownika, co zmienia również stosowane wobec niego reguły dostępu. W przypadku pojedynczego serwera VPS użycie przełącznika w konsoli jest prostszym rozwiązaniem.

Wybór węzła wyjściowego na laptopie

Na kliencie z systemem Linux:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

exit-node list wyświetla zatwierdzone węzły wyjściowe w sieci tailnet wraz z ich adresami. Pusta lista oznacza, że krok zatwierdzenia nie został wykonany. W systemach macOS, Windows, iOS oraz Android ten sam wybór znajduje się w menu Exit Node w aplikacji Tailscale.

Weryfikacja z poziomu klienta, nigdy z serwera:

curl -4 https://ifconfig.me

Uruchom to polecenie raz przed wyborem węzła wyjściowego i raz po nim. Adres musi zmienić się z lokalnego na publiczny adres IP serwera VPS. Aby przestać korzystać z węzła wyjściowego:

sudo tailscale set --exit-node=

W pierwszym dniu ważna jest jeszcze jedna flaga. Po wybraniu węzła wyjściowego klient przesyła cały ruch do tunelu, w tym pakiety kierowane do 192.168.1.50, przez co drukarka i pamięć masowa w sieci przestają odpowiadać. Aby zachować dostęp do sieci lokalnej:

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

Dlaczego DNS zmienia się po włączeniu węzła wyjściowego (exit node)

Domyślnie urządzenie korzystające z węzła wyjściowego używa go również jako swojego interpretera DNS (systemu nazw domenowych) dla każdej domeny, co nadpisuje globalne i rozdzielone serwery nazw skonfigurowane dla Twojej sieci tailnet. Jest to zachowanie zamierzone. Gdyby zapytania nadal trafiały do lokalnego interpretera, router w kawiarni nadal widziałby nazwy wszystkich odwiedzanych witryn, mimo że sam ruch byłby prywatny. Nazwy i pakiety powinny wychodzić z tego samego miejsca.

Konsekwencją, która dotyka użytkowników korzystających z wewnętrznego interpretera, jest fakt, że serwer nazw sieci tailnet, od którego zależą, przestaje być używany, gdy węzeł wyjściowy jest aktywny. Włącz opcję Use with exit node dla tego serwera nazw na stronie DNS w konsoli administracyjnej, aby przywrócić jego działanie.

Nazwy MagicDNS nadal działają, ponieważ klient Tailscale odpowiada na nie lokalnie w 100.100.100.100, zanim cokolwiek dotrze do węzła wyjściowego. Sprawdź to za pomocą dig @100.100.100.100 your-vps.your-tailnet.ts.net lub na kliencie z systemd-resolved za pomocą resolvectl status, gdzie interfejs Tailscale wymienia 100.100.100.100 jako swój serwer DNS.

Jeśli wyłączysz obsługę DNS przez Tailscale za pomocą --accept-dns=false, klient zachowa interpreter, który uzyskał z sieci lokalnej. Ruch jest tunelowany, ale zapytania nie, co stanowi ten sam wyciek DNS, który dotyczy ręcznie konfigurowanych tuneli WireGuard. Nie zmieniaj --accept-dns, chyba że masz konkretny powód, aby to zrobić.

Obsługa IPv6 przez węzeł wyjściowy

Węzeł wyjściowy rozgłasza obie trasy domyślne, 0.0.0.0/0 oraz ::/0. Jeśli VPS nie posiada działającej ścieżki IPv6 do Internetu, pakiety IPv6 docierają przez tunel i są tam blokowane. Przed wdrożeniem należy przeprowadzić test na VPS:

ip -6 addr show
curl -6 https://ifconfig.me

Nieudane żądanie oznacza, że VPS nie ma łączności IPv6 z siecią nadrzędną. Witryny korzystające z dual stack zazwyczaj nadal się ładują, ponieważ klient rezygnuje z IPv6 i ponawia próbę przez IPv4, choć takie ponowienie powoduje opóźnienie przy pierwszym połączeniu z każdą witryną. Miejsca docelowe dostępne wyłącznie przez IPv6 pozostają nieosiągalne.

Drugą kwestią jest przekazywanie pakietów. Ustawienie net.ipv4.ip_forward = 1 przy pozostawieniu net.ipv6.conf.all.forwarding na wartości 0 zapewnia działającą ścieżkę IPv4 oraz czarną dziurę dla IPv6, co użytkownik odczuwa jako "powolne działanie niektórych witryn", a nie jako błąd, który można łatwo zdiagnozować. Obie linie powinny znaleźć się w pliku sysctl.

Czy VPS powinien również ogłaszać trasy podsieci?

Węzeł wyjściowy (exit node) obsługuje cały ruch internetowy. Trasa podsieci obsługuje jeden prywatny zakres adresów znajdujący się za maszyną, która go ogłasza. Są to odrębne funkcje z oddzielnymi zatwierdzeniami, a jedna maszyna może realizować obie.

sudo tailscale set --advertise-routes=10.0.0.0/24

Ogłoś podsieć, gdy VPS współdzieli sieć prywatną z innymi serwerami, do których chcesz uzyskać dostęp za pomocą ich prywatnych adresów. Zatwierdź ją w tym samym panelu Edit route settings, używając dedykowanego przełącznika.

Wybierz zakres ostrożnie. Ogłoszona trasa jest bardziej szczegółowa niż domyślna trasa Twojego laptopa, więc ogłoszenie 192.168.1.0/24 z poziomu VPS przejmie adresację sieci domowej korzystającej z tego samego zakresu, co spowoduje utratę łączności z urządzeniami w Twojej lokalnej sieci. Użyj zakresu, który sam wybrałeś, a nie zakresu narzuconego przez domowy router.

Zwiększenie wydajności węzła wyjściowego za pomocą UDP GRO forwarding

Tailscale w wersji 1.54 lub nowszej, działający na jądrze Linux 6.2 lub nowszym, może wykorzystywać funkcję odciążania odbioru (receive offload), która zwiększa przepustowość przekazywanego ruchu. GRO (generic receive offload) scala pakiety przychodzące, zanim jądro przetworzy je pojedynczo. Według stanu na sierpień 2026 r. jest to nadal czynność wykonywana ręcznie na węźle wyjściowym.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8 wskazuje interfejs, który faktycznie łączy się z Internetem, dzięki czemu nie trzeba zgadywać między eth0, ens3 a enp1s0. Potwierdź to za pomocą ethtool -k $NETDEV | grep udp-gro-forwarding, co powinno teraz zwrócić on.

Ustawienie to jest tracone po restarcie. W systemie korzystającym z networkd-dispatcher można zautomatyzować ten proces:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Najpierw sprawdź, czy /etc/networkd-dispatcher/routable.d/ istnieje. Jeśli nie, oznacza to, że w systemie nie działa networkd-dispatcher. W takim przypadku to samo zadanie wykona mała jednostka systemd, która uruchomi linię ethtool podczas startu systemu.

Co zasady dopuszczalnego użytkowania dostawcy oznaczają dla ruchu wyjściowego

Każdy pakiet wysyłany przez klienta przez węzeł wyjściowy opuszcza sieć z publicznym adresem IP serwera VPS, co oznacza, że jest przypisywany do Twojego konta. Zgłoszenia o nadużyciach trafiają bezpośrednio do Twojej skrzynki odbiorczej: powiadomienia o naruszeniu praw autorskich czy skargi na skanowanie portów. Przed skierowaniem ruchu domowego lub zespołowego przez jeden serwer należy zapoznać się z dokumentem AUP (acceptable use policy) dostawcy. Nie należy udostępniać węzła wyjściowego osobom, których działań nie można zweryfikować.

Przepustowość jest liczona podwójnie. Ruch dociera do serwera VPS przez tunel, a następnie wychodzi do Internetu; oba kierunki zazwyczaj wliczają się do limitu transferu w ramach planu. Strumień wideo oglądany przez węzeł wyjściowy generuje większe zużycie danych, niż większość użytkowników zakłada.

Zakresy adresów centrów danych mają również swoją reputację. Niektóre witryny wyświetlają użytkownikom tych adresów więcej testów CAPTCHA, a niektóre serwisy streamingowe całkowicie blokują do nich dostęp. Żadna konfiguracja tego nie zmieni, ponieważ jest to cecha bloku adresowego należącego do dostawcy.

Dlaczego ruch nadal wychodzi przez lokalne połączenie

Węzeł wyjściowy jest ogłoszony, ale niezatwierdzony. tailscale exit-node list na kliencie nie zwraca żadnych informacji, a żadna z maszyn nie rejestruje błędu. Przejdź do strony Machines i włącz opcję Use as exit node.

Klient nigdy go nie wybrał. Zatwierdzenie udostępnia węzeł w sieci tailnet. Wybór jest osobną czynnością wykonywaną na każdym urządzeniu. Uruchom ponownie sudo tailscale set --exit-node=<name>, a następnie sprawdź ponownie curl -4 https://ifconfig.me.

Przekazywanie jest wyłączone. Objaw jest specyficzny: tailscale ping <vps> kończy się powodzeniem, tunel jest wyraźnie aktywny, a każdy zewnętrzny adres przekracza limit czasu. sysctl net.ipv4.ip_forward wskazuje 0. Popraw plik sysctl, a następnie wykonaj sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

Firewall odrzuca przekazywane pakiety. tailscaled wstawia własny łańcuch ts-forward, co na czystym VPS jest wystarczające. Maszyna z uruchomionym ufw lub Docker może mieć politykę FORWARD ustawioną na DROP oraz reguły przetwarzane przed regułami Tailscale. Nie zgaduj, która z nich: uruchom sudo iptables -L FORWARD -n -v w trakcie, gdy klient próbuje załadować stronę i obserwuj, które liczniki rosną. Na maszynie z ufw typowym rozwiązaniem jest DEFAULT_FORWARD_POLICY="ACCEPT" w /etc/default/ufw, a następnie sudo ufw reload. Sprawdź również sieciowy firewall dostawcy w panelu sterowania, ponieważ jest to kontrola niezależna od wszystkiego, co działa na serwerze.

Działa, ale jest wolno. Uruchom tailscale netcheck na obu maszynach. Jeśli raportuje UDP jako zablokowane, urządzenia nie mogą zbudować bezpośredniej ścieżki i przełączają się na przekaźnik DERP, co zwiększa opóźnienie każdego połączenia. Zezwolenie na ruch przychodzący UDP na porcie 41641 do VPS w firewallu sieciowym dostawcy zazwyczaj przywraca bezpośrednią ścieżkę.

Kiedy zrezygnować z serwera koordynacji Tailscale

Wszystkie powyższe rozwiązania polegają na hostowanym serwerze koordynacji Tailscale w zakresie wymiany kluczy oraz zatwierdzania dostępu. Ruch sieciowy nadal przesyłany jest bezpośrednio między laptopem a VPS i serwer koordynacji nigdy go nie obsługuje, choć decyduje o tym, kto może dołączyć do tailnet oraz do jakich zasobów ma dostęp każde urządzenie. Jeśli ta zależność jest elementem, który chcesz wyeliminować, uruchom Headscale jako własny serwer kontroli Tailscale i skieruj na niego oba klienty. Kroki dotyczące węzła wyjściowego (exit node) pozostają następnie takie same, z tą różnicą, że zatwierdzanie tras odbywa się przez wiersz poleceń Headscale zamiast przez konsolę hostowaną. Headscale zastępuje płaszczyznę kontrolną, ale pozwala zachować klienty Tailscale. Jeśli wolisz samodzielnie zarządzać całym stosem, NetBird dostarcza własny serwer koordynacji oraz klienty, które hostujesz na jednym VPS.

FAQ

Dlaczego mój ruch nadal korzysta z lokalnego połączenia po wybraniu węzła wyjściowego (exit node)?

Istnieją dwie częste przyczyny. Węzeł wyjściowy został ogłoszony, ale nie został zatwierdzony: otwórz stronę Machines w konsoli administracyjnej, znajdź VPS, wybierz Edit route settings i włącz opcję Use as exit node. Zatwierdzenie jest przełącznikiem w konsoli i żadne polecenie na serwerze go nie wykonuje. Druga przyczyna wygląda inaczej: przekazywanie IP (IP forwarding) jest wyłączone, więc tunel zostaje nawiązany, tailscale ping do VPS działa, a wszystkie adresy zewnętrzne kończą się przekroczeniem czasu oczekiwania. Sprawdź to za pomocą sysctl net.ipv4.ip_forward, które musi zwracać wartość 1.

Czy muszę zatwierdzać węzeł wyjściowy ręcznie za każdym razem?

Przełącznik jest jednorazową akcją dla każdej maszyny. Jeśli często przebudowujesz VPS, dodaj blok autoApprovers do pliku polityki tailnet zawierający "exitNode": ["tag:exit"], zdefiniuj tag:exit w sekcji tagOwners i uruchom węzeł za pomocą --advertise-tags=tag:exit. Urządzenie z tagiem jest własnością tailnetu, a nie konta użytkownika, więc zasady dostępu, które go dotyczą, również ulegają zmianie.

Z jakiego serwera DNS korzysta mój laptop, gdy włączony jest węzeł wyjściowy?

Z samego węzła wyjściowego. Urządzenie korzystające z węzła wyjściowego wysyła tam wszystkie zapytania DNS, co nadpisuje globalne i rozdzielone serwery nazw ustawione dla tailnetu. Uniemożliwia to sieci lokalnej podglądanie wyszukiwanych nazw. Aby zachować stosowanie jednego serwera nazw tailnetu, włącz opcję Use with exit node dla niego na stronie DNS w konsoli administracyjnej. Nazwy MagicDNS nadal są rozwiązywane, ponieważ klient Tailscale odpowiada na nie lokalnie pod adresem 100.100.100.100.

Czy jeden VPS może być jednocześnie węzłem wyjściowym i routerem podsieci?

Tak. sudo tailscale set --advertise-exit-node oraz sudo tailscale set --advertise-routes=10.0.0.0/24 są niezależne i każdy z nich posiada własny przełącznik zatwierdzania w sekcji Edit route settings. Oba wymagają włączonego przekazywania IP na VPS. Unikaj ogłaszania zakresu, który pokrywa się z siecią domową laptopa, ponieważ ogłoszona trasa jest bardziej szczegółowa niż trasa domyślna, co sprawia, że urządzenia lokalne stają się nieosiągalne.

Czy węzeł wyjściowy ukrywa mój ruch przed dostawcą VPS?

Nie. Tunel kończy się na VPS, więc ruch opuszcza serwer w formie oczekiwanej przez miejsce docelowe, a dostawca przesyła go w postaci jawnej wszędzie tam, gdzie sama witryna nie jest szyfrowana. Węzeł wyjściowy przesuwa punkt, w którym ruch łączy się z Internetem, z sieci, w której aktualnie przebywasz, na wynajmowany serwer. Ukrywa to przeglądanie przed Wi-Fi w kawiarni i domowym dostawcą ISP, ale jednocześnie ujawnia to samo przeglądanie dostawcy VPS wraz z przypisaną nazwą konta.