Serviços de rede de aplicativos : Cisco LocalDirector 400 Series

Configurando HTTP para redirecionamento de HTTPS no Cisco LocalDirector

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


LocalDirector é agora Fim--venda. Refira os boletins do Cisco LocalDirector série 400 para mais informação.


Índice


Introdução

Este documento explica como configurar o http (site não-seguro) para redirecionamento para o HTTPS (site seguro) no Cisco Local Director. Note por favor as limitações neste exemplo de configuração.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware abaixo.

  • Diretor local 416

  • Versão do software Local Director 4.2.1

  • Microsoft Internet Explorer 5.5

  • Netscape Communicator 4.7

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Diagrama de Rede

Este documento utiliza a instalação de rede mostrada no diagrama abaixo.

http2https-01.gif

Informações importantes

Há um problema conhecido de manter um limite da sessão a um servidor real físico depois que a sessão setup no transporte HTTP (abra) e está movida mais tarde para o protocolo de transporte (seguro) HTTPS. Neste caso, o Redireção do HTTP deve ser setup a nível do aplicativo. O server pode enviar uma reorientação (uns 302 ou um HREF encaixado no página da web real próprio) ao HTTP, assim que nenhum Balanceamento de carga ocorre no diretor local.

Uma outra solução possível seria comutar mais logo ao HTTPS, e executa a abertura da sessão cifrada. Isto é preferido igualmente cifrando o nome de usuário e senha do início de uma sessão. Se você mantém a sessão inteira ser executado através do HTTPS, o Sticky genérico pode assegurar-se de que o mesmo server esteja usado para um cliente.

A segundas solução e configuração são descritas neste documento. O tráfego de HTTP é limitado ao primeiro contato com o local (o cliente pode datilografar o nome de site simples à barra de endereços). Ao alcançar o diretor local, o navegador recebe uns 302 reorienta a mensagem com a URL configurada, incluindo a etiqueta HTTPS, tão lá é o nome completo do server a alcançar. A sessão (no nível do aplicativo) é construída desde o início com o servidor seguro (os servidores reais não seguram o HTTP de todo). Continua A sessão com o nome do servidor original, assim que está alcançando sempre o mesmos.

Os comandos dip, backup, e link, segundo as indicações do exemplo, são precisados de resolver o problema do endereço da Internet quando um usuário salvar uma URL com um nome do servidor e retornam mais tarde quando o server está para baixo. O servidor de backup configurado servirá a sessão. Se você espera ter parte da sessão (no nível do aplicativo) segurada através do HTTP, a seguir não há nenhuma possibilidade no diretor local (ou em algum outro dispositivo de rede) para ligar a conexão de HTTPS a algumas das conexões de HTTP de preexistência. O único parâmetro de uso geral pode ser o endereço IP de origem. O endereço IP de origem transforma-se conexões de HTTPS inusáveis quando você considera o proxy HTTP, mas diretas. Toda a informação armazenada na URL ou no cabeçalho HTTP (tal como Cookie) é cifrada, assim não acessível.

A única solução é neste caso que o aplicativo próprio usa o nome do servidor específico ao comutar ao HTTPS. Porque o aplicativo é executado no servidor real, e gera o HTTPS URL, é o único lugar onde a edição pode ser resolvida. O server envia simplesmente uma URL dirigida ao server próprio. Com a ajuda do comando backup, você pode resolver o problema do endereço da Internet, como acima. Uma desvantagem de ambas as soluções é uma necessidade para Certificados diferentes do Secure Socket Layer (SSL) em ambos os servidores reais. O número de server HTTP/HTTPS não é limitado, e o diretor local permanece de equilíbrio as requisições de sessão iniciais. Depois que a sessão é estabelecida, contudo, os clientes referem um server somente.

Como configurar o redirecionamento de HTTP para HTTPS no Cisco Local Director

Use os seguintes passos para configurar o redirecionamento de HTTP para HTTPS no Local Director:

  1. Crie um endereço do IP virtual do limite de porta (VIP) e incorpore-o ao Domain Name System (DNS). Por exemplo:

    virtual 172.18.124.209:80:0:tcp is
    
  2. Crie um endereço IP direto (DIP) para cada servidor real que aceitará chamadas para esse endereço VIP. Use um endereço IP de Um ou Mais Servidores Cisco ICM NT extra no primeiro parte da indicação, como no seguinte:

    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
    

    O sistema criará o seguinte:

    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 o limite de porta ou o específico de porta VIP, os MERGULHOS, e os endereços IP real, um endereço IP de Um ou Mais Servidores Cisco ICM NT adicional são precisados para que cada servidor real permita conexões externas continuadas aos endereços IP real. Além disso, esse endereço adicional permite endereços VIP seguros caso qualquer pacotes de redefinição TCP (RST) sejam enviados para portas não balanceadas para carga ou redirecionadas. Os atendimentos dirigidos aos endereços do MERGULHO por seu endereço verdadeiro seriam permitidos ao usar outros endereços IP de Um ou Mais Servidores Cisco ICM NT para os endereços do MERGULHO virtuais.

  3. Crie um redirecionamento de URL para cada servidor real. Estas URL são o lugar onde o cliente será reorientado quando um endereço VIP é batido. Por exemplo:

    url s2 https://www.mysecureserver.com 302
    url s1 https://www.yoursecureserver.com 302
    
  4. Crie um comando de backup para cada endereço DIP para o endereço VIP comum a fim de resolver possíveis problemas de marcação. Se um cliente marcar a URL de um endereço DIP e esse endereço DIP (servidor real) não estiver disponível (FALHO), então, o comando de backup será usado para chamar o endereço VIP novamente.

    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: Você não pode alternativo um TCP/443 com um TCP/80, consequentemente, você tem duas opções:

    • Backup um endereço do MERGULHO com um outro endereço do MERGULHO, ou em um sytle da malha cheia (cada endereço do MERGULHO tem um backup a cada outro endereço do MERGULHO).

    • Faça backup de um endereço DIP com VIP/443 vinculado ao real/443.

  5. Ligue o endereço VIP a cada comando de URL. Por exemplo:

    bind 172.18.124.209:80:0:tcp s1
    bind 172.18.124.209:80:0:tcp s2
    
  6. Crie um comando de enlace para cada URL na primeira parte do endereço DIP.

    Isso cria uma associação entre o endereço DIP e os URLs associados àquele apelido. O link garante que o Local Director não redireciona clientes para um endereço DIP falho, que é mapeado um para um com um servidor real. Se um endereço DIP falhar, não redirecione para o URL que enviaria uma chamada ao endereço DIP que falhou.

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

Verificar

Esta seção fornece informações que você pode usar para confirmar se sua configuração está funcionando adequadamente.

A Output Interpreter Tool (somente clientes registrados) oferece suporte a determinados comandos show, o que permite exibir uma análise da saída do comando show.

  • show version - Exibe a versão de software em execução no Local Director.

  • show configuration - Exibe a configuração de execução atual no Local Director.

  • mergulho da mostra - Pairings do MERGULHO dos indicadores.

  • mostra real - Indica as estatísticas e os estados dos servidores reais.

  • show statistics - Exibe as estatísticas do servidor real e virtual.

  • show syslog – Exibe mensagens de log para o servidor syslog.

  • show url - exibe informações de conexões de URLs.

O seguinte é a saída do comando show version:

localdirector#show version
LocalDirector 416 Version 4.2.1

A saída a seguir corresponde à saída do 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]

A saída do comando show dip é a seguinte:

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*

O que se segue é a saída do 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

A saída a seguir corresponde à saída do 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

O seguinte é a saída do 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#

A seguir, a saída do 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

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 44124