L'utente originale è riuscito a far funzionare la propria topologia, ma il risultato deve essere descritto accuratamente: lo script ha creato un bridge Ethernet di livello 2 Linux br0 tra due interfacce fisiche. Non ha configurato un router NAT tradizionale con inoltro IP e masquerading.
La soluzione era inoltre fragile, secondo quanto ammesso dallo stesso autore. Arrestava NetworkManager, eliminava gli indirizzi, ricreava manualmente il bridge, dipendeva dai nomi delle interfacce e da un gateway/indirizzo IP codificato, e doveva essere eseguita nuovamente dopo ogni riavvio. In seguito IceWhale ha risposto che, nel breve termine, non era prevista una funzione bridge integrata. Consideratela una sperimentazione della community, non una funzione di rete ufficiale attualmente disponibile in ZimaOS.
L'obiettivo era Router → ZimaOS → PC personale
Il NAS disponeva di più porte Ethernet. Una era collegata al router a monte e un'altra direttamente al PC personale. L'utente voleva che il PC rimanesse sulla stessa LAN attraverso la macchina ZimaOS.
Un bridge non è la stessa cosa del NAT
Un bridge collega segmenti Ethernet al livello 2, permettendo ai dispositivi di rimanere nella stessa sottorete IP e di utilizzare il DHCP/gateway del router a monte. Il NAT, invece, instrada il traffico tra reti IP diverse e riscrive gli indirizzi.
I comandi originali usavano brctl addbr e brctl addif; non erano presenti regole NAT/masquerade.
Lo script originale sostituiva temporaneamente la gestione di rete di ZimaOS
Lo script arrestava NetworkManager, eliminava gli indirizzi da un'interfaccia, creava br0, aggiungeva entrambe le schede di rete, assegnava un indirizzo statico per la gestione e impostava una route predefinita.
Questo può interrompere immediatamente la gestione remota se i nomi delle interfacce, il gateway, la sottorete o i comandi del bridge sono errati.
Il bridge non era persistente
L'utente ha dichiarato esplicitamente che lo script doveva essere eseguito nuovamente dopo ogni riavvio. In seguito ha creato una soluzione alternativa basata su Windows/Plink che si collegava via SSH a ZimaOS per eseguirlo all'avvio del PC.
Codificare le password SSH in chiaro in un file batch di Windows non è una buona pratica di sicurezza attuale.
La successiva forzatura della velocità con ethtool era specifica dell'hardware
L'autore ha aggiunto un comando ethtool per forzare un'interfaccia 10GbE a 10 Gbps full duplex. La forzatura di velocità/duplex può interrompere l'autonegoziazione con alcuni PHY e switch. Utilizzate le normali impostazioni di collegamento negoziate, a meno che l'hardware non richieda una forzatura documentata.
L'autore ha eliminato una soluzione alternativa basata su Docker perché interrompeva l'accesso a Internet
La fonte stessa afferma che è stato rimosso un metodo basato su un container/strumento multifunzione di rete perché l'host perdeva talvolta la connettività a Internet.
L'attuale ZimaOS non documenta questo script come bridge host supportato
La documentazione attuale di IceWhale sulla rete si concentra sulle interfacce fisiche, sull'indirizzamento DHCP/statico e sulla normale gestione della rete.
Utilizzate le informazioni di base aggiornate sulla rete di ZimaOS.
Se vi servono routing/NAT, utilizzate un sistema operativo o un'architettura VM pensati per i router
Per firewall, NAT, routing VLAN, DHCP e multi-WAN, pfSense o OPNsense sono piattaforme router meglio definite. Utilizzare il NAS in linea come bridge non documentato aggiunge un singolo punto di guasto sia per lo storage sia per l'accesso alla rete.
Mantenete un percorso di ripristino per l'IP di gestione di ZimaOS
Quando lo script elimina un'interfaccia e sposta l'indirizzo di gestione su br0, una sessione SSH attiva attraverso quell'interfaccia può interrompersi immediatamente. Eseguite i primi test da una console locale oppure assicuratevi di avere disponibile un altro percorso di gestione sicuramente funzionante.
Annotate gli indirizzi originali delle interfacce e la route predefinita prima di modificarli.
Un bridge di livello 2 può creare loop di rete
Se entrambe le porte del bridge vengono accidentalmente collegate alla stessa rete commutata, la configurazione può creare un loop Ethernet. Senza un comportamento STP corretto, il traffico broadcast può sovraccaricare la LAN.
La topologia originale era una semplice catena router → ZimaOS → PC in linea; non estendete lo script a configurazioni arbitrarie con più switch.
Il router a monte continua a fornire DHCP e il gateway predefinito
Poiché si tratta di un bridge e non di NAT, il PC a valle rimane normalmente nella sottorete del router e riceve la configurazione di rete dal router a monte. ZimaOS inoltra frame Ethernet, non diventa il gateway di una nuova sottorete instradata.
Uno script per bridge a livello host può rompersi dopo modifiche alle interfacce o allo stack di rete
I nomi delle interfacce, il comportamento di NetworkManager, gli strumenti bridge del kernel e l'ordine di avvio possono cambiare tra una versione e l'altra. Eseguite nuovamente i test dopo gli aggiornamenti principali di ZimaOS e non date per scontato che uno script scritto per lo stack di rete del 2025 rimanga compatibile per sempre.
Domande frequenti sul bridge di rete di ZimaOS
Lo script originale ha funzionato per l'utente?
Sì. Ha riferito che il PC ha ottenuto la connettività attraverso il bridge di ZimaOS.
Era NAT?
No. I comandi pubblicati hanno creato un bridge Linux di livello 2.
IceWhale ha detto che sarebbe arrivata presto una funzione bridge integrata?
No. Zima-Giorgio ha detto che non era prevista nel breve termine.
