Jak uruchomić Tailscale w systemie ZimaOS, aby uzyskać zdalny dostęp

Jeśli aplikacja Tailscale zainstaluje się w ZimaOS, ale kliknięcie jej WebUI po prostu przenosi z powrotem do pulpitu ZimaOS, nie musi to oznaczać, że kontener Tailscale jest uszkodzony. Wątek społeczności z listopada 2024 roku rozpoczął się dokładnie od tego objawu w ZimaOS 1.2.5. Przydatne wyjaśnienie było takie, że Tailscale konfiguruje się głównie za pomocą uwierzytelniania, zmiennych środowiskowych i interfejsu wiersza poleceń Tailscale, a nie za pośrednictwem konwencjonalnego interfejsu WebUI.

Pierwotna odpowiedź zalecała użycie pakietu ze sklepu aplikacji i podanie klucza uwierzytelniania Tailscale za pośrednictwem TS_AUTHKEY. Późniejszy wątek ZimaOS z 2025 roku potwierdził inną działającą ścieżkę: zainstaluj Tailscale, uruchom tailscale status w interfejsie wiersza poleceń otwórz zwrócony adres URL logowania i uwierzytelnij węzeł. Aktualna dokumentacja Tailscale dla Dockera obsługuje zarówno procesy oparte na kluczu uwierzytelniania, jak i logowaniu, a jednocześnie zaleca utrwalanie stanu, aby kontener zachowywał tę samą tożsamość węzła po ponownym uruchomieniu.

Dlaczego łącze „WebUI” Tailscale może wprowadzać w błąd

Pierwotny użytkownik oczekiwał, że po instalacji aplikacja otworzy stronę zarządzania. Zamiast tego przeglądarka wróciła na stronę główną ZimaOS.

Oryginalna poprawka społecznościowa: użyj TS_AUTHKEY

Pierwsza odpowiedź stwierdzała, że pakiet ze sklepu aplikacji może działać po utworzeniu klucza uwierzytelniania Tailscale i wklejeniu go do:

TS_AUTHKEY

Aktualna dokumentacja Tailscale nadal definiuje TS_AUTHKEY jako zmienną środowiskową używaną do uwierzytelniania kontenera Dockera w sieci tailnet.

Bieżące źródło: Parametry konfiguracji Tailscale dla Dockera.

Wygeneruj klucz w konsoli administracyjnej Tailscale, a następnie traktuj go jako sekret. Nie publikuj go na zrzutach ekranu, w postach na forum, repozytoriach Git ani udostępnianych plikach Compose.

Alternatywa: uwierzytelnianie za pomocą interfejsu wiersza poleceń Tailscale

Późniejsze rozwiązanie społeczności ZimaOS wykorzystywało:

tailscale status

Gdy węzeł nie był jeszcze uwierzytelniony, Tailscale zwracał adres URL logowania. Użytkownik otworzył ten adres URL w przeglądarce i zatwierdził urządzenie.

W zależności od zainstalowanego kontenera i kontekstu powłoki może być konieczne uruchomienie polecenia wewnątrz kontenera Tailscale, a nie bezpośrednio na hoście ZimaOS.

Najpierw zidentyfikuj kontener:

docker ps --format '{{.Names}}' | grep -i tailscale

Następnie, jeśli to konieczne:

docker exec -it TAILSCALE_CONTAINER tailscale status

Użyj rzeczywistej nazwy kontenera wyświetlanej przez system.

Zachowaj stan Tailscale między ponownymi uruchomieniami

Aktualna dokumentacja Tailscale dotycząca Dockera zaleca ustawienie:

TS_STATE_DIR=/var/lib/tailscale

oraz zamontowanie tego katalogu w trwałej pamięci hosta. Bez trwałego stanu ponownie uruchomiony lub utworzony na nowo kontener może zarejestrować się jako nowy węzeł zamiast zachować swoją wcześniejszą tożsamość.

Tailscale udostępnia również:

TS_AUTH_ONCE=true

w przypadku wdrożeń, które powinny uwierzytelniać się tylko wtedy, gdy kontener nie ma istniejącego stanu.

Czego wymaga aktualna konfiguracja kontenera

Minimalna, koncepcyjna konfiguracja Dockera obejmuje:

environment:
  - TS_AUTHKEY=YOUR_SECRET_KEY
  - TS_STATE_DIR=/var/lib/tailscale
  - TS_AUTH_ONCE=true

volumes:
  - /YOUR/ZIMAOS/PERSISTENT/PATH:/var/lib/tailscale

Dokładna ścieżka na hoście oraz dodatkowe ustawienia sieci i urządzeń zależą od definicji aplikacji w App Store ZimaOS. Nie zastępuj działającej, aktualnej definicji aplikacji starym plikiem YAML CasaOS wyłącznie dlatego, że wątek z 2024 roku odsyłał do samouczka CasaOS.

Dostęp do ZimaOS różni się od rozgłaszania całej sieci LAN

Istnieją dwa typowe cele:

• Dostęp do samego węzła Tailscale: połącz się z węzłem ZimaOS/Tailscale za pomocą jego adresu Tailscale lub nazwy MagicDNS.
• Dostęp do innych urządzeń w sieci LAN ZimaOS: skonfiguruj węzeł jako router podsieci Tailscale.

Drugi cel jest bardziej złożony. Aktualna dokumentacja Tailscale wymaga, aby router rozgłaszał trasy i aby zostały one zatwierdzone w konsoli administracyjnej.

Zobacz dokumentację routera podsieci Tailscale.

Routing podsieci w aplikacji Tailscale dla ZimaOS uruchomionej w Dockerze wymaga dodatkowej konfiguracji

Raport społeczności ZimaOS z 2026 roku opisywał kontener Docker z Tailscale, który pomyślnie się połączył, ale nie rozgłaszał tras LAN. Ta konfiguracja używała sieci hosta, trybu uprzywilejowanego oraz /dev/net/tun, jednak trasy podsieci nadal się nie pojawiły.

To ważna kwestia: kontener, który pomyślnie dołączy do Twojej sieci tailnet, nie staje się automatycznie działającym routerem podsieci. Routing wymaga uprawnień do jądra i sieci, przekazywania pakietów, rozgłaszania tras oraz zatwierdzenia przez administratora.

Jeśli jedynym celem jest zdalny dostęp do samego ZimaOS, nie włączaj niepotrzebnie routingu podsieci.

Tailscale nie wymaga dostępu gościa SMB

Odpowiedź społeczności z 2024 roku twierdziła, że udostępnianie folderów SMB wymagało uprawnień gościa, aby działać przez tunel Tailscale. Nie należy uogólniać tego jako aktualnego wymagania Tailscale.

Tailscale zapewnia łączność sieciową. Uwierzytelnianie SMB pozostaje niezależną warstwą uprawnień Samby/Windows/macOS. Prawidłowo skonfigurowane nazwane konto SMB może działać przez połączenie Tailscale tak samo jak przez sieć LAN.

Dostęp gościa mógł być obejściem problemu w konkretnej konfiguracji Samby w CasaOS/ZimaOS opisanej w tamtej starszej dyskusji, ale nie jest nieodłącznym wymaganiem Tailscale.

Uwagi dotyczące bezpieczeństwa

• Użyj ograniczonego/ponownie używalnego lub efemerycznego klucza uwierzytelniającego, zależnie od potrzeb wdrożenia.
• Nie umieszczaj kluczy uwierzytelniających na zrzutach ekranu ani w repozytoriach.
• Utrwalaj stan, aby węzeł nie rejestrował się ponownie przy każdym uruchomieniu.
• Użyj list kontroli dostępu Tailscale lub reguł grants, aby kontrolować, które urządzenia w tailnecie mogą łączyć się z węzłem ZimaOS.
• Nie wystawiaj bezpośrednio pulpitu ZimaOS do publicznego internetu tylko dlatego, że potrzebny jest zdalny dostęp.

Lista kontrolna konfiguracji Tailscale w ZimaOS

1. Zainstaluj bieżący pakiet Tailscale ze sklepu z aplikacjami.
2. Nie polegaj na odnośniku WebUI aplikacji jako podstawowej metodzie konfiguracji.
3. Uwierzytelnij za pomocą TS_AUTHKEY lub adresu URL logowania CLI Tailscale.
4. Utrwal /var/lib/tailscale używając TS_STATE_DIR.
5. Sprawdź, czy węzeł pojawia się w konsoli administracyjnej Tailscale.
6. Uruchom tailscale status i potwierdź, że węzeł jest połączony.
7. Przetestuj dostęp do węzła ZimaOS przed próbą skonfigurowania routingu podsieci.
8. Jeśli potrzebujesz dostępu do całej sieci LAN, skonfiguruj i zatwierdź trasy podsieci osobno.

Najczęściej zadawane pytania dotyczące ZimaOS i Tailscale

Dlaczego odnośnik WebUI Tailscale przekierowuje z powrotem do ZimaOS?

Kontener Tailscale jest zwykle konfigurowany za pomocą zmiennych środowiskowych, uwierzytelniania i poleceń CLI, a nie za pośrednictwem standardowego interfejsu WebUI aplikacji. Wątek źródłowy pokazywał dokładnie to nieporozumienie.

Czym jest TS_AUTHKEY?

To zmienna środowiskowa Tailscale Docker używana do uwierzytelniania kontenera w tailnecie.

Dlaczego należy utrwalać TS_STATE_DIR?

Trwały stan pozwala kontenerowi zachować tożsamość węzła i uwierzytelnianie po ponownym uruchomieniu lub odtworzeniu.

Czy potrzebuję routingu podsieci, aby uzyskać zdalny dostęp do ZimaOS?

Nie. Routing podsieci jest potrzebny tylko wtedy, gdy węzeł Tailscale ma kierować ruch do innych urządzeń w sieci lokalnej, które nie korzystają z Tailscale.

Czy SMB wymaga trybu gościa przez Tailscale?

Nie, jako ogólna zasada dotycząca Tailscale. Uwierzytelnianie konta SMB jest niezależne od sieci Tailscale.