Il giorno lun 1 lug 2024 alle ore 14:18 Piviul <piv...@riminilug.it> ha scritto:
> Ciao a tutti, mi piacerebbe creare un captive portal per una wifi guest > che quando un utente che non ha il permesso di accesso viene rediretto > al captive portal, possa avere la possibilità di accettare qualcosa (le > classe condizioni d'uso) e fare la richiesta di accesso. La richiesta > dovrebbe quindi arrivare via mail all'amministratore il quale può poi > abilitare quel mac address per un tempo limitato definito al momento > della abilitazione. > > Secondo voi è possibile? Per ora per la gestione del wifi ho la net app > di ubnt. > Buongiorno, Per realizzare il captive portal, devi tirare necessariamente su un resolver DNS (eventualmente sulla stessa macchina dove risiede l'Access Point) che venga servito via DHCP alle macchine che si collegano all'Access Point. Tale resolver deve a sua volta interrogare un normale DNS esterno, come quello del tuo provider che già rispetta le regole italiane - molto stringenti - sulla censura, se sei in Italia (altrimenti, a seconda delle leggi locali, potrebbe essere un normale resolver ricorsivo). Il resolver deve però puntare i domini di terzo (secondo per l'ultimo) livello per i seguenti URL: - http://clients3.google.com/generate_204 - http://captive.apple.com/hotspot-detect.html - http://detectportal.firefox.com/canonical.html - http://msftncsi.com all'IP di un tuo server, che dia per quegli URL un redirect HTTP 302 con header Location che punta alla pagina di richiesta accesso. I browser (nell'ordine: Chrome, Safari, Firefox, Edge/IE) interrogano quegli indirizzi (che normalmente restituiscono risposte HTTP standard o 204) per sapere se vi sia un captive portal e dove sia. Sconsiglio MOLTO vivamente di fare, come ti è stato consigliato, in modo che il DNS restituisca la pagina di richiesta accesso indipendentemente da quale sia il dominio. Lo sconsiglio per due motivi, entrambi molto molto rilevanti: - Il DNS deve per standard essere messo in cache. Se il sistema operativo, o il browser, o un resolver intermedio mettono in cache l'IP - come, ribadisco, devono - della tua pagina di accesso, tocca aspettare che gli scada la cache perché anche una volta abilitati non entreranno. Per questo motivo consiglio anche che i controlli siano fatti a livello di IP e non di MAC: non hai modo di discriminare per MAC. I client metteranno in cache l'IP della pagina di check che il browser usa, e interrogheranno quella pure quando il client è autenticato. Dovrai, a livello di webserver, restituire 302 o 204 (nel secondo caso puoi pure reverseproxare la pagina reale) rispettivamente se il client è autenticato o no. Se vuoi un controllo a livello di MAC, fallo sul DHCP: assegna un IP noto a quel MAC. - Quasi tutta Internet è HTTPS, talvolta con HSTS. Se provi a redirezionare via DNS una richiesta HTTPS (specie se HSTS) verso una pagina tua con certificato non originale, nel migliore dei casi all'utente viene dato un errore di sicurezza aggirabile e nel peggiore non avrà modo neanche volendo di raggiungere il login. -- Lorenzo Breda
