Come funzionano le connessioni di rete del portale captive?

L'accesso a Internet negli hotel, nei caffè degli aeroporti è spesso gestito da un portale captive che ti costringe a una determinata pagina Web al primo utilizzo, ad esempio una pagina di pagamento o una pagina per accettare i termini di servizio o una pagina di autenticazione / autorizzazione. Lo vedi con connessioni sia wireless che cablate.

Come funziona?

Sicuramente varia a seconda del fornitore del prodotto wireless, ma nella mia esperienza di solito funziona in questo modo:

1. Il laptop esegue una connessione wireless a un punto di accesso intelligente, che può essere collegato a una stazione di gestione centralizzata.
2. La tua prima richiesta web viene intercettata e risposta con Location:un'intestazione che ti reindirizza a una pagina di accesso / politica (ad esempio http://hotelwireless.net/login ). Questo potrebbe vivere direttamente sul punto di accesso intelligente o su una stazione di gestione centrale.
3. Una volta completata l'autenticazione, il tuo indirizzo MAC viene aggiunto a un elenco di client consentiti, facendo sì che le richieste future vengano indirizzate correttamente a Internet o alle risorse Intranet accessibili.

Per quanto riguarda come chiamarlo, l'ho sentito spesso definito "portale captive" o "portale di accesso wireless".

Innanzitutto per ottenere il reindirizzamento, è necessario un autenticatore in linea (controller di accesso). Nel contesto del tuo argomento, avrai bisogno di un controller LAN wireless se opti per la gestione centralizzata di AP. OPPURE puoi anche posizionare un tipo di portale captive di controller di accesso alla rete con le funzionalità di Wall Garden.

Il NAS monitora il traffico che entra nel downlink (lato client) attraverso socket raw in modalità promiscua e quando viene rilevato il traffico avviato dal browser per un client non autenticato, viene fornito un reindirizzamento HTTP come risposta. Quindi il browser alla ricezione viene reindirizzato alla nostra homepage del portale CAPTIVE, che può essere ospitata in linea sull'autenticatore o pronta all'uso su alcuni server Web esterni.

L'unico lavoro di questa pagina è fornire all'utente un'interfaccia utente per inserire le credenziali. le credenziali immesse vengono inoltrate all'autenticatore Daemon come il peperoncino in caso di peperoncino coova, inoltre queste credenziali vengono passate come richiesta di raggio al server RADIUS o possono essere verificate localmente. In caso di autenticazione riuscita, lo stato del client nell'autenticatore viene contrassegnato come autorizzato e al client viene concesso l'accesso.

Come si ottiene il reindirizzamento

L'approccio più utilizzato è quello di intercettare la richiesta HTTP avviata dall'utente e il codice 302 come risposta al client. Nel peperoncino viene eseguito tramite la funzione di seguito

http_redirect2() {

cat < <  EOF
HTTP/1.1 302 Redirect 

Location: $1

Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID

Set-Cookie: COOVA_USERURL=$COOVA_USERURL

Connection: close

EOF
    exit

}

Questo reindirizzamento può essere facilmente raggiunto dall'interfaccia tun tap pragmaticamente controllata all'interfaccia lato client che intercetta il traffico client. Un ulteriore reindirizzamento può essere ottenuto anche con avvelenamento da DNS ma a volte può causare problemi se le risposte vengono memorizzate nella cache del browser client. Ulteriori cose possono essere fatte in modo più specifico in base al dominio del problema. Posso aiutarti se vuoi.

C'è un'ottima descrizione di questo su https://www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htm .

Eccone una parte:

Processo di autenticazione del portale captive

Captive portal è un'autenticazione di livello 3, che richiede che i dispositivi si connettano alla rete e ottengano un indirizzo IP e le informazioni DNS correlate prima di eseguire l'autenticazione tramite il portale captive. I seguenti passaggi spiegano l'intero processo del portale captive quando ArubaOS nativo viene utilizzato per l'autenticazione del portale captive:

1. Al dispositivo associato al SSID guest viene assegnato un ruolo iniziale (ruolo di accesso guest nella configurazione di esempio). Questo ruolo iniziale consente DHCP, quindi l'utente ottiene un indirizzo IP.

2. L'utente apre un browser e invia una richiesta HTTP (o HTTPS) a una destinazione (ad esempio, www.bbc.com).

3. Il resolver nel dispositivo invia una richiesta DNS per risolvere www.bbc.com. Il ruolo iniziale (ruolo di accesso guest) consente i servizi DNS, in modo che il resolver possa comunicare con il server DNS.

4. Il server DNS risponde con l'indirizzo corretto a www.bbc.com.

5. Il resolver indica al browser quale indirizzo IP utilizzare in base alla risposta DNS.

6. Il browser avvia una connessione TCP alla porta 80 dell'indirizzo www.bbc.com.

7. Il controller intercetta la connessione e falsifica gli handshake TCP iniziali del processo HTTP. In questo momento, il browser client pensa che stia comunicando con il server bbc.com.

8. Quando il browser invia la richiesta HTTP GET per la pagina Web, il controller risponde dicendo che bbc.com si è "temporaneamente spostato" in.

9. Il browser chiude la connessione.

10. Il browser tenta di connettersi, ma deve prima inviare una richiesta DNS per l'indirizzo.

11. Il server DNS effettivo risponde che non è in grado di risolvere https://securelogin.arubanetworks.com , ma il controller intercetta questa risposta e modifica il pacchetto per dire che securelogin.arubanetworks.com si trova all'indirizzo IP del controller stesso. Ricorda che è fondamentale che il server DNS rispedisca una risposta alla query. È solo allora che il controller può falsificare la risposta dal server DNS. L'invio di una richiesta DNS senza ricevere una risposta non è sufficiente, poiché senza una risposta il controller non aiuterà mai il client a risolvere securelogin.arubanetworks.com.

12. Il browser avvia una connessione HTTPS all'indirizzo del controller, che risponde alla pagina di accesso del portale captive, in cui il guest esegue l'autenticazione.

13. Al termine dell'autenticazione corretta, all'utente viene assegnato il ruolo di post autenticazione (ruolo di autenticazione-ospite nella configurazione di esempio). Questo è il ruolo predefinito nel profilo del portale captive.

14. Dopo l'autenticazione, il browser viene reindirizzato a bbc.com all'indirizzo originariamente risolto dal DNS. In alternativa, se viene configurata una pagina di benvenuto, il browser viene reindirizzato alla pagina di benvenuto.

15. Per reindirizzare correttamente alla pagina Web originale, il controller invia una risposta da bbc.com per comunicare al client che bbc.com si è "spostato permanentemente" su bbc.com. Questo passaggio corregge il "trasferimento temporaneo" che si è verificato durante l'accesso al portale captive.

16. Questo fa sì che il client richieda nuovamente il DNS per l'indirizzo di www.bbc.com.

17. Il browser inizia a comunicare con l'attuale server bbc.com.