Servicios de redes de aplicaciones : Cisco LocalDirector de la serie 400

Configuración del redireccionamiento de HTTP a HTTPS en Cisco LocalDirector.

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


LocalDirector ahora es Fin de la Venta. Refiera a los boletines del Cisco LocalDirector de la serie 400 para más información.


Contenido


Introducción

Este documento explica cómo configurar HTTP (sitio no seguro) para redireccionamiento HTTPS (sitio seguro) en Cisco Local Director. Observe por favor las limitaciones en este ejemplo de configuración.

Antes de comenzar

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

prerrequisitos

No hay requisitos previos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las versiones de software y hardware indicadas a continuación.

  • Local Director 416

  • Versión 4.2.1 del Software Local Director

  • Microsoft Internet Explorer 5.5

  • Netscape Communicator 4.7

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Diagrama de la red

Este documento utiliza la instalación de red que se muestra en el siguiente diagrama.

http2https-01.gif

Información importante

Hay un problema bien conocido de guardar un límite de la sesión a un servidor real físico después de que la sesión se ponga en el transporte HTTP (ábrase) y posterior movido al Transport Protocol (seguro) HTTPS. En este caso, la redirección de HTTP se debe poner en el nivel de aplicación. El servidor puede enviar una reorientación (302 o un HREF integrado en la página web real sí mismo) al HTTP, así que ningún Equilibrio de carga ocurre en el Local Director.

Otra Solución posible sería conmutar al HTTPS más pronto, y realiza la apertura de la sesión cifrada. Esto se prefiere también para cifrar el nombre de usuario y contraseña del login. Si usted guarda la sesión entera el ejecutarse vía el HTTPS, el Sticky genérico puede asegurarse de que el mismo servidor sea utilizado para un cliente.

La segunda solución y configuración se describe en este documento. El tráfico HTTP se limita al primer contacto con el sitio (el cliente puede teclear el nombre del sitio simple a la barra de dirección). Al alcanzar al Local Director, el navegador recibe 302 reorienta el mensaje con el URL configurado, incluyendo la etiqueta HTTPS, tan allí es el nombre completo del servidor a alcanzar. La sesión (en el nivel de aplicación) se construye del empezando por el servidor seguro (los servidores reales no dirigen el HTTP en absoluto). El La sesión continúa con el único Nombre del servidor, así que está alcanzando siempre lo mismo.

Los comandos dip, backup, y link, tal y como se muestra en del ejemplo, son necesarios solucionar el problema del marcador cuando un usuario guarda un URL con uno Nombre del servidor y las devoluciones más adelante cuando el servidor está abajo. El servidor de backup configurado servirá la sesión. Si usted espera tener una parte de la sesión (en el nivel de aplicación) manejada vía el HTTP, después no hay posibilidad en el Local Director (o cualquier otro dispositivo de red) para conectar la conexión HTTPS a las conexiones HTTP preexistentes unas de los. El único parámetro de uso general puede ser la dirección IP de origen. La dirección IP de origen se convierte en conexiones HTTPS inutilizables cuando usted considera el proxy de HTTP, solamente directas. Toda la información salvada en el URL o encabezado HTTP (por ejemplo los Cookie) se cifra, así no accesible.

La única solución en este caso es que la aplicación sí mismo utiliza el específico Nombre del servidor al conmutar al HTTPS. Pues la aplicación se ejecuta en el servidor real, y genera el HTTPS URL, es el único lugar en donde el problema puede ser solucionado. El servidor envía simplemente un URL dirigido al servidor sí mismo. Con la ayuda del comando backup, usted puede solucionar el problema del marcador, como arriba. Una desventaja de ambas soluciones es una necesidad de diversos Certificados del Secure Socket Layer (SSL) en ambos servidores reales. El número de servidores HTTP/HTTPS no es limitado, y el Local Director sigue siendo de equilibrio de los pedidos de sesión iniciales. Después de que se establezca la sesión, sin embargo, los clientes refieren a un servidor solamente.

Cómo configurar HTTP para el redireccionamiento de protocolos HTTP en Cisco Local Director

Utilice el siguiente procedimiento para configurar HTTP para el redireccionamiento HTTPS en el Local Director:

  1. Cree un direccionamiento del límite del acceso IP virtual (VIP) y ingreselo en el Domain Name System (DNS). Por ejemplo:

    virtual 172.18.124.209:80:0:tcp is
    
  2. Cree una dirección IP directa (DIP) para cada servidor real que aceptará llamadas para esta dirección VIP. Utilice una dirección IP adicional en la primera parte de la declaración, por ejemplo en el siguiente:

    direct-ip 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp is
    direct-ip 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp is
    

    El sistema creará lo siguiente:

    real 172.18.124.206:443:0:tcp is
    real 172.18.124.207:443:0:tcp is
     
    bind 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp
    bind 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp
    

    Nota: Para el límite del acceso o el específico portuario VIP, las INMERSIONES, y los IP Address reales, una dirección IP adicional son necesarios para que cada servidor real permita las conexiones salientes continuas a los IP Address reales. Además, esta dirección adicional acepta direcciones VIP seguras en caso de que se envíen paquetes de reinicio TCP (RST) hacia puertos que no poseen balance de carga ni se hallan redireccionados. Las llamadas dirigidas a los direccionamientos de la INMERSIÓN por su dirección verdadera serían permitidas mientras que usaban otros IP Addresses para los direccionamientos de la INMERSIÓN virtuales.

  3. Cree un redireccionamiento de URL para cada servidor real Estos URL son donde reorientarán al cliente cuando se golpea un direccionamiento VIP. Por ejemplo:

    url s2 https://www.mysecureserver.com 302
    url s1 https://www.yoursecureserver.com 302
    
  4. Cree un comando backup para cada dirección DIP de la dirección VIP común para solucionar los posibles problemas de marcadores. Si un cliente añade la URL de una dirección DIP a favoritos y esa dirección DIP (servidor real) no está disponible (FALLÓ), entonces el comando backup se utiliza para llamar nuevamente a la dirección VIP.

    backup 172.18.124.211:443:0:tcp 172.18.124.212:443:0:tcp
    backup 172.18.124.212:443:0:tcp 172.18.124.211:443:0:tcp
    

    Nota: Usted no puede de reserva un TCP/443 con un TCP/80, por lo tanto, usted tiene dos opciones:

    • Respaldo un direccionamiento de la INMERSIÓN con otro direccionamiento de la INMERSIÓN, o en un sytle de la interconexión total (cada direccionamiento de la INMERSIÓN tiene un respaldo a cada otro direccionamiento de la INMERSIÓN).

    • Realizar una copia de seguridad de una dirección DIP con un VIP/443 conectado al real/443.

  5. Enlazar la dirección VIP a cada comando URL. Por ejemplo:

    bind 172.18.124.209:80:0:tcp s1
    bind 172.18.124.209:80:0:tcp s2
    
  6. Cree un comando de link para cada URL a la primera parte de la dirección DIP.

    Esto crea una asociación entre la dirección DIP y la URL que se asocia con ese apodo. El link asegura que Local Director no redireccione a los clientes hacia una dirección DIP errónea, la cual está asignada de uno en uno con un servidor real. Si una dirección de DIP falla, no redireccione al URL que enviaría una llamada a la dirección de DIP con falla.

    link s2 172.18.124.211:443:0:tcp
    link s1 172.18.124.212:443:0:tcp
    

Verificación

En esta sección encontrará información que puede utilizar para confirmar que su configuración esté funcionando correctamente.

La herramienta Output Interpreter (sólo para clientes registrados) permite utilizar algunos comandos “show” y ver un análisis del resultado de estos comandos.

  • show version: muestra la versión de software que ejecuta Local Director.

  • show configuration - Muestra la configuración actual que se ejecuta en el Local Director.

  • inmersión de la demostración - Pairings de la INMERSIÓN de las visualizaciones.

  • show real - Muestra las estadísticas y estados de los servidores reales.

  • show statistics - Muestra las estadísticas reales y virtuales del servidor.

  • show syslog - Muestra mensajes de registro al servidor syslog.

  • show url - Muestra la información de conexión hacia las URL.

Lo que sigue es la salida del comando show version:

localdirector#show version
LocalDirector 416 Version 4.2.1

El siguiente es el resultado del comando show configuration:

localdirector#show configuration
Building configuration...
: Saved
: LocalDirector 416 Version 4.2.1
syslog output 23.7
no syslog console
enable password 000000000000000000000000000000 encrypted
hostname localdirector
no shutdown ethernet 0
no shutdown ethernet 1
shutdown ethernet 2
interface ethernet 0 auto
interface ethernet 1 auto
interface ethernet 2 auto
mtu 0 1500
mtu 1 1500
mtu 2 1500
multiring all
no secure 0
no secure 1
no secure 2
no ping-allow 0
no ping-allow 1
no ping-allow 2
ip address 172.18.124.210 255.255.255.0
route 0.0.0.0 0.0.0.0 172.18.124.1 1
arp timeout 30
no rip passive
rip version 1
failover ip address 0.0.0.0
no failover
failover hellotime 30
password 636973636f004661696c6f766572204e encrypted
snmp-server enable traps
snmp-server community public
no snmp-server contact
no snmp-server location
virtual 172.18.124.209:80:0:tcp is
real 172.18.124.206:443:0:tcp is
real 172.18.124.207:443:0:tcp is
direct-ip 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp is
direct-ip 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp is
url s2 https://www.mysecureserver.com 302
url s1 https://www.yoursecureserver.com 302
backup 172.18.124.211:443:0:tcp 172.18.124.212:443:0:tcp
backup 172.18.124.212:443:0:tcp 172.18.124.211:443:0:tcp
bind 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp
bind 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp
bind 172.18.124.209:80:0:tcp s1
bind 172.18.124.209:80:0:tcp s2
link s2 172.18.124.211:443:0:tcp
link s1 172.18.124.212:443:0:tcp
: end
[OK]

El siguiente es el resultado del comando show dip:

localdirector#show dip
Direct IPs:
 
Virtual Real Conns State Predictor Slowstart
172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp 0 IS leastconns roundrobin*
172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp 0 IS leastconns roundrobin*

A continuación se muestra el resultado del comando show real:

localdirector#show real
Real Machines:
 
No Answer TCP Reset DataIn
Machine Connect State Thresh Reassigns Reassigns Conns
(DIP) 172.18.124.206:443:0:tcp 1 IS 8 0 0 0
(DIP) 172.18.124.207:443:0:tcp 1 IS 8 0 0 0

El siguiente es el resultado del comando show statistics:

localdirector#show statistics
Real Machine(s) Bytes Packets Connections
(DIP) 172.18.124.206:443:0:tcp 480 8 1
(DIP) 172.18.124.207:443:0:tcp 240 4 1
 
Virtual Machine(s) Bytes Packets Connections
(DIP) 172.18.124.211:443:0:tcp 480 8 1
(DIP) 172.18.124.212:443:0:tcp 240 4 1
172.18.124.209:80:0:tcp 10215 80 6

Lo que sigue es la salida del comando show syslog:

OUTPUT ON (23.7)
CONSOLE ON
<189> July 2 13:07:40 LD-NOTICE Begin Configuration: reading from terminal
<189> July 2 13:07:45 LD-NOTICE End Configuration: OK
<186> July 2 13:08:00 LD-CRIT Switching '172.18.124.209:80:0:tcp' 
from 'slowstart' to 'leastconns'
<186> July 2 13:10:25 LD-CRIT Switching '172.18.124.211:443:0:tcp' 
from 'slowstart' to 'leastconns'
<186> July 2 13:10:41 LD-CRIT Switching '172.18.124.212:443:0:tcp' 
from 'slowstart' to 'leastconns'
localdirector#

El siguiente es el resultado del comando show url:

localdirector#show url
Urls:
 
Id Connect Rcode State Url
s2 2 302 IS https://www.mysecureserver.com
s1 2 302 IS https://www.yoursecureserver.com

Troubleshooting

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 44124