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 puede interceptarse y redirigirse 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 una política de uso de 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 vallado, también conocido como lista de permitidos, define un grupo de servidores en los que 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 de jardines amurallados 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 los términos servicio de redireccionamiento HTTP y servicio de entrega de contenido de portal cautivo (CPCD) indistintamente.
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 controla 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. 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 la 17.3R1, el servidor de redireccionamiento devuelve el código de estado 302 independientemente de la versión de HTTP. Ambos códigos informan al cliente HTTP de que utilice la URL original, en lugar de la URL de redireccionamiento, para las solicitudes GET posteriores.
Cuando se envía la respuesta a la solicitud HTTP 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 adjunta, es de 128 bytes. La longitud máxima de la URL de redireccionamiento se incrementa 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 adjunta a la dirección URL. Para anexar la información del suscriptor, puede especificar determinados atributos de suscriptor en los VSA devueltos en el mensaje de acceso de aceptación 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 activación de servicio (26-65) como de desactivación de servicio (26-66). La información del suscriptor se recupera de la base de datos de sesiones 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 redireccionamiento y el puerto y el destino de la IP de reescritura. Para lograr un rendimiento más rápido, el controlador de control mantiene una caché de las entidades configuradas pertinentes, como direcciones URL, en un concentrador de puerto modular (MPC).
Los servicios de redireccionamiento HTTP son compatibles tanto con IPv4 como con 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 adjuntar servicios HTTP o conjuntos de servicios dinámicamente al iniciar sesión del suscriptor o mediante un cambio de autorización (CoA) de RADIUS.
-
Puede configurar hasta 1000 servicios de redireccionamiento HTTP.
-
Puede crear contadores para cada término en un filtro de servicio de redireccionamiento HTTP. Dado que el filtro de servicio se instala como un filtro compartido, solo hay un único contador de agregados disponible en el hardware para cada término configurado. La aplicación de entrega de contenido de portal cautivo (CPCD) cuenta los paquetes redirigidos en software mediante un contador de agregados. Utilice el
show services captive-portal-content-delivery statistics interfacecomando para ver las estadísticas del contador.
Hay tres métodos para configurar los servicios de redireccionamiento HTTP. También puede configurar el redireccionamiento HTTP 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 para los servicios de redireccionamiento HTTP y las versiones de Junos OS compatibles con cada método.
| Método |
Versiones de Junos OS compatibles |
|
|---|---|---|
| MS-DPC-based |
(No compatible con servicios de próxima generación en la tarjeta de servicios MX-SPC3) |
|
| Estático |
Versiones anteriores a la 15.1 |
|
| Convergencia |
No compatible |
|
| MS-MPC-based |
(No compatible con servicios de próxima generación en la tarjeta de servicios MX-SPC3). |
|
| Estático |
A partir de la versión 15.1 de Junos OS |
|
| Convergencia |
A partir de la versión 17.2 de Junos OS |
|
| MX-SPC3-based |
||
| Estático |
A partir de la versión 19.3R2 de Junos OS, si los servicios de próxima generación están habilitados en la tarjeta de servicios MX-SPC3. |
|
| Convergencia |
A partir de la versión 19.3R2 de Junos OS, 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 |
|
| Convergencia |
A partir de Junos OS versión 16.1R4 y 17.2 |
|
Para todos los métodos, configure el jardín vallado 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 vallado" 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 de la serie MX es el concentrador de puerto modular multiservicios (MS-MPC) con una tarjeta de interfaz modular multiservicios (MS-MIC). Esta combinación proporciona una mejor escala y un alto rendimiento. Las MS-MIC y MS-MPC tienen capacidades mejoradas de memoria (16 GB para MS-MIC, 32 GB por NPU de MS-MPC) y de procesamiento. Las interfaces de servicios en MS-MPC y MS-MIC se identifican en la configuración con un prefijo ms- (por ejemplo, ms-1/2/1).
A lo largo de esta documentación, el término basado en MS-MPC se refiere a las MPC con MS-MIC instaladas y solo a las MS-MIC cuando están instaladas 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 la versión 19.3R2 de Junos OS, puede configurar los 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 vallado" configurado como filtro de servicio
El flujo de paquetes de un portal cautivo basado en tarjetas de servicios varía en función de cómo se configure el jardín vallado. 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 a 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 que haga 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 IP de destino no se proporciona en la política, el controlador de control busca la dirección IP de destino.
Para una condición de redireccionamiento HTTP: el proxy TCP se activa para completar su apretón de manos 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 el 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 coincida con las reglas definidas en el filtro de 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 redirección y reescritura para el motor de enrutamiento. La interfaz si debe estar operativa con un estado activo para habilitar y activar el servicio de entrega de contenido de 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 la versión 17.2R1 de Junos OS, el aprovisionamiento de servicios convergente se admite tanto para portales cautivos basados en motores de enrutamiento como basados en MS-MPC/MS-MIC. A partir de Junos OS versión 19.3R2, el aprovisionamiento de servicios convergente 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 convergente 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 VSA de RADIUS o un mensaje de 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 la suscriptor coincidente a $redirect-url. Cuando RADIUS autentica al usuario, Activate-Service VSA (26–65) proporciona la URL específica de ese usuario.
Aprovisionamiento de servicios estáticos para servicios de redireccionamiento HTTP
A partir de la versión 17.4R1 de Junos OS, el aprovisionamiento de servicios estáticos se admite tanto para portales cautivos basados en motores de enrutamiento como basados 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 servicios que se rellenan mediante un VSA de RADIUS o un mensaje de cambio de autorización (CoA).
En CPCD estático, los atributos de una URL de redireccionamiento no se envían en los VSA de Juniper Networks, Activate-Service (26-65) y Deactivate-Service (26-66). Puede configurarla 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 dirección URL como "subsc-ip", "nas-ip", "ac-name" deben especificarse entre el símbolo "%". El orden de las fichas no importa.
A continuación se muestra una lista de tokens con su significado:
%subsc-ip%: dirección IP privada del suscriptor.
%nas-ip%: dirección IP de BNG.
%ac-name%: estará vacío para el BNG.
%dest-url%: la url de la solicitud original.
%nas-port-id%: se utiliza para el suscriptor. Este parámetro debe incluir el nombre de la interfaz, pvlan y cvlan. El nombre de interfaz puede ser un nombre de 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%: ID de sesión del suscriptor.
%user-name%: nombre de usuario de un suscriptor.
%subsc-IPv6%: dirección IPv6 del suscriptor (solo dirección de la AANI). Si no se especifica la dirección AANI para el suscriptor, este campo estará vacío.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.