Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Flujo operativo del servidor de redireccionamiento HTTP local (serie MX, ACX7100-48L, ACX7332 y ACX7348)

Puede utilizar la característica de redireccionamiento HTTP local en configuraciones en las que el servidor de redireccionamiento reside localmente en un enrutador. Esta función está disponible en enrutadores serie MX y en enrutadores ACX7100-48L, ACX7332 y ACX7348.

Un servidor local de redireccionamiento HTTP que reside localmente en un enrutador procesa las solicitudes HTTP redirigidas a él y responde con una URL de redireccionamiento que apunta a un portal cautivo. Puede implementar el servidor local como servicio dentro de un conjunto de servicios, lo que proporciona más escalabilidad y un mejor rendimiento. Cuando utilice un servidor de redireccionamiento HTTP local, debe configurar una regla de servicio HTTP para redirigir las solicitudes HTTP a un portal cautivo dentro de un jardín amurallado.

Un jardín amurallado es un grupo de servidores que proporcionan acceso a los suscriptores a sitios dentro del jardín amurallado sin necesidad de reautorización a través de un portal cautivo. El tráfico de solicitudes HTTP de los suscriptores destinados a servidores fuera del jardín amurallado es interceptado y redirigido por el servicio de entrega de contenido del portal cautivo (CPCD) o por el motor de enrutamiento. El servicio CPCD o el motor de enrutamiento localizan la URL de redireccionamiento aprovisionada para el suscriptor específico y envían una respuesta con el código de estado HTTP 302 o 307 que incluye la URL localizada.

La figura 1 muestra el despliegue general de servicios durante la configuración de acceso para un servidor de redireccionamiento HTTP local. El servidor de redireccionamiento HTTP reside localmente en el enrutador. La asociación del servicio se produce al iniciar sesión del suscriptor y la separación del servicio se produce al cerrar la sesión del suscriptor.

Nota:

Una solución completa de redireccionamiento HTTP depende de los servidores back-end, como SRC, portal cautivo y RADIUS; su integración es específica para el esquema de integración preferido de cada cliente.

Figura 1: Despliegue del servidor de redireccionamiento HTTP local Network diagram of subscriber authentication process with captive portal: login, redirect, authentication, policy management, and internet access.

  1. El suscriptor inicia sesión conectándose a través de la red de acceso.

  2. RADIUS autentica al suscriptor y envía una activación de servicio (redireccionamiento HTTP), que redirige el tráfico HTTP al portal cautivo en un jardín amurallado.

  3. El suscriptor intenta acceder al servidor de contenido (tráfico HTTP) fuera del jardín amurallado.

  4. El enrutador redirige el tráfico HTTP del suscriptor al portal cautivo.

  5. El portal cautivo envía una página de autorización al suscriptor.

  6. El suscriptor introduce las credenciales para obtener la autorización.

  7. El portal cautivo verifica las credenciales del suscriptor.

  8. El portal cautivo autoriza al suscriptor y notifica al servidor de políticas de redireccionamiento SRC.

  9. El servidor de políticas de redireccionamiento SRC comprueba la base de datos de suscriptores y formula una política para que el suscriptor pueda acceder al servidor de contenido.

  10. El servidor de políticas de redireccionamiento SRC envía la política directamente al enrutador mediante JSRC o Diameter.

    Como alternativa, el servidor de políticas de redireccionamiento SRC notifica al servidor RADIUS, que a su vez envía un cambio de autorización (CoA) al enrutador.

  11. El enrutador adjunta la nueva política, anulando la política de redireccionamiento inicial.

  12. El suscriptor ahora obtiene acceso al servidor de contenido.

Documentación relacionada