Configuración de servicios de redireccionamiento HTTP estáticos basados en motores de enrutamiento

Cuando se configura el jardín amurallado como un filtro de servicio de firewall, se identifica y omite el tráfico destinado a los servidores dentro del jardín amurallado. El resto del tráfico HTTP está destinado a direcciones fuera del jardín amurallado. Dado que este tráfico no coincide con las condiciones del filtro, fluye hacia el motor de enrutamiento para su manejo.

Puede configurar el filtro de servicio para que el jardín amurallado contenga un único servidor como portal cautivo o una lista de servidores.

• Configure el jardín amurallado con un solo servidor como portal cautivo:

  1. Cree el filtro de servicio.

     content_copy zoom_out_map

     [edit]
     user@host# edit firewall family address-family service-filter filter-name
     

  2. Defina un término de filtro para identificar y omitir el procesamiento del tráfico al portal cautivo.

     1. Especifique las condiciones de filtro para que coincidan con el tráfico destinado al portal cautivo especificando la dirección de destino del portal cautivo y el puerto de destino.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name from destination-address ip-address
        user@host# set term name from destination-port port-number
        

     2. Especifique que el tráfico coincidente omite el procesamiento en la tarjeta de línea.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name then skip
        

  3. Defina un término de filtro para identificar el tráfico HTTP de todo el tráfico que no coincidía con el término anterior y envíelo para su procesamiento mediante las reglas del servicio CPCD.

     1. Especifique uno o más números de puerto HTTP para que coincidan con el tráfico HTTP omitido.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name from destination-port http-port-number
        

     2. Especifique que un servicio CPCD procesa el tráfico coincidente.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name then service
        

  4. Defina un término de filtro para omitir más acciones para cualquier tráfico restante que no sea HTTP.

     content_copy zoom_out_map

     [edit firewall family inet service-filter filter-name]
     user@host# set term name then skip
     

  Por ejemplo, la siguiente configuración crea un filtro para el tráfico HTTP IPv4, walled-v4, con el portal cautivo en 192.0.2.0. El procesamiento se omite para el tráfico que coincide con la dirección; El tráfico se envía al portal cautivo. El tráfico no coincidente va al término http, donde el tráfico HTTP se selecciona de todo el tráfico omitido y se envía para ser procesado de acuerdo con un servicio CPCD. Por último, la omisión de término hace que se omita todo el tráfico restante que no sea HTTP.

  content_copy zoom_out_map

  [edit]
  user@host# edit firewall family inet service-filter walled-v4
  [edit firewall family inet service-filter walled-v4]
  user@host# set term portal from destination-address 192.0.2.0
  user@host# set term portal from destination-port 80
  user@host# set term portal then skip
  user@host# set term http from destination-port 80
  user@host# set term http then service
  user@host# set term skip then skip
  

• Configure el jardín amurallado como una lista o subred de servidores.

  1. Cree el filtro de servicio.

     content_copy zoom_out_map

     [edit]
     user@host# edit firewall family address-family service-filter filter-name
     

  2. Defina un término de filtro.

     1. Especifique las condiciones de filtro para que coincidan con el tráfico destinado a cualquier servidor del jardín amurallado especificando una lista de prefijos de destino de servidores.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name from destination-prefix-list list-name
        user@host# set term name from destination-port port-number
        

     2. Especifique que el tráfico coincidente omite el procesamiento en la tarjeta de línea.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name then skip
        

  3. Defina un término de filtro para identificar el tráfico HTTP de todo el tráfico que no coincidía con el término anterior y envíelo para su procesamiento mediante las reglas del servicio CPCD.

     1. Especifique uno o más números de puerto HTTP para que coincidan con el tráfico HTTP omitido.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name from destination-port http-port-number
        

     2. Especifique que un servicio CPCD procesa el tráfico coincidente.

        content_copy zoom_out_map

        [edit firewall family inet service-filter filter-name]
        user@host# set term name then service
        

  4. Defina un término de filtro para omitir más acciones para cualquier tráfico restante que no sea HTTP.

     content_copy zoom_out_map

     [edit firewall family inet service-filter filter-name]
     user@host# set term name then skip
     

  5. (Opcional) Defina una lista de prefijos que especifique los servidores dentro del jardín amurallado. Puede especificar una subred o varias direcciones individuales.

     content_copy zoom_out_map

     [edit policy-options]
     user@host# set prefix-list list- name ip-address/mask
     user@host# set prefix-list list- name ip-address1
     user@host# set prefix-list list- name ip-address2
     

  Por ejemplo, la siguiente configuración crea un filtro para el tráfico HTTP IPv6, walled-v6-list, con una lista de prefijos, wg-list, que especifica dos servidores en el jardín amurallado. El término de filtro portal6 identifica el tráfico IPv6 destinado al jardín amurallado. El tráfico no coincidente pasa al término http6, donde el tráfico HTTP se selecciona de todo el tráfico omitido y se envía para ser procesado de acuerdo con un servicio CPCD. Finalmente, el término skip6 hace que se omita todo el tráfico restante que no sea HTTP.

  content_copy zoom_out_map

  [edit]
  user@host# edit firewall family inet6 service-filter walled-v6-list
  user@host# set term portal6 from destination-prefix-list wg-list
  user@host# set term portal6 then skip
  user@host# set term http6 from destination-port [80 8080]
  user@host# set term http6 then service
  user@host# set term skip6 then skip
  [edit policy-options]
  user@host# set prefix-list wg-list 2001:db8::10.10
  user@host# set prefix-list wg-list 2001:db8::10.22
  

Cuando se realizan solicitudes HTTP para sitios fuera del jardín amurallado, CPCD puede redirigir el tráfico a un portal cautivo para su autenticación y autorización.

Configure una regla de servicio CPCD que especifique la acción que debe realizarse para el tráfico destinado fuera del jardín amurallado. Este tráfico fue identificado por el filtro de servicio de jardín amurallado y pasado al servicio, o identificado y aceptado por la regla de servicio de jardín amurallado. La acción que configure dependerá de si está utilizando un servidor de redireccionamiento HTTP local o remoto:

• Si utiliza un servidor de redireccionamiento HTTP local en el enrutador, especifique la acción de redireccionamiento.

• Si está utilizando un servidor de redireccionamiento HTTP remoto, que reside en un jardín amurallado detrás del enrutador, entonces no puede simplemente especificar una URL de redireccionamiento. En este caso, la regla de servicio debe reescribir la dirección IP de destino del tráfico. La nueva dirección de destino es la dirección del servidor de redireccionamiento HTTP remoto. A continuación, el servidor remoto proporciona una URL de redireccionamiento para enviar el tráfico a un portal cautivo.

El servicio CPCD está asociado a una interfaz de servicio mediante un conjunto de servicios. Tanto el conjunto de servicios como el filtro de servicio de jardín amurallado se aplican a una interfaz configurada estáticamente.

Los conjuntos de servicios definen uno o más servicios que debe realizar el motor de enrutamiento. Para los servicios de redireccionamiento HTTP, se define un perfil de servicio CPCD que incluye reglas CPCD. El conjunto de servicios aplica el perfil de servicio CPCD a una interfaz de servicio específica.

Para utilizar los servicios de redireccionamiento HTTP, debe adjuntar el conjunto de servicios CPCD a una interfaz lógica. Si el jardín amurallado está configurado como un filtro de servicio, debe adjuntarlo a la misma interfaz que el conjunto de servicios. El tráfico que entra y sale de esa interfaz se filtra mediante el filtro de servicio. El tráfico identificado para el mantenimiento se envía a la interfaz de servicio del motor de enrutamiento, donde se aplica el perfil CPCD.

Los siguientes pasos corresponden a la figura 1.

1. El dispositivo del usuario, el cliente HTTP, realiza una secuencia de protocolo de enlace TCP con el servidor HTTP.

2. Cuando el protocolo de enlace se realiza correctamente, el cliente envía un HTTP GET con la URL solicitada por el usuario.

3. El motor de enrutamiento modifica esa URL concatenando una cadena de caracteres aleatorios encerrados por /$ y $/. La longitud de la cadena coincide con la longitud combinada de las etiquetas que se insertarán más adelante. La cadena sirve como identificador cuando el cliente la devuelve.

   Supongamos que la longitud de las etiquetas que se van a insertar es de 30 caracteres y la URL solicitada es http://192.51.100.20/test.html. El motor de enrutamiento devuelve la dirección URL modificada con una cadena de 30 caracteres aleatorios, como en el ejemplo siguiente:

   http://192.51.100.20/test.html/$IIGSbVdNDTDvnJFIAyoysXwVJawoYj$/

4. El motor de enrutamiento envía la URL modificada con un código de estado de 302 (encontrado) o 307 (redireccionamiento temporal). El código enviado depende de la versión de HTTP que se utilice y de la versión de Junos OS en el BNG. Ambos códigos indican al cliente que la solicitud de acceso debe reenviarse con la URL modificada.

5. El motor de enrutamiento restablece la conexión TCP con el cliente y el servidor.

6. El cliente realiza un protocolo de enlace TCP con el servidor HTTP para una dirección URL modificada.

7. El cliente envía un HTTP GET con la URL modificada.

8. El motor de enrutamiento comprueba si la longitud de la cadena concatenada es la misma que la enviada al cliente.

   • Si la longitud es correcta, devuelve la URL a la URL solicitada originalmente, inserta las etiquetas en el encabezado GET y reenvía la GET al servidor HTTP. Si está configurado, el GET se puede reenviar opcionalmente a una URL de redireccionamiento en lugar del servidor solicitado originalmente.

   • Si la longitud no es correcta, el motor de enrutamiento descarta el paquete e incrementa el contador de entrega.

9. El servidor HTTP evalúa el mensaje GET y envía una respuesta al cliente con un código de estado de 200 (OK) si concede acceso o 403 (Forbidden) si se rechaza la solicitud.

10. El motor de enrutamiento termina la conexión TCP con el cliente y el servidor.

Figura 1: Inserción de etiquetas para el flujo de mensajes de redireccionamiento HTTP.

Para configurar las etiquetas que se insertarán en los encabezados GET: