Een Tailscale-container kan aangeven dat hij verbonden is zonder als subnetrouter te functioneren. In deze ZimaOS-thread uit april 2026 draaide Tailscale in Docker met hostnetwerk, privileged-modus en /dev/net/tun gekoppeld, maar de Tailscale-beheerconsole meldde dat de machine geen routes beschikbaar stelde. Navidrome werkte op het lokale netwerk, maar was op afstand niet bereikbaar via de tailnet.
De thread eindigde niet met een bevestigde oplossing van de oorspronkelijke poster. In plaats daarvan deelde een ander communitylid een werkende BigBear Tailscale-containerconfiguratie die in diens eigen ZimaOS-omgeving met succes een LAN-subnet adverteerde. Die configuratie is nuttig als referentie voor probleemoplossing, maar vormt geen door IceWhale ondersteunde garantie voor elk Tailscale-apppakket.
Verbonden met Tailscale betekent niet dat subnetroutes worden geadverteerd
De oorspronkelijke configuratie had de apparaatauthenticatie al voltooid. Het probleem betrof specifiek de routing: de logs toonden een lege routelijst en de Tailscale-beheerconsole bood geen subnetroute aan om goed te keuren.
Dit onderscheid is belangrijk, omdat een normale Tailscale-node alleen verbinding maakt met de tailnet. Een subnetrouter heeft extra verantwoordelijkheden: hij moet een of meer LAN-prefixes adverteren en voldoen aan de routingvereisten van het besturingssysteem om verkeer tussen de tailnet en dat LAN door te sturen.
De huidige Tailscale-documentatie beschrijft subnetrouters als gateways die privénetwerken adverteren naar apparaten in de tailnet. Ook is IP-forwarding op Linux vereist, evenals routegoedkeuring in de Tailscale-beheerconsole, tenzij een autoApprovers dit beleid de goedkeuring automatisch afhandelt.
Documentatie over subnetrouters van Tailscale
De werkende communityreferentie gebruikte TS_ROUTES
Het antwoord van TomasSzwed gebruikte een BigBear Tailscale-container en configureerde het subnet via omgevingsvariabelen, in plaats van te vertrouwen op een handmatige eenmalige opdracht na het opstarten. Belangrijke onderdelen van die referentie waren:
-
network_mode: host; - privileged-modus;
-
/dev/net/tungekoppeld aan de container; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24voor het LAN dat wordt geadverteerd; -
TS_EXTRA_ARGS=--accept-routesin de configuratie van die gebruiker; - persistente Tailscale-status onder
/var/lib/tailscale.
Gebruik het juiste LAN-prefix voor je netwerk
Het werkende voorbeeld dat werd geadverteerd 192.168.2.0/24. Die waarde is alleen zinvol voor een LAN dat dat subnet gebruikt. Een ander thuisnetwerk kan 192.168.1.0/24, 10.0.0.0/24, of een ander privéprefix.
Het adverteren van het verkeerde subnet kan ertoe leiden dat een Tailscale-node gezond lijkt, maar nog steeds geen toegang heeft tot de beoogde ZimaOS-services. Bepaal het daadwerkelijke lokale netwerkprefix voordat je instelt TS_ROUTES of een equivalent --advertise-routes optie.
Geadverteerde routes moeten nog actief worden
De huidige richtlijnen van Tailscale maken onderscheid tussen routeadvertenties en routegoedkeuring. Zodra de subnetrouter een route adverteert, moet die route worden ingeschakeld in de beheerconsole van Tailscale, tenzij het tailnetbeleid deze automatisch goedkeurt.
Als de beheerconsole aangeeft dat de machine helemaal geen routes adverteert, richt je dan eerst op de configuratie voor routeadvertenties van de container. Als de route wel verschijnt, maar verkeer nog steeds niet werkt, controleer dan de routegoedkeuring, het toegangsbeleid, doorsturen en de bestemmingsservice zelf.
Docker-netwerken bepalen wat de container kan routeren
De oorspronkelijke poster gebruikte hostnetwerken en koppelde het TUN-apparaat aan de container. De communityreferentie deed hetzelfde. De huidige Tailscale-documentatie ondersteunt ook het uitvoeren van Tailscale in Docker, maar Docker-netwerken en Tailscale-routing zijn afzonderlijke lagen die beide correct moeten zijn ingesteld.
Tailscale-documentatie voor Docker
Ga er niet van uit dat twee Tailscale-apps in de ZimaOS App Store identieke containerdefinities gebruiken. De oorspronkelijke poster merkte specifiek op dat het gedeelde voorbeeld het BigBear-Tailscale-pakket gebruikte, terwijl de bestaande installatie het andere Tailscale-item gebruikte.
Wat dit betekent voor Navidrome en andere lokale services
Het doel in de thread uit de bron was om Navidrome vanaf een iPhone te benaderen zonder openbare poortdoorschakeling. Als Navidrome al bereikbaar is op het lokale LAN, kan een werkende subnetrouter dat LAN-adres bereikbaar maken vanaf geautoriseerde apparaten in de tailnet.
De thread bevestigt echter niet dat de oorspronkelijke poster de overstap naar de BigBear-configuratie heeft voltooid of Navidrome daarna succesvol heeft bereikt. De pagina beschrijft daarom een bruikbare communityreferentie en een diagnostisch model, maar geen bevestigde oplossing voor precies die installatie.
Veelgestelde vragen over subnetrouting met Tailscale in ZimaOS
Waarom zegt Tailscale dat het verbonden is, maar toont het geen subnetroutes?
Deelnemen aan de tailnet en een LAN-route adverteren zijn twee verschillende handelingen. In het geval uit de bron lukte de authenticatie, maar bleef de routelijst leeg.
Kan Tailscale in Docker op ZimaOS als subnetrouter fungeren?
Een communitylid meldde dat het werkte in diens ZimaOS-installatie en deelde een Tailscale-configuratie van BigBear. Tailscale ondersteunt zelf ook subnetrouting en Docker-implementaties, maar de exacte appconfiguratie in ZimaOS blijft belangrijk.
Moet ik de route in Tailscale goedkeuren?
Volgens het huidige gedrag van Tailscale moeten geadverteerde subnetroutes normaal gesproken in de beheerconsole worden goedgekeurd, tenzij een autoApprovers het beleid handelt ze automatisch af.
Moet ik 192.168.2.0/24 uit de schermafbeelding kopiëren?
Nee. Gebruik het daadwerkelijke subnet van het LAN dat je wilt ontsluiten. De waarde in de schermafbeelding hoort bij het netwerk van een ander communitylid.
