Źródło problemu jest wyjątkowo jasne: nie była to awaria Dockera wpływająca na każdą aplikację. Użytkownik skonfigurował Tailscale z użyciem węzła wyjściowego, po czym Jellyfin i adresy URL innych aplikacji przestały działać nawet w sieci lokalnej. Później odinstalował Tailscale, połączył się za pośrednictwem adresu IP ZimaOS w sieci LAN i zgłosił, że wszystko znów działa.
To zachowanie odpowiada aktualnej dokumentacji Tailscale. Gdy klient korzysta z węzła wyjściowego, dostęp do lokalnej sieci LAN jest domyślnie wyłączony, chyba że włączona jest opcja Zezwalaj na dostęp do sieci lokalnej. Przed ponowną instalacją aplikacji lub ponownym uruchomieniem Dockera sprawdź tablicę routingu oraz to, czy klient celowo przesyła ruch przez węzeł wyjściowy.
Bezpośrednie porty aplikacji również nie działały
Użytkownik próbował otwierać porty aplikacji bezpośrednio i stwierdził, że żaden nie działał poza Tailscale. To cenna wskazówka: gdy wiele niezależnych kontenerów nagle staje się niedostępnych, najpierw sprawdź wspólne warstwy sieciowe i routing, zanim założysz, że każda aplikacja zepsuła się niezależnie.
Nieudane polecenie ponownego uruchomienia Dockera odwróciło uwagę od problemu
ZimaOS nie jest typowym systemem Debian, w którym każde polecenie zarządzania usługami znalezione w internetowych poradnikach będzie działać. Jeśli wszystkie aplikacje przestają działać, najpierw sprawdź, czy kontenery rzeczywiście są uruchomione oraz czy ich opublikowane porty są dostępne z hosta lub sieci LAN.
Węzły wyjściowe zmieniają domyślną trasę klienta
Węzły wyjściowe Tailscale kierują ogólny ruch internetowy przez inne urządzenie w tailnecie. Aktualna dokumentacja Tailscale wyraźnie informuje, że podczas korzystania z węzła wyjściowego dostęp do sieci lokalnej jest domyślnie wyłączony.
Zobacz aktualne zasady działania węzłów wyjściowych Tailscale.
Włącz opcję Zezwalaj na dostęp do sieci lokalnej, gdy celowo potrzebujesz obu rodzajów dostępu
Aktualne klienty Tailscale udostępniają opcję Zezwalaj na dostęp do sieci lokalnej. W klientach opartych na wierszu poleceń odpowiednik tej opcji można skonfigurować za pomocą flagi zezwalającej na dostęp do sieci LAN przez węzeł wyjściowy.
Włączaj ją tylko wtedy, gdy sieć lokalna jest zaufana.
Wyłącz węzeł wyjściowy, aby odizolować problem
Szybką metodą diagnostyczną jest wybranie opcji Brak jako aktywnego węzła wyjściowego, a następnie ponowne sprawdzenie adresu IP ZimaOS w sieci LAN oraz portu jednej aplikacji. Jeśli dostęp lokalny natychmiast powróci, routing — a nie Docker — jest właściwym miejscem do dalszego badania.
Autor pierwotnego zgłoszenia usunął Tailscale i potwierdził przywrócenie działania
Użytkownik poinformował, że komputer tracił połączenie z routerem i ścieżką opartą na lokalnym adresie IP po połączeniu za pośrednictwem jego konfiguracji Tailscale. Po odinstalowaniu Tailscale i użyciu lokalnego adresu IP wszystkie aplikacje znów działały.
To potwierdzone przez źródło przywrócenie działania, choć użytkownik nie udokumentował dokładnych flag węzła wyjściowego, które spowodowały nieprawidłowe zachowanie.
Lepsza kolejność diagnozowania problemu
- otwórz bezpośrednio pulpit ZimaOS, korzystając z adresu IP w sieci LAN;
- sprawdź, czy jeden z portów aplikacji działa lokalnie;
- wyłącz aktywny węzeł wyjściowy Tailscale;
- ponownie spróbuj uzyskać dostęp do lokalnej aplikacji;
- dopiero wtedy przeanalizuj logi Dockera lub aplikacji, jeśli porty nadal będą niedostępne.
FAQ: komunikat Service Unavailable we wszystkich aplikacjach
Czy ponowna instalacja aplikacji rozwiązała pierwotny problem?
Nie. Aplikacje zaczęły działać dopiero po usunięciu problematycznego stanu routingu Tailscale.
Czy węzeł wyjściowy Tailscale może blokować dostęp do lokalnej sieci LAN?
Tak. Aktualna dokumentacja Tailscale informuje, że podczas korzystania z węzła wyjściowego dostęp do sieci LAN jest domyślnie wyłączony, chyba że użytkownik włączy dostęp do sieci lokalnej.
Czy potwierdzono, że sam Docker był uszkodzony?
Nie. Źródło problemu wskazuje na routing, a nie awarię demona Dockera.
