Użytkownik ZimaOS uznał, że Tailscale uległ awarii po pierwszym uruchomieniu, ponieważ strona aplikacji wyświetlała komunikat „usługa niedostępna”, a telefon nie mógł uzyskać dostępu do usług domowego serwera. Diagnostyka kontenera wykazała inny stan: Tailscale działał, urządzenie było autoryzowane, a punkty montowania stanu i tunelu były obecne.
Potwierdzonym problemem był adres używany w telefonie. Użytkownik próbował uzyskać dostęp do zwykłego adresu domowej sieci LAN bez skonfigurowania routowania podsieci. Połączenie z usługą za pośrednictwem adresu Tailscale urządzenia ZimaOS 100.x.x.x adres działał.
Kontener Tailscale nie uległ awarii
Początkowy objaw sugerował, że kontener zatrzymał się po ponownym uruchomieniu, ale zebrany stan pokazał:
- Stan kontenera wskazywał na działanie, a kod wyjścia wynosił 0.
- Tailscale przeszedł ze stanu Starting do Running.
- Maszyna została autoryzowana w tailnecie użytkownika.
- Trwały katalog stanu został zamapowany do kontenera.
- Urządzenie TUN wymagane przez Tailscale również zostało zamapowane.
- Urządzenie otrzymało adres IPv4 Tailscale i mogło wykrywać inne węzły.
Dowody te oddzieliły komunikat strony aplikacji ZimaOS lub interfejsu internetowego od stanu usługi Tailscale.
Dlaczego pierwsze próby diagnostyczne wykazały odmowę dostępu
Sesja terminala korzystała ze zwykłego użytkownika ZimaOS. Pierwsza lista Dockera została uruchomiona z podwyższonymi uprawnieniami, ale późniejsze polecenia próbowały uzyskać dostęp do gniazda Dockera bez tych uprawnień i dlatego zwróciły błędy odmowy dostępu. Zakrzywione cudzysłowy skopiowane z forum również uniemożliwiły prawidłową interpretację niektórych podstawień poleceń.
Te komunikaty o uprawnieniach opisywały sesję diagnostyczną, a nie awarię Tailscale podczas działania. Późniejsze dane wyjściowe uzyskane z odpowiednimi uprawnieniami pokazały, że kontener działał prawidłowo.
Adres domowej sieci LAN nie jest automatycznie adresem Tailscale
Adres taki jak 10.0.0.93 należy do domowej sieci LAN. Telefon połączony zdalnie z tym samym tailnetem nie uzyskuje automatycznie trasy do każdego prywatnego adresu LAN.
Tailscale przypisuje każdemu węzłowi własny adres, zazwyczaj z zakresu 100.x.x.x. Oficjalna dokumentacja adresów IP Tailscale wyjaśnia, że adresy te identyfikują urządzenia wewnątrz tailnetu i pozostają oddzielone od zwykłej adresacji LAN.
Metoda połączenia, która zadziałała
Osoba odpowiadająca poprosiła użytkownika o połączenie z aplikacją za pomocą adresu IP Tailscale węzła ZimaOS i własnego portu aplikacji:
http://TAILSCALE-IP:APP-PORT
Na przykład usługa działająca na porcie 8096 użyłby adresu URL w formacie:
http://100.x.x.x:8096
Telefon również musi być zalogowany do tego samego tailnetu i aktywnie połączony z Tailscale. Użytkownik potwierdził, że ten adres działał, co potwierdziło prawidłowe działanie samego Tailscale.
Gdy wymagane jest routowanie podsieci
Jeśli celem jest uzyskanie dostępu do urządzeń za pośrednictwem ich istniejących adresów LAN, na przykład 10.0.0.x—urządzenie w tej sieci musi rozgłaszać podsieć LAN jako trasę, a trasa musi zostać zatwierdzona zgodnie z konfiguracją sieci tailnet.
To inna konfiguracja niż bezpośredni dostęp do hosta ZimaOS przez jego własny adres IP Tailscale. Zanim zaczniesz oczekiwać, że zwykłe adresy LAN będą działać zdalnie, zapoznaj się z oficjalną dokumentacją routerów podsieci Tailscale.
Dlaczego strona aplikacji nadal mogła wyświetlać komunikat „Usługa niedostępna”
Sprawdzanie dostępności interfejsu webowego może zakończyć się niepowodzeniem, nawet gdy demon sieciowy działa. W omawianym przypadku decydującymi dowodami były stan działania, pomyślna autoryzacja w sieci tailnet, przypisany adres IP Tailscale, widoczne urządzenia równorzędne oraz działające zdalne połączenie z usługą.
Zmiana przypadkowych portów aplikacji, usunięcie stanu Tailscale lub wielokrotne ponowne instalowanie kontenera nie rozwiązałyby problemu nieprawidłowego adresu docelowego. Przed zresetowaniem działającej tożsamości sprawdź stan demona i sposób nawiązywania połączenia.
Dlaczego działające połączenie może wydawać się wolne
W końcowej odpowiedzi zasugerowano, że połączenie może korzystać z przekaźnika DERP zamiast bezpośredniej ścieżki peer-to-peer. Przekazywany przez DERP ruch Tailscale może działać prawidłowo, zapewniając jednak mniejszą przepustowość lub większe opóźnienia, zależnie od sieci, routerów i dostępnego regionu przekaźnika.
Sama niska szybkość nie dowodzi, że kontener nie działa. Najpierw potwierdź, czy połączenie działa i czy Tailscale zgłasza ścieżkę bezpośrednią czy przekazywaną, a następnie zbadaj działanie NAT-u i zapory sieciowej, jeśli wydajność ma znaczenie.
Bezpieczniejsza kolejność diagnostyki
- Sprawdź, czy kontener Tailscale działa, zamiast polegać wyłącznie na statusie wyświetlanym na stronie aplikacji.
- Potwierdź, że węzeł ZimaOS jest widoczny jako autoryzowany i aktywny w tej samej sieci tailnet co telefon.
- Ustal adres Tailscale węzła ZimaOS
100.x.x.xadresu za pośrednictwem interfejsu Tailscale lub konsoli administracyjnej. - Połącz się z docelową usługą, używając tego adresu Tailscale i portu usługi.
- Routing podsieci konfiguruj tylko wtedy, gdy wymagany jest dostęp za pośrednictwem zwykłych adresów domowej sieci LAN.
- Jeśli połączenie działa, ale jest wolne, osobno sprawdź użycie przekaźnika DERP.
FAQ dotyczące połączenia Tailscale w ZimaOS
Czy komunikat „usługa niedostępna” oznacza, że Tailscale przestał działać?
Nie. W tym przypadku kontener działał, był autoryzowany i połączony, mimo że strona aplikacji wyświetlała ten komunikat.
Dlaczego zmiana portu aplikacji Tailscale nie pomogła?
Problemem był adres docelowy, a nie zwykły konflikt portu aplikacji webowej. Użytkownik potrzebował adresu IP Tailscale węzła.
Jakiego adresu powinien użyć zdalny telefon?
Użyj Tailscale węzła ZimaOS 100.x.x.x adresu oraz portu aplikacji, chyba że dla adresów LAN skonfigurowano router podsieci.
Dlaczego adres 10.0.0.x nie działa przez Tailscale?
To prywatny adres domowej sieci LAN. Zdalny dostęp do tej podsieci wymaga rozgłoszonej i zatwierdzonej trasy podsieci.
Dlaczego działające połączenie Tailscale może działać wolno?
Połączenie może być przekazywane przez DERP zamiast korzystać z bezpośredniej ścieżki peer-to-peer.
