Jeden host Tailscale nieosiągalny: router podsieci czy węzeł wyjściowy?

Jeden host Tailscale odpowiada, a drugi pozostaje ciemny, albo wszystko działa, dopóki publiczne strony nie zaczną zgłaszać niewłaściwego kraju. Oba zgłoszenia przychodzą jako „Tailscale jest zepsuty”, a oba zwykle są niewłaściwą konstrukcją włączoną dla niewłaściwego celu. Najpierw uporządkuj cel, który zawodzi, a potem wybierz rolę, która go obejmuje.

Zacznij od celu, który zawiódł

Zapisz adres lub nazwę, które nie działały, i czym to jest. Urządzenie w prywatnej sieci LAN za inną lokalizacją, usługa w twoim własnym segmencie i publiczna strona to trzy problemy routingu, które przypadkiem dzielą jednego klienta. Rozróżnienie nie jest kosmetyczne, bo obie konstrukcje obejmują różne zbiory celów. Włączenie jednej nic nie robi dla drugiej, i to jest całe źródło zamieszania.

Zwróć uwagę także na rodzinę adresów. Podsieć anonsowana tylko jako IPv4 zostawia cele IPv6 na ścieżce lokalnej, co wygląda na częściową awarię, dopóki ktoś nie porówna obu tabel routingu. Zapisz, jakiej ścieżki oczekiwałeś, żeby test miał później czemu zaprzeczyć.

Dotrzyj do urządzenia, które nigdy nie uruchamia Tailscale

Router anonsuje określone zakresy tailnetowi, a następnie przekazuje pakiety między tailnetem a segmentem prywatnym, więc urządzenia w tym segmencie nie potrzebują własnego klienta. Dotarcie do NAS-a w biurze z laptopa w domu to dokładnie ten przypadek. Router jest jedynym członkiem tailnetu po tej stronie.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

Anonsowanie to dopiero pierwszy z trzech warunków. Trasa musi zostać zatwierdzona dla tailnetu, klient musi zaakceptować anonsowane trasy, a reguła dostępu musi zezwalać na połączenie. To ta łańcuchowa zależność sprawia, że objawem tak często jest działający router i niedziałający NAS. Osiągalny router dowodzi, że tunel działa; nie dowodzi niczego o zatwierdzeniu, akceptacji przez klienta ani polityce.

Każda z tych trzech awarii wygląda w konsoli administracyjnej inaczej. Sprawdzaj je po kolei, zamiast zmieniać wszystkie naraz, bo druga zmiana ukrywa, która miała znaczenie.

Wyprowadź ruch publiczny przez inną maszynę

Węzeł wyjściowy kieruje twój ogólny ruch internetowy przez siebie, co jest najbliższym odpowiednikiem pełnego tunelu w innych produktach VPN. On też wymaga trzech osobnych zgód: urządzenie anonsuje rolę, administrator ją zatwierdza, a klient ją wybiera. Dołączenie do tailnetu domyślnie niczego nie wysyła przez innego członka.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Wybór węzła wyjściowego nie daje automatycznie dostępu do jego własnej sieci LAN. Opcja dostępu do sieci LAN istnieje właśnie dlatego, że to różne uprawnienia, a pozostawienie jej wyłączonej jest bezpieczniejszym ustawieniem domyślnym. Trasy do innych zasobów Tailscale zachowują własną obsługę nawet przy aktywnym węźle wyjściowym. Dlatego usługa hostowana w podsieci może dalej działać, mimo że publiczna ścieżka internetowa się zmieniła.

Węzeł wyjściowy zmienia też to, jak widzi cię internet, nie tylko to, jak szybko się to wydaje. Spodziewaj się, że geolokalizacja, katalogi streamingowe i limity szybkości będą podążać za adresem wyjścia, a nie twoim.

Przeczytaj trójdzielny podział, gdy zawodzi tylko jeden host

Drukarka w twoim segmencie, NAS za zdalnym routerem podsieci i publiczna strona to trzy cele o trzech różnych ścieżkach. Jeśli zawodzi dokładnie jeden z nich, defekt należy do ścieżki tego celu, a nie do klienta jako całości. Dla lokalnej drukarki przy aktywnym węźle wyjściowym zwykłą odpowiedzią jest ustawienie dostępu do sieci LAN. Dla zdalnego NAS-a sprawdź anonsowany zakres, stan jego zatwierdzenia i reguły dostępu w tej kolejności. Dla publicznej strony sprawdź, który węzeł wyjściowy jest wybrany i czy klient naprawdę go zaakceptował.

Jeśli adres działa, a nazwa nie, przestań patrzeć na trasy. Prywatny DNS konfiguruje się osobno, a nazwa, która rozwiązuje się na zły adres, zawodzi w sposób wyglądający identycznie jak zablokowana trasa. Najpierw przetestuj adres, potem nazwę, a oba wyniki powiedzą ci, którą warstwę otworzyć.

Potwierdź ścieżkę, którą uważasz, że zbudowałeś

Weryfikacja to wyszukanie trasy plus sprawdzenie adresu, a nie ping. Wyszukanie mówi, którego interfejsu użyłby cel, a sprawdzenie adresu mówi, w jakim zakresie cel faktycznie się znajduje. Udany ping mówi, że host gdzieś żyje, co nie jest pytaniem. Uruchom oba, zanim zmienisz jakąkolwiek konfigurację.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Połącz to z własnym widokiem tailnetu, który pokazuje, czy peer jest połączony bezpośrednio, czy przez przekaźnik. Ścieżka przez przekaźnik nadal działa, i to wyjaśnia skargi na opóźnienia, które nie mają nic wspólnego z trasą, którą debugowałeś. dokumentacja routera podsieci obejmuje krok zatwierdzenia, jeśli nie jest znany. Potem zapisz, która konstrukcja obejmuje który cel w twojej sieci, bo następna osoba dodająca lokalizację zada to samo pytanie.