Kluczowym błędem w tym wątku z września 2025 roku było zinterpretowanie modprobe tun uznając awarię za dowód, że ZimaOS w ogóle nie obsługuje TUN. Zima-Jerry skorygował to założenie: w kompilacji źródłowej TUN skompilowano bezpośrednio w jądrze, więc nie było osobnego tun.ko plik pod /lib/modules dla modprobe załadować.
Jednak konkretny przepływ pracy użytkownika z dockerowym routerem podsieci nadal wymagał zachowania urządzenia/modułu oczekiwanego przez Tailscale. Dlatego IceWhale zmieniło sposób pakowania w ZimaOS 1.5.0, tak aby TUN stał się ładowalnym modułem jądra. Autor pierwotnego wpisu ponownie przetestował rozwiązanie 29 września i odpowiedział, że teraz działa.
Użytkownik chciał utworzyć router podsieci Tailscale między lokalizacjami
Źródłowy projekt łączył dwie fizyczne lokalizacje, Meksyk i Urugwaj, i zakładał, że urządzenia lokalne w każdej lokalizacji będą komunikować się przez Tailscale bez instalowania Tailscale na każdym punkcie końcowym.
To przypadek użycia routera podsieci, a nie tylko „zdalny dostęp do pulpitu ZimaOS”. Router podsieci musi przekazywać pakiety między siecią tailnet a inną podsiecią IP.
modprobe nie zgłosił pliku modułu tun
Użytkownik uruchomił uprzywilejowany kontener Tailscale i zobaczył:
modprobe: FATAL: Module tun not found in directory /lib/modules/6.12.25Nie znaleźli również tun.ko plik i nie znaleźli wpisu TUN w wynikach kontroli listy modułów.
IceWhale powiedział, że TUN skompilowano bezpośrednio w jądrze
Pierwsza oficjalna odpowiedź Zima-Jerry’ego była jednoznaczna: funkcja TUN została bezpośrednio wbudowana w jądro, więc nie pojawiała się jako zwykły plik modułu w /lib/modules/6.12.25.
To rozróżnienie w jądrze Linuksa: funkcja skonfigurowana jako wbudowana jest dostępna bez pojawiania się w lsmod lub ładowany przez modprobe.
Wbudowana obsługa nie rozwiązała w pełni przepływu pracy z kontenerem źródłowym
Autor pierwotnego wpisu odpowiedział, że jego kontener nadal przechodził w tryb przestrzeni użytkownika i nie mógł zapewnić oczekiwanego pełnego działania routera podsieci w stylu hosta. Zapytał konkretnie, czy TUN można udostępnić w sposób modułowy.
Zima-Jerry powiedział, że można to dostosować w następnej wersji.
ZimaOS 1.5.0 zmienił TUN w moduł ładowalny
28 września Zima-Jerry napisał, że w nowym wydaniu 1.5.0 tun.ko stał się modułem jądra i poprosił użytkownika o ponowne przetestowanie.
Autor pierwotnego wpisu odpowiedział następnego dnia: „Dzięki, teraz działa”.
To potwierdzone w źródłach rozwiązanie i najważniejszy wniosek z tego wątku.
Sieciowanie Tailscale w przestrzeni użytkownika to inny tryb działania
Aktualna dokumentacja Tailscale wyjaśnia, że kontenery mogą działać bez urządzenia TUN, korzystając z sieci w przestrzeni użytkownika. W tym trybie tailscaled działa za pośrednictwem stosu sieciowego/proxy w przestrzeni użytkownika, zamiast zachowywać się jak zwykły interfejs tunelowy Linuksa.
Skorzystaj z obecnego modelu sieci użytkownika Tailscale, decydując, czy TUN jądra jest rzeczywiście wymagany.
Obecne Tailscale może routować podsieci w trybie jądra lub użytkownika
Obecna dokumentacja Tailscale opisuje teraz zarówno routing podsieci w trybie jądra, jak i w trybie użytkownika/netstack. Tryb jądra w systemie Linux zachowuje standardowe przekazywanie pakietów i zazwyczaj zapewnia lepszą wydajność; tryb użytkownika również może routować ruch, ale kończy obsługę wspieranego ruchu i ponownie go inicjuje we własnym stosie sieciowym.
W przypadku Dockera obecna dokumentacja Tailscale również opisuje, że TS_USERSPACE jest domyślnie włączony, natomiast tryb jądra wymaga /dev/net/tun oraz wymagane uprawnienia.
Działające urządzenie TUN to nie cała konfiguracja routera podsieci
Router podsieci Linux wymaga również przekazywania adresów IP, rozgłoszonych tras, zatwierdzenia tras w konsoli administracyjnej Tailscale oraz odpowiednich reguł dostępu tailnetu. Kontener pomyślnie tworzący tailscale0 samo w sobie nie oznacza, że zdalne urządzenia w sieci LAN mogą kierować przez nie ruchu.
Po uruchomieniu warstwy jądra/urządzenia ZimaOS postępuj zgodnie z bieżącym procesem konfiguracji routera podsieci Tailscale.
Nie stosuj diagnozy „brakującego tun.ko” z wersji 1.4.x do obecnego ZimaOS
Sam tekst źródłowy dokumentuje granicę między wersjami: pliku brakowało z powodu sposobu zbudowania jądra w wersji 1.4.x, a w ZimaOS 1.5.0 zmieniono funkcję TUN na moduł. Obecne ZimaOS znacznie wykracza poza tę wersję.
W przypadku współczesnego problemu sprawdź bieżące ustawienia kontenera, dostępność urządzenia TUN, tryb użytkownika/jądra, przekazywanie adresów IP oraz zatwierdzenie tras, zamiast zakładać, że powrócił problem z pakowaniem jądra z 2025 roku.
FAQ Tailscale dotyczące TUN
Czy niepowodzenie polecenia modprobe tun dowodziło, że ZimaOS nie obsługiwał TUN?
Nie. IceWhale poinformowało, że TUN został skompilowany bezpośrednio w jądrze źródłowym, zamiast być dostarczany jako osobny moduł.
Co zmieniono w ZimaOS 1.5.0?
Zima-Jerry powiedział tun.ko stał się ładowalnym modułem jądra.
Czy autor oryginalnego posta potwierdził, że nowa wersja działała?
Tak. Ponownie przetestowali to po zmianie w wersji 1.5.0 i powiedzieli, że działało.
