De bronpost bevat de belangrijkste onderdelen die nodig zijn om een Tailscale-Docker-client op ZimaOS te registreren bij een zelfgehost besturingsvlak van Headscale: persistente status, een eenmalige/pre-authenticatiesleutel, de aangepaste Headscale-URL, toegang tot TUN en de vereiste containermogelijkheden.
De huidige documentatie van Tailscale en Headscale biedt nu een duidelijker contract van de oorspronkelijke ontwikkelaars. Tailscale ondersteunt officieel een aangepaste URL voor de besturingsserver en Headscale documenteert zowel interactieve registratie als registratie met een pre-authenticatiesleutel. Gebruik deze methoden van de oorspronkelijke ontwikkelaars om de huidige opdracht en URL te valideren, in plaats van uitsluitend te vertrouwen op een screenshot uit 2025.
Headscale vervangt het coördinatiebesturingsvlak van Tailscale
Headscale is een zelfgehoste implementatie van het Tailscale-protocol voor de besturingsserver. Tailscale-clients maken nog steeds versleutelde peer-to-peer-tunnels, maar registratie en coördinatie worden afgehandeld door de Headscale-instantie van de gebruiker in plaats van door het standaardbesturingsvlak van Tailscale.
Maak de statusmap van Tailscale persistent
De bron maakte het volgende aan /DATA/AppData/tailscale/state en koppelde deze aan /var/lib/tailscale. Dit is belangrijk omdat de identiteit/status van de node behouden moet blijven na het opnieuw aanmaken van de container en na een herstart van de host.
De bron adviseerde ook beperkte machtigingen voor de statusmap op de host. Dat is verstandig, omdat de status deel uitmaakt van de identiteit van de node en niet voor iedereen leesbaar mag zijn.
Gebruik de Headscale-URL als aangepaste besturingsserver
De huidige documentatie van Tailscale ondersteunt aangepaste besturingsservers via:
tailscale login --login-server=<URL>De eigen documentatie van Headscale gebruikt hetzelfde model met tailscale up --login-server <YOUR_HEADSCALE_URL>.
Zie de huidige richtlijnen van Tailscale voor aangepaste besturingsservers.
Gebruik een pre-authenticatiesleutel voor niet-interactieve registratie
De bron voegde tijdelijk toe TS_AUTHKEY, registreerde de node en verwijderde de variabele vervolgens. In de huidige documentatie van Headscale wordt beschreven hoe je een pre-authenticatiesleutel aanmaakt en deze gebruikt met --authkey voor niet-interactieve registratie.
Gebruik de huidige registratiemethoden van Headscale.
Laat geen herbruikbare authenticatiesleutel in de appdefinitie staan
Als de sleutel herbruikbaar is of een lange geldigheidsduur heeft, zorgt het laten staan ervan in de omgeving van de ZimaOS-app voor onnodige blootstelling. Verwijder het registratiesecret nadat de identiteit van de node succesvol is opgeslagen, zodra het niet langer nodig is.
Als een sleutel in een openbaar forum of een screenshot is geplaatst, trek deze dan in en maak een nieuwe aan.
Kernel-TUN en mogelijkheden beïnvloeden de netwerkmodus
De bron koppelt /dev/net/tun en verleent NET_ADMIN/NET_RAW, wat de stijl van kernelnetwerken is in plaats van puur netwerken in de gebruikersruimte.
Huidige Tailscale-containers kunnen ook in de gebruikersruimtemodus werken. Kies de modus daarom bewust, afhankelijk van of je subnetrouting, exit-nodegedrag of volledige kernelnetwerken nodig hebt.
Hostnetwerken zijn krachtig
De bron gebruikt Docker-hostnetwerken. Hierdoor vervalt de normale isolatie van containerpoorten en werkt Tailscale rechtstreeks in de netwerknaamruimte van de host.
Schakel niet over van host- naar bridge-netwerken, of andersom, zonder te begrijpen hoe de huidige Tailscale-app routes, listeners en geadverteerde services opslaat.
De Headscale-URL moet betrouwbaar bereikbaar en goed beveiligd zijn
Een zelfgehoste controleserver wordt kritieke infrastructuur. Gebruik stabiele DNS, een geldige TLS-configuratie en back-ups van de database en configuratie van Headscale. Als de controleserver verdwijnt, kunnen bestaande peers tijdelijk blijven communiceren, maar nieuwe registraties en coördinatiewijzigingen zijn dan niet meer beschikbaar.
De bron is één werkende configuratie, geen ondersteuningsovereenkomst met IceWhale
Het bericht bevat geen bevestiging van IceWhale-medewerkers. Het is een configuratie uit de community die goed aansluit bij de concepten van Tailscale en Headscale upstream, maar moet nog steeds worden getest met het huidige Tailscale-pakket van ZimaOS.
Veelgestelde vragen over Headscale op ZimaOS
Kunnen Tailscale-clients een aangepaste Headscale-controleserver gebruiken?
Ja. De huidige Tailscale-documentatie ondersteunt officieel aangepaste URL's voor controleservers.
Moet TS_AUTHKEY permanent in de app blijven staan?
Nee. De bron verwijderde deze na de registratie, en langdurig geldige registratiesleutels mogen niet onnodig blootgesteld blijven.
Waarom /var/lib/tailscale persistent maken?
De identiteit/status van de node blijft behouden bij het opnieuw aanmaken van de container en na een herstart.
