¿Cómo funcionan las conexiones de red del portal cautivo?

El acceso a Internet en los hoteles y cafés de los aeropuertos a menudo está cerrado por un portal cautivo que lo obliga a una página web particular en el primer uso, por ejemplo, una página de pago o alguna página para aceptar los términos del servicio o una página de autenticación / autorización. Ves esto con conexiones inalámbricas y cableadas.

¿Como funciona esto?

Ciertamente varía según el proveedor del producto inalámbrico, pero en mi experiencia, por lo general, funciona de la siguiente manera:

1. Su computadora portátil realiza una conexión inalámbrica a un punto de acceso inteligente, que puede conectarse a una estación de administración centralizada.
2. Su primera solicitud web es interceptada y respondida con un Location:encabezado que lo redirige a una página de inicio de sesión / política (por ejemplo, http://hotelwireless.net/login ). Esto podría vivir directamente en el punto de acceso inteligente o en una estación de administración central.
3. Una vez que haya completado la autenticación, su dirección MAC se agregará a una lista de clientes permitidos, lo que provocará que las solicitudes futuras se enruten correctamente a Internet o a los recursos de Intranet accesibles.

Con respecto a cómo llamarlo, lo he escuchado referido como un "portal cautivo" o "portal de acceso inalámbrico" con mayor frecuencia.

Primero para lograr la redirección, necesita un autenticador en línea (controlador de acceso). En el contexto de su tema, necesitará un controlador LAN inalámbrico si opta por la administración central de AP. O también puede colocar un tipo de portal cautivo de controlador de acceso a la red con funciones de jardín de pared.

NAS monitorea el tráfico que ingresa al enlace descendente (lado del cliente) a través del socket sin procesar de modo promiscuo y cuando el navegador inicia el tráfico para un cliente no autenticado se detecta una redirección HTTP como respuesta. Por lo tanto, el navegador al recibir se redirige a nuestra página de inicio del portal CAPTIVE, que se puede alojar en línea en el autenticador o listo para usar en algún servidor web externo.

El único trabajo de esta página es proporcionar al usuario una IU para ingresar credenciales. las credenciales ingresadas se reenvían al autenticador Daemon como chilli en caso de coova chilli, luego estas credenciales se pasan como solicitud de radio al servidor RADIUS o se pueden verificar localmente. Tras una autenticación exitosa, el estado del cliente en el autenticador se marca como autorizado y se le otorga acceso al cliente.

Cómo se logra la redirección

El enfoque más utilizado es interceptar la solicitud HTTP iniciada por el usuario y el código 302 como respuesta al cliente. En chile se hace a través de la siguiente función

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

}

Esta redirección se puede lograr fácilmente con una interfaz de toque de control controlada pragmáticamente a la interfaz del lado del cliente que intercepta el tráfico del cliente. También se puede lograr una redirección adicional a través del envenenamiento de DNS, pero a veces puede causar problemas si las respuestas se almacenan en caché en el navegador del cliente. Se pueden hacer más cosas más específicamente según el dominio del problema. Puedo ayudarte con eso si quieres.

Hay una gran descripción de esto en https://www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htm .

Aquí hay parte de esto:

Proceso de autenticación de portal cautivo

El portal cautivo es una autenticación de Capa 3, que requiere que los dispositivos se conecten a la red y obtengan una dirección IP e información DNS relacionada antes de autenticarse a través del portal cautivo. Los siguientes pasos explican todo el proceso del portal cautivo cuando se usa el ArubaOS nativo para la autenticación del portal cautivo:

1. Al dispositivo que se está asociando al SSID invitado se le asigna una función inicial (función de inicio de sesión de invitado en la configuración de ejemplo). Este rol inicial permite DHCP, por lo que el usuario obtiene una dirección IP.

2. El usuario abre un navegador y realiza una solicitud HTTP (o HTTPS) a algún destino (por ejemplo, www.bbc.com).

3. La resolución en el dispositivo envía una solicitud de DNS para resolver www.bbc.com. La función inicial (función de inicio de sesión de invitado) permite los servicios DNS, por lo que el solucionador puede comunicarse con el servidor DNS.

4. El servidor DNS responde con la dirección correcta a www.bbc.com.

5. El solucionador le dice al navegador qué dirección IP usar en función de la respuesta DNS.

6. El navegador inicia una conexión TCP al puerto 80 de la dirección www.bbc.com.

7. El controlador intercepta la conexión y falsifica los protocolos de enlace TCP iniciales del proceso HTTP. En este momento, el navegador del cliente cree que se está comunicando con el servidor bbc.com.

8. Cuando el navegador envía la solicitud HTTP GET para la página web, el controlador responde diciendo que bbc.com se ha "movido temporalmente" a.

9. El navegador cierra la conexión.

10. El navegador intenta conectarse, pero primero debe enviar una solicitud de DNS para la dirección.

11. El servidor DNS real responde que no puede resolver https://securelogin.arubanetworks.com , pero el controlador intercepta esa respuesta y cambia el paquete para decir que securelogin.arubanetworks.com está en la dirección IP del controlador. Recuerde que es fundamental que el servidor DNS envíe una respuesta a la consulta. Es solo entonces que el controlador puede falsificar la respuesta del servidor DNS. Enviar una solicitud DNS sin recibir una respuesta no es suficiente, ya que sin una respuesta, el controlador nunca ayudará al cliente a resolver securelogin.arubanetworks.com.

12. El navegador inicia una conexión HTTPS a la dirección del controlador, que responde con la página de inicio de sesión del portal cautivo, donde el invitado se autentica.

13. Después de una autenticación exitosa, al usuario se le asigna la función de autenticación posterior (función de invitado de autenticación en la configuración de ejemplo). Este es el rol predeterminado en el perfil del portal cautivo.

14. Después de la autenticación, el navegador se redirige a bbc.com en la dirección originalmente resuelta por el DNS. Alternativamente, si se configura una página de bienvenida, el navegador se redirige a la página de bienvenida.

15. Para redirigir con éxito a la página web original, el controlador falsifica una respuesta de bbc.com para decirle al cliente que bbc.com se ha "movido permanentemente" a bbc.com. Este paso corrige la "reubicación temporal" que ocurrió como parte del inicio de sesión en el portal cautivo.

16. Esto hace que el cliente vuelva a consultar DNS para la dirección de www.bbc.com.

17. El navegador comienza a comunicarse con el servidor real de bbc.com.