Den vanliga Tailscale-Docker-appen är praktisk, men ett containerbaserat VPN fungerar inte alltid som Tailscale installerat direkt på en Linux-värd. Källförfattaren ville ha en fullvärdig daemon på värdsystemet med en riktig TUN-enhet, så att ZimaOS självt kunde fungera som subnätsrouter eller utgångsnod och montera resurser som är tillgängliga via tailnet.
Eftersom ZimaOS har en skrivskyddad rot i appliance-stil och saknar en konventionell apt install tailscale sökvägen paketerade författaren Tailscale som ett systemd-sysext tillägg. Detta är ett communityprojekt, inte ett Tailscale-paket som stöds av IceWhale, så dess kommandon och livscykel bör märkas därefter.
Varför köra Tailscale på värdsystemet?
Källförfattaren beskrev Dockers nätverk med userspace som tillräckligt bra för vanlig anslutning men besvärligt för routing på värdnivå. En inbyggd daemon kan använda kärnans TUN-enhet direkt och integreras med systemctl, IP-vidarebefordran, subnätsrutter och beteende som utgångsnod.
Varför systemd-sysext passar ZimaOS
systemd-sysext lägger över ytterligare filer på platser som /usr vid körning utan att ändra den oföränderliga basavbildningen. Författaren återskapade Tailscales layout från det ursprungliga Buildroot-projektet och lagrade beständigt autentiseringstillstånd under /DATA/AppData/tailscale/.
Projektet tillhandahåller ett installationsskript för värdsystemet
Communitykodarkivets snabbstart klonar projektet, kör installationsprogrammet med sudo och autentiserar sedan med tailscale up. Eftersom detta är kod från tredje part som körs som root bör du granska kodarkivet och versionshistoriken innan du kör den.
Läs det aktuella sysext-projektet och dess underhållna installationsanvisningar i stället för att kopiera en gammal forumversion.
Autentiseringstillståndet lagras utanför det flyktiga tillägget
Projektet lagrar nodens tillstånd under /DATA/AppData/tailscale/. Det gör att Tailscale-identiteten överlever när .raw sysext-filen.
Ett verkligt omstartsproblem upptäcktes efter den första lanseringen
En användare rapporterade att tailscaled startade inte efter omstart. Projektförfattaren återskapade problemet och förklarade kapplöpningen: multi-user.target löste tjänsteberoenden före systemd-sysext.service hade slagit samman tillägget, så tjänsteenheten fanns inte när systemd byggde målet.
v1.0.1 lade till en watchdog-timer
Författaren löste uppstartsproblemet med en enkel timer och en oneshot-tjänst som lagras i den beständiga roten under /etc/systemd/system/Det körs strax efter uppstart och startar tailscaled när sysext-overlay-lagret finns på plats.
Källförfattaren uppgav att lösningen hade verifierats efter en riktig omstart.
Inställningar för IP-vidarebefordran var en separat fråga om beständighet
Tråden frågade också om sysctl-inställningar för subnätsroutern överlever en omstart. Författaren förklarade att ZimaOS sparar /etc via ett overlay-lager som stöds av beständig lagring, så att konfiguration under /etc/sysctl.d/ överlever och tillämpas på nytt.
De här vidarebefordringsinställningarna behövs för användning som subnet-router eller exit-nod, inte för en vanlig Tailscale-klient.
IPv6-begränsningen ändrades med ZimaOS-kärnan
Den ursprungliga modulen från maj 2026 dokumenterade saknade kärnalternativ för IPv6-policybaserad routning på ZimaOS 1.6.1/kärna 6.12.25, vilket fick Tailscale att inaktivera tunnlad IPv6.
Den 30 juli uppdaterade upphovspersonen tråden eftersom IceWhales nyare kärna tillhandahöll de nödvändiga IPv6-funktionerna. Det aktuella projektarkivet verifierar IPv6-funktion i tailnet på ZimaOS 1.7.0/kärna 6.18.9.
Kör installationsprogrammet igen efter ZimaOS-uppdateringar
Projektet är utformat för att bygga om sysext från officiella statiska Tailscale-binärer och bevara autentiseringstillståndet separat. Arkivet rekommenderar för närvarande att installationsprogrammet körs igen efter en ZimaOS-uppgradering.
Behandla en communitymodul på rotnivå som systemprogramvara
Den här modulen körs direkt på NAS-värden och dess installationsprogram har utökade behörigheter. Granska källkod, hashvärden, uppdateringsbeteende och avinstallationsbeteende innan du distribuerar den på ett system som lagrar viktiga data.
Projektet verifierades på nytt på ZimaOS 1.7.0
Det aktuella arkivet rapporterar ett felfritt test från början till slut på ZimaOS 1.7.0 med kärnan 6.18.9, inklusive kvarstående funktion efter omstart och fungerande IPv6 i tailnet. Det är starkare belägg än det ursprungliga inlägget från maj 2026, som utvecklades mot ZimaOS 1.6.1.
Docker och inbyggd sysext löser olika behov
Om du bara behöver göra utvalda program åtkomliga via Tailscale kan Docker-vägen vara enklare och hålla ändringarna på värden till ett minimum. Sysext-vägen är attraktiv när själva ZimaOS-värden behöver montera tailnet-resurser, annonsera lokala subnät eller fungera som exit-nod.
Byt inte ut en fungerande Docker-installation enbart för att den inbyggda metoden finns. Välj utifrån om routning på värdnivå faktiskt behövs.
Avinstallation och rensning är olika åtgärder
Communityprojektet skiljer medvetet mellan att ta bort sysext och att radera Tailscale-tillståndet. Den normala avinstallationsvägen kan behålla beständiga noddata, medan en rensning även tar bort tillståndskatalogen. Den skillnaden är viktig om du tänker installera om utan att skapa en ny tailnet-identitet.
Boot-watchdogen är fortfarande en del av designen
Den aktuella projektdokumentationen säger att watchdog fortfarande behövs även på ZimaOS 1.7.0, eftersom serviceenheten inuti sysext fortfarande kan missa den första sammansättningen av systemd-målet. Den nyare kärnan åtgärdade IPv6-funktionaliteten, inte kapplöpningstillståndet i sysext-tjänstens startordning.
Vanliga frågor om inbyggda Tailscale
Är detta ett officiellt IceWhale Tailscale-paket?
Nej. Det är ett communityprojekt för systemd-sysext.
Varför använda det i stället för Docker?
Projektet är inriktat på TUN på värdnivå, subnet-router, exit-nod och normal systemd-integration.
Har problemet med att starten efter omboot misslyckades åtgärdats?
Projektets upphovsperson återskapade problemet och släppte en watchdog-baserad korrigering i v1.0.1.
Har IPv6 fortfarande begränsningen från 1.6.1?
Projektet rapporterar att den nyare kärnan 6.18.9 som används av ZimaOS 1.7.0 tillhandahåller det nödvändiga stödet för IPv6-policybaserad routning.
