Nethesis
NethSecurity: rete ospiti e captive portal non sono la stessa cosa
Separare i visitatori dalla LAN protegge le risorse interne; il captive portal gestisce invece l’accesso a Internet e l’identità degli ospiti.
Due esigenze che spesso vengono confuse
Offrire il Wi-Fi a un visitatore comporta almeno due problemi distinti. Il primo è impedire che il suo dispositivo raggiunga PC, server, stampanti e altri sistemi aziendali. Il secondo è decidere come autorizzare e, se necessario, registrare l’accesso a Internet. La rete ospiti risponde soprattutto al primo obiettivo mediante segmentazione e regole firewall; il captive portal interviene sul secondo mostrando una pagina di accesso. Attivare un portale senza separare correttamente la rete non crea da solo un confine sicuro verso la LAN.
La zona Guest costruisce il confine di rete
La documentazione NethSecurity descrive una zona Guest dedicata ai dispositivi temporanei. La configurazione proposta consente il traffico verso Internet, blocca quello diretto al firewall e quello tra dispositivi della stessa zona, mentre non autorizza l’inoltro verso la LAN. Questo comportamento va verificato sulle regole effettive: il nome guest o il colore blu dell’interfaccia non sostituiscono la politica firewall. Anche access point e VLAN devono portare il traffico sulla rete corretta; collegare l’SSID ospiti alla stessa rete aziendale vanifica la separazione prevista.
Il captive portal controlla l’ingresso a Internet
Il servizio Hotspot di NethSecurity reindirizza gli utenti a un portale dal quale possono autenticarsi mediante email, SMS, social login o voucher, secondo la configurazione scelta. L’architettura documentata comprende un gestore centrale e una unità sul firewall: la parte locale assegna gli indirizzi e intercetta il traffico, mentre il gestore amministra istanze, pagina di accesso, utenti e sessioni. Il portale può quindi stabilire chi entra e per quanto tempo, ma non sostituisce la segmentazione, la cifratura Wi-Fi o le regole che limitano le destinazioni raggiungibili.
DNS e DHCP richiedono eccezioni precise
Una rete ospiti deve comunque ottenere indirizzo IP e risolvere i nomi. Se NethSecurity fornisce DHCP e DNS, la guida ufficiale indica di creare regole di input dalla zona Guest per DNS sulle porte 53 TCP e UDP e per DHCP sulla porta 67 UDP. Queste aperture sono verso il firewall, non verso l’intera LAN. Se i servizi sono erogati da un altro apparato, il percorso va progettato in modo coerente. Aggiungere permessi generici per far funzionare il portale può esporre servizi amministrativi che gli ospiti non devono vedere.
Un esempio per una sala riunioni
Immaginiamo un’azienda che riceva tecnici esterni per una giornata. Viene creato un SSID dedicato, associato a una VLAN e alla zona Guest di NethSecurity. La zona permette Internet, blocca LAN e comunicazione tra ospiti; DHCP e DNS ricevono solo le eccezioni necessarie. Dal gestore Hotspot vengono preparati voucher con durata limitata, consegnati individualmente alla reception. Prima dell’uso si provano navigazione, scadenza del voucher e impossibilità di raggiungere un server interno. È uno scenario ipotetico: nomi, porte e apparati effettivi dipendono dall’infrastruttura.
Versione e comportamento vanno verificati insieme
Alla data del 4 novembre 2026, le note ufficiali riportano come importante aggiornamento più recente NethSecurity 8.8.0 del 29 luglio 2026, basato su OpenWrt 25.12.5. Le stesse note includono correzioni ai log dei componenti Hotspot. La presenza della funzione non garantisce però che una configurazione precedente mantenga automaticamente ogni comportamento dopo un aggiornamento. Prima di applicarlo servono backup, lettura delle note complete e test su autenticazione, assegnazione degli indirizzi, rinnovo delle sessioni e raggiungibilità delle reti.
Limiti, dati e verifiche periodiche
Un captive portal non protegge da un access point configurato male, da credenziali Wi-Fi condivise senza controllo o da dispositivi già collegati alla LAN. La documentazione indica inoltre che i dati degli account ospiti e dei voucher possono essere conservati per la validità dell’account e per i dodici mesi successivi: l’azienda deve quindi valutare informativa, finalità, ruoli e tempi applicabili al proprio servizio, senza affidarsi al solo valore predefinito. Vanno controllati anche copertura, banda, isolamento tra client e procedura di assistenza. La prova decisiva usa un dispositivo ospite reale e verifica sia ciò che funziona sia ciò che deve restare inaccessibile.
Fonti e riferimenti
Fonti consultate il 04/11/2026.