Captive portal Wi-Fi ospiti: come funziona e cosa serve davvero

Un captive portal è la pagina di login che intercetta il traffico di un client Wi-Fi prima di concedergli l'accesso a Internet. Hotel, bar, studi professionali e uffici lo usano per separare gli ospiti dalla rete interna e per tenere traccia di chi si collega. Sotto la superficie è un meccanismo di intercettazione HTTP e di manipolazione delle regole di firewall, e capirlo evita la maggior parte dei problemi tipici.

Come funziona il meccanismo di intercettazione

Il flusso è sempre lo stesso, indipendentemente dal vendor:

• Il client si associa alla SSID ospiti e riceve un indirizzo via DHCP, con DNS e gateway che puntano al dispositivo che ospita il portale (router, controller Wi-Fi o server dedicato).
• Il firewall inserisce il MAC address del client in uno stato "non autenticato": tutto il traffico è bloccato tranne DHCP, DNS e le porte 80/443 verso il portale stesso.
• Al primo tentativo di navigazione, la richiesta HTTP viene rediretta con un 302 verso la pagina di login. In alternativa il DNS risponde con l'IP del portale per qualsiasi dominio.
• Dopo l'autenticazione, il MAC (o la coppia MAC/IP) passa allo stato "autenticato" e le regole di firewall si aprono per la durata della sessione.

Il punto critico è il traffico HTTPS. Un client che apre direttamente un sito in TLS non può essere rediretto senza generare un errore di certificato: il portale non può presentarsi al posto del dominio richiesto. Per questo i sistemi operativi moderni usano un meccanismo di rilevamento dedicato, chiamato CNA su iOS e macOS o "captive portal detection" su Android e Windows: il dispositivo interroga in chiaro un URL noto del proprio vendor e, se la risposta non è quella attesa, apre automaticamente la finestra di login. Se il portale blocca quegli URL di test, la finestra non compare e l'utente resta convinto che la rete non funzioni.

Metodi di autenticazione

• Click-through: accettazione dei termini e via. Zero attrito, nessuna identificazione dell'utente.
• Voucher o PSK per ospite: codici a tempo generati dalla reception o dallo staff. Buon compromesso in ambito ricettivo.
• SMS o e-mail: l'utente riceve un codice OTP. Identifica il numero, non la persona, ma è tracciabile.
• Social login: comodo per l'utente, ma introduce una dipendenza da terze parti e obblighi privacy aggiuntivi.
• RADIUS con credenziali aziendali: la scelta corretta quando gli "ospiti" sono in realtà collaboratori o consulenti ricorrenti.

Il quadro normativo italiano

Il decreto che imponeva l'identificazione obbligatoria degli utenti e la richiesta di autorizzazione (il cosiddetto decreto Pisanu) è stato superato: dal 2013 chi offre Wi-Fi al pubblico in via accessoria alla propria attività non è tenuto a identificare gli utenti né a chiedere licenze. Restano però due aspetti da non trascurare:

• GDPR: se raccogli e-mail, numeri di telefono o log di navigazione stai trattando dati personali. Servono informativa, base giuridica, tempi di conservazione definiti e un responsabile del trattamento se il portale è in cloud presso un fornitore.
• Responsabilità sul traffico: non c'è un obbligo generalizzato di conservazione per chi non è operatore di comunicazione elettronica, ma mantenere log tecnici essenziali (MAC, IP assegnato, timestamp di sessione) per un periodo limitato e documentato è una prassi ragionevole in caso di richieste dell'autorità giudiziaria.

Chi eroga connettività come attività principale rientra invece in un regime diverso, con obblighi di conservazione stabiliti dalla normativa di settore.

Errori ricorrenti in fase di configurazione

• Nessun isolamento client: senza il client isolation gli ospiti si vedono tra loro sulla stessa L2. Va attivato sempre sulla SSID ospiti.
• Ospiti e rete interna sulla stessa VLAN: la rete ospiti deve avere una VLAN dedicata, con regole che vietano il traffico verso le subnet interne e verso le interfacce di management degli apparati.
• Banda non limitata: senza un rate limit per client, un singolo download saturi l'uplink. Un limite tra 5 e 20 Mbps per dispositivo, più uno shaping complessivo sulla VLAN ospiti, protegge il traffico produttivo e le chiamate VoIP.
• DNS non filtrato: usare un resolver con filtro contenuti riduce il rischio di traffico verso domini malevoli originato dalla tua connessione.
• Sessioni infinite: un idle timeout di 15-30 minuti e una durata massima di sessione di poche ore evitano che tabelle di stato e liste MAC crescano senza controllo.
• Portale in HTTP puro: la pagina di login deve essere in HTTPS con un certificato valido su un dominio reale, altrimenti l'utente vede un avviso di sicurezza a ogni accesso.

Dove far girare il portale

Su reti piccole il captive portal integrato in un router MikroTik (hotspot) o in pfSense è più che sufficiente e non ha costi ricorrenti. Su installazioni multi-sede conviene un controller cloud o un server RADIUS centralizzato: si ottiene una gestione unica delle policy, log aggregati e la possibilità di applicare le stesse regole su tutte le sedi senza toccare i singoli apparati.

La regola pratica: se hai un solo access point e pochi ospiti al giorno, resta sull'integrato. Se gestisci più sedi o devi rendicontare gli accessi, passa a una soluzione centralizzata fin dall'inizio, perché migrare dopo significa riconfigurare ogni apparato.