Jak skonfigurować router podsieci Tailscale na VPS

Działanie routera podsieci Tailscale

Router podsieci Tailscale to maszyna, która ogłasza cały zakres prywatnych adresów IP wewnątrz sieci tailnet, dzięki czemu każde urządzenie w tej sieci może uzyskać dostęp do adresów z tego zakresu, nawet jeśli nie jest na nich zainstalowany program Tailscale. Tailnet to prywatna sieć Tailscale, obejmująca zestaw urządzeń zalogowanych na jedno konto lub w jednej organizacji. Węzeł wyjściowy (exit node) to funkcja często mylona z routerem podsieci, mimo że pełni odwrotną rolę. Kieruje on cały ruch urządzenia przez VPS, dzięki czemu VPS staje się bramą tego urządzenia do publicznego Internetu.

Każde zdanie opisuje jedno zagadnienie. Router podsieci zapewnia dostęp do sieci prywatnej z poziomu tailnet. Węzeł wyjściowy zmienia punkt wyjścia publicznego ruchu sieciowego. Jeśli celem jest to drugie rozwiązanie, należy zapoznać się z jak uruchomić węzeł wyjściowy Tailscale na VPS. Są to odrębne flagi i jeden VPS może pełnić obie funkcje jednocześnie, jednak rozwiązują one inne problemy i ulegają awariom w odmienny sposób.

Kiedy VPS wymaga routera podsieci

Typowym przypadkiem jest sieć prywatna udostępniona przez dostawcę. VPS posiada adres publiczny oraz drugi interfejs w segmencie prywatnym, podczas gdy pozostałe serwery w tym segmencie nie mają adresów publicznych: baza danych pod 10.0.0.20, cel kopii zapasowych pod 10.0.0.30. Zainstaluj Tailscale na jednym VPS, ogłoś 10.0.0.0/24, a Twój laptop uzyska bezpośredni dostęp do tych prywatnych adresów. Nic innego w segmencie nie ulega zmianie, a baza danych nadal nie posiada adresu publicznego. Jeśli z tego segmentu potrzebujesz tylko jednej aplikacji webowej na jednym porcie, ogłaszanie całego zakresu jest zbędne, a Tailscale serve pozwala na umieszczenie HTTPS na tym pojedynczym porcie. To samo rozumowanie dotyczy demona, który celowo nasłuchuje tylko na localhost, takiego jak dsh działający bezgłowo pod systemd, gdzie adres tailnet na tym VPS zastępuje tunel SSH, który w przeciwnym razie musiałbyś utrzymywać otwarty, aby uzyskać dostęp do jego interfejsu użytkownika.

Drugi przypadek to sieć znajdująca się po drugiej stronie VPS. Sieć lokalna (LAN) w domu lub biurze za własnym routerem albo szafa rack z urządzeniami, na których nie można uruchomić Tailscale, takimi jak zarządzalny przełącznik lub stary NAS z zablokowanym oprogramowaniem układowym. Jedna maszyna z systemem Linux w tej sieci staje się routerem podsieci dla wszystkich pozostałych urządzeń. W domu taką maszyną jest często mała maszyna wirtualna na używanym już hypervisorze, a rachunek kosztów hosta Proxmox w domu w porównaniu z wynajmowanym VPS jest kwestią, którą należy rozstrzygnąć przed podjęciem decyzji, po której stronie tunelu powinny znajdować się Twoje usługi.

Oba przypadki mają jeden wspólny wymóg. Router podsieci musi być już w stanie dotrzeć do zakresu, który ogłasza, korzystając z własnej tablicy routingu i własnego firewalla. Tailscale nie buduje tego połączenia. Przenosi ruch do routera i przekazuje go do jądra systemu w celu dalszego przesyłania.

Instalacja Tailscale i weryfikacja trasy lokalnej

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

Skrypt wykrywa dystrybucję, dodaje repozytorium pakietów Tailscale, instaluje polecenie tailscale oraz demona tailscaled, a następnie aktywuje usługę. Potwierdź to za pomocą systemctl is-active tailscaled, co powinno zwrócić active.

Przed wykonaniem jakichkolwiek innych czynności sprawdź, czy VPS ma dostęp do sieci, którą zamierzasz udostępnić.

ip route show
ping -c3 10.0.0.20

ip route show musi wyświetlić prywatny zakres adresów na rzeczywistym interfejsie, na przykład 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Jeśli polecenie ping nie powiedzie się na tym etapie, bezpośrednio z routera, żadna flaga Tailscale nie rozwiąże problemu. Przyczyną jest konfiguracja sieci VPS lub zapora ogniowa na docelowym hoście. Rozwiąż ten problem w pierwszej kolejności, ponieważ wszystkie późniejsze testy są od niego zależne.

Włączenie przekazywania IP i zapewnienie trwałości po restarcie

Maszyna z systemem Linux odrzuca każdy pakiet, który nie jest zaadresowany bezpośrednio do niej, chyba że włączono funkcję przekazywania (forwarding). Przekazywanie pakietów z innych maszyn jest podstawowym zadaniem routera podsieci, dlatego ten krok jest obowiązkowy.

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

Sprawdź stan za pomocą sysctl net.ipv4.ip_forward, co powinno zwrócić net.ipv4.ip_forward = 1.

Często ten krok jest wykonywany tylko częściowo. Polecenie sudo sysctl -w net.ipv4.ip_forward=1 działa natychmiast, ale ustawienie znika po restarcie systemu. W rezultacie router podsieci działa przez wiele tygodni, a następnie przestaje funkcjonować po restarcie wymuszonym aktualizacją jądra. Kłopotliwe jest to, że na pierwszy rzut oka wszystko wydaje się sprawne. tailscale status nadal wskazuje, że węzeł jest online, konsola administratora pokazuje zatwierdzoną trasę, a klienci mają zainstalowaną trasę. Pakiety docierają do VPS, a jądro odrzuca je bez rejestrowania jakichkolwiek informacji w logach. Zapisanie wartości w /etc/sysctl.d/99-tailscale.conf zapewnia ich przywrócenie po restarcie.

Jeśli ogłaszasz trasy przy wyłączonym przekazywaniu, tailscale up wyświetli ostrzeżenie w momencie uruchomienia, zawierające komunikat zbliżony do Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Należy przeczytać dane wyjściowe tego polecenia, zamiast je ignorować.

Ogłaszanie tras

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

Na serwerze VPS, który jest już zalogowany do sieci tailnet, należy zmienić ustawienie w miejscu:

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

Do każdej późniejszej zmiany należy używać tailscale set. Ponowne uruchomienie tailscale up z pojedynczą flagą resetuje flagi, które nie zostały powtórzone, a interfejs CLI blokuje operację, zwracając błąd informujący, że zmiana ustawień w ten sposób wymaga podania wszystkich flag innych niż domyślne. tailscale set zmienia jedno ustawienie, pozostawiając pozostałe bez zmian.

Kilka zakresów należy umieścić na jednej liście rozdzielonej przecinkami, bez spacji: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Każdy wpis musi być adresem sieci w notacji CIDR (classless inter-domain routing, format 10.0.0.0/24). Wpisanie przez pomyłkę własnego adresu hosta, 10.0.0.5/24, zostanie odrzucone, ponieważ bity po prefiksie nie są zerami, a komunikat błędu wskaże prefiks, który prawdopodobnie był zamierzony. Aby zatrzymać ogłaszanie tras, należy ustawić pustą listę za pomocą sudo tailscale set --advertise-routes=.

Zatwierdzenie trasy w konsoli administracyjnej

Ogłoszenie trasy jest jedynie żądaniem, a nie zmianą konfiguracji. Dopóki administrator jej nie zatwierdzi, żaden klient nie otrzyma trasy i żaden adres z tego zakresu nie będzie osiągalny. Jest to celowe działanie, ponieważ maszyna, która mogłaby samodzielnie dodać się do tablicy routingu każdego urządzenia, mogłaby przejmować ruch dla dowolnego zakresu adresów.

Zatwierdź trasę na stronie Machines w konsoli administracyjnej. VPS będzie widoczny z etykietą subnet. Rozwiń jego wiersz, znajdź sekcję subnets, edytuj ustawienia tras, zaznacz odpowiednią trasę i zapisz zmiany.

Zatwierdzenie odbywa się dla każdego prefiksu z osobna. Jeśli ogłosisz 10.0.0.0/24 dzisiaj, a 192.168.50.0/24 w przyszłym miesiącu, nowy prefiks pojawi się jako niezatwierdzony, podczas gdy stary będzie nadal działał. Z perspektywy VPS zatwierdzona i zignorowana trasa wyglądają identycznie, dlatego przed rozpoczęciem debugowania sprawdź stan w konsoli.

Możesz pominąć krok ręczny, stosując blok autoApprovers w pliku polityki tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Następnie uruchom węzeł z tym znacznikiem, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, a trasa zostanie zatwierdzona w momencie jej ogłoszenia. Znacznik musi najpierw istnieć w sekcji tagOwners tego samego pliku polityki. Warto to skonfigurować, jeśli VPS jest przebudowywany ze skryptu, ponieważ przebudowany węzeł jest traktowany jako nowy, a jego trasy domyślnie wymagają ponownego zatwierdzenia.

Dlaczego klienci Linux ignorują trasę bez flagi --accept-routes

Trasa jest teraz rozgłaszana i zatwierdzona. Telefon oraz komputer Mac mogą uzyskać dostęp do 10.0.0.20. Laptop z systemem Linux nie może, a konsola administracyjna nie wskazuje na żaden problem.

Akceptacja trasy podsieci oznacza wpisanie odpowiednich pozycji do tablicy routingu klienta. W systemach Android, iOS, macOS, tvOS oraz Windows klient Tailscale wykonuje to automatycznie. W systemie Linux tak się nie dzieje, ponieważ maszyna z systemem Linux często pełni rolę serwera lub routera, którego tablica routingu została skonfigurowana celowo. Ciche wprowadzenie trasy /24 pobranej z sieci mogłoby zakłócić ruch, który ta maszyna już obsługuje. Dlatego w systemie Linux należy wyrazić zgodę na każdym kliencie:

sudo tailscale set --accept-routes

Następnie należy sprawdzić, gdzie trafiła trasa:

ip route show table 52
ip route get 10.0.0.20

Tailscale w systemie Linux nie umieszcza zaakceptowanych tras w głównej tablicy routingu. Umieszcza je w tablicy routingu 52 i instaluje reguły polityki, widoczne za pomocą ip rule show w zakresie priorytetów od 5210 do 5270, które kierują niedopasowane pakiety do tej tablicy. Zatem polecenie ip route show samo w sobie nigdy nie wyświetli 10.0.0.0/24, a użytkownik sprawdzający tylko to polecenie uzna, że --accept-routes nie wykonało żadnej akcji. ip route show table 52 to polecenie, które ukazuje stan faktyczny i powinno wyświetlić rozgłaszany zakres na tailscale0.

Warto znać jeden wyjątek. Jeśli ten węzeł Linux jest jednocześnie drugim routerem podsieci dla własnej sieci lokalnej, --accept-routes spowoduje, że będzie on wysyłał ruch dla własnej, bezpośrednio podłączonej podsieci przez drugi router, zamiast przez własny interfejs. W przypadku routera w trybie gotowości (standby) w parze o wysokiej dostępności, należy pozostawić --accept-routes wyłączone i jedynie rozgłaszać trasy.

Tryb awarii: dwa routery ogłaszające nakładające się zakresy

Dwa routery podsieci nie mogą ogłaszać identycznych zakresów. Nakładające się zakresy o różnych długościach prefiksu są dozwolone, a Tailscale wybiera najbardziej szczegółowe dopasowanie. Gdy router A ogłasza 10.0.0.0/24, a router B ogłasza 10.0.0.0/16, ruch do 10.0.0.20 trafia do A.

Użytkowników zaskakuje zachowanie systemu, gdy A przechodzi w tryb offline. Tailscale nie przełącza się automatycznie na mniej szczegółową trasę. Ruch do 10.0.0.20 zostaje wstrzymany, podczas gdy ruch do 10.1.0.20 nadal działa przez B. Objaw wygląda jak awaria połowy sieci prywatnej, a przyczyną jest węzeł offline, który posiada bardziej szczegółowy prefiks. Aby zapewnić przełączanie awaryjne (failover), należy skonfigurować szerszy router tak, aby ogłaszał również węższe prefiksy, dzięki czemu oba urządzenia pokrywają te same adresy.

Drugi rodzaj nakładania się występuje bliżej klienta. Korzystanie z sieci hotelowej w zakresie 192.168.1.0/24, podczas gdy własny router podsieci ogłasza 192.168.1.0/24, powoduje rywalizację o te same miejsca docelowe. To, która trasa wygra, zależy od platformy. W systemie Linux należy zainstalować regułę przed regułą Tailscale, aby adresy lokalne korzystały z głównej tablicy:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Ta reguła nie jest trwała i znika po ponownym uruchomieniu systemu. Prawidłowym rozwiązaniem jest wybór zakresu prywatnego, który nie występuje w typowych sieciach publicznych. 192.168.0.0/24 oraz 192.168.1.0/24 to wartości domyślne w większości routerów domowych, dlatego należy wybrać adresację z zakresu 10.0.0.0/8, która została wybrana świadomie. Ta sama kolizja powoduje awarię w przypadku standardowego tunelu WireGuard skonfigurowanego ręcznie, z tego samego powodu: wygrywa bardziej szczegółowa trasa lokalna, więc ruch nigdy nie trafia do tunelu.

Tryb awarii: DNS wskazuje na adres, dla którego brak trasy

Ten problem jest trudny w diagnostyce, ponieważ żaden komponent nie zgłasza błędu. Nazwa zostaje rozwiązana, a połączenie kończy się przekroczeniem czasu oczekiwania.

Załóżmy, że db.internal.example.com jest rozwiązywane do 10.0.5.20 przez prywatny serwer nazw, a użytkownik ogłosił 10.0.0.0/24. Wyszukiwanie kończy się powodzeniem, ponieważ rozwiązywanie nazw DNS (domain name system) oraz trasowanie IP to odrębne etapy i żaden z nich nie weryfikuje drugiego. Następnie pakiet do 10.0.5.20 nie znajduje pasującej trasy w sieci tailnet, więc opuszcza ją przez domyślną bramę klienta i znika.

Dwie komendy pozwalają rozdzielić te dwa etapy:

nslookup db.internal.example.com
ip route get 10.0.5.20

Jeśli wyszukiwanie zwraca adres, ale ip route get nie odpowiada za pomocą dev tailscale0, oznacza to, że nazwa jest poprawna, natomiast brakuje trasy. Należy ogłosić zakres obejmujący ten adres, używając 10.0.0.0/16 lub drugiego jawnego prefiksu, a następnie zatwierdzić nowy prefiks w konsoli.

Istnieje powiązana pułapka na samym serwerze nazw. Jeśli w konsoli administracyjnej ustawiono globalny serwer nazw pod prywatnym adresem, takim jak 10.0.0.53, adres ten musi znajdować się wewnątrz zatwierdzonej trasy, w przeciwnym razie urządzenia w ogóle nie osiągną resolvera. Włączenie opcji nadpisującej lokalne serwery DNS przy jednoczesnym wskazaniu resolvera, do którego nikt nie ma dostępu, powoduje natychmiastową utratę rozwiązywania nazw przez wszystkie urządzenia w sieci tailnet, włącznie z tymi, które działały chwilę wcześniej. Najpierw należy ogłosić i zatwierdzić trasę do resolvera, a dopiero potem zmienić ustawienia DNS. Jeśli DNS wewnątrz tunelu jest elementem sprawiającym ciągłe problemy, sposób, w jaki DNS ulega awarii w tunelu WireGuard opisuje ten sam mechanizm bez dodatkowej warstwy koordynacji.

Source NAT i połączenia typu site-to-site

Domyślnie router podsieci nadpisuje adres źródłowy każdego przekazywanego pakietu własnym adresem prywatnym. Jest to SNAT (source network address translation), który zapewnia poprawne działanie odpowiedzi bez konieczności wprowadzania zmian w sieci prywatnej: baza danych pod adresem 10.0.0.20 odpowiada do VPS, do którego potrafi wysłać ruch. Kosztem tego rozwiązania jest fakt, że baza danych widzi każde połączenie z tailnet jako pochodzące z VPS, przez co reguły firewalla oparte na źródle oraz logi dostępu nie dostarczają użytecznych informacji.

Wyłącz tę funkcję w systemie Linux, jeśli chcesz zachować rzeczywisty adres tailnet klienta:

sudo tailscale set --snat-subnet-routes=false

Hosty w sieci prywatnej wymagają wówczas trasy powrotnej do 100.64.0.0/10, czyli zakresu adresów przydzielanego urządzeniom przez Tailscale, wskazującej na router podsieci. Bez tej trasy zwrotnej odpowiedzi trafiają do domyślnej bramy i nigdy nie docierają do celu, co powoduje zawieszanie się połączeń po pierwszym pakiecie. Dodaj trasę statyczną na bramie sieci prywatnej lub pozostaw włączony SNAT.

Połączenie typu site-to-site to dwa routery podsieci wykonujące tę operację jednocześnie, z których każdy ogłasza własną sieć i akceptuje sieć drugiego:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Uruchom odpowiednią komendę na drugim routerze, używając jego własnego zakresu adresów. Oba zakresy muszą być różne. Jeśli duże transfery ulegają zawieszeniu, podczas gdy ssh i ping działają poprawnie, przyczyną jest MSS (maximum segment size), czyli największy fragment danych przenoszony przez pakiet TCP. Narzut tunelu sprawia, że przekazywane pakiety stają się zbyt duże dla niektórych ogniw pośrednich, a rozwiązaniem jest ich przycięcie (clamping):

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Zapisz tę regułę za pomocą iptables-persistent, w przeciwnym razie zniknie ona po kolejnym uruchomieniu systemu.

Utrzymanie ciągłości działania

Klucze węzłów wygasają domyślnie po 180 dniach, począwszy od sierpnia 2026 roku. Gdy klucz na routerze podsieci wygaśnie, węzeł wylogowuje się, a cały anonsowany zakres staje się nieosiągalny, bez żadnej zmiany w konfiguracji, która mogłaby to wyjaśnić. Należy wyłączyć wygasanie klucza dla tej maszyny na stronie Machines w konsoli administracyjnej, a następnie odnotować ten fakt.

Tailscale preferuje bezpośrednie połączenie między węzłami i przełącza się na serwery przekaźnikowe (relay), gdy nie może go nawiązać. Przekaźniki działają, ale zwiększają opóźnienia. VPS z publicznym adresem to prosty przypadek: należy zezwolić na ruch przychodzący UDP 41641, a większość węzłów połączy się bezpośrednio. Jeśli ufw zarządza firewallem, reguły ufw faktycznie wymagane przez VPS zawierają odpowiednią składnię.

Reguły dostępu stanowią drugą połowę konfiguracji. W domyślnej sieci tailnet każde urządzenie ma dostęp do każdego innego, więc zatwierdzona trasa działa automatycznie. Po utworzeniu polityki ACL, strona docelowa reguły musi wskazywać prywatny zakres, ponieważ 10.0.0.20 nie jest adresem tailnet i nie jest objęty regułami zapisanymi dla adresów IP lub tagów tailnet.

Na koniec należy zdecydować, czy korzystać z serwera koordynacji, którego nie uruchamiamy samodzielnie. Płaszczyzna kontrolna Tailscale to usługa hostowana. Klucze pozostają na maszynach, ale konto i plik polityki znajdują się w chmurze. Warto rozważyć, co można zrobić w przypadku przejęcia płaszczyzny kontrolnej lub kradzieży danych logowania, zanim przyzna się jej dostęp do sieci prywatnej, a model zaufania Tailscale wyznacza granice tego bezpieczeństwa. Koszt rzadko jest powodem rezygnacji, ponieważ darmowy plan obejmuje do sześciu użytkowników z nieograniczoną liczbą własnych urządzeń, choć router podsieci uruchomiony z użyciem tagu jest liczony inaczej niż ten przypisany do użytkownika. Powyżej tego limitu opłaty naliczane są za osoby, a nie za maszyny, więc koszty dla gospodarstwa domowego lub pięcioosobowego zespołu po wyczerpaniu darmowego planu warto obliczyć przed dodaniem konta, które przekroczy limit. Uruchomienie Headscale, samodzielnie hostowanego serwera kontrolnego Tailscale pozwala zachować kontrolę na własnym VPS, kosztem konieczności jego utrzymania. Innym rozwiązaniem tego problemu jest rezygnacja z klientów Tailscale, a samodzielne hostowanie serwera VPN NetBird umieszcza warstwę koordynacji oraz własne klienty mesh na maszynie pod pełną kontrolą. Jeśli decyzja między tym modelem a ręczną konfiguracją nadal trwa, porównanie WireGuard i Tailscale wyjaśnia, co zapewnia warstwa koordynacji i jakie są jej koszty.

FAQ

Jaka jest różnica między routerem podsieci a węzłem wyjściowym?

Router podsieci ogłasza zakres adresów prywatnych, dzięki czemu urządzenia w sieci tailnet mogą łączyć się z maszynami, na których nie uruchomiono Tailscale. Węzeł wyjściowy (exit node) ogłasza się jako trasa do całego Internetu, co powoduje, że urządzenie kieruje cały swój ruch przez publiczny adres tego węzła. Jeden serwer VPS może pełnić obie te funkcje jednocześnie. Są to odrębne flagi, --advertise-routes oraz --advertise-exit-node, a każda z nich wymaga osobnego zatwierdzenia w konsoli administracyjnej.

Dlaczego mój klient Linux ignoruje ogłoszoną trasę podsieci?

Klienci z systemem Linux nie akceptują tras podsieci, dopóki nie zostanie to jawnie wymuszone. Uruchom sudo tailscale set --accept-routes na kliencie. Następnie sprawdź stan za pomocą ip route show table 52, a nie ip route show. Tailscale instaluje zaakceptowane trasy w tablicy routingu 52 i uzyskuje do nich dostęp poprzez reguły polityki, dlatego główna tablica routingu ich nie wyświetla, a działająca trasa może wyglądać na nieobecną.

Moja podsieć przestała działać po restarcie. Co uległo awarii?

Najprawdopodobniej przekazywanie pakietów IP (IP forwarding). Wartość ustawiona za pomocą sysctl -w nie jest zachowywana po restarcie, dlatego należy zapisać ją w /etc/sysctl.d/99-tailscale.conf i potwierdzić za pomocą sysctl net.ipv4.ip_forward. Jeśli przekazywanie jest włączone, a zakres nadal pozostaje nieosiągalny, sprawdź węzeł w konsoli administracyjnej. Klucze węzłów wygasają domyślnie po 180 dniach, a wygasły router podsieci wygląda jak błąd sieci, a nie problem z kontem.

Czy dwa routery podsieci mogą ogłaszać ten sam zakres?

Nie identyczne zakresy. Nakładające się zakresy o różnych długościach prefiksów są dopuszczalne, a pierwszeństwo ma trasa najbardziej szczegółowa. Przełączanie awaryjne wymaga uwagi: gdy router obsługujący bardziej szczegółowy prefiks przejdzie w tryb offline, Tailscale nie przełączy się automatycznie na szerszą trasę, co spowoduje przerwanie ruchu. Aby uzyskać rzeczywistą parę rezerwową, oba routery powinny ogłaszać te same szczegółowe prefiksy.

Nazwa hosta jest rozpoznawana, ale połączenie przekracza limit czasu. Dlaczego?

Rozpoznawanie DNS i routing to odrębne etapy. Nazwa może zostać rozpoznana jako adres, którego nie obejmuje żadna zatwierdzona trasa, przez co pakiet opuszcza urządzenie przez domyślną bramę klienta. Uruchom ip route get <address> na kliencie. Jeśli odpowiedź nie zawiera dev tailscale0, ogłoś zakres obejmujący ten adres i zatwierdź nowy prefiks w konsoli administracyjnej.