Kontener Tailscale może być oznaczony jako połączony, a mimo to nie działać jako router podsieci. W tym wątku ZimaOS z kwietnia 2026 roku Tailscale działał w Dockerze z siecią hosta, trybem uprzywilejowanym oraz /dev/net/tun zamontowane, jednak konsola administracyjna Tailscale informowała, że maszyna nie udostępnia żadnych tras. Navidrome działał w sieci lokalnej, ale nie można było uzyskać do niego zdalnego dostępu przez tailnet.
Wątek nie zakończył się potwierdzonym rozwiązaniem przedstawionym przez autora oryginalnego wpisu. Zamiast tego inny członek społeczności udostępnił działającą konfigurację kontenera Tailscale BigBear, która skutecznie reklamowała podsieć LAN w jego własnym środowisku ZimaOS. Konfiguracja ta jest przydatnym punktem odniesienia podczas rozwiązywania problemów, ale nie stanowi gwarancji wsparcia IceWhale dla każdego pakietu aplikacji Tailscale.
Połączenie z Tailscale nie oznacza reklamowania tras podsieci
Pierwotna konfiguracja miała już ukończone uwierzytelnianie urządzenia. Problem dotyczył konkretnie routingu: logi pokazywały pustą listę tras, a konsola administracyjna Tailscale nie oferowała trasy podsieci do zatwierdzenia.
To rozróżnienie ma znaczenie, ponieważ zwykły węzeł Tailscale dołącza tylko do tailnetu. Router podsieci ma dodatkowe zadania: musi reklamować co najmniej jeden prefiks LAN i spełniać wymagania systemu operacyjnego dotyczące routingu, niezbędne do przekazywania ruchu między tailnetem a tą siecią LAN.
Aktualna dokumentacja Tailscale opisuje routery podsieci jako bramy reklamujące prywatne sieci urządzeniom tailnetu. Wymaga także włączenia przekazywania adresów IP w systemie Linux oraz zatwierdzenia trasy w konsoli administracyjnej Tailscale, chyba że autoApprovers zasady automatycznie obsługują zatwierdzanie.
dokumentacja routera podsieci Tailscale
Działająca konfiguracja społeczności korzystała z TS_ROUTES
Odpowiedź użytkownika TomasSzwed wykorzystywała kontener Tailscale BigBear i konfigurowała podsieć za pomocą zmiennych środowiskowych, zamiast polegać na ręcznym, jednorazowym poleceniu po uruchomieniu. Najważniejsze elementy tej konfiguracji obejmowały:
-
network_mode: host; - tryb uprzywilejowany;
-
/dev/net/tunzamontowane w kontenerze; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24dla reklamowanej sieci LAN; -
TS_EXTRA_ARGS=--accept-routesw konfiguracji tego użytkownika; - trwały stan Tailscale w
/var/lib/tailscale.
Użyj prawidłowego prefiksu LAN dla swojej sieci
Działający przykład reklamowanej podsieci 192.168.2.0/24. Ta wartość ma sens tylko w sieci LAN korzystającej z tej podsieci. Inna sieć domowa może używać 192.168.1.0/24, 10.0.0.0/24lub innego prywatnego prefiksu
Reklamowanie niewłaściwej podsieci może spowodować, że węzeł Tailscale będzie działać prawidłowo, ale nadal nie będzie kierować ruchu do zamierzonych usług ZimaOS. Przed skonfigurowaniem TS_ROUTES lub równoważny --advertise-routes opcja.
Zareklamowane trasy nadal muszą zostać aktywowane
Obecne zalecenia Tailscale rozdzielają reklamowanie tras od ich zatwierdzania. Gdy router podsieci zareklamuje trasę, należy ją włączyć w konsoli administracyjnej Tailscale, chyba że zasady tailnetu zatwierdzają ją automatycznie.
Jeśli konsola administracyjna informuje, że maszyna nie udostępnia żadnych tras, najpierw skup się na konfiguracji reklamowania tras w kontenerze. Jeśli trasa się pojawia, ale ruch nadal nie działa, sprawdź zatwierdzenie trasy, zasady kontroli dostępu, przekazywanie pakietów oraz samą usługę docelową.
Sieci Dockera wpływają na to, jakie trasy może obsługiwać kontener
Autor oryginalnego posta używał sieci hosta i montował urządzenie TUN. Przykład społeczności korzystał z tego samego rozwiązania. Aktualna dokumentacja Tailscale również opisuje uruchamianie Tailscale w Dockerze, ale sieci Dockera i routing Tailscale to oddzielne warstwy, które obie muszą być poprawnie skonfigurowane.
Dokumentacja Tailscale dotycząca Dockera
Nie zakładaj, że dwie aplikacje Tailscale w sklepie aplikacji ZimaOS korzystają z identycznych definicji kontenerów. Autor oryginalnego posta zauważył konkretnie, że udostępniony przykład używał pakietu Tailscale od BigBear, podczas gdy jego istniejąca instalacja korzystała z innej pozycji Tailscale.
Co to oznacza dla Navidrome i innych usług lokalnych
Celem wątku źródłowego był dostęp do Navidrome z iPhone'a bez przekierowywania portów publicznych. Jeśli Navidrome jest już dostępny w lokalnej sieci LAN, działający router podsieci może sprawić, że ten adres LAN będzie osiągalny z autoryzowanych urządzeń tailnetu.
Jednak wątek nie potwierdza, że autor oryginalnego posta zakończył przełączanie na konfigurację BigBear ani że później pomyślnie uzyskał dostęp do Navidrome. Strona dokumentuje więc działający przykład społeczności i model diagnostyczny, a nie potwierdzone rozwiązanie dla tej konkretnej instalacji.
Często zadawane pytania dotyczące routingu podsieci Tailscale w ZimaOS
Dlaczego Tailscale pokazuje połączenie, ale nie wyświetla żadnych tras podsieci?
Dołączenie do tailnetu i reklamowanie trasy LAN to dwie różne operacje. W opisywanym przypadku uwierzytelnianie zakończyło się powodzeniem, ale lista tras pozostała pusta.
Czy Tailscale uruchomiony w Dockerze może działać jako router podsieci w ZimaOS?
Członek społeczności zgłosił, że zadziałało to w jego konfiguracji ZimaOS, i udostępnił konfigurację Tailscale od BigBear. Sam Tailscale również obsługuje routing podsieci i wdrożenia Dockera, ale dokładna konfiguracja aplikacji w ZimaOS nadal ma znaczenie.
Czy muszę zatwierdzić trasę w Tailscale?
Zgodnie z obecnym działaniem Tailscale reklamowane trasy podsieci zwykle wymagają zatwierdzenia w konsoli administracyjnej, chyba że autoApprovers zasady obsługują je automatycznie.
Czy mam skopiować ze zrzutu ekranu wartość 192.168.2.0/24?
Nie. Użyj rzeczywistej podsieci sieci LAN, którą chcesz udostępnić. Wartość na zrzucie ekranu należy do sieci innego członka społeczności.
