Co powinieneś sprawdzić, gdy Tailscale nie może połączyć się z Twoim domowym serwerem?

Gdy Tailscale nie może połączyć się z twoim serwerem domowym, awaria nie zawsze leży w samej sieci Tailscale. Serwer może być offline, nazwa urządzenia może się nie rozwiązywać, reguła dostępu może odrzucać połączenie, zapora systemu operacyjnego może blokować usługę lub aplikacja może nasłuchiwać tylko na localhost.

Najszybszym sposobem znalezienia przyczyny jest rozwiązywanie problemów warstwami. Najpierw potwierdź, że oba węzły Tailscale są online. Następnie przetestuj surowy adres IP Tailscale serwera, oddziel podstawową łączność węzła od dostępu do aplikacji i przejdź do routingu podsieci lub rozwiązywania problemów DERP tylko wtedy, gdy objawy na to wskazują.

Zacznij od zidentyfikowania, która warstwa zawodzi

Częstym błędem w rozwiązywaniu problemów jest traktowanie każdego timeoutu jako tego samego problemu. Serwer domowy, który wydaje się offline w tailnecie, różni się od serwera, który odpowiada na ping Tailscale, ale odmawia połączenia SSH lub webowego.

Tailscale zapewnia prywatną ścieżkę sieciową między urządzeniami, ale ostateczna usługa zależy od systemu operacyjnego serwera, zapory, nasłuchującego portu, konfiguracji aplikacji, sieci Docker i polityki dostępu. Naprawa niewłaściwej warstwy może spowodować dodatkowe problemy bez przywrócenia połączenia.

Przed wprowadzeniem zmian zapisz dokładny objaw. Sprawdź, czy serwer jest online, czy jego adres IP Tailscale odpowiada, czy nazwa MagicDNS się rozwiązuje oraz czy konkretny port aplikacji akceptuje połączenie.

Potwierdź, że oba węzły Tailscale są online

Zacznij od dwóch urządzeń biorących udział w połączeniu. Zdalny laptop lub telefon musi być połączony z tailnetem, a serwer domowy musi być również online pod oczekiwanym kontem, tagiem lub tożsamością urządzenia.

Na serwerze Linux sprawdź usługę Tailscale i uruchom tailscale statusNa systemach stacjonarnych sprawdź, czy klient jest połączony, a nie wstrzymany, wylogowany lub oczekujący na uwierzytelnienie. Serwer, który nie uruchomił Tailscale po restarcie, nie zostanie naprawiony przez zmianę DNS lub portów aplikacji.

Sprawdź także, czy serwer pojawia się pod oczekiwaną nazwą urządzenia i adresem IP Tailscale. Jeśli węzeł jest offline, napraw usługę, stan logowania, zachowanie podczas uruchamiania systemu lub wersję klienta, zanim zaczniesz diagnozować cokolwiek powyżej warstwy sieciowej.

Użyj surowego adresu IP Tailscale przed testowaniem nazwy hosta

Nazwa hosta dodaje rozwiązywanie DNS do ścieżki połączenia. Jeśli zaczynasz od nazwy serwera takiej jak homeserver lub nas-device, nie możesz od razu stwierdzić, czy awaria wynika z sieci czy rozwiązywania nazw.

Znajdź adres IPv4 Tailscale serwera, zwykle w zakresie 100.x.x.x, i spróbuj tego adresu bezpośrednio. Gdy trasy LAN, węzły wyjściowe lub nakładające się podsieci komplikują ścieżkę, szczególnie przydatne jest przetestowanie adresu IP Tailscale urządzenia przed jego prywatnym adresem LAN.

Jeśli surowy adres IP działa, ale nazwa hosta nie, podstawowa łączność węzła jest prawdopodobnie zdrowa. Przejdź do ustawień MagicDNS i DNS klienta zamiast reinstalować Tailscale lub zmieniać router.

Jeśli IP działa, ale nazwa zawodzi, sprawdź MagicDNS

MagicDNS pozwala urządzeniom używać czytelnych nazw maszyn zamiast zapamiętywania adresów IP Tailscale. Gdy działa, urządzenie o nazwie home-server można osiągnąć pod tą nazwą z innego urządzenia w tym samym tailnecie.

Funkcja tworzy automatyczne nazwy urządzeń w tailnecie, ale pomyślne rozwiązywanie nazw nadal zależy od połączenia urządzenia i akceptacji konfiguracji DNS tailnetu przez klienta. Lokalne filtry DNS, narzędzia bezpieczeństwa korporacyjnego, niestandardowe resolvery lub przestarzałe rekordy w pamięci podręcznej mogą przeszkadzać.

Porównaj krótą nazwę hosta, pełną nazwę tailnetu i surowy adres IP Tailscale. Jeśli tylko nazwy zawodzą, sprawdź, czy MagicDNS jest włączony, czy maszyna została przemianowana oraz czy inny produkt DNS nie nadpisuje konfiguracji resolvera.

Oddziel łączność Tailscale od łączności aplikacji

Udane połączenie węzeł-do-węzła nie dowodzi, że każda usługa na serwerze jest dostępna. Możesz być w stanie pingować adres Tailscale, podczas gdy SSH, Jellyfin, panel sterowania, SMB lub interfejs webowy Dockera nadal przekraczają limit czasu.

Zazwyczaj oznacza to, że ścieżka Tailscale istnieje, ale warstwa aplikacji odmawia lub nie nawiązuje połączenia. Usługa może być zatrzymana, nasłuchiwać na innym porcie, być powiązana z niewłaściwym interfejsem, zablokowana przez zaporę serwera lub nieopublikowana z kontenera.

Przetestuj dokładny cel, którego potrzebujesz, na przykład 100.x.x.x:22 dla SSH lub http://100.x.x.x:8080 dla usługi internetowej. Jeśli węzeł odpowiada, ale port nie, przestań diagnozować MagicDNS i DERP, dopóki nie zostanie zweryfikowana usługa po stronie serwera.

Sprawdź, czy usługa nasłuchuje na właściwym interfejsie.

Aplikacja może działać normalnie na serwerze domowym, a mimo to być niedostępna z innych urządzeń. Dzieje się tak, gdy usługa nasłuchuje tylko na 127.0.0.1, która akceptuje połączenia z samego serwera, ale nie przez interfejsy LAN lub Tailscale.

Usługa nasłuchująca na 0.0.0.0 akceptującą ruch IPv4 na wszystkich dostępnych interfejsach, podczas gdy usługa może być również przypisana wyraźnie do adresu LAN serwera lub adresu Tailscale. Właściwy wybór zależy od tego, czy usługa powinna być dostępna z LAN, tailnetu, czy tylko przez lokalny reverse proxy.

Nie zmieniaj automatycznie każdej usługi na 0.0.0.0. Najpierw potwierdź zamierzoną ścieżkę dostępu, a następnie użyj reguł zapory i uwierzytelniania aplikacji, aby ograniczyć, kto może dotrzeć do portu.

Zapora serwera może blokować ruch Tailscale.

Usługa może działać przez adres LAN serwera, ale nie działać przez adres Tailscale, ponieważ system operacyjny traktuje interfejs Tailscale jako osobną ścieżkę sieciową. Reguły LAN nie zawsze mają zastosowanie do ruchu przychodzącego przez tailscale0.

Systemy Linux mogą używać UFW, firewalld, iptables lub nftables. Windows może klasyfikować adapter Tailscale inaczej niż domową sieć LAN. Szersze zapory sieciowe mogą również blokować bezpośrednie połączenia UDP i wymuszać ruch przez ścieżki retransmisji. Istotne jest, czy zapora pozwala na zamierzony sposób połączenia Tailscale.

Nie wyłączaj całkowicie zapory jako stałego rozwiązania. Zezwól tylko na wymagany port usługi z interfejsu Tailscale, wybranych adresów Tailscale lub odpowiedniej polityki tailnet. Następnie przetestuj aplikację bezpośrednio.

Sprawdź Polityki Dostępu, Uprawnienia, Tagi i Tożsamość Urządzenia.

Jeśli jedno urządzenie Tailscale może połączyć się z serwerem domowym, a inne nie, różnica może wynikać z celowej polityki, a nie awarii sieci. Dostęp może zależeć od użytkownika, urządzenia źródłowego, tagu celu, protokołu i portu.

Serwer oznaczony tagiem dostępu do infrastruktury może nie akceptować ruchu z urządzenia osobistego, chyba że polityka na to pozwala. Reguła zezwalająca na SSH niekoniecznie pozwala na dostęp do panelu webowego na innym porcie, a urządzenie współdzielone może mieć inne uprawnienia niż urządzenie należące do tego samego użytkownika.

Przejrzyj razem tożsamość źródła, tożsamość celu, tagi serwera oraz żądany port. Tymczasowa szeroka reguła może pomóc w izolacji problemu z polityką, ale po testach zastąp ją najwęższą poprawną regułą.

Bezpośredni serwer domowy nie potrzebuje routera podsieci.

Jeśli Tailscale jest zainstalowany bezpośrednio na serwerze domowym, użyj własnego adresu IP Tailscale serwera lub nazwy MagicDNS. Do dotarcia do tej maszyny nie jest wymagany router podsieci.

Routery podsieci rozwiązują inny problem: zapewniają dostęp do urządzeń, które same nie uruchamiają Tailscale, takich jak drukarka, kamera, starszy NAS, urządzenie smart home lub inna maszyna w domowej sieci LAN.

Dodanie routingu podsieci do prostego problemu z bezpośrednim węzłem tworzy więcej miejsc, gdzie połączenie może zawieść. Najpierw udowodnij, że klient Tailscale na domowym serwerze jest osiągalny. Problemy z ogłoszonymi trasami LAN diagnozuj tylko wtedy, gdy faktyczny cel znajduje się za tym serwerem.

Routing podsieci wymaga kompletnego łańcucha routingu

Gdy celem jest urządzenie LAN bez Tailscale, router podsieci musi zrobić więcej niż tylko być online. Musi odbierać ruch z tailnet, przekazywać go do domowej sieci LAN i pozwolić na powrót odpowiedzi.

Działająca konfiguracja zwykle wymaga włączenia przekazywania IP na urządzeniu routującym, ogłoszonych tras podsieci, zatwierdzenia tras, dopasowanych kontroli dostępu oraz akceptacji tras po stronie klienta, jeśli jest to wymagane. Celem jest ogłoszenie prywatnej podsieci przez bramę, aby urządzenia w tailnet mogły dotrzeć do maszyn, które nie uruchamiają klienta.

Jeśli trasa jest widoczna, ale ruch nie działa, sprawdź każdy etap osobno. Potwierdź, że poprawna podsieć została ogłoszona, zweryfikuj jej zatwierdzenie, sprawdź zaporę przekierowującą i upewnij się, że urządzenie LAN ma ważną ścieżkę powrotną.

Nakładające się prywatne podsieci mogą kierować ruch w niewłaściwą stronę

Wiele sieci domowych, biurowych i hotelowych ponownie używa adresów takich jak 192.168.1.0/24. Jeśli Twój obecny Wi-Fi i domowa podsieć korzystają z tego samego zakresu, system operacyjny może traktować cel jako lokalny zamiast wysyłać go przez Tailscale.

To powoduje mylący objaw: bezpośredni adres IP Tailscale serwera działa, ale jego adres IP w domowej sieci LAN nie. Żądanie może trafiać do bieżącej sieci zamiast do zdalnego routera podsieci.

Używaj adresu IP Tailscale celu, gdy to możliwe. Jeśli konieczny jest dostęp do podsieci, rozważ zmianę jednej sieci LAN na mniej popularny zakres prywatny lub zastosowanie projektu routingu, który świadomie obsługuje nakładające się sieci.

Węzeł Wyjściowy Może Zmienić Dostęp Do Obecnej Sieci LAN

Jeśli urządzenie klienckie korzysta z węzła wyjściowego Tailscale, jego wybór tras różni się od normalnego połączenia tailnet. Dostęp do pobliskich urządzeń LAN może być zablokowany, chyba że wyraźnie zezwolono na dostęp do sieci lokalnej.

Ma to znaczenie podczas rozwiązywania problemów z laptopa podłączonego do hotelowego, biurowego lub domowego Wi-Fi, jednocześnie korzystającego z węzła wyjściowego. Brak dostępu do prywatnego adresu LAN może wynikać z zachowania węzła wyjściowego, a nie serwera domowego.

Testuj bez węzła wyjściowego lub włącz dostęp LAN tylko wtedy, gdy ufasz lokalnej sieci. Nie włączaj szerokiego dostępu lokalnego automatycznie w nieznanych publicznych sieciach Wi-Fi.

Docker Dodaje Kolejną Granicę Portu i Interfejsu

Usługa hosta, taka jak SSH, może działać przez Tailscale, podczas gdy aplikacja Docker na tym samym serwerze zawodzi. Zazwyczaj wskazuje to na problem z siecią kontenera, a nie z łącznością węzła.

Sprawdź, czy kontener działa, czy aplikacja nasłuchuje wewnątrz kontenera oraz czy jej port jest opublikowany na hoście. Mapowanie Compose takie jak 8080:80 udostępnia port kontenera 80 przez port hosta 8080, podczas gdy port powiązany tylko z 127.0.0.1 może pozostać niedostępny przez adres IP Tailscale.

Sprawdź także trasy reverse-proxy, sieć hosta, zasady zapory Dockera oraz czy sama aplikacja zezwala na połączenia spoza sieci LAN. Przetestuj port hosta bezpośrednio przed debugowaniem domen wyższego poziomu lub certyfikatów.

DERP Zazwyczaj Wyjaśnia Wolne Działanie Bardziej Niż Całkowitą Awarię

Tailscale próbuje tworzyć bezpośrednie połączenia między urządzeniami. Gdy zachowanie NAT lub ograniczenia zapory to uniemożliwiają, może użyć ścieżki przekaźnika.

DERP zapewnia zaszyfrowany fallback przekaźnika, gdy bezpośrednia łączność zawiedzie. Przekaźnik przesyła już zaszyfrowany ruch i może łączyć urządzenia przez trudne kombinacje IPv4, IPv6, NAT i zapór.

Ścieżka DERP często działa z większym opóźnieniem lub mniejszą przepustowością, więc jest silnym podejrzanym, gdy SSH działa opornie lub transfery plików są wolne. Jeśli połączenie w ogóle nie działa, najpierw sprawdź status węzła, politykę dostępu, lokalną zaporę, port aplikacji i adres powiązania.

Użyj diagnostyki połączenia przed zmianą routera

Polecenia takie jak tailscale ping pomaga oddzielić ścieżkę węzła od ścieżki aplikacji. Udany wynik jest bardziej wartościowy niż nieudana karta przeglądarki, ponieważ testuje łączność bez polegania na porcie aplikacji, proxy czy certyfikacie.

tailscale netcheck może pomóc pokazać dostępność UDP, zachowanie NAT, łączność IPv4 lub IPv6 oraz pobliskie regiony przekaźników. Wyniki te są najbardziej przydatne, gdy połączenie działa tylko przez przekaźnik lub zmienia się między sieciami.

Nie zaczynaj od dodawania publicznego przekierowania portów na routerze domowym. Tailscale jest zaprojektowany do działania bez bezpośredniego wystawiania portów aplikacji serwera domowego w internecie. Zmiany w routerze powinny odpowiadać potwierdzonemu problemowi ze ścieżką, a nie zastępować wcześniejsze kroki diagnostyczne.

Restartuj i aktualizuj dopiero po zidentyfikowaniu warstwy, która zawodzi

Restart Tailscale może przywrócić działanie uszkodzonego demona lub przestarzały stan klienta, ale powtarzające się restarty nie są diagnozą. Jeśli ten sam błąd pojawia się po każdym restarcie, prawdopodobną przyczyną są ustawienia startowe, polityka zapory, routing lub powiązanie aplikacji.

Potwierdź, że serwer domowy uruchamia Tailscale bez interaktywnego logowania do pulpitu i pozostaje połączony po restarcie. Porównaj też wersje klientów, jeśli jedno urządzenie zachowuje się inaczej niż reszta tailnetu.

Po aktualizacji lub restarcie powtórz te same testy w tej samej kolejności: status węzła, surowy IP, nazwa hosta, ping Tailscale i port aplikacji. Spójna sekwencja testów pokazuje, która warstwa faktycznie się zmieniła.

Postępuj według jednego porządku rozwiązywania problemów

Najszybsza ścieżka to przejście od węzła Tailscale do aplikacji. Nie modyfikuj jednocześnie DNS, tras podsieci, reguł zapory i sieci Docker.

Najpierw potwierdź, że oba węzły są online. Następnie przetestuj surowy adres IP Tailscale, a potem nazwę MagicDNS. Przetestuj ścieżkę węzła, a potem port aplikacji. Dopiero po tych sprawdzeniach zbadaj zaporę serwera, adres powiązania, politykę dostępu, mapowanie Dockera lub routing podsieci.

Ten porządek zapobiega przekształceniu prostego zatrzymania usługi w skomplikowany projekt routingu. Każdy test powinien odpowiedzieć na jedno pytanie, zanim przejdziesz do kolejnej warstwy.

Ostateczne wnioski

Gdy Tailscale nie może połączyć się z Twoim serwerem domowym, zacznij od najprostszej różnicy: czy oba węzły Tailscale mogą się komunikować i czy aplikacja akceptuje ruch? Potwierdź, że oba węzły są online, przetestuj surowy adres IP Tailscale, a następnie nazwę MagicDNS i dokładny port usługi.

Jeśli ścieżka węzła działa, ale aplikacja nie, skup się na zaporze serwera, interfejsie nasłuchującym, ustawieniach aplikacji, mapowaniu portów Docker i polityce dostępu. Jeśli cel nie uruchamia Tailscale, przejdź do konfiguracji routera podsieci, zatwierdzania tras, przekazywania IP i sprawdzania nakładających się podsieci.

Ścieżki przekaźnika DERP zwykle tłumaczą wolniejszą wydajność, a nie całkowitą awarię. Spójne testy warstwa po warstwie są skuteczniejsze niż ponowna instalacja Tailscale, wyłączanie zapory czy dodawanie publicznego przekierowania portów bez wiedzy, gdzie połączenie się zatrzymuje.

FAQ

Dlaczego mogę pingować mój serwer Tailscale, ale nie mogę otworzyć jego interfejsu webowego?

Połączenie między węzłami działa, ale usługa webowa może być zatrzymana, nasłuchiwać na innym porcie, być powiązana tylko z localhost, zablokowana przez zaporę serwera lub nieopublikowana z kontenera Docker.

Dlaczego adres IP Tailscale działa, a nazwa serwera nie?

To wskazuje na problem z MagicDNS lub inną konfiguracją DNS. Sprawdź, czy MagicDNS jest włączony, czy nazwa maszyny się zmieniła oraz czy inny resolver DNS nie nadpisuje ustawień Tailscale.

Czy potrzebuję routera podsieci, aby uzyskać dostęp do mojego serwera domowego?

Nie, jeśli Tailscale jest zainstalowany bezpośrednio na tym serwerze. Użyj jego adresu IP Tailscale lub nazwy MagicDNS. Router podsieci jest potrzebny do dostępu do innych urządzeń LAN, które nie uruchamiają Tailscale.

Czy zapora może blokować Tailscale, nawet gdy węzeł jest online?

Tak. Klient Tailscale może połączyć się z tailnetem, podczas gdy zapora systemu operacyjnego nadal blokuje port SSH, web, SMB lub innej aplikacji przychodzący przez interfejs Tailscale.

Czy połączenie DERP oznacza, że Tailscale jest uszkodzony?

Nie. DERP to zaszyfrowany mechanizm awaryjny, gdy nie można nawiązać bezpośredniego połączenia. Może powodować opóźnienia lub zmniejszać przepustowość, ale nadal zapewnia łączność między urządzeniami.

Dlaczego mogę połączyć się z serwerem, ale nie z innym urządzeniem w mojej sieci domowej?

Serwer jest bezpośrednim węzłem Tailscale, podczas gdy inne urządzenie wymaga routera podsieci. Sprawdź przekazywanie IP, reklamowane trasy, zatwierdzenie tras, reguły dostępu oraz ścieżkę powrotną urządzenia LAN.

Czy nakładające się podsieci domowe i zdalne mogą przerwać dostęp do Tailscale?

Tak. Jeśli oba miejsca korzystają z tej samej prywatnej podsieci, klient może wysyłać ruch do swojej obecnej sieci LAN zamiast do trasy zdalnej podsieci. Preferuj adres IP Tailscale celu lub zmień zakres adresów jednej z sieci.

Czy powinienem otworzyć porty na routerze, aby naprawić Tailscale?

Zazwyczaj nie. Najpierw potwierdź status węzła, zachowanie zapory sieciowej, powiązanie aplikacji, politykę dostępu oraz czy połączenie jest bezpośrednie, czy przekazywane. Publiczne przekierowanie portu aplikacji nie zastępuje znalezienia rzeczywistej przyczyny awarii Tailscale.