Un container Tailscale può risultare connesso senza funzionare come router subnet. In questa discussione di ZimaOS dell’aprile 2026, Tailscale era in esecuzione in Docker con rete host, modalità privilegiata e /dev/net/tun montato, ma la console di amministrazione Tailscale indicava che la macchina non esponeva alcuna route. Navidrome funzionava sulla rete locale, ma non era raggiungibile da remoto attraverso la tailnet.
La discussione non si è conclusa con una correzione confermata dall’autore del post originale. Invece, un altro membro della community ha condiviso una configurazione funzionante di un container Tailscale per BigBear, che pubblicizzava correttamente una subnet LAN nel proprio ambiente ZimaOS. Questa configurazione è utile come riferimento per la risoluzione dei problemi, ma non costituisce una garanzia supportata da IceWhale per ogni pacchetto app Tailscale.
Essere connessi a Tailscale non significa che le route subnet siano pubblicizzate
La configurazione originale aveva già completato l’autenticazione del dispositivo. Il problema riguardava specificamente il routing: i log mostravano un elenco di route vuoto e la console di amministrazione Tailscale non offriva alcuna route subnet da approvare.
Questa distinzione è importante perché un normale nodo Tailscale si limita a unirsi alla tailnet. Un router subnet ha responsabilità aggiuntive: deve pubblicizzare uno o più prefissi LAN e soddisfare i requisiti di routing del sistema operativo necessari per inoltrare il traffico tra la tailnet e quella LAN.
La documentazione attuale di Tailscale descrive i router subnet come gateway che pubblicizzano reti private ai dispositivi tailnet. Richiede inoltre l’abilitazione dell’inoltro IP su Linux e l’approvazione della route nella console di amministrazione Tailscale, a meno che una autoApprovers la policy gestisce automaticamente l’approvazione.
Documentazione sui router subnet di Tailscale
Il riferimento funzionante della community utilizzava TS_ROUTES
La risposta di TomasSzwed utilizzava un container Tailscale di BigBear e configurava la subnet tramite variabili d’ambiente, invece di affidarsi a un comando manuale eseguito una sola volta dopo l’avvio. Gli elementi principali di quel riferimento includevano:
-
network_mode: host; - modalità privilegiata;
-
/dev/net/tunmontato nel container; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24per la LAN pubblicizzata; -
TS_EXTRA_ARGS=--accept-routesnella configurazione di quell’utente; - stato persistente di Tailscale in
/var/lib/tailscale.
Usa il prefisso LAN corretto per la tua rete
L’esempio funzionante pubblicizzava 192.168.2.0/24. Quel valore ha senso solo per una LAN che utilizza quella subnet. Una rete domestica diversa potrebbe usare 192.168.1.0/24, 10.0.0.0/24, o un altro prefisso privato.
Pubblicizzare la subnet sbagliata può produrre un nodo Tailscale integro, ma comunque incapace di instradare verso i servizi ZimaOS desiderati. Determina il prefisso effettivo della rete locale prima di impostare TS_ROUTES o un equivalente --advertise-routes opzione.
Le route pubblicizzate devono ancora diventare attive
Le indicazioni attuali di Tailscale distinguono tra pubblicizzazione e approvazione delle route. Una volta che il router per sottoreti pubblicizza una route, questa deve essere abilitata nella console di amministrazione di Tailscale, a meno che la policy della tailnet non la approvi automaticamente.
Se la console di amministrazione indica che la macchina non espone alcuna route, concentrati innanzitutto sulla configurazione del container per la pubblicizzazione delle route. Se la route appare, ma il traffico continua a non funzionare, verifica l'approvazione della route, la policy di controllo degli accessi, l'inoltro e il servizio di destinazione.
La configurazione di rete Docker determina ciò che il container può instradare
L'autore originale utilizzava la rete dell'host e montava il dispositivo TUN. Anche il riferimento della community faceva lo stesso. La documentazione attuale di Tailscale supporta inoltre l'esecuzione di Tailscale in Docker, ma la rete Docker e il routing di Tailscale sono livelli separati, che devono essere entrambi configurati correttamente.
Documentazione Docker di Tailscale
Non dare per scontato che due app Tailscale nell'App Store di ZimaOS utilizzino definizioni di container identiche. L'autore originale ha notato in particolare che l'esempio condiviso usava il pacchetto Tailscale di BigBear, mentre l'installazione esistente utilizzava l'altra voce Tailscale.
Cosa significa per Navidrome e per gli altri servizi locali
L'obiettivo della discussione originale era accedere a Navidrome da un iPhone senza configurare il port forwarding pubblico. Se Navidrome è già raggiungibile sulla LAN locale, un router per sottoreti funzionante può rendere quell'indirizzo LAN raggiungibile dai dispositivi autorizzati della tailnet.
Tuttavia, la discussione non conferma che l'autore originale abbia completato il passaggio alla configurazione BigBear o che abbia raggiunto Navidrome con successo in seguito. La pagina documenta quindi un riferimento valido fornito dalla community e un modello diagnostico, non una soluzione confermata per quella specifica installazione.
Domande frequenti sul subnet routing di Tailscale in ZimaOS
Perché Tailscale indica che è connesso, ma non mostra alcuna route per le sottoreti?
L'accesso alla tailnet e la pubblicizzazione di una route LAN sono operazioni diverse. Nel caso di origine, l'autenticazione è riuscita, ma l'elenco delle route è rimasto vuoto.
Tailscale in Docker può fungere da router per sottoreti su ZimaOS?
Un membro della community ha riferito che ha funzionato nella sua configurazione ZimaOS e ha condiviso una configurazione Tailscale di BigBear. Anche Tailscale supporta il subnet routing e le distribuzioni Docker, ma la configurazione esatta dell'app ZimaOS è comunque importante.
Devo approvare la route in Tailscale?
Secondo il comportamento attuale di Tailscale, le route delle sottoreti pubblicizzate normalmente richiedono l'approvazione nella console di amministrazione, a meno che una autoApprovers la policy li gestisce automaticamente.
Devo copiare 192.168.2.0/24 dallo screenshot?
No. Usa la sottorete effettiva della LAN che vuoi esporre. Il valore nello screenshot appartiene alla rete di un altro membro della community.
