En Tailscale-container kan visas som ansluten utan att fungera som subnätsrouter. I denna ZimaOS-tråd från april 2026 kördes Tailscale i Docker med värdnätverk, privilegierat läge och /dev/net/tun monterad, men Tailscales administratörskonsol rapporterade att maskinen inte exponerade några rutter. Navidrome fungerade i det lokala nätverket men kunde inte nås via tailnet på distans.
Tråden avslutades inte med en bekräftad lösning från den ursprungliga skribenten. I stället delade en annan communitymedlem en fungerande konfiguration för en BigBear Tailscale-container som framgångsrikt annonserade ett LAN-subnät i sin egen ZimaOS-miljö. Konfigurationen är användbar som felsökningsreferens, men den är ingen av IceWhale stödd garanti för alla Tailscale-appaket.
Ansluten till Tailscale betyder inte att subnätsrutter annonseras
Den ursprungliga konfigurationen hade redan slutfört enhetsautentiseringen. Problemet gällde specifikt routningen: loggarna visade en tom ruttlista och Tailscales administratörskonsol erbjöd ingen subnätsrutt att godkänna.
Denna skillnad är viktig eftersom en vanlig Tailscale-nod bara ansluter till tailnet. En subnätsrouter har ytterligare ansvar: den måste annonsera ett eller flera LAN-prefix och uppfylla operativsystemets routningskrav för att vidarebefordra trafik mellan tailnet och det LAN-nätverket.
Aktuell Tailscale-dokumentation beskriver subnätsroutrar som gateways som annonserar privata nätverk till tailnet-enheter. Den kräver också IP-vidarebefordran i Linux och ruttgodkännande i Tailscales administratörskonsol, såvida inte en autoApprovers policy hanterar godkännandet automatiskt.
Tailscales dokumentation om subnätsroutrar
Den fungerande communityreferensen använde TS_ROUTES
Svaret från TomasSzwed använde en BigBear Tailscale-container och konfigurerade subnätet via miljövariabler i stället för att förlita sig på ett manuellt engångskommando efter starten. Viktiga delar av den referensen var:
-
network_mode: host; - privilegierat läge;
-
/dev/net/tunmonterad i containern; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24för det LAN som annonseras; -
TS_EXTRA_ARGS=--accept-routesi den användarens konfiguration; - beständigt Tailscale-tillstånd under
/var/lib/tailscale.
Använd rätt LAN-prefix för ditt nätverk
Det fungerande exemplet annonserade 192.168.2.0/24. Det värdet är bara giltigt för ett LAN som använder det subnätet. Ett annat hemnätverk kan använda 192.168.1.0/24, 10.0.0.0/24eller ett annat privat prefix.
Att ange fel subnät kan skapa en Tailscale-nod som är frisk men ändå inte kan dirigera trafik till de avsedda ZimaOS-tjänsterna. Fastställ det faktiska lokala nätverksprefixet innan du anger TS_ROUTES eller motsvarande --advertise-routes alternativet.
Annonserade rutter måste fortfarande aktiveras
Aktuell vägledning för Tailscale skiljer mellan ruttannonsering och ruttgodkännande. När subnätsroutern annonserar en rutt måste rutten aktiveras i Tailscales administratörskonsol, såvida inte tailnet-policyn automatiskt godkänner den.
Om administratörskonsolen anger att datorn inte exponerar några rutter alls bör du först fokusera på containerns konfiguration för ruttannonsering. Om rutten visas men trafiken fortfarande inte fungerar bör du sedan granska ruttgodkännande, åtkomstkontrollpolicy, vidarebefordran och själva måltjänsten.
Docker-nätverk påverkar vad containern kan routa
Den ursprungliga skribenten använde värdnätverk och monterade TUN-enheten. Communityreferensen gjorde samma sak. Aktuell Tailscale-dokumentation stöder också att köra Tailscale i Docker, men Docker-nätverk och Tailscale-routing är separata lager som båda måste vara korrekt konfigurerade.
Tailscales Docker-dokumentation
Anta inte att två Tailscale-appar i ZimaOS App Store använder identiska containerdefinitioner. Den ursprungliga skribenten lade särskilt märke till att det delade exemplet använde BigBears Tailscale-paket, medan den befintliga installationen använde den andra Tailscale-posten.
Vad detta innebär för Navidrome och andra lokala tjänster
Målet i källtråden var att få åtkomst till Navidrome från en iPhone utan offentlig portvidarebefordran. Om Navidrome redan kan nås via det lokala LAN-nätet kan en fungerande subnätsrouter göra den LAN-adressen nåbar från auktoriserade tailnet-enheter.
Tråden bekräftar dock inte att den ursprungliga skribenten slutförde bytet till BigBear-konfigurationen eller lyckades nå Navidrome efteråt. Sidan dokumenterar därför en fungerande communityreferens och en diagnostisk modell, inte en bekräftad lösning för just den installationen.
Vanliga frågor om Tailscales subnätsrouting i ZimaOS
Varför säger Tailscale att den är ansluten men visar inga subnätsrutter?
Att ansluta till tailnet och att annonsera en LAN-rutt är två olika åtgärder. I källfallet lyckades autentiseringen, men ruttlistan förblev tom.
Kan Tailscale i Docker fungera som en subnätsrouter i ZimaOS?
En communitymedlem rapporterade att det fungerade i deras ZimaOS-konfiguration och delade en Tailscale-konfiguration från BigBear. Tailscale stöder även subnätsrouting och Docker-distributioner, men den exakta appkonfigurationen i ZimaOS är fortfarande viktig.
Behöver jag godkänna rutten i Tailscale?
Med Tailscales nuvarande beteende behöver annonserade subnätsrutter normalt godkännas i administratörskonsolen, om inte en autoApprovers policyn hanterar dem automatiskt.
Ska jag kopiera 192.168.2.0/24 från skärmbilden?
Nej. Använd det faktiska subnätet för det LAN som du vill exponera. Värdet på skärmbilden tillhör en annan communitymedlems nätverk.
