Come The Social Dork crea un firewall domestico con OPNsense

Grazie a The Social Dork | Cyber Security per aver condiviso una configurazione di firewall domestico OPNsense su ZimaBoard 2. Una macchina virtuale gestisce il routing e le policy del firewall, un access point fornisce il Wi-Fi e Pi-hole filtra le richieste DNS dei client connessi. Guarda il tutorial originale su YouTube per la dimostrazione completa.

Guarda prima di leggere: Questo video di circa dieci minuti è utile se vuoi separare il gateway di rete dall'access point wireless. Il creator spiega la topologia, avvia OPNsense in Zima Virtual Machine, assegna le interfacce e configura il DHCP, poi verifica il funzionamento di un laptop connesso via Wi-Fi e del relativo filtro DNS.

Il risultato mostrato è un laptop che si connette alla rete tramite il nuovo firewall e usa il filtro DNS scelto. Il video illustra la configurazione del primo client. La preoccupazione iniziale per i dispositivi IoT vulnerabili richiederebbe un'ulteriore segmentazione della rete e policy di accesso; collegare i dispositivi a un'unica nuova rete SSID non li isola automaticamente tra loro.

Decidi quali funzioni deve mantenere il gateway esistente

La discussione sulla topologia distingue tre funzioni che un router tutto in uno può nascondere: la connessione del provider, il confine del firewall con funzioni di routing e l'accesso wireless. Un collegamento Ethernet può alimentare il nuovo firewall, mentre una connessione DSL o via cavo richiede comunque il modem o l'apparecchiatura appropriata del provider. Sostituire la funzione di routing non elimina la necessità di quella connessione fisica.

Nella configurazione funzionante del creator, il router domestico esistente alimenta il lato WAN del firewall e un access point è collegato al lato LAN. Se anche il gateway a monte esegue la traduzione degli indirizzi di rete, si crea un doppio NAT. Può andar bene per una prova iniziale, ma può complicare i servizi in ingresso e la risoluzione dei problemi. La disponibilità della modalità bridge o passthrough dipende dall'apparecchiatura e dal servizio del provider: verificala prima di modificare la connessione in uso.

Annota le impostazioni attuali rivolte al provider prima della migrazione. Un video che mostra una connessione Ethernet non chiarisce i requisiti di autenticazione, VLAN o modem del tuo ISP. Tieni a disposizione la configurazione del vecchio gateway mentre provi il nuovo percorso con un solo client. In questo modo potrai distinguere un problema del servizio upstream da un errore nella nuova LAN.

Il doppio NAT descrive due livelli di traduzione con instradamento; è diverso dal semplice collegamento di un punto di accesso a valle. Se il dispositivo wireless continua a instradare il traffico, può introdurre un altro livello e un altro servizio DHCP. Verifica la modalità operativa effettiva e la disposizione dei cavi, invece di dedurne il ruolo dall’etichetta del prodotto sul case.

Associa le interfacce virtuali ai confini WAN e LAN effettivi

The Social Dork scarica un’immagine di installazione di OPNsense e la avvia in Zima Virtual Machine su ZimaBoard 2. Si tratta di una dimostrazione di firewall virtualizzato. L’host continua a eseguire ZimaOS, quindi anche la sua configurazione di rete fa parte del progetto, insieme alle impostazioni di OPNsense all’interno del guest.

Per una configurazione simile, associa esplicitamente ogni interfaccia virtuale alla porta fisica prevista o a una rete host isolata. La presenza di due prese di rete non definisce automaticamente questa associazione. Tieni il percorso verso la WAN separato dai normali servizi host e assicurati che il traffico dei client LAN debba attraversare il firewall per raggiungere la connessione upstream. Se un client dispone di un altro percorso che aggira la VM, il firewall non può applicare le proprie regole a quel traffico.

Usa le istruzioni per l’installazione di OPNsense e le indicazioni sulle macchine virtuali aggiornate, adatte all’immagine e alla piattaforma selezionate. Prima di modificare le interfacce, annota come accedere all’host e alla console della VM. Il riavvio dell’host, un problema di archiviazione o l’arresto della VM possono interrompere questo gateway, quindi pianifica la manutenzione tenendo conto della connessione Internet domestica.

Definisci chiaramente il piano delle interfacce

1. Individua le porte fisiche dell’host e annota quale cavo raggiunge la connessione upstream.
2. Assegna all’interfaccia WAN del guest la rete upstream prevista.
3. Assegna alla sua interfaccia rivolta verso la LAN una rete downstream distinta.
4. Verifica che il percorso di gestione e i normali servizi host non siano esposti involontariamente sul lato WAN.
5. Collega un client di prova a valle e verifica il suo gateway predefinito effettivo prima di aggiungere altri dispositivi.

Il nome di un’interfaccia all’interno della macchina virtuale potrebbe non corrispondere all’etichetta stampata accanto a una porta fisica. Usa la mappatura di rete dell’hypervisor e la console della macchina virtuale per individuare la corrispondenza. Verificala di nuovo dopo aver modificato gli adattatori virtuali. Il video mostra una configurazione funzionante sulla macchina dell’autore, ma non fornisce un inventario completo di tutti i bridge host o delle impostazioni degli adattatori che potresti incontrare.

Assegna risorse al firewall lasciando capacità sufficiente per ZimaOS e gli altri servizi sull’host. L’attuale guida alla virtualizzazione di OPNsense indica 3 GB di RAM come minimo, un disco virtuale minimo consigliato di 8 GB e indicazioni sulla compatibilità di rete. Sono condizioni di partenza, non una promessa sulle prestazioni. Log, VPN, funzionalità di ispezione e altri carichi di lavoro possono modificare il margine necessario.

È un compromesso operativo legato alla condivisione di una macchina: un aggiornamento o un riavvio dell’host può causare l’interruzione anche della VM gateway. Decidi come avviare la VM dopo l’avvio dell’host e come recuperarla se non si avvia. Una console stabile è particolarmente utile quando un’impostazione di rete errata rende irraggiungibile l’interfaccia web.

Fai gestire ogni rete client da un solo servizio DHCP

L’autore usa reti IPv4 upstream e downstream diverse: il lato upstream usa indirizzi 192.168.0.x e la LAN dei client usa indirizzi 192.168.1.x. Sono esempi tratti dal video. Scegli sottoreti non sovrapposte adatte alla tua rete, invece di copiare indirizzi che potrebbero essere già in uso.

Il punto di accesso fornisce la connessione radio, mentre OPNsense assegna i lease DHCP ai client downstream. La guida illustra la modalità AP e la disattivazione del servizio DHCP del vecchio router wireless. Se l’apparecchiatura non dispone di una modalità AP dedicata, la sola disattivazione del DHCP non garantisce un comportamento da punto di accesso trasparente: verifica le istruzioni del produttore per il cablaggio LAN-to-LAN e i requisiti di routing/NAT. Mantieni raggiungibile il suo indirizzo di gestione senza che entri in conflitto con il pool DHCP.

Verifica il lease risultante su un portatile. Dovrebbe ricevere un indirizzo nella LAN prevista, l’indirizzo LAN del firewall come gateway predefinito e il server DNS previsto. La connessione Wi-Fi riuscita dimostra solo che il collegamento radio funziona. L’indirizzo, il gateway e il resolver indicano se il client è effettivamente entrato nel nuovo percorso di rete.

Pianifica separatamente gli indirizzi fissi e il pool di concessioni

Il seguente è un piano LAN /24 illustrativo, non una trascrizione degli indirizzi esatti del creator. Adattalo alle reti esistenti. Riserva gli indirizzi fissi dell’infrastruttura al di fuori del pool assegnato dinamicamente e mantieni la rete a monte diversa dalla LAN a valle.

Se Pi-hole si trova effettivamente su un’altra subnet o su una rete virtuale lato host, usa l’endpoint realmente raggiungibile e configura il routing e le policy necessari. L’indirizzo dell’esempio non rende il servizio accessibile dalla LAN. Una voce DHCP indica ai client dove inviare una richiesta; non crea la route né avvia il server.

Dopo aver modificato il DHCP, controlla la concessione sul laptop, anziché verificare solo la pagina di configurazione del server. Conferma l’indirizzo assegnato, la maschera, il gateway e le voci DNS. Un client che conserva ancora una vecchia concessione può far sembrare errata una nuova configurazione corretta. Un indirizzo o gateway inatteso è anche un indizio utile del fatto che potrebbe essere ancora attivo un altro server DHCP.

Considera la prima regola di autorizzazione come un test di connettività

Il creator inizia con una regola in uscita permissiva per il singolo laptop di prova e spiega come impedire connessioni non richieste dalla WAN verso la LAN. OPNsense usa il filtraggio stateful, quindi le risposte a una connessione consentita vengono gestite tramite lo stato della connessione. La documentazione delle regole del firewall OPNsense spiega come interfaccia, direzione e ordine delle regole influiscano su questo comportamento.

Il video apre anche l’interfaccia web dalla sua rete privata a monte. Nella tua installazione, limita l’accesso amministrativo a un percorso di gestione fidato e mantieni un’opzione di ripristino tramite console. L’etichetta WAN descrive un ruolo relativo a questo firewall; un segmento privato di laboratorio a monte e Internet pubblica presentano condizioni di esposizione diverse.

Per affrontare il problema dei dispositivi IoT sollevato all’inizio, crea reti distinte con apparecchiature che le supportano, quindi definisci il traffico consentito tra di esse. I dispositivi che scambiano traffico all’interno dello stesso segmento locale possono comunicare senza attraversare il firewall di instradamento. Per un’altra prospettiva pratica sulle decisioni relative al gateway e alla privacy, consulta la configurazione del firewall OPNsense di cachito labs.

Separare la connettività dall’isolamento

Definisci l’origine, la destinazione, il protocollo e lo scopo previsto prima di aggiungere una regola. Una regola che dimostra che un laptop può accedere a Internet non è una policy valida per tutti i dispositivi di una casa. Per la segmentazione, usa reti distinte e un percorso firewall tra di esse. Il traffico scambiato localmente sullo stesso segmento potrebbe non raggiungere affatto il gateway.

Quando una modifica alle regole sembra inefficace, prova una nuova connessione e considera lo stato della connessione. La guida alle regole di OPNsense spiega l’elaborazione con stato. Gli stati esistenti possono influire su una nuova prova, mentre azzerare tutti gli stati interromperebbe altre connessioni attive. Individua il flusso di prova specifico prima di apportare modifiche diagnostiche generali.

Collegare Pi-hole tramite DHCP senza creare un loop DNS

Verso la fine, The Social Dork imposta come server DNS fornito dal DHCP l’indirizzo di Pi-hole. In questo modo, il precedente progetto di blocco degli annunci con Pi-hole e Tailscale viene integrato nella nuova rete wireless. OPNsense controlla il percorso del traffico instradato; Pi-hole valuta i nomi DNS richiesti tramite il suo servizio. I due componenti hanno responsabilità diverse.

La guida all’integrazione di Pi-hole con OPNsense descrive la distribuzione diretta tramite DHCP e l’inoltro attraverso il firewall come configurazioni alternative. Scegli un percorso coerente e assicurati che i resolver non si inoltrino le richieste a vicenda creando un ciclo. Verifica inoltre che i client possano raggiungere l’indirizzo di Pi-hole se si trova su una rete diversa.

Scegli un percorso per il resolver e traccialo da un capo all’altro

Nel video si usa l’indirizzo di Pi-hole fornito tramite DHCP per i client. La configurazione di inoltro descritta nella guida ufficiale collegata è un’alternativa. Se scegli questa opzione, assicurati che il server DNS upstream di Pi-hole non invii la richiesta direttamente alla stessa catena di inoltro. Un percorso chiaro rende molto più facile diagnosticare l’assenza di una risposta.

Anche il DNS dipende dal trasporto e dall’instradamento. Se il client e il resolver si trovano su reti diverse, controlla il percorso e le regole che riguardano la porta TCP/UDP 53. Se il risultato osservato differisce dalla configurazione DHCP, verifica gli annunci DNS IPv6 e le impostazioni DNS indipendenti dei client. Il solo accesso all’interfaccia web di Pi-hole non è una prova sufficiente.

Per filtrare il traffico quando sei fuori casa, consulta di nuovo la guida a Pi-hole e Tailscale. L’accesso DNS remoto, le regole del gateway locale e l’instradamento di tutto il traffico Internet tramite VPN sono decisioni distinte. Verifica ciascuna opzione sulla connessione in cui verrà effettivamente utilizzata.

Verifica l’intero percorso prima di spostare ogni dispositivo

La dimostrazione finale cambia la rete Wi-Fi del laptop e confronta lo stesso sito web con e senza il sistema di filtraggio. Illustra il percorso del client selezionato, ma non dimostra che tutti i siti web siano privi di annunci o che tutti i dispositivi siano isolati. Verifica prima l’accesso a Internet e il DNS, poi controlla i log pertinenti del firewall e di Pi-hole per collegare ogni risultato al client previsto.

Prima di trasferire tutta la famiglia, prova il rinnovo di un client, una connessione consentita e una connessione deliberatamente negata tra reti separate, se la segmentazione fa parte del tuo progetto. Esporta una configurazione del firewall funzionante e verifica il percorso di ripristino. Il risultato utile è un gateway di cui sai spiegare e gestire routing, DHCP, filtraggio e amministrazione. Guarda la guida completa di The Social Dork per configurare un firewall domestico con OPNsense per vedere la topologia originale e la sequenza di configurazione.

Esegui un test di accettazione graduale

1. Connettiti alla rete wireless prevista e controlla il nuovo lease del client.
2. Verifica il gateway predefinito, quindi, se opportuno, prova una connessione consentita basata su IP.
3. Risolvi un nome host consentito tramite il resolver selezionato e individua la query.
4. Cerca un dominio nei criteri Pi-hole attivi e verifica che venga restituita la risposta prevista.
5. Se hai configurato la segmentazione, prova una connessione consentita e una negata oltre il confine instradato.
6. Riconnetti il client o rinnova il lease e verifica che vengano ripristinate le impostazioni previste.
7. Durante una finestra di manutenzione pianificata, verifica il percorso di avvio dell’host e della VM gateway prima di farvi affidamento in modo continuativo.

Risolvi i problemi seguendo l’ordine della rete

Usa i log per rispondere a una domanda alla volta. La documentazione sulla registrazione del firewall di OPNsense spiega che un flusso con stato non genera necessariamente una nuova riga nel registro in tempo reale per ogni pacchetto. La guida alla diagnostica del firewall fornisce la visualizzazione degli stati. Un registro silenzioso, da solo, non dimostra che nessun traffico abbia attraversato il firewall.

Salva una configurazione funzionante prima di apportare modifiche importanti e conserva un piano di rollback chiaro. Durante i test, mantieni disponibile separatamente la vecchia connessione ed evita di collegare per errore le reti a monte e downstream aggirando il firewall. Un rollback efficace ripristina una configurazione nota del gateway e dei client, invece di introdurre due router in competizione nello stesso segmento client.

Domande frequenti

ZimaBoard 2 può sostituire da sola la scheda Wi-Fi?

In questo video, un access point separato fornisce il Wi-Fi. La scheda ospita il gateway virtualizzato e i servizi correlati. L'instradamento e l'accesso wireless sono funzioni diverse.

Posso rimuovere il modem dell'ISP?

Solo se il passaggio al nuovo servizio non ne richiede più l'uso. Le configurazioni DSL, via cavo e specifiche di alcuni provider potrebbero aver ancora bisogno dell'apparecchiatura di terminazione originale. Verifica i requisiti fisici e del servizio prima di sostituire un gateway.

Una regola che consente il traffico in uscita isola i dispositivi IoT?

Non crea una separazione di rete. I dispositivi sullo stesso segmento locale possono comunicare senza attraversare il firewall di instradamento. Per isolarli servono reti distinte e una policy verificata tra di esse.

Pi-hole dovrebbe essere eseguito all'interno di OPNsense?

Il progetto mostrato usa un servizio Pi-hole insieme al firewall virtualizzato e ne pubblicizza l'indirizzo tramite DHCP. Il requisito fondamentale è un percorso DNS raggiungibile e coerente; non dare per scontato che installare OPNsense installi anche quel servizio.

Perché la VM del firewall ha bisogno di due percorsi di rete?

La configurazione con instradamento richiede un percorso verso la rete a monte e un percorso downstream separato. La mappatura corretta tra guest e host definisce questo confine. La presenza di due nomi di adattatori non dimostra, da sola, che le reti siano isolate.

Cosa succede quando si riavvia l'host ZimaOS?

Il firewall per gli ospiti e gli altri servizi ospitati potrebbero diventare indisponibili. Pianifica l'avvio e il ripristino delle VM, quindi verificali durante una finestra di manutenzione. Condividere l'hardware significa che la manutenzione dell'host incide sulla disponibilità del gateway.

Conclusione

La configurazione di The Social Dork è utile perché trasforma un gateway tutto-in-uno in una serie di funzioni comprensibili: connettività con il provider, instradamento virtualizzato, accesso wireless, assegnazione degli indirizzi e filtraggio DNS. Il primo test riuscito con un laptop costituisce un punto di partenza. Per mantenere un gateway domestico servono anche confini di rete verificati, criteri adeguati per ciascun gruppo di client e una procedura di ripristino.

Completa le verifiche per un singolo client prima di migrare l'intera rete domestica, quindi verifica separatamente ogni eventuale segmentazione aggiuntiva o comportamento della VPN. Tieni la video guida a OPNsense di The Social Dork accanto al tuo schema di rete e alla documentazione ufficiale aggiornata. L'obiettivo è una rete di cui sai spiegare, testare e ripristinare il funzionamento.