Källinlägget fångar de centrala delarna som behövs för att få en Tailscale Docker-klient på ZimaOS att registrera sig med ett självhostat Headscale-kontrollplan: beständigt tillstånd, en engångsnyckel/förhandsautentiseringsnyckel, den anpassade Headscale-URL:en, TUN-åtkomst och de nödvändiga containerfunktionerna.
Aktuell dokumentation för Tailscale och Headscale ger nu ett tydligare uppströmskontrakt. Tailscale stöder officiellt en anpassad URL för kontrollservern, och Headscale dokumenterar både interaktiv registrering och registrering med förhandsautentiseringsnyckel. Använd dessa uppströmsmetoder för att verifiera det aktuella kommandot/URL:en i stället för att enbart förlita dig på en skärmbild från 2025.
Headscale ersätter Tailscales kontrollplan för samordning
Headscale är en självhostad implementation av Tailscales protokoll för kontrollservern. Tailscale-klienter skapar fortfarande krypterade peer-to-peer-tunnlar, men registrering och samordning hanteras av användarens Headscale-instans i stället för Tailscales standardkontrollplan.
Spara Tailscales tillståndskatalog
Källan skapade /DATA/AppData/tailscale/state och mappade den till /var/lib/tailscale. Detta är viktigt eftersom nodens identitet/tillstånd bör finnas kvar när containern återskapas och värddatorn startas om.
Källan rekommenderade även begränsade behörigheter för värddatorns tillståndskatalog. Det är rimligt eftersom tillståndet är en del av nodens identitet och inte bör vara läsbart för alla.
Använd Headscale-URL:en som anpassad kontrollserver
Aktuell Tailscale-dokumentation stöder anpassade kontrollservrar via:
tailscale login --login-server=<URL>Headscales egen dokumentation använder samma modell med tailscale up --login-server <YOUR_HEADSCALE_URL>.
Se Tailscales aktuella vägledning för anpassade kontrollservrar.
Använd en förhandsautentiseringsnyckel för icke-interaktiv registrering
Källan lade tillfälligt till TS_AUTHKEY, registrerade noden och tog sedan bort variabeln. Headscale dokumenterar för närvarande hur man skapar en förhandsautentiseringsnyckel och använder den med --authkey för icke-interaktiv registrering.
Använd Headscales aktuella registreringsmetoder.
Lämna inte en återanvändbar autentiseringsnyckel i appdefinitionen
Om nyckeln kan återanvändas eller har lång giltighetstid innebär det onödig exponering att lämna den i ZimaOS-appens miljö. När nodidentiteten har lagrats korrekt ska du ta bort registreringshemligheten när den inte längre behövs.
Om en nyckel klistrades in på ett offentligt forum eller i en skärmbild ska du återkalla den och skapa en ny.
Kärnans TUN och funktioner påverkar nätverksläget
Källan mappar /dev/net/tun och tilldelar NET_ADMIN/NET_RAW, vilket är en stil för kärnnätverkshantering snarare än ren userspace-nätverkshantering.
Aktuella Tailscale-containrar kan även köras i userspace-läge, så välj läge medvetet utifrån om du behöver subnätsroutning, exit-nodsbeteende eller fullständig kärnnätverkshantering.
Värdnätverk är kraftfullt
Källan använder Dockers värdnätverk. Det tar bort den normala portisoleringen för containrar och gör att Tailscale körs direkt i värdens nätverksnamnrymd.
Byt inte från värd- till bryggnätverk – eller tvärtom – utan att förstå hur den aktuella Tailscale-appen lagrar rutter, lyssnare och annonserade tjänster.
Headscale-URL:en bör vara tillförlitligt nåbar och ordentligt säkrad
En självhostad kontrollserver blir kritisk infrastruktur. Använd stabil DNS, en giltig TLS-konfiguration och säkerhetskopior av Headscales databas/konfiguration. Om kontrollservern försvinner kan befintliga peers fortsätta kommunicera tillfälligt, men nya registreringar och ändringar av samordningen blir inte tillgängliga.
Källan är en fungerande konfiguration, inte ett supportavtal med IceWhale
Inlägget innehåller ingen bekräftelse från IceWhale-personal. Det är en community-konfiguration som stämmer väl överens med de grundläggande koncepten i Tailscale/Headscale, men den bör fortfarande testas mot det aktuella Tailscale-paketet i ZimaOS.
Vanliga frågor om Headscale på ZimaOS
Kan Tailscale-klienter använda en anpassad Headscale-kontrollserver?
Ja. Den aktuella Tailscale-dokumentationen stöder officiellt anpassade URL:er för kontrollservern.
Bör TS_AUTHKEY finnas kvar i appen för alltid?
Nej. Källan tog bort den efter registreringen, och långlivade registreringshemligheter bör inte lämnas exponerade i onödan.
Varför spara /var/lib/tailscale?
Den bevarar nodens Tailscale-identitet/tillstånd vid återskapande av containern och omstart.
