Un container Tailscale permanente dovrebbe rimanere la stessa macchina nella console di amministrazione di Tailscale dopo un riavvio di ZimaOS o una modifica dell'applicazione. Nel thread della fonte, risalente a settembre 2025, non accadeva: ogni riavvio o nuova distribuzione creava un altro nodo Tailscale, anche se il file Compose aveva già montato /var/lib/tailscale allo spazio di archiviazione persistente di AppData di ZimaOS.
Il risultato finale della fonte è importante perché restringe la causa. L'autore del post originale ha affermato che lo spazio di archiviazione persistente era già configurato correttamente; l'unica modifica necessaria è stata eliminare la variabile d'ambiente della chiave di autenticazione fornita continuamente. Dopodiché, l'identità del nodo Tailscale è rimasta persistente.
Tailscale richiede uno stato persistente della macchina
Tailscale memorizza l'identità del nodo, le chiavi e lo stato della connessione nella propria directory dello stato. In Docker, il percorso viene comunemente configurato con:
TS_STATE_DIR=/var/lib/tailscaleSe quella directory esiste solo nel file system temporaneo del container, la sua ricreazione genera una nuova identità Tailscale.
La fonte aveva già montato la directory dello stato
Il file Compose originale includeva:
/DATA/AppData/tailscale:/var/lib/tailscaleinsieme a TS_STATE_DIR=/var/lib/tailscalela rete dell'host, NET_ADMIN, NET_RAWe l'accesso a /dev/net/tun. In teoria, questo dovrebbe preservare lo stato.
Una chiave di autenticazione serve per la registrazione, non necessariamente per ogni riavvio
Il file Compose forniva anche TS_AUTHKEY a ogni avvio del container. Un membro della community ha spiegato che la riautenticazione può creare una nuova macchina quando lo stato del nodo esistente non viene riutilizzato come previsto.
Il rispondente ha suggerito di usare una chiave di autenticazione riutilizzabile e non effimera per il primo avvio, attendere che il nodo comparisse nella console di amministrazione, quindi rimuovere la riga della chiave di autenticazione e ridistribuire il container, così che lo stato della macchina salvato diventasse la fonte dell'identità.
L'autore del post originale ha confermato che la rimozione della chiave di autenticazione ha risolto il problema
La risposta finale della fonte afferma che gli altri elementi della persistenza erano già configurati correttamente e che era sufficiente eliminare la variabile d'ambiente della chiave di autenticazione. Il nome della macchina è quindi rimasto invariato dopo i riavvii.
Questa conferma è più solida di un'ipotesi generica sui permessi. Per questa installazione specifica, il fattore pratico scatenante era la riautenticazione ripetuta.
Tailscale attualmente fornisce TS_AUTH_ONCE
Le moderne distribuzioni Docker di Tailscale possono usare TS_AUTH_ONCE=true. Quando esiste già uno stato persistente, indica al container di non forzare un altro accesso ogni volta che si avvia.
Consulta gli attuali parametri Docker per lo stato e l’autenticazione di Tailscale prima di riutilizzare invariato un file Compose del 2025.
Usa una cartella dedicata sull’host per lo stato
Una directory dedicata sull’host, come una cartella AppData/stato di Tailscale, facilita la verifica che le chiavi della macchina sopravvivano alla ridistribuzione. Il responsabile della risposta nella fonte ha inoltre raccomandato di assicurarsi che la cartella sia scrivibile dal processo che archivia lo stato di Tailscale.
Le autorizzazioni sono importanti perché un volume può essere montato correttamente mentre il processo non riesce comunque ad aggiornare i suoi file. In questa situazione, Tailscale può comportarsi come se la macchina non disponesse di uno stato riutilizzabile.
Evita le chiavi di autenticazione effimere per un server permanente
Tailscale supporta nodi effimeri, intenzionalmente temporanei. Sono utili per processi CI di breve durata o container usa e getta, ma sono l’opposto di ciò che serve a un server ZimaOS permanente.
Quando crei una credenziale, verifica che corrisponda al ciclo di vita previsto. Un server domestico persistente dovrebbe normalmente conservare la stessa identità finché non decidi deliberatamente di revocarla o sostituirla.
TS_HOSTNAME non definisce l’identità della macchina
Il container della fonte utilizzava TS_HOSTNAME=zimaos. Questa impostazione controlla il nome descrittivo presentato alla tailnet, ma mantenere la stessa stringa del nome host non preserva l’identità crittografica della macchina. Due macchine appena autenticate possono tentare entrambe di usare nomi simili pur rimanendo nodi separati.
Testare sia il riavvio sia la ridistribuzione dell’app
Il problema originale si verificava sia dopo i riavvii completi del sistema operativo sia dopo le modifiche all’app di ZimaOS. Una soluzione corretta deve quindi superare entrambi:
- riavviare il container Tailscale;
- modificare e ridistribuire l’app senza cambiare il volume dello stato;
- riavviare ZimaOS;
- verifica che la stessa macchina sia ancora online nella console di amministrazione di Tailscale.
Se compare un duplicato dopo uno solo di questi eventi, confronta cosa accade alla directory dello stato durante quella specifica operazione del ciclo di vita.
Domande frequenti sulla persistenza di Tailscale
Perché veniva creata una nuova macchina Tailscale dopo ogni riavvio?
Nel caso della fonte, il volume dello stato esisteva già e l’uso ripetuto della chiave di autenticazione era il problema pratico rimanente.
Quale percorso deve essere persistente?
Il percorso configurato da TS_STATE_DIR, comunemente /var/lib/tailscale all’interno del container.
TS_AUTHKEY deve rimanere per sempre nell’ambiente?
Non necessariamente. L’utente della fonte ha risolto i nodi duplicati rimuovendolo dopo l’autenticazione iniziale, e l’attuale Tailscale offre anche TS_AUTH_ONCE.
TS_HOSTNAME preserva l’identità del nodo?
No. Lo stato della macchina Tailscale memorizzato è ciò che ne preserva l’identità.
