Zwykła aplikacja Tailscale w Dockerze jest wygodna, ale konteneryzowana sieć VPN nie zawsze działa tak jak Tailscale zainstalowany bezpośrednio na hoście z Linuksem. Autor źródła chciał udostępnić natywnego demona hosta z prawdziwym urządzeniem TUN, aby sam ZimaOS mógł działać jako router podsieci lub węzeł wyjściowy oraz montować zasoby dostępne przez tailnet.
Ponieważ ZimaOS ma przeznaczony dla urządzeń, tylko do odczytu katalog główny i nie ma standardowego apt install tailscale ścieżką, autor spakował Tailscale jako systemd-sysext rozszerzenie. To projekt społecznościowy, a nie pakiet Tailscale wspierany przez IceWhale, dlatego jego polecenia i cykl życia należy odpowiednio oznaczyć.
Dlaczego uruchamiać Tailscale na hoście?
Autor źródła opisał sieć użytkownika Dockera jako wystarczającą do zwykłej łączności, ale niewygodną w przypadku routingu na poziomie hosta. Natywny demon może bezpośrednio korzystać z urządzenia TUN jądra i integrować się z systemctl, przekazywaniem adresów IP, trasami podsieci i działaniem jako węzeł wyjściowy.
Dlaczego systemd-sysext pasuje do ZimaOS
systemd-sysext nakłada dodatkowe pliki w lokalizacjach takich jak /usr w czasie działania bez modyfikowania niezmiennego obrazu bazowego. Autor odwzorował układ Buildroot z upstreamu Tailscale i przechowuje trwały stan uwierzytelniania w /DATA/AppData/tailscale/.
Projekt udostępnia skrypt instalacyjny dla hosta
Szybki start z repozytorium społecznościowego klonuje projekt, uruchamia jego instalator z sudo, a następnie uwierzytelnia za pomocą tailscale up. Ponieważ jest to kod zewnętrzny uruchamiany jako root, przed wykonaniem przejrzyj repozytorium i historię wydań.
Przeczytaj bieżący projekt sysext i aktualizowane instrukcje instalacji, zamiast kopiować starą wersję z forum.
Projekt przechowuje stan węzła w
Stan uwierzytelniania znajduje się poza nietrwałym rozszerzeniem /DATA/AppData/tailscale/Dzięki temu tożsamość Tailscale przetrwa przebudowę lub wymianę .raw plik sysext.
Po pierwszym wydaniu znaleziono rzeczywisty błąd ponownego uruchamiania
Użytkownik zgłosił, że tailscaled nie uruchamiał się po ponownym uruchomieniu. Autor projektu odtworzył problem i wyjaśnił wyścig: multi-user.target rozwiązał zależności usług przed systemd-sysext.service scalił rozszerzenie, więc jednostka usługi nie istniała w chwili, gdy systemd tworzył cel.
v1.0.1 dodano timer watchdog
Autor naprawił wyścig podczas uruchamiania za pomocą niewielkiego timera i usługi oneshot przechowywanych w trwałym katalogu głównym pod /etc/systemd/system/Uruchamia się krótko po starcie i uruchamia tailscaled gdy nakładka sysext jest już dostępna.
Autor źródła poinformował, że zweryfikował poprawkę podczas rzeczywistego ponownego uruchomienia.
Ustawienia przekazywania adresów IP były osobną kwestią trwałości
Wątek poruszał również kwestię tego, czy ustawienia sysctl routera podsieci przetrwają ponowne uruchomienie. Autor wyjaśnił, że ZimaOS zachowuje /etc za pośrednictwem nakładki opartej na trwałej pamięci masowej, dzięki czemu konfiguracja w /etc/sysctl.d/ przetrwa i zostanie zastosowane ponownie.
Te ustawienia przekazywania są potrzebne do działania routera podsieci lub węzła wyjściowego, ale nie zwykłego klienta Tailscale.
Ograniczenie IPv6 zmieniło się wraz z jądrem ZimaOS
Oryginalny moduł z maja 2026 roku dokumentował brak opcji jądra związanych z routingiem opartym na regułach IPv6 w ZimaOS 1.6.1/jądrze 6.12.25, co powodowało wyłączenie przez Tailscale tunelowanego IPv6.
Do 30 lipca autor zaktualizował wątek, ponieważ nowsze jądro IceWhale zapewniło wymagane możliwości IPv6. Aktualne repozytorium projektu potwierdza działanie IPv6 w tailnecie na ZimaOS 1.7.0/jądrze 6.18.9.
Ponownie uruchom instalator po aktualizacjach ZimaOS
Projekt jest przeznaczony do ponownego budowania sysext na podstawie oficjalnych statycznych plików binarnych Tailscale oraz oddzielnego przechowywania stanu uwierzytelniania. Aktualnie repozytorium zaleca ponowne uruchomienie instalatora po aktualizacji ZimaOS.
Społecznościowy moduł działający z uprawnieniami roota traktuj jak oprogramowanie systemowe
Ten moduł działa bezpośrednio na hoście NAS, a jego instalator ma podwyższone uprawnienia. Przed wdrożeniem go w systemie przechowującym ważne dane przeanalizuj kod źródłowy, sumy kontrolne, sposób aktualizacji oraz sposób odinstalowania.
Projekt został ponownie zweryfikowany w ZimaOS 1.7.0
Aktualne repozytorium informuje o pomyślnym kompleksowym teście w ZimaOS 1.7.0 z jądrem 6.18.9, obejmującym zachowanie po ponownym uruchomieniu i działający IPv6 w tailnecie. To mocniejszy dowód niż oryginalny wpis z maja 2026 roku, opracowany dla ZimaOS 1.6.1.
Docker i natywne sysext odpowiadają na różne potrzeby
Jeśli potrzebujesz jedynie udostępnić wybrane aplikacje przez Tailscale, rozwiązanie Docker może być prostsze i ogranicza modyfikacje hosta do minimum. Rozwiązanie sysext jest atrakcyjne, gdy sam host ZimaOS musi montować zasoby tailnetu, rozgłaszać podsieci LAN lub działać jako węzeł wyjściowy.
Nie zastępuj działającej instalacji Dockera tylko dlatego, że istnieje podejście natywne. Wybierz rozwiązanie w zależności od tego, czy rzeczywiście potrzebujesz routingu na poziomie hosta.
Odinstalowanie i pełne wyczyszczenie to różne operacje
Projekt społecznościowy celowo rozdziela usunięcie sysext od usunięcia stanu Tailscale. Standardowa ścieżka odinstalowania może zachować trwałe dane węzła, natomiast pełne wyczyszczenie usuwa również katalog stanu. To rozróżnienie ma znaczenie, jeśli planujesz ponowną instalację bez tworzenia kolejnej tożsamości tailnetu.
Watchdog uruchamiania nadal jest częścią projektu
Aktualna dokumentacja projektu informuje, że watchdog jest nadal potrzebny nawet w ZimaOS 1.7.0, ponieważ jednostka usługi wewnątrz sysext może nadal nie trafić do początkowego zestawu celów systemd. Nowsze jądro naprawiło obsługę IPv6, ale nie wyścig kolejności uruchamiania usługi sysext.
Najczęstsze pytania dotyczące natywnego Tailscale
Czy to oficjalny pakiet IceWhale Tailscale?
Nie. To społecznościowy projekt systemd-sysext.
Dlaczego używać tego zamiast Dockera?
Projekt jest przeznaczony do obsługi TUN na poziomie hosta, routera podsieci, węzła wyjściowego oraz standardowej integracji z systemd.
Czy problem z uruchamianiem po ponownym uruchomieniu został rozwiązany?
Autor projektu odtworzył ten problem i wydał poprawkę opartą na mechanizmie watchdog w wersji 1.0.1.
Czy IPv6 nadal ma ograniczenie z wersji 1.6.1?
Projekt informuje, że nowsze jądro 6.18.9 używane przez ZimaOS 1.7.0 zapewnia wymaganą obsługę routingu opartego na regułach IPv6.
