L'errore principale in questa discussione del settembre 2025 è stato interpretare modprobe tun fallimento come prova che ZimaOS non supportasse affatto TUN. Zima-Jerry ha corretto questa supposizione: nella build dalla fonte, TUN era compilato direttamente nel kernel, quindi non esisteva un elemento tun.ko file sotto /lib/modules per modprobe da caricare.
Tuttavia, il flusso di lavoro specifico dell'utente con Docker come subnet router aveva ancora bisogno del comportamento del dispositivo/modulo previsto da Tailscale. Per questo IceWhale ha modificato il pacchetto in ZimaOS 1.5.0, rendendo TUN un modulo del kernel caricabile. L'autore del post originale ha ripetuto il test il 29 settembre e ha risposto che ora funzionava.
L'utente voleva un subnet router Tailscale da sito a sito
La progettazione descritta nella fonte collegava due sedi fisiche, Messico e Uruguay, e prevedeva che i dispositivi locali di ciascuna sede comunicassero tramite Tailscale senza installare Tailscale su ogni endpoint.
Si tratta di un caso d'uso come subnet router, non semplicemente di «accesso remoto al pannello di controllo di ZimaOS». Un subnet router deve inoltrare i pacchetti tra la tailnet e un'altra sottorete IP.
modprobe non ha rilevato alcun file del modulo tun
L'utente ha eseguito un container Tailscale con privilegi elevati e ha visualizzato:
modprobe: FATAL: Module tun not found in directory /lib/modules/6.12.25Non hanno trovato neppure tun.ko file e non ha visto alcuna voce TUN nell'output dei controlli per l'elenco dei moduli.
IceWhale ha dichiarato che TUN era compilato direttamente nel kernel
La prima risposta ufficiale di Zima-Jerry era esplicita: la funzionalità TUN era integrata direttamente nel kernel, quindi non sarebbe comparsa come un normale file di modulo in /lib/modules/6.12.25.
Questa è una distinzione del kernel Linux: una funzionalità configurata come integrata è presente senza comparire in lsmod o essere caricabile tramite modprobe.
Il supporto integrato non ha risolto completamente il flusso di lavoro del container indicato nella fonte
L'autore del post originale ha risposto che il suo container passava ancora alla modalità in spazio utente e non poteva fornire il comportamento completo di subnet router lato host che desiderava. Ha chiesto in particolare se TUN potesse essere esposto in modo modulare.
Zima-Jerry ha detto che questo avrebbe potuto essere modificato nella versione successiva.
ZimaOS 1.5.0 ha trasformato TUN in un modulo caricabile
Il 28 settembre, Zima-Jerry ha pubblicato che nella nuova versione 1.5.0, tun.ko era diventato un modulo del kernel e ha chiesto all'utente di ripetere il test.
L'autore del post originale ha risposto il giorno seguente: «Grazie, ora funziona.»
Questa è una soluzione confermata dalla fonte e la conclusione più importante della discussione.
La rete in spazio utente di Tailscale è una modalità operativa diversa
La documentazione attuale di Tailscale spiega che i container possono funzionare senza un dispositivo TUN usando la rete in spazio utente. In questa modalità, tailscaled agisce attraverso uno stack/proxy di rete userspace invece di comportarsi come una normale interfaccia tunnel Linux.
Usa l'attuale modello di rete userspace di Tailscale per decidere se TUN nel kernel sia effettivamente necessario.
L'attuale Tailscale può instradare le subnet in modalità kernel o userspace
L'attuale documentazione di Tailscale descrive ora sia l'instradamento delle subnet in modalità kernel sia in modalità userspace/netstack. La modalità kernel su Linux mantiene il normale comportamento di inoltro dei pacchetti e generalmente offre prestazioni migliori; la modalità userspace può anch'essa instradare il traffico, ma termina e genera nuovamente il traffico supportato nel proprio stack di rete.
Per Docker, l'attuale documentazione di Tailscale indica inoltre che TS_USERSPACE è abilitata per impostazione predefinita, mentre la modalità kernel richiede /dev/net/tun e le funzionalità necessarie.
Un dispositivo TUN funzionante non è l'intera configurazione del router di subnet
Un router di subnet Linux richiede anche l'inoltro IP, l'annuncio delle route, l'approvazione delle route nella console di amministrazione Tailscale e regole di accesso tailnet appropriate. Un container che crea correttamente tailscale0 di per sé non significa che i dispositivi LAN remoti possano instradare il traffico attraverso di esso.
Segui il flusso di lavoro attuale del router di subnet Tailscale dopo che il livello kernel/dispositivo di ZimaOS è operativo.
Non applicare all'attuale ZimaOS la diagnosi «tun.ko mancante» della versione 1.4.x
La fonte stessa documenta il limite tra le versioni: il file era assente a causa del modo in cui era stato compilato il kernel della versione 1.4.x, mentre ZimaOS 1.5.0 ha trasformato la funzionalità TUN in un modulo. L'attuale ZimaOS è ormai ben oltre quella versione.
In caso di un errore attuale, controlla le impostazioni correnti del container, la disponibilità del dispositivo TUN, la modalità userspace/kernel, l'inoltro IP e l'approvazione delle route, invece di presumere che sia tornato il problema del pacchetto del kernel del 2025.
FAQ di Tailscale su TUN
Il mancato funzionamento di modprobe tun dimostrava che ZimaOS non supportava TUN?
No. IceWhale ha detto che TUN è stato compilato direttamente nel kernel di origine, anziché essere distribuito come modulo separato.
Che cosa è cambiato in ZimaOS 1.5.0?
Zima-Jerry ha detto tun.ko è diventato un modulo del kernel caricabile.
Il post originale ha confermato che la nuova versione funzionava?
Sì. Hanno ripetuto il test dopo la modifica alla versione 1.5.0 e hanno detto che funzionava.
