Un utente ZimaOS riteneva che Tailscale avesse smesso di funzionare dopo il primo avvio perché la pagina dell’app mostrava “servizio non disponibile” e un telefono non riusciva a raggiungere i servizi del server domestico. La diagnostica del container ha mostrato un risultato diverso: Tailscale era in esecuzione, il dispositivo era autorizzato e i mount dello stato e del tunnel erano presenti.
Il problema confermato era l’indirizzo utilizzato dal telefono. L’utente stava cercando di raggiungere un normale indirizzo LAN domestico senza aver configurato il routing delle subnet. La connessione al servizio tramite l’indirizzo Tailscale del dispositivo ZimaOS 100.x.x.x l’indirizzo funzionava.
Il container Tailscale non aveva avuto problemi
Il sintomo iniziale suggeriva che il container si fosse arrestato dopo un riavvio, ma lo stato raccolto mostrava:
- Lo stato del container era “in esecuzione”, con codice di uscita 0.
- Tailscale è passato da Avvio in corso a In esecuzione.
- La macchina era autorizzata nel tailnet dell’utente.
- La directory dello stato persistente era stata mappata nel container.
- Anche il dispositivo TUN richiesto da Tailscale era stato mappato.
- Il dispositivo ha ricevuto un indirizzo IPv4 Tailscale e riusciva a vedere i peer.
Questa evidenza ha distinto un messaggio della pagina dell’app o dell’interfaccia web di ZimaOS dallo stato di salute del demone Tailscale.
Perché i primi tentativi diagnostici hanno mostrato “Permesso negato”
La sessione del terminale utilizzava un normale utente ZimaOS. Il primo elenco Docker è stato eseguito con privilegi elevati, ma i comandi successivi hanno tentato di accedere al socket Docker senza tali privilegi e hanno quindi restituito errori di autorizzazione. Le virgolette curve copiate dal forum hanno inoltre impedito la corretta interpretazione di alcune sostituzioni di comando.
Quei messaggi relativi alle autorizzazioni descrivevano la sessione diagnostica, non un errore di runtime di Tailscale. L’output successivo, ottenuto con i privilegi appropriati, ha mostrato che il container era integro.
Un indirizzo della LAN domestica non è automaticamente un indirizzo Tailscale
Un indirizzo come 10.0.0.93 appartiene alla LAN domestica. Un telefono connesso da remoto allo stesso tailnet non ottiene automaticamente una route verso ogni indirizzo LAN privato.
Tailscale assegna a ogni nodo un proprio indirizzo, generalmente nell’intervallo 100.x.x.x. La documentazione ufficiale degli indirizzi IP di Tailscale spiega che questi indirizzi identificano i dispositivi all’interno del tailnet e rimangono separati dal normale indirizzamento LAN.
Il metodo di connessione che ha funzionato
Il risponditore ha chiesto all’utente di connettersi all’applicazione utilizzando l’IP Tailscale del nodo ZimaOS e la porta dell’applicazione:
http://TAILSCALE-IP:APP-PORTAd esempio, un servizio sulla porta 8096 userebbe un URL strutturato così:
http://100.x.x.x:8096Anche il telefono deve aver effettuato l’accesso allo stesso tailnet ed essere connesso attivamente a Tailscale. L’utente ha confermato che questo indirizzo funzionava, dimostrando che Tailscale funzionava correttamente.
Quando è necessario il routing delle subnet
Se l’obiettivo è raggiungere i dispositivi tramite i loro indirizzi LAN esistenti, ad esempio 10.0.0.x—un dispositivo su quella rete deve annunciare la sottorete LAN come percorso e il percorso deve essere approvato in base alla configurazione della tailnet.
Questa configurazione è diversa dal raggiungere direttamente l’host ZimaOS tramite il suo indirizzo IP Tailscale. Consulta la documentazione ufficiale sui router di sottorete di Tailscale prima di aspettarti che i normali indirizzi LAN funzionino da remoto.
Perché la pagina dell’app poteva continuare a indicare “Servizio non disponibile”
Un controllo della disponibilità tramite interfaccia web può fallire anche quando il daemon di rete è in esecuzione. Nel caso originale, le prove decisive erano lo stato di esecuzione, l’autorizzazione riuscita nella tailnet, l’indirizzo IP Tailscale assegnato, i peer visibili e una connessione funzionante al servizio remoto.
Cambiare casualmente le porte dell’app, eliminare lo stato di Tailscale o reinstallare ripetutamente il container non avrebbe risolto un indirizzo di destinazione errato. Verifica lo stato del daemon e il metodo di connessione prima di reimpostare un’identità funzionante.
Perché la connessione funzionante poteva sembrare lenta
La risposta finale suggeriva che la connessione potrebbe utilizzare un relay DERP invece di un percorso peer-to-peer diretto. Il traffico Tailscale inoltrato può funzionare correttamente, offrendo però una velocità inferiore o una latenza maggiore, a seconda delle reti, dei router e della regione di relay disponibile.
La sola lentezza non dimostra che il container stia avendo problemi. Verifica innanzitutto se la connessione funziona e se Tailscale segnala un percorso diretto o inoltrato, quindi analizza il comportamento di NAT e firewall se le prestazioni sono importanti.
Un ordine di diagnostica più sicuro
- Controlla se il container Tailscale è in esecuzione, invece di basarti solo sullo stato mostrato nella pagina dell’app.
- Verifica che il nodo ZimaOS risulti autorizzato e online nella stessa tailnet del telefono.
- Identifica l’indirizzo Tailscale del nodo ZimaOS
100.x.x.xindirizzo tramite l’interfaccia Tailscale o la console di amministrazione. - Connettiti al servizio di destinazione utilizzando quell’indirizzo Tailscale e la porta del servizio.
- Configura il routing delle sottoreti solo se è necessario accedere tramite i normali indirizzi della LAN domestica.
- Analizza separatamente l’uso del relay DERP se la connessione funziona ma è lenta.
FAQ sulla connessione Tailscale di ZimaOS
“Servizio non disponibile” dimostra che Tailscale si è arrestato?
No. In questo caso, il container era in esecuzione, autorizzato e connesso, anche se la pagina dell’app mostrava quel messaggio.
Perché cambiare la porta dell’app Tailscale non ha risolto il problema?
Il problema era l’indirizzo di destinazione, non un normale conflitto sulla porta dell’app web. L’utente aveva bisogno dell’indirizzo IP Tailscale del nodo.
Quale indirizzo deve usare un telefono remoto?
Usa Tailscale del nodo ZimaOS 100.x.x.x indirizzo più la porta dell’applicazione, a meno che non sia stato configurato un router di sottorete per gli indirizzi LAN.
Perché un indirizzo 10.0.0.x non funziona tramite Tailscale?
È un indirizzo privato della LAN domestica. Per raggiungere quella sottorete da remoto è necessario un percorso di sottorete annunciato e approvato.
Perché una connessione Tailscale funzionante può essere lenta?
La connessione potrebbe essere inoltrata tramite DERP invece di utilizzare un percorso peer-to-peer diretto.
