Un container VPN può connettersi a una rete remota mentre l’host ZimaOS rimane completamente ignaro di quella route. Questo era il problema descritto nel thread originale di settembre 2025. Il container Tailscale dell’utente si era unito correttamente alla tailnet, ma ZimaOS — e quindi l’app File e il flusso di lavoro per montare con SMB dall’host — non riusciva a raggiungere il server CasaOS remoto attraverso lo spazio dei nomi di rete del container.
L’utente ha risolto il problema pratico del backup modificando l’architettura, invece di forzare il container Tailscale a diventare una VPN dell’host. Ha aggiunto il server CasaOS remoto alla rete ZeroTier associata a ZimaOS e ha riferito che l’accesso SMB funzionava correttamente.
La topologia originale aveva due server remoti
La configurazione descritta era:
- ZimaBlade con ZimaOS come macchina sorgente;
- server remoto con CasaOS come destinazione del backup SMB;
- Tailscale per collegare i due siti.
Quando entrambe le macchine eseguivano CasaOS, l’utente aveva installato Tailscale direttamente sugli host e montato normalmente la condivisione SMB remota.
Il container Tailscale si è unito alla tailnet, ma ZimaOS no
Su ZimaOS, l’utente eseguiva Tailscale in Docker. Questo forniva connettività al container Tailscale stesso, ma non aggiungeva automaticamente route o indirizzi Tailscale allo spazio dei nomi di rete dell’host ZimaOS.
Di conseguenza, l’app File non poteva semplicemente esplorare un server SMB raggiungibile solo dall’interno del container Tailscale.
Si tratta di un confine tra spazi dei nomi di rete, non di un problema di password SMB
Normalmente un container Docker dispone di interfacce, route e contesto firewall propri. Anche se il container riesce a eseguire il ping di un indirizzo remoto della tailnet, le applicazioni dell’host non ereditano quelle route, a meno che la VPN non sia stata integrata intenzionalmente con il networking dell’host, con il routing o con un’architettura basata su proxy.
Modificare le credenziali SMB non risolverebbe l’assenza della route.
L’utente ha spostato il server CasaOS remoto su ZeroTier
Dopo ulteriori ricerche, l’autore del post originale ha installato ZeroTier sul server CasaOS remoto e lo ha aggiunto alla rete virtuale utilizzata da ZimaOS. Ha poi dichiarato che il server remoto riusciva ad accedere alla condivisione SMB e che la soluzione funzionava bene.
Il comando di installazione esatto riportato nel forum era un suggerimento fornito dalla community. L’architettura riutilizzabile è più importante che copiare quello specifico script di installazione in una sola riga.
L’accesso remoto attuale a ZimaOS si basa su una rete virtuale basata su ZeroTier
La documentazione attuale di IceWhale descrive il Login remoto/Network ID di ZimaOS come un’identità di rete ZeroTier. ZimaClient utilizza questa rete virtuale per la connettività remota crittografata.
Questo fa apparire la soluzione dell’utente originale meno simile a una semplice soluzione alternativa di quanto potrebbe sembrare: invece di cercare di esportare una route Tailscale da Docker all’host, il NAS remoto si unisce alla rete virtuale che ZimaOS utilizza già a livello dell’host.
IceWhale documenta ora lo stesso schema con altre piattaforme NAS
La documentazione attuale di ZimaOS per la sincronizzazione con QNAP indica agli utenti di ottenere il Network ID di ZimaOS, installare ZeroTier sul lato QNAP e aggiungere quel dispositivo all’ID prima di creare un’attività di sincronizzazione tra reti diverse.
Utilizza lo schema attuale di rete ZeroTier tra NAS diversi come riferimento architetturale supportato.
Un’opzione Tailscale a livello dell’host è una soluzione diversa
Progetti community più recenti hanno distribuito Tailscale come systemd-sysext nativa per ZimaOS, con l’obiettivo specifico di fornire all’host una vera interfaccia TUN e supportare il routing a livello dell’host. Questo può risolvere la limitazione dello spazio dei nomi originale, ma si tratta di software della community, non di una funzionalità Tailscale ufficiale di ZimaOS.
Se l’obiettivo è soltanto eseguire un backup SMB remoto, aggiungere il server remoto alla rete virtuale esistente di ZimaOS potrebbe essere più semplice che installare una nuova estensione VPN a livello dell’host.
La raggiungibilità a livello dell’host deve esistere prima che File possa montare SMB
Qualunque rete overlay tu scelga, l’host ZimaOS deve poter instradare il traffico verso l’indirizzo del server SMB remoto. Solo a quel punto il nome della condivisione SMB, il nome utente, la password e i permessi diventano il livello successivo della risoluzione dei problemi.
Considera la destinazione SMB remota parte del perimetro di sicurezza del backup
Una condivisione di backup raggiungibile tramite una rete overlay dovrebbe comunque richiedere l’autenticazione e dovrebbe esporre solo le cartelle necessarie al flusso di lavoro del backup. Evita di rendere scrivibile l’intero server remoto solo perché il traffico è crittografato.
Domande frequenti sull’SMB remoto tramite reti overlay
Perché il container Tailscale riusciva a raggiungere il server remoto mentre File di ZimaOS non ci riusciva?
Il container aveva uno spazio dei nomi di rete e route propri; l’host ZimaOS non li ereditava automaticamente.
Che cosa ha usato invece l’autore del post originale?
Ha aggiunto il server CasaOS remoto alla rete ZeroTier utilizzata da ZimaOS e ha riferito che funzionava bene.
ZimaOS utilizza ZeroTier per il networking remoto?
La documentazione attuale di IceWhale descrive il Network ID per il Login remoto e i flussi di lavoro tra NAS diversi utilizzando una rete virtuale basata su ZeroTier.
