Descripción general del servicio de redireccionamiento HTTP
El tráfico de solicitudes HTTP de los suscriptores se agrega desde las redes de acceso a un enrutador del servidor de acceso remoto de banda ancha (B-RAS), donde el tráfico HTTP se puede interceptar y redirigir a un portal cautivo en un dispositivo externo. El portal cautivo suele ser la página inicial que ve un suscriptor después de iniciar sesión en una sesión de suscriptor. El portal cautivo también recibe y administra solicitudes HTTP a recursos web no autorizados.
Por ejemplo, el usuario puede ser redirigido a una página web que muestra el logotipo de una empresa y la política de uso de la red o a una página donde el suscriptor paga por los servicios. El portal cautivo suele proporcionar servicios de autenticación y autorización para los suscriptores redirigidos antes de conceder acceso a servidores protegidos fuera de un jardín amurallado.
Un jardín amurallado, también conocido como lista de permitidos, define un grupo de servidores donde se proporciona acceso a los suscriptores sin reautorización a través de un portal cautivo. Estos jardines amurallados le permiten aumentar los ingresos mediante la comercialización de diversos servicios a sus clientes.
Los enlaces típicos del jardín amurallado son:
Servicios de proveedores, como alquiler de automóviles
Portales de programas corporativos o de fidelización de hoteles y moteles
Servicios de habitaciones
Atracciones locales y clima
Esta documentación utiliza indistintamente los términos servicio de redireccionamiento HTTP y servicio de entrega de contenido de portal cautivo (CPCD).
El servicio de redireccionamiento HTTP implementa un controlador de datos y un controlador de control y los registra con reglas de servicio aplicables a las aplicaciones HTTP. Estas reglas son analizadas por el proceso cpcdd en el motor de enrutamiento. El controlador de datos aplica las reglas a los flujos de datos HTTP y maneja la reescritura de la dirección IP de destino o el envío de una respuesta HTTP con una URL de redireccionamiento preconfigurada. El mensaje de respuesta incluye un código de estado HTTP. A partir de Junos OS versión 17.3R1, el código de estado que se devuelve depende de la versión HTTP utilizada por el cliente HTTP que envió la solicitud GET. Cuando la versión es superior a HTTP 1.0, el servidor de redireccionamiento devuelve el código de estado 307 (redireccionamiento temporal). Cuando la versión es HTTP 1.0, se devuelve el código de estado 302 (encontrado). En versiones anteriores a 17.3R1, el servidor de redireccionamiento devuelve el código de estado 302 independientemente de la versión HTTP. Ambos códigos informan al cliente HTTP para que utilice la URL original, en lugar de la URL de redireccionamiento, para las solicitudes GET posteriores.
Cuando la respuesta a la solicitud HTTP se envía al suscriptor, la URL original se conserva anexándola opcionalmente al final de la URL de redireccionamiento configurada. La longitud máxima de la URL de redireccionamiento, incluida la URL original anexa, es de 128 bytes. A partir de la versión 17.3R1 de Junos, la longitud máxima de la URL de redireccionamiento aumenta a 1360 bytes y el servidor de redireccionamiento puede anexar información adicional sobre el suscriptor a la URL de redireccionamiento. La longitud máxima se aplica independientemente de si la información del suscriptor se anexa a la URL. Para anexar la información del suscriptor, puede especificar ciertos atributos de suscriptor en los VSA devueltos en el mensaje de aceptación y acceso de RADIUS en respuesta al inicio de sesión del suscriptor o en un mensaje de cambio de autorización (CoA) de RADIUS. Esto se aplica tanto a los VSA de servicio de activación (26-65) como a los de servicio de desactivación (26-66). La información del suscriptor se recupera de la base de datos de la sesión del suscriptor.
El controlador de control mantiene una conexión con el proceso cpcdd en el motor de enrutamiento para aprender los cambios de configuración, como la URL de redirección y el destino y puerto de la IP de reescritura. Para lograr un rendimiento más rápido, el controlador de control mantiene una caché de entidades configuradas relevantes, como direcciones URL, en un concentrador de puerto modular (MPC).
Los servicios de redireccionamiento HTTP son compatibles con IPv4 e IPv6. Puede asociar un servicio de redireccionamiento HTTP o un conjunto de servicios a una interfaz estática o dinámica. Para la administración dinámica de suscriptores, puede asociar servicios HTTP o conjuntos de servicios dinámicamente al iniciar sesión del suscriptor o mediante un cambio de autorización (CoA) de RADIUS.
A partir de Junos OS versión 17.2R1, existen tres métodos para configurar los servicios de redireccionamiento HTTP. A partir de Junos OS versión 19.3R2, la redirección HTTP también se puede configurar en la tarjeta de procesamiento de servicios MX-SPC3 si los servicios de próxima generación están habilitados. En la tabla 1 se enumeran los métodos admitidos por los servicios de redireccionamiento HTTP y las versiones de Junos OS que admiten cada método.
Le recomendamos que utilice Junos OS versión 15.1 y versiones posteriores para implementar servicios de redireccionamiento HTTP.
Método |
Versiones de Junos OS compatibles |
|
|---|---|---|
MS-DPC-based |
(No compatible con los servicios de próxima generación en la tarjeta de servicios MX-SPC3) |
|
Estático |
Versiones anteriores a la 15.1 |
|
Convergentes |
No compatible |
|
MS-MPC-based |
(No es compatible con los servicios de próxima generación en la tarjeta de servicios MX-SPC3). |
|
Estático |
A partir de Junos OS versión 15.1 |
|
Convergentes |
A partir de Junos OS versión 17.2 |
|
MX-SPC3-based |
|
|
|
Estático |
A partir de Junos OS versión 19.3R2 si los servicios de próxima generación están habilitados en la tarjeta de servicios MX-SPC3. |
|
Convergentes |
A partir de Junos OS versión 19.3R2 si los servicios de próxima generación están habilitados en la tarjeta de servicios MX-SPC3. |
Routing Engine-based |
|
|
Estático |
Todas las versiones de Junos OS |
|
Convergentes |
A partir de Junos OS versión 16.1R4 y 17.2 |
|
Para todos los métodos, configure el jardín amurallado como un filtro de servicio de firewall estático.
Portal cautivo basado en tarjetas de servicios
- Portal cautivo basado en MS-MPC
- Portal cautivo basado en tarjeta de servicios MX-SPC3
- Jardín amurallado configurado como filtro de servicio
Portal cautivo basado en MS-MPC
A partir de Junos OS versión 15.1R4, la única combinación de tarjeta de línea y tarjeta de interfaz que admite servicios de redireccionamiento HTTP en enrutadores serie MX es el concentrador de puerto modular multiservicios (MS-MPC) con una tarjeta de interfaz modular multiservicios (MS-MIC). Esta combinación proporciona un escalado mejorado y un alto rendimiento. Las MS-MIC y MS-MPC tienen memoria mejorada (16 GB para MS-MIC, 32 GB por NPU de MS-MPC) y capacidades de procesamiento. Las interfaces de servicios en MS-MPC y MS-MICs se identifican en la configuración con un prefijo ms- (por ejemplo, ms-1/2/1).
En toda esta documentación, el término basado en MS-MPC se refiere a las MPC con MS-MICs instaladas y a las MS-MICs solamente cuando se instalan en enrutadores de la serie MX que no aceptan tarjetas de línea.
Portal cautivo basado en tarjeta de servicios MX-SPC3
A partir de Junos OS versión 19.3R2, puede configurar servicios de redireccionamiento HTTP si los servicios de próxima generación están habilitados en la tarjeta de servicios MX-SPC3. Las interfaces de servicios en MX-SPC3 se identifican en la configuración con un prefijo vms- (por ejemplo, vms-1/2/1).
Jardín amurallado configurado como filtro de servicio
El flujo de paquetes para un portal cautivo basado en tarjetas de servicios difiere en función de cómo configure el jardín amurallado. El tráfico HTTP destinado a los servidores dentro del jardín amurallado no fluye a la tarjeta de servicios. Sin embargo, cualquier tráfico HTTP destinado fuera del jardín amurallado fluye hacia la tarjeta de servicios.
Para las solicitudes de suscriptor contenidas en el primer paquete de tráfico de datos, el sistema espera que el proxy TCP genere un indicador TCP SYN, lo que hace que el controlador de datos realice una búsqueda de reglas y aplique esas reglas a los flujos de datos HTTP.
Para una condición de reescritura HTTP: si la dirección de destino IP no se proporciona en la política, el controlador de control busca la dirección de destino IP.
Para una condición de redireccionamiento HTTP: el proxy TCP se activa para completar su protocolo de enlace de tres vías.
Para paquetes de solicitud HTTP.
Para una condición de reescritura HTTP: el controlador de control utiliza la dirección de destino IP almacenada en caché y modifica el paquete de datos.
Para una condición de redireccionamiento HTTP: el controlador de control envía una respuesta HTTP 302 o 307 con una URL de redireccionamiento preconfigurada.
Portal cautivo basado en motor de enrutamiento
El portal cautivo basado en motor de enrutamiento admite un jardín amurallado como filtro de servicio de firewall para servicios estáticos y convergentes. Tan pronto como el tráfico HTTP coincide con las reglas definidas en el filtro del servicio de firewall, el tráfico HTTP se envía al motor de enrutamiento. Las interfaces de servicios en el motor de enrutamiento se identifican con un prefijo si- (por ejemplo, si-1/1/0). La interfaz si- controla todo el tráfico y los servicios de redireccionamiento y reescritura para el motor de enrutamiento. La interfaz si- debe estar operativa con un estado de up para habilitar y activar el servicio de entrega de contenido del portal cautivo (CPCD). Una vez habilitado el servicio CPCD, cualquier cambio en el estado operativo de la interfaz si- no afecta a los servicios CPCD existentes.
Aprovisionamiento de servicios convergentes para servicios de redireccionamiento HTTP
A partir de Junos OS versión 17.2R1, el aprovisionamiento de servicios convergentes se admite tanto para los portales cautivos basados en motores de enrutamiento como en MS-MPC/MS-MIC. A partir de Junos OS versión 19.3R2, el aprovisionamiento de servicios convergentes también se admite para portales cautivos basados en tarjetas de servicios MX-SPC3 si los servicios de próxima generación están habilitados en la tarjeta de servicios MX-SPC3. El aprovisionamiento de servicios convergentes significa que puede configurar el aprovisionamiento de servicios en un perfil dinámico. Puede especificar variables definidas por el usuario para los servicios que se rellenan mediante un mensaje RADIUS VSA o un cambio de autorización (CoA).
Por ejemplo, es posible que desee tener una URL de redireccionamiento diferente para cada suscriptor. Puede crear una variable redirect-url en el perfil dinámico y, a continuación, configurar una regla de servicio para redirigir al suscriptor coincidente a $redirect-url. Cuando RADIUS autentica al usuario, el VSA de Activate-Service (26–65) proporciona la URL específica para ese usuario.
Aprovisionamiento de servicios estáticos para servicios de redireccionamiento HTTP
A partir de Junos OS versión 17.4R1, el aprovisionamiento de servicios estáticos se admite tanto para los portales cautivos basados en motores de enrutamiento como en MS-MPC/MS-MIC. A partir de Junos OS versión 19.3R2, el aprovisionamiento de servicios estáticos también se admite para portales cautivos basados en MX-SPC3 si los servicios de próxima generación están habilitados en la tarjeta de servicios MX-SPC3. El aprovisionamiento de servicios estáticos significa que puede configurar el aprovisionamiento de servicios en un perfil estático. Puede especificar variables definidas por el usuario (por ejemplo, http://portal.wifi.example.com/xx?wlanuseraddr=%subsc-ip%&nasaddr=%nas-ip%&acname=%ac -name%&url=%dest-url%&userlocation=%nas-port-id%&usermac=%mac-sa%& session-id=%sess-id%&username=%user-name%&wlanuseraddrv6=%subsc-ipv6%) para los servicios que se rellenan mediante un mensaje RADIUS VSA o un mensaje de cambio de autorización (CoA).
En la CPCD estática, los atributos de una URL de redireccionamiento no se envían en los VSA, Activate-Service (26-65) y Deactivate-Service (26-66) de Juniper Networks. Puede configurarlo como se muestra en el siguiente ejemplo:
captive-portal-content-delivery {
rule redirect {
match-direction input;
term t1 {
then {
redirect url;
}
}
}
}
Los tokens en la url como "subsc-ip", "nas-ip", "ac-name" deben especificarse entre el símbolo "%". El orden de los tokens no importa.
La siguiente es una lista de tokens con su significado:
%subsc-ip%: dirección IP privada del suscriptor.
%nas-ip%: dirección IP BNG.
%ac-name%: estará vacío para el BNG.
%dest-url%: la URL de la solicitud original.
%nas-port-id%: se utiliza para suscriptores. Este parámetro debe incluir el nombre de la interfaz, pvlan y cvlan. El nombre de la interfaz puede ser el nombre de la interfaz física o virtual. Por ejemplo, ge0/0/0 o ae0. El rango de pvlan y cvlan es 14095
%mac-sa%: dirección MAC del cliente WLAN.
%sess-id%: identificador de sesión del suscriptor.
%user-name%: nombre de usuario de un suscriptor.
%subsc-ipv6%: dirección IPv6 del suscriptor (solo la dirección de la IANA). Si no se especifica la dirección IANA para el suscriptor, este campo estará vacío.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.