LSLB | Fazendas | Atualizar | Perfil HTTP

PUBLICADO EM 15 de maio de 2019

Configurações globais para o perfil de farm HTTP

Esse perfil gerencia a troca de conteúdo na entrega do aplicativo 7 da camada HTTP para os protocolos HTTP e HTTPS.

visão geral de farm http

Depois de enviar as alterações na configuração do farm HTTP / S, será necessário reiniciar manualmente o farm para aplicar as alterações. Esse requisito de reinicialização será indicado por uma mensagem mostrada no canto inferior direito da página, alertando o administrador de sistema de que há alterações que precisam ser aplicadas por meio de uma reinicialização do farm. Também é possível fazer mais de uma modificação na configuração do farm e, em seguida, reiniciá-lo quando terminar.

Depois de aplicar todas as alterações necessárias, clique no REINICIAR botão e uma mensagem de sucesso será mostrada se a reinicialização tiver sido feita com sucesso.

Também pode ser feito manualmente usando o topo direito Opções seção, se necessário.

A Estado é mostrado por meio das balas de cor como segue:

  • Verde: Significa UP. O farm está em execução e todos os back-ends estão UP ou o redirecionamento está configurado.
  • Vermelho: Significa BAIXA. Fazenda está parada.
  • Amarelo: Significa REINICIAR NECESSÁRIO. Há alterações recentes que precisam de uma reinicialização de farm para serem aplicadas.
  • Preto: Significa CRÍTICA. O farm é UP, mas não há back-end disponível ou eles estão no modo de manutenção
  • Azul: Significa PROBLEMA. A fazenda está em execução, mas pelo menos um back-end está desativado.
  • Laranja: Significa MANUTENÇÃO. O farm está em execução, mas pelo menos um back-end está no modo de manutenção.

Esses códigos de cores são os mesmos em toda a interface gráfica do usuário. Você poderia vê-los melhor explicados no Seção de Fazendas LSLB

No perfil de farms HTTP (S), o cabeçalho HTTP X-transmitido-Para é preenchido por padrão com o endereço IP do cliente. Ao contrário do perfil do farm L4xNAT, o perfil HTTP usa o algoritmo de ponderação implicitamente.

Cada farm HTTP (S) (ou serviço virtual) é capaz de gerenciar vários serviços da Web, como um proxy reverso, portanto, um par IP e porta virtual HTTP pode manipular mais de um serviço da Web com carga balanceada. Por essa razão, existe uma seção chamada serviço em um farm HTTP para oferecer flexibilidade de host virtual e permitir criar uma lista de back-ends para cada serviço.

Cada serviço HTTP (S) usa uma combinação de expressões regulares (para host virtual e padrão de URL) para gerenciar toda a conexão de entrada cujo cabeçalho HTTP corresponde a ambos.

Configuração básica

Os parâmetros básicos para o perfil de farms HTTP / S são os seguintes:

Nome. É o campo de identificação e um nome descritivo para o serviço da fazenda. Não será possível alterar o nome do farm, a menos que o farm seja interrompido em primeiro lugar. Certifique-se de que o novo nome do farm já não esteja em uso.

IP virtual e porta. Esses são o endereço IP virtual e o par de portas do qual o farm estará atendendo às conexões de entrada. A nova combinação de endereço IP e porta deve estar sem uso e disponível antes de ser configurada.

Ouvinte. Este campo especifica o protocolo a ser gerenciado na camada 7 para troca de conteúdo.

  • HTTP. O serviço virtual só entenderá o conteúdo HTTP simples.
  • HTTPS. O serviço virtual compreenderá o conteúdo HTTP seguro, gerenciará o handshake SSL, manipulará configurações de criptografia segura, certificados SSL (curinga ou SNI), etc., a fim de realizar o descarregamento de SSL e aliviar os servidores de aplicativos reais dessas tarefas pesadas.

Parâmetros HTTPS

Parâmetros HTTPS pode ser encontrada abaixo.

Parâmetros HTTPS

A Desativar SSLV2, Desativar SSLV3, Desativar TLSV1, Desativar TLSV1.1, Desativar TLSV1.2 botões selecionáveis, se selecionado, evite usar esses protocolos. Assim, uma vez que um protocolo é desativado, suas cifras também serão desativadas.

Cifras. Esse campo é usado para criar uma lista de cifras aceitas por conexões SSL para fortalecer essa conexão. Antes que um cliente e um servidor possam começar a trocar informações protegidas por TLS, eles devem trocar ou concordar com segurança sobre uma chave de criptografia e uma criptografia a ser usada ao criptografar dados. Mais informações sobre segurança podem ser encontradas em recursos externos, como Wikipedia.

Para configurar quais códigos serão usados, selecione uma das seguintes opções.

  • Todos os Produtos. Este item indica que todas as cifras podem ser gerenciadas pelo ouvinte HTTPS. Esta é a configuração padrão.
  • Alta seguranca. Esta opção ativa as seguintes cifras:
    kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

    Qual será o suficiente para passar por um A+ in SSL Labs .

  • Segurança personalizada. Esta opção permite definir as suas próprias cifras permitidas através do Cifras personalizadas campo.
  • Cifras personalizadas. Isso permite que você personalize quais cifras serão permitidas ou proibidas de serem usadas pela conexão SSL. Deve ser uma string no mesmo formato de Cifras do OpenSSL . Esta opção será exibida se Segurança personalizada é definido.
  • Desligamento SSL. Esta versão inclui recursos de descarga de SSL que aumentam o desempenho AES CPUs compatíveis. Se o seu hardware implementar esses recursos, essa opção será mostrada. Caso contrário, não será.

Certificados disponíveis. Estes são os certificados SSL disponíveis instalados no dispositivo. Para habilitar um deles, você pode selecionar o certificado e pressionar o botão de seta ou simplesmente arrastá-lo e soltá-lo da caixa Disponível para a caixa Ativado. Você também pode ativar / desativar vários certificados ou até mesmo todos eles.

Certificados habilitados. Nessa lista, você pode ver, gerenciar e solicitar os certificados que estão atualmente em uso pelo farm. Você pode mover para o topo ou para baixo com as setas duplas de cima / baixo ou até mesmo desativar todas elas, exceto uma com as setas duplas esquerdas.

Configuração avançada

Reescrever cabeçalhos de localização. Se ativado, o farm é forçado a modificar o Localização e Localização de conteúdo cabeçalhos nas respostas aos clientes. Se eles tiverem o valor do próprio backend ou do VIP (mas com um protocolo diferente), a resposta será modificada para mostrar o host virtual na solicitação. Se a opção ativado e comparar backends for selecionado, então, apenas o endereço IP de back-end é comparado, isso pode ser útil para redirecionar uma solicitação para um ouvinte HTTPS no mesmo servidor que o ouvinte HTTP.

Verbos HTTP aceitos. Este campo indica as operações HTTP que serão permitidas nas solicitações do cliente HTTP. Se um verbo não permitido for solicitado, um erro será mostrado ao cliente. Cada nível de verbo inclui seus verbos e verbos de níveis mais baixos.

  • Pedido HTTP padrão. Solicitações HTTP padrão (GET, POST, HEAD).
  • + solicitação HTTP estendida. solicitações HTTP estendidas (PUT, DELETE).
  • + verbos padrão do WebDAV. verbos padrão do WebDAV (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPÇÕES, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
  • + Verbos extensões Web MSDAV. Verbos WebDAV de extensões MS (SUBSCREVER, UNSUBSCRIBE, NOTIFICAR, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
  • + Verbos de extensões MS RPC. Verbos de extensões MS RPC (RPC_IN_DATA, RPC_OUT_DATA).

Ignorar 100 Continuar. Se marcado, 100 Continue propriedade será desativada. De acordo com o protocolo HTTP 1.1, quando este cabeçalho é enviado, os dados do formulário não são enviados com a solicitação inicial. Em vez disso, esse cabeçalho é enviado ao back-end do servidor da web que responde com 100 (continuar). Isso significa que o servidor recebeu cabeçalhos de solicitação e que o cliente deve prosseguir com o envio do corpo da solicitação (no caso de uma solicitação para a qual um corpo precisa ser enviado; por exemplo, uma solicitação POST). Se o corpo da solicitação for grande, enviá-lo a um servidor quando uma solicitação já foi rejeitada com base em cabeçalhos inadequados é ineficiente. Para que um servidor verifique se a solicitação pode ser aceita com base apenas nos cabeçalhos da solicitação, um cliente deve enviar Espere: 100-continue como um cabeçalho em sua solicitação inicial e verifique se um código de status 100 Continue é recebido em resposta antes de continuar (ou receber 417 Expectation Failed e não continuar).

Logs. Ative ou desative os registros de tráfego de farm para depurar e analisar o que está passando pelo balanceador de carga.

Tempo limite da conexão de back-end. Esse valor indica quanto tempo o farm vai aguardar uma conexão com o back-end em segundos. Normalmente, será a espera do tempo de abertura do soquete. Por padrão, esse valor será definido como 20 segundos.

Tempo limite de resposta de back-end. Este valor indica quanto tempo o farm aguardará por uma resposta dos back-ends em segundos. Por padrão, esse valor será definido como 45 segundos.

Frequência para verificar back-ends ressuscitados. Esse valor em segundos é quanto tempo o balanceador de carga aguardará para verificar se um back-end está acessível novamente e para sair de um servidor real na lista negra se estiver ativo. O farm estará verificando o backend periodicamente quando o servidor real estiver marcado como inativo, independentemente de haver ou não uma nova conexão com o cliente. Por padrão, esse valor será definido como 10 segundos.

Tempo limite da solicitação do cliente. Esse valor indica quanto tempo o farm vai aguardar uma solicitação do cliente em segundos. Quando esse tempo limite for atingido sem obter nenhum dado do cliente, a conexão será encerrada. Por padrão, esse valor será definido como 30 segundos.

Mensagens de erro personalizadas. Por meio das mensagens de erro personalizadas, o serviço do farm pode responder uma mensagem personalizada do seu site quando um erro de código da Web é detectado nos servidores reais. Uma página HTML personalizada será mostrada para os códigos de erro 414, 500, 501 e 503.

Adicionar cabeçalhos de solicitação. Lista de cabeçalhos que serão adicionados às solicitações HTTP do cliente.

Remover cabeçalhos de solicitação. Lista de padrões de cabeçalho que serão removidos das solicitações HTTP do cliente.

Configurações de serviços

Os serviços em um farm LSLB com perfil HTTP fornecem recursos de troca de conteúdo para serviços virtuais da Web para fornecer vários serviços e aplicativos da Web por meio do mesmo IP e PORT virtual, o que ajuda a unificar aplicativos da web através de um único domínio, gerenciar hosts virtuais, gerenciar URLs, configurar redirecionamentos, configurar persistência e back-ends por serviço. Cada serviço em um farm LSLB tem propriedades diferentes, verificações de integridade e lista de back-end. Expressões regulares podem ser usadas como condições de correspondência que podem especificar qual serviço deve ser usado por solicitação.

Todas as condições de correspondência de serviço serão verificadas pelo núcleo do perfil de farm HTTP no modo de prioridade (que pode ser alterado se necessário) e, se nenhum serviço for correspondido, o núcleo do farm retornará um erro. Por esse motivo, são permitidas definições específicas de vários serviços. Se nenhuma URL for definida, todas as solicitações serão correspondentes. As condições do serviço HTTP serão determinadas por um host virtual e / ou um padrão de URL.

Primeiro, é necessário criar pelo menos um serviço para adicionar back-ends.

Após a criação, você será solicitado a Reiniciar a fazenda para aplicar o novo serviço.

Depois que o novo serviço é aplicado, os serviços HTTP são avaliados de cima para baixo na ordem da lista, o primeiro serviço que corresponde às duas condições processará a solicitação. Essas condições de serviços podem ser determinadas por padrões de URL, cabeçalhos específicos ou redirecionamento e permitem identificar vários serviços da Web no mesmo farm.

As condições de serviço a serem correspondidas são duas:

Host Virtual. Este campo especifica a condição determinada pelo nome do domínio por meio do mesmo IP virtual e porta definidos por um farm HTTP. Para descartar essa condição, deixe-a vazia. Este campo suporta expressões regulares no formato PCRE.

Padrão de URL. Esse campo permite determinar um serviço da Web em relação à URL que o cliente está solicitando por meio de um padrão de URL específico que será verificado sintaticamente. Para descartar essa condição, deixe-a vazia. Este campo suporta expressões regulares no formato PCRE.

A Host Virtual e Padrão de URL os valores são expressões regulares; se forem deixados em branco, qualquer valor corresponderá. Os dois campos devem corresponder ou ele irá pular para o próximo serviço. Recomenda-se incluir um serviço como padrão se nenhuma correspondência for detectada na parte inferior.

Menos Resposta. Esta caixa de seleção permite uma melhoria do algoritmo round robin. O balanceador de carga estabelece dinamicamente a conexão com o valor mais baixo do back-end de tempo de resposta.

Back-ends HTTPS. Essa caixa de seleção indica ao farm que os servidores de back-ends definidos no serviço atual estão usando o protocolo HTTPS para que os dados sejam criptografados antes de serem enviados.

Segurança estrita de transporte

O HTTP Strict Transport Security, ou HSTS, é uma política de segurança da Web para impedir ameaças durante a comunicação de tráfego da Web ou a divulgação de cookies. Os navegadores da Web precisam suportar essa opção.
Por padrão, em farms HTTPS está habilitado em todos os serviços.

Cabeçalho STS. Caixa de seleção para ativar ou desativar essa opção.

Timeout. Tempo limite de expiração deste cabeçalho.

Redirecionar

Se o serviço tiver a opção de redirecionamento ativada, os servidores de back-end não poderão ser usados, pois todos os pedidos serão enviados para o URL especificado.

URL de redirecionamento. Esse campo se comporta como um back-end especial, pois a solicitação do cliente é respondida automaticamente por um redirecionamento para um novo URL. Se você configurar um valor de redirecionamento, NÃO configure back-ends neste serviço. E se Host Virtual e Padrão de URL jogo então Zevenet envia um HTTP Cabeçalho da localização resposta ao cliente para ser redirecionado para o URL configurado.

Tipo de redirecionamento. Existem duas opções: Padrão or Acrescentar. Com o Padrão opção, o URL é tomado como um host absoluto e caminho para redirecionar para. Com o Acrescentar opção, o caminho da solicitação original será anexado ao host e ao caminho que você especificou.

Código de redirecionamento. Existem vários códigos HTTP de redirecionamento que podem ser usados: 301 (movido permanentemente), 302 (movido temporariamente) ou 307 (redirecionamento temporário).

Persistência

Persistência. Este parâmetro define como o serviço HTTP irá gerenciar a sessão do cliente e qual campo de conexão HTTP deve ser controlado para manter as sessões seguras do cliente. Quando um tipo de sessão de persistência é selecionado, uma sessão de persistência TTL será mostrada.

  • Sem persistência. O serviço do farm não controlará as sessões do cliente e as solicitações HTTP ou HTTPS serão entregues a servidores reais.
  • IP: endereço do cliente. O endereço IP do cliente será usado para manter abertas as sessões do cliente por meio dos servidores reais.
  • BASIC: autenticação básica. O cabeçalho de autenticação básica HTTP será usado para controlar as sessões do cliente. Por exemplo, quando uma página da web solicita uma autenticação básica para o cliente, um cabeçalho HTTP conterá uma string como a seguinte:
    		HTTP/1.1 401 Authorization Required
    		Server: HTTPd/1.0
    		Date: Sat, 27 Nov 2011 10:18:15 GMT
    		WWW-Authenticate: Basic realm="Secure Area"
    		Content-Type: text/html
    		Content-Length: 31
    

    Então o cliente responde com o cabeçalho:

                    GET /private/index.html HTTP/1.1
    		Host: localhost
    		Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    

    Essa sequência de autenticação básica é usada como um ID para a sessão para identificar a sessão do cliente.

  • URL: um parâmetro de solicitação. Quando o ID da sessão é enviado por meio de um parâmetro GET com o URL, será possível usar essa opção, indicando o nome do parâmetro associado ao ID da sessão do cliente. Por exemplo, um pedido do cliente como http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 deve ser configurado o parâmetro Identificador de Sessão de Persistência:

  • PARM: um parâmetro de URI. Outra maneira de identificar uma sessão do cliente é por meio de um parâmetro URI separado de um caractere de ponto-e-vírgula usado como um identificador de sessão do usuário. No exemplo http://www.example.com/private.php;EFD4Y7 o parâmetro será usado como o identificador da sessão.
  • COOKIE: um determinado cookie. Além disso, você poderá selecionar uma variável de cookie HTTP para manter a sessão do cliente por meio do BOLINHO opção. Um cookie precisa ser criado pelo programador de aplicativos real na página da Web para identificar a sessão do cliente, por exemplo:
                    GET /spec.html HTTP/1.1
                    Host: www.example.org
                    Cookie: sessionidexample=75HRSd4356SDBfrte
    
  • CABEÇALHO: um determinado cabeçalho de pedido. Um campo personalizado de cabeçalho HTTP pode ser usado para identificar a sessão do cliente. Por exemplo:
                   GET /index.html HTTP/1.1
                   Host: www.example.org
                   X-sess: 75HRSd4356SDBfrte
    

Tempo de permanência da sessão de persistência. Esse valor indica o tempo máximo de vida de uma sessão do cliente inativa (duração máxima da sessão) em segundos.

Identificador de Sessão de Persistência. Este campo é o Parâmetro de URL, biscoito or campo de cabeçalho nome que será analisado pelo serviço do farm e gerenciará a sessão do cliente.

Inserção de Cookie. Se definido, os farms HTTP injetarão biscoito em cada resposta com a chave apropriada do backend, de forma que mesmo se a tabela de sessão for esvaziada ou as sessões forem desabilitadas, o back-end apropriado será escolhido. Esse recurso evita alterar o código do servidor real para criar um cookie de sessão.

A Nome do cookie É o nome do cookie que será criado e adicionado à solicitação do cliente. o Caminho do bolinho é o URI ou caminho relativo onde o novo cookie será criado, para todo o domínio o caractere / precisa ser definido. Domínio do cookie é o domínio onde o cookie será criado. Finalmente, Cookie TTL é o número de segundos que o cookie será mantido na memória entre o cliente e o backend. Este campo deve ser maior que 0.

Após a configuração do serviço, será necessário atualizar as alterações através do botão verde Enviar.

Farmguardian

Os farms HTTP fornecem uma verificação de integridade de backend básica e nativa, mas a configuração do Farmguardian é recomendada para verificações de integridade de back-ends heurísticas mais inteligentes, a fim de garantir o estado real da integridade do aplicativo.

Algumas verificações de integridade avançadas ou personalizadas podem ser atribuídas a esse serviço a partir das verificações de farmguardians já criadas.

Para mais informações de Farmguardian, vá para o Monitoramento >> Farmguardian seção.

Observe que depois de selecionar o guardião da fazenda, ele será aplicado automaticamente ao farm.

Backends

A respeito de Seção de backends, o perfil do farm HTTP permite que você configure as seguintes propriedades de servidores reais:
Todos os back-ends devem ser IPv4 ou IPv6, com a mesma versão de IP do Farm VIP.

ID. É o índice que faz referência ao backend na configuração do farm.
ALIAS. Alias ​​de back-end, se algum alias foi selecionado.
IP. O endereço IP do back-end fornecido, se você tiver selecionado algum alias, este campo não será editável, você deve alterar o campo alias. Se você selecionou 'IP personalizado' no campo alias, ele será editável para o IP desejado.
PORT. É o valor da porta para o servidor real atual.
TIMEOUT. É o valor de tempo limite específico para um back-end responder. Esse valor substitui o parâmetro do farm de tempo limite de conexão de back-end global para o back-end atual.
PESO. É o valor do peso para o servidor real atual. Mais valor de peso indica mais conexões entregues ao backend atual. Por padrão, um valor de peso de 1 será definido. Os valores disponíveis variam de 1 a 9.
AÇÃO. As ações disponíveis por back-end são:

Para back-ends já criados:

  • Ativar manutenção. Esta ação está disponível se o back-end foi ativado anteriormente. Colocar um determinado servidor real no modo de manutenção significa que nenhuma nova conexão será redirecionada para ele. Existem dois métodos diferentes para ativar o modo de manutenção:
    • Drenar modo. Mantém conexões estabelecidas e persistência, se ativado, mas não admitirá novas conexões.
    • Modo de corte. Solta todas as conexões ativas no backend
  • Desativar manutenção. Esta ação está disponível se o backend for manutenção. Ative novas conexões para o servidor real novamente após a manutenção ativada.
  • Apagar. Exclua o servidor real fornecido do serviço virtual. O alias não será excluído se houver algum.

Adicionar formulário de back-end:

Você poderá configurar os mesmos parâmetros descritos anteriormente, mas o ID, assim que a configuração dos campos estiver concluída, clicar no botão Salvar para criar o back-end.

Por meio do botão do menu Ações, as seguintes ações estão disponíveis para um ou mais back-ends selecionados:

  • Adicionar back-end. Esta opção abre o formulário de criação de back-end.
  • As ações mencionadas acima: Ativar manutenção (Modo de drenagem e corte), Desativar manutenção e Excluir

Regras do IPDS para farms HTTP

Esta seção permite ativar as regras do IPDS. A lista mostra diferentes tipos de proteção e uma caixa de seleção para ativá-los. Para mais informações, por favor, vá para o IPDS >> Regras de listas negras, IPDS >> regras DoS or IPDS >> regras RBL documentação específica.

zevenet vista ipds

Para cada um dos três tipos de regras do IPDS, Blacklist, DoS e RBL, existem duas tabelas, Disponível e ativada, e um ícone de cadeia que redireciona para o seu IPDS seção. Em Tabela disponível, pode-se ver todas as regras disponíveis do mesmo tipo, que podem ser aplicadas ao farm. Sob a tabela habilitada, pode-se ver cada regra do mesmo tipo aplicada ao farm, existe também uma bola de status para cada regra que informa se a regra está parada em vermelho ou correndo em verde.

Cada regra pode ser acessada clicando em seu nome, o que lhe permitirá alterar os parâmetros das regras ou até mesmo iniciar / parar a regra. Não é possível criar uma nova regra nesta visão de farm, você deve fazê-lo através do IPDS seção.

Você pode adicionar uma regra, clicar na regra desejada e, em seguida, na seta à direita ou em mais de uma, mantendo pressionada a tecla Shift e selecionando as regras que deseja adicionar, você precisará clicar na seta única direita. Você também pode adicionar todas as listas negras disponíveis clicando na seta dupla à direita.

Para excluir uma ou mais regras, selecione-as e clique na seta para esquerda ou clique na seta dupla para remover todas.

Extras

Confira nosso vídeo para saber como é fácil configurar um redirecionamento de HTTPS com o Zevenet.

Compartilhar no:

Documentação sob os termos da Licença de Documentação Livre GNU.

Esse artigo foi útil?

Artigos Relacionados