Dlaczego zatwierdzona trasa podsieci Tailscale nadal kończy się przekroczeniem czasu

Zatwierdzenie w konsoli administracyjnej wygląda na ostatni krok, ale nim nie jest. Najpierw aplikacja kończy się przekroczeniem czasu, a dopiero potem okazuje się, że router jest online, a trasa zatwierdzona. Zatwierdzenie to krok dystrybucji, nie uprawnienie i nie gwarancja przekazywania. Cztery etapy muszą się zgadzać, zanim pakiet dotrze do hosta za routerem podsieci, i każdy może się udać, gdy następny zawodzi. Przejdź je po kolei i zatrzymaj się na pierwszym etapie, który się nie utrzymuje.

Cztery etapy, jedna awaria

Router ogłasza prefiks, tailnet zatwierdza to ogłoszenie, klient akceptuje otrzymaną trasę, a polityka dostępu zezwala na konkretne połączenie. To cztery odrębne decyzje podejmowane przez trzy różne komponenty. Zatwierdzona trasa mówi więc tylko, że sieć jest teraz częścią tabeli routingu tailnetu.

Czwarty etap jest pomijany najczęściej, ponieważ pierwsze trzy dają widoczny stan. Uprawnienie obejmujące własny adres tailnet routera nie obejmuje automatycznie prywatnej podsieci za nim. To różne cele, a polityka jest oceniana dla każdego celu osobno.

W systemie Linux trzeci etap ma też ustawienie domyślne, które zaskakuje: akceptowanie tras podsieci jest opcjonalne. Kilka klientów z interfejsem graficznym domyślnie akceptuje ogłoszone trasy, więc w mieszanej flocie jedna maszyna może zawodzić, gdy reszta działa.

Potwierdź ustawienie na zawodzącej maszynie, zamiast zakładać platformę. Trasa nigdy nie była brakującym elementem na działających maszynach, więc pozwól im udowodnić, że strona tailnetu jest zdrowa. Dokumentacja Tailscale dotycząca routerów podsieci obejmuje zatwierdzanie, akceptację tras w kliencie i etap polityki.

Sprawdź trasę tam, gdzie działa klient

Zacznij od zawodzącego klienta, nie od routera. Potwierdź, że trasa istnieje i że ustawienie klienta w ogóle pozwala akceptować trasy.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Pierwsze polecenie pokazuje listę peerów i to, czy router podsieci jest osiągalny, drugie wypisuje preferencje klienta, w tym flagę akceptacji tras, a trzecie pyta jądro, którego interfejsu użyłoby dla rzeczywistego hosta w podsieci. Jeśli to ostatnie polecenie wymienia interfejs fizyczny zamiast interfejsu Tailscale, trasa nigdy nie trafiła do tabeli. Brakująca trasa to problem po stronie klienta, a nie zatwierdzenia. Napraw go, zanim spojrzysz na politykę.

Aby akceptować trasy w systemie Linux, połącz się ponownie z flagą, zamiast zakładać, że jest ustawiona: tailscale up --accept-routes. Klient dołączony z innymi flagami zachowuje je, dopóki nie zostaną zmienione, więc sprawdź bieżące ustawienie, zanim dodasz kolejne. Ponowne uruchomienie pierwszego polecenia po zmianie powinno pokazać trasę w tabeli.

Udowodnij przekazywanie i drogę powrotną

Zatwierdzenie nie konfiguruje routera do przekazywania pakietów i nie organizuje odpowiedzi. Oba są kwestiami na poziomie hosta po stronie LAN routera. Testuj je na routerze, nie na kliencie.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Pierwsze polecenie musi zgłosić 1, inaczej jądro odrzuci przekazany pakiet. Drugie pokazuje, czy maskowanie trasy podsieci przepisuje źródło, co jest zachowaniem domyślnym i zwykle tym, czego chcesz. Trzecie pokazuje, czy żądanie dociera do celu i czy coś wraca; żądanie bez odpowiedzi to problem drogi powrotnej, a nie zatwierdzenia. Przeczytaj trzy wyniki razem, zanim zmienisz którykolwiek z nich.

Jeśli maskowanie zostało wyłączone, sieć docelowa potrzebuje trasy powrotnej do adresów tailnetu, a każdy skok pomiędzy musi o tym wiedzieć. Ponowne włączenie maskowania to najszybsza naprawa dla jednej usługi, ale kosztem ukrycia oryginalnego adresu klienta przed celem. Ten kompromis ma znaczenie, gdy cel rejestruje adresy źródłowe na potrzeby audytu, więc zdecyduj świadomie, zamiast przełączać flagę w trakcie incydentu. Udokumentuj wybór, bo następna osoba zobaczy tylko jedno z dwóch zachowań.

Przeczytaj regułę dostępu do zasobu

Gdy trasa istnieje, a przekazywanie jest udowodnione, pozostałym podejrzanym jest polityka. Przeczytaj uprawnienie, które ma zezwalać na połączenie, i sprawdź jego cel, nie tylko źródło. Tożsamość samego klienta też musi odpowiadać selektorowi polityki, więc zapisz ją na tej samej maszynie, która zawodzi.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Dane wyjściowe statusu identyfikują własne adresy klienta i peery, które widzi, i z tym musi się zgadzać selektor źródła polityki. tailscale ping dowodzi ścieżki tailnetu do samego routera podsieci; rozwiązuje nazwy peerów i adresy tailnetu, a nie hosty wewnątrz ogłoszonej podsieci. Trzecie polecenie wysyła zwykłe echo ICMP przez trasę podsieci, więc wynik opisuje cel, a nie router. Odmowa na poziomie tailnetu zwykle wraca jako odmowa, podczas gdy pakiet, który wychodzi i nigdy nie wraca, kończy się przekroczeniem czasu.

Nieudana nazwa to inne pytanie niż nieudany adres; rozwiąż host bezpośrednio, zanim obwinisz trasę. Pisz uprawnienie według rzeczywistej potrzeby zasobu, a nie całej podsieci. Otwarcie całego /24, aby jedna aplikacja działała, to droga, na której wąskie żądanie staje się szerokim uprawnieniem, którego później nikt nie odważy się usunąć.

Jeśli celem było wyjście do internetu, a nie prywatna podsieć, właściwym komponentem jest węzeł wyjścia, a nie router podsieci, i polityka oraz routing różnią się odpowiednio. Sprawdź tę decyzję, zanim rozszerzysz uprawnienie. Węzeł wyjścia zmienia trasę domyślną; router podsieci tylko ogłasza prefiks.