Come cachito labs costruisce un firewall OPNsense su ZimaBoard 2

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Grazie a cachito labs per aver documentato questo interessante progetto con ZimaBoard 2. Nel suo video originale del progetto, un problema con l’ISP diventa una lezione pratica su routing, criteri del firewall, privacy DNS e uscita tramite VPN. L’idea utile non è semplicemente copiare una configurazione, ma capire come un piccolo computer dedicato possa diventare il punto di controllo dell’intera rete domestica.

Questa guida è particolarmente utile se il gateway del tuo ISP ti offre poco controllo sul routing o sulla privacy. Segue il passaggio da una connessione rivolta al provider a ZimaBoard 2 con OPNsense, quindi mostra come le regole del firewall, le scelte DNS e il routing tramite VPN modifichino il comportamento della rete. Le sezioni seguenti trasformano quel progetto in una guida decisionale riutilizzabile, anziché in una trascrizione minuto per minuto.

Nota sulla collaborazione: La descrizione del video originale include una dichiarazione di affiliazione per prodotti o servizi eventualmente citati nel progetto. L’articolo seguente riassume la configurazione e l’uso previsti da cachito labs; le versioni software, i dettagli dell’interfaccia, i bundle hardware e la compatibilità possono cambiare dopo la pubblicazione.

Il risultato: ZimaBoard 2 Mini Home Server  non è un sostituto in miniatura di un server rack con molti core. Il suo punto di forza è combinare funzionamento silenzioso, doppia connettività 2.5GbE, archiviazione SATA diretta ed espansione PCIe aperta in un piccolo sistema x86 a cui assegnare un ruolo ben definito nella rete domestica: un firewall OPNsense e dispositivo di routing dedicato.

Durante la visione, concentrati su tre cambiamenti collegati: ZimaBoard 2 diventa il gateway di rete, OPNsense separa i criteri di firewall e NAT dal comportamento DNS, e la VPN crea un’identità di uscita diversa per il traffico selezionato. Questi livelli spiegano perché il progetto possa ridurre la visibilità dell’ISP senza promettere l’anonimato assoluto.

Quando un ISP insiste per controllare il dispositivo di frontiera, ciò che si perde davvero sono visibilità e possibilità di scelta. Un firewall separato ripristina entrambe. ZimaBoard 2 si trova tra la connessione del provider e il resto della rete domestica, mentre OPNsense decide quale traffico è consentito, dove viene indirizzato e quali servizi devono risolvere i nomi o uscire tramite una VPN. Questa separazione rende la rete più facile da comprendere e da modificare in seguito.

Perché un problema con l’ISP è diventato un progetto firewall

Il progetto inizia con una frustrazione comune nelle reti domestiche: il provider non vuole che il cliente utilizzi il proprio router come dispositivo di frontiera. Invece di trattare il gateway dell’ISP come il cervello della rete, cachito labs trasferisce routing e criteri su hardware controllato dal proprietario. Il risultato è un confine chiaro: l’ISP fornisce la connettività, mentre il firewall locale gestisce la rete privata.

Questa distinzione è importante perché un gateway tutto-in-uno nasconde diversi compiti dietro un’unica interfaccia. Routing, traduzione degli indirizzi, inoltro DNS, accesso wireless e regole di sicurezza possono essere tutti raggruppati. Un firewall dedicato espone invece queste funzioni come decisioni separate. Puoi sostituire il punto di accesso senza cambiare il router, inviare solo determinati dispositivi attraverso una VPN oppure modificare il comportamento DNS senza riprogettare l’intera LAN.

Perché ZimaBoard 2 è adatto al ruolo di firewall

Un firewall non deve assomigliare a un PC desktop. Ha bisogno di interfacce di rete affidabili, di sufficiente margine di elaborazione per i servizi scelti e di un formato fisico che possa rimanere acceso 24 ore su 24. ZimaBoard 2 è una piattaforma x86 compatta con doppia connettività 2.5GbE, quindi è naturalmente adatta a funzionare come dispositivo a due lati: una porta verso l’ISP o il modem upstream e l’altra verso lo switch interno.

L’hardware è soltanto la base. Un dispositivo di frontiera dedicato modifica anche il modello di guasto. Se si riavvia o perde alimentazione, l’intera casa potrebbe perdere la connettività; perciò il progetto dovrebbe includere un piano di ripristino: conserva un backup di configurazione funzionante, etichetta entrambi i collegamenti Ethernet e assicurati che l’amministrazione locale rimanga possibile quando la WAN non è disponibile. L’hardware compatto è pratico, ma merita comunque una gestione all’altezza di un’infrastruttura.

L’architettura di rete deve essere corretta prima che le regole diventino importanti

Prima di scrivere una regola del firewall, traccia il percorso che dovrebbe seguire un pacchetto. L’interfaccia upstream riceve l’indirizzo del provider, l’interfaccia downstream gestisce la subnet privata e ogni client utilizza l’indirizzo di ZimaBoard 2 come gateway predefinito. Se questi rapporti sono errati, un set di regole dall’aspetto perfetto non potrà correggere la topologia.

Architettura di rete con ZimaBoard 2 che esegue OPNsense tra la connessione ISP e la rete domestica
L’architettura è il fondamento: OPNsense diventa l’unico gateway tra la connessione del provider e la LAN privata.

È proprio questa posizione come gateway a permettere al firewall di vedere il traffico di ogni dispositivo gestito. Può applicare un unico criterio all’intera abitazione oppure criteri più specifici a VLAN, server, workstation e dispositivi per la smart home. Il design rende anche la risoluzione dei problemi più sistematica: verifica prima la WAN, poi il gateway LAN, quindi il DNS e solo dopo analizza i problemi a livello applicativo.

Installare OPNsense su un dispositivo di frontiera dedicato

Installare OPNsense su un piccolo computer x86 è un modo pratico per trasformare hardware generico in un router progettato per uno scopo preciso. L’immagine viene scritta su un’unità avviabile, il dispositivo viene avviato da quel supporto e il programma di installazione colloca il sistema operativo sull’archiviazione interna. Al termine del primo avvio, la console serve ad assegnare le interfacce fisiche prima che subentri il pannello web.

L’assegnazione delle interfacce è il momento in cui conviene procedere con calma. Un’etichetta come “WAN” o “LAN” è utile solo se corrisponde al cavo e alla porta effettivi. Verifica lo stato del collegamento, collega un lato alla volta e mantieni semplice la configurazione iniziale. In seguito potrai aggiungere altre reti e servizi senza dover indovinare quale interfaccia fisica li trasporta.

Interfacce, gateway, NAT e primo percorso funzionante

Una volta assegnate le interfacce, OPNsense ha bisogno di un gateway upstream e di un indirizzo LAN privato. L’indirizzo LAN diventa la route predefinita per i client, mentre il gateway WAN punta verso l’apparecchiatura dell’ISP. La traduzione degli indirizzi consente quindi ai client privati di condividere la connessione upstream, secondo il normale schema di una rete domestica dietro un unico indirizzo pubblico.

A questo punto, verifica la connettività di base prima di aggiungere funzioni per la privacy. Un client dovrebbe ricevere un indirizzo, raggiungere il pannello del firewall, risolvere un nome di prova e accedere a Internet. Testare separatamente questi livelli evita che una modifica a VPN o DNS nasconda un errore più semplice di cablaggio, DHCP o gateway.

Le regole del firewall e la privacy DNS sono livelli diversi

Le regole del firewall rispondono alla domanda “quale traffico è consentito?”. Il NAT risponde a “come fa il traffico privato a condividere l’indirizzo upstream?”. Le impostazioni DNS rispondono a “quale resolver gestisce la ricerca di un nome?”. Questi controlli interagiscono, ma non sono intercambiabili. Consentire il traffico in uscita non cifra il DNS e scegliere un resolver cifrato non invia automaticamente tutto il traffico applicativo attraverso una VPN.

Configurazione del firewall OPNsense che mostra i controlli di routing e NAT per la rete ZimaBoard 2
OPNsense espone i criteri di firewall, NAT e routing come controlli separati, che possono essere testati un livello alla volta.

Una base sensata consiste nel consentire il traffico di ritorno relativo a connessioni già stabilite, autorizzare solo i servizi in uscita necessari alla rete e mantenere l’amministrazione accessibile da un segmento di gestione affidabile. Il DNS può quindi essere indirizzato verso un resolver scelto, abilitando il trasporto cifrato quando supportato. L’obiettivo non è creare una rete magicamente “invisibile”, ma ridurre e rendere più deliberato l’insieme dei soggetti che possono osservare o influenzare ciascun livello.

Il routing tramite VPN modifica l’identità di uscita

La parte VPN del progetto modifica il percorso di uscita della rete. Invece di inviare direttamente all’ISP il traffico selezionato, OPNsense stabilisce un tunnel e vi instrada i client o le destinazioni corrispondenti. I servizi esterni vedranno quindi l’indirizzo di uscita del provider VPN anziché il consueto indirizzo pubblico domestico.

Vista del routing VPN in OPNsense che mostra il traffico in uscita dal firewall ZimaBoard 2 attraverso un tunnel
Un gateway VPN può diventare il percorso di uscita selezionato per i dispositivi o le reti che ne hanno bisogno.

Questo migliora la separazione dall’ISP, ma non equivale all’anonimato totale. L’ISP può comunque osservare la connessione al servizio VPN e le caratteristiche generali del traffico. Il provider VPN diventa un altro soggetto di cui fidarsi e i siti web possono ancora identificare gli utenti tramite account, cookie, browser o impronte digitali dei dispositivi. Una buona configurazione parte quindi da una domanda precisa: quale traffico ha bisogno di un’uscita diversa e per quale motivo?

Un case stampato in 3D e il posizionamento nel rack rendono il progetto pratico

Il contenitore fisico non è solo decorativo. Protegge la scheda, mantiene stabili i collegamenti Ethernet e facilita il montaggio del firewall nel punto in cui si trovano già modem e switch. Anche il posizionamento nel rack favorisce una separazione ordinata tra dispositivo di frontiera, punti di accesso wireless, archiviazione e altri server.

Lascia spazio per il flusso d’aria e per gli interventi di manutenzione, soprattutto se la scheda funzionerà senza interruzioni. Contrassegna l’alimentatore e i due cavi di rete ed evita di collocare il firewall in un punto in cui un singolo strattone accidentale possa scollegare la WAN. Un dispositivo di rete compatto ha successo quando rimane comprensibile anche sei mesi dopo il progetto iniziale.

Cosa nasconde questa configurazione e cosa invece non nasconde

Installare OPNsense su ZimaBoard 2 può nascondere all’ISP la struttura interna della rete domestica. Il provider non deve più gestire individualmente ogni client privato; dall’esterno, il firewall di frontiera presenta un confine controllato. Le scelte DNS e il routing VPN possono ridurre la quantità di informazioni sulle destinazioni esposta attraverso il percorso predefinito.

Questi vantaggi hanno dei limiti. L’ISP fornisce comunque il collegamento fisico, può vedere che la connessione è attiva e potrebbe identificare l’endpoint VPN o altri metadati. Il firewall non può proteggere un client compromesso, impedire il tracciamento effettuato da un servizio a cui hai effettuato l’accesso né garantire che ogni applicazione rispetti il percorso previsto. Considera il progetto come uno strumento di controllo e segmentazione della rete, non come una promessa di privacy assoluta.

Chi dovrebbe realizzare un firewall OPNsense con ZimaBoard 2?

Questo design è ideale per una famiglia tecnicamente curiosa che desidera controllare routing, DNS, criteri VPN e futura segmentazione senza acquistare un grande dispositivo enterprise. È utile anche in un laboratorio in cui diversi servizi hanno bisogno di una rete prevedibile e il proprietario vuole comprendere il percorso seguito da ogni pacchetto.

È meno adatto quando la priorità è la totale assenza di manutenzione. Un gateway gestito potrebbe essere la scelta migliore per chi non desidera occuparsi di aggiornamenti, backup, certificati, credenziali VPN e procedure di ripristino. Per tutti gli altri, la combinazione di una scheda a basso consumo e di una piattaforma firewall trasparente offre un pratico compromesso tra un dispositivo dell’ISP e un server rack completo.

Considerazione finale

Il progetto di cachito labs dimostra perché un piccolo computer possa avere un effetto enorme su una rete domestica. ZimaBoard 2 fornisce la piattaforma compatta a doppia interfaccia; OPNsense fornisce il motore dei criteri; il proprietario decide come combinare DNS, NAT, regole del firewall e route VPN. La lezione più duratura è architetturale: stabilisci prima un gateway corretto, testa ogni livello in modo indipendente, quindi aggiungi funzioni di privacy e routing comprendendo chiaramente cosa ciascuna di esse può nascondere e cosa invece non può nascondere.

Per un progetto di frontiera simile e a basso consumo, scopri ZimaBoard 2Mini Home Server . Per la documentazione del firewall, visita il sito ufficiale di OPNsense. Se vuoi confrontare le configurazioni e condividere la tua configurazione home server, entra nella community Discord di ZimaSpace.

Centro Campagne Zima

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.