Dlaczego klient Tailscale w Linuksie ignoruje ogłaszane trasy podsieci

Tabela 52 to wskazówka: klient Tailscale w Linuksie instaluje ogłoszoną trasę podsieci dopiero po --accept-routes, a zatwierdzenie urządzenia to osobna brama.

Siedzisz przy laptopie z Linuksem, tailscale status wyświetla inne maszyny, a NAS pod 10.80.0.25 wciąż kończy się przekroczeniem czasu. Tailnet jest zdrowy, router podsieci jest online, a nic w danych wyjściowych klienta nie mówi, dlaczego sieć LAN za nim jest nieosiągalna. Poniższy przewodnik wychodzi od tego objawu na zewnątrz: flaga na tym kliencie, potem ogłoszenie na routerze, potem zatwierdzenie, potem polityka, a dopiero na końcu samo miejsce docelowe. Każda brama zawodzi z tym samym przekroczeniem czasu, więc kolejność liczy się bardziej niż polecenia.

Czego klient Linuksa odmawia zainstalowania

Klienci Tailscale w Linuksie nie akceptują ogłoszonych tras podsieci, chyba że ich o to poprosisz. Bez tego ustawienia klient dołącza do tailnetu i osiąga adresy równorzędnych węzłów, podczas gdy każdy prefiks ogłaszany przez router pozostaje nieużywany. Domyślne zachowanie jest celowe i dlatego objaw wygląda na zepsuty router, a nie na lokalną decyzję.

Dwie różne rzeczy nazywa się tu routingiem, a tylko jedna jest twoja. Router ogłasza prefiks do tailnetu; twoja maszyna decyduje, czy go zainstalować. Awaria w którejkolwiek z nich daje to samo przekroczenie czasu, dlatego zgadywanie marnuje popołudnie. Ustal, która strona odmawia, zanim cokolwiek zmienisz.

Włącz akceptację tras dla tej maszyny

Ustaw preferencję na kliencie, a potem zobacz, co się zmieniło, zamiast zakładać, że polecenie zadziałało. Obecna forma stosuje ustawienie bez powtarzania przepływu logowania, co ma znaczenie, gdy jesteś w środku sesji.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale instaluje zaakceptowane trasy we własnej tabeli w Linuksie, więc prefiks, który pojawia się w tabeli 52, jest bezpośrednim dowodem, że ten klient zainstalował ogłoszenie. Jeśli twojego zakresu nie ma w tej tabeli, zatrzymaj się: problem jest lokalny i żadna praca na routerze tego nie zmieni.

Starsze klienty udostępniają tę samą preferencję jako flagę polecenia logowania, więc sudo tailscale up --accept-routes jest rozwiązaniem zastępczym, gdy brakuje tailscale set. Użyj go zamiast ręcznej edycji tras, ponieważ demon przepisuje własną tabelę, a twoja zmiana znika przy następnym połączeniu. Sprawdź wersję, zanim skopiujesz polecenie ze starszego wpisu.

Sprawdź ogłoszenie i zatwierdzenie osobno

Na routerze podsieci prefiks musi być ogłoszony, a jądro musi przekazywać pakiety między interfejsami. Ogłaszanie bez przekazywania daje zatwierdzoną trasę, która po cichu odrzuca ruch, i to jest najczęstsza niedokończona konfiguracja.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Porównaj ogłoszony prefiks z adresem, do którego naprawdę próbujesz dotrzeć, znak po znaku. Router ogłaszający 10.70.0.0/24 nic nie mówi o NAS pod 10.80.0.25, a niezgodność jest niewidoczna w każdym wyjściu statusu, bo obie liczby wyglądają równie wiarygodnie. Większość zgłoszeń zepsutej trasy kończy się tutaj. Popraw ogłoszenie, zanim dotkniesz czegokolwiek dalej.

Zatwierdzenie to następna brama i łatwo je pominąć, gdy router konfigurowano z powłoki. Ogłoszenie musi być włączone dla tego urządzenia w konsoli administracyjnej, zanim inne maszyny będą mogły go używać. Akceptowanie tras na kliencie niczego nie zatwierdza i nie omija żadnej reguły dostępu.

Sprawdź adres prywatny przed nazwą hosta

Udane połączenie z własnym adresem tailnet routera dowodzi, że tailnet działa, co już wiedziałeś. Przydatny test to usługa, której naprawdę potrzebujesz, najpierw pod adresem prywatnym, aby awaria DNS nie mogła udawać awarii routingu.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Jeśli adres odpowiada, a nazwa hosta nie, masz problem z rozwiązywaniem nazw i powinieneś przestać traktować go jako problem trasy. Jeśli żadne nie odpowiada, cofnij się o sekcję i potwierdź, że ogłoszenie obejmuje adres. Obie awarie wyglądają z aplikacji identycznie i naprawia się je w różnych miejscach.

Jedna lokalna kontrola jest warta zachodu, zanim obwinisz tailnet. Gdy twoja obecna sieć LAN używa tego samego prefiksu co zdalna podsieć, jądro preferuje trasę bezpośrednio podłączoną i ruch nigdy nie opuszcza maszyny; dzieje się tak, gdy dom i biuro wybierają oba 192.168.1.0/24.

Dlaczego flaga klienta nie jest ustawieniem routera

To różne role o różnych wymaganiach, a kopiowanie flagi klienta na router to sposób, w jaki działający tailnet zyskuje pętlę. Maszyna ogłaszająca trasy potrzebuje przekazywania, reguł zapory pozwalających na przekazywany ruch i decyzji, które prefiksy ogłasza. Nic z tego nie wynika z --accept-routes.

Dokumentacja routerów podsieci ostrzega przed włączaniem akceptacji tras na nadmiarowych routerach ogłaszających jeden prefiks, ponieważ węzeł rezerwowy może wypchnąć ruch, który już jest lokalny, przez aktywny. Jeśli prowadzisz parę HA, traktuj to jako ograniczenie projektowe, a nie przypis, i zdecyduj, który węzeł posiada prefiks, zanim zatwierdzisz go na obu. Na jednym routerze to samo ostrzeżenie czyta się jako przypomnienie, że akceptacja należy do klientów, a nie do maszyny, która ogłasza. Zapisz, która brama była zamknięta.

Dla zwykłego klienta sekwencja kończy się testem aplikacji, który nie powiódł się na początku. Dla routera przejrzyj przekazywanie, ogłoszenie, zatwierdzenie i zaporę w tej kolejności, bo pierwszy brakujący element daje dokładnie to przekroczenie czasu, od którego zacząłeś.

Powiązane artykuły