LSLB | Fazendas | Atualizar | Perfil HTTP

21 min read

Conteúdo

Configurações globais para o perfil de farm HTTP
Regras do IPDS para farms HTTP
Extras

Configurações globais para o perfil de farm HTTP #

O perfil HTTP gerencia a alternância de conteúdo na camada de aplicativo do modelo OSI para os protocolos HTTP e HTTPS. Projetamos o perfil para distribuir o tráfego da Web recebido por vários recursos de back-end de maneira inteligente, analisando o conteúdo das solicitações recebidas e tomando decisões de roteamento com base em parâmetros específicos, como URL, cookies, cabeçalhos e informações da sessão. Com essas informações, podemos direcionar o tráfego para os pools de servidores (serviços) apropriados.

Na seção superior direita, temos 2 Indicadores. Ação botões e os Status.
Caixa quadrada: quando clicado, o farm LSLB será interrompido.
Botão Atualizar: Ao clicar, a Fazenda será reiniciada.
Botão Reproduzir: Se a fazenda estiver desligada ou inativa, ela iniciará ao clicar.

Cada uma das cores descritas abaixo representa o Status de um dado Farm:
Verde: Significa que a fazenda está UP e todos os back-ends estão em execução. Também pode significar que um redirecionamento está configurado.
Vermelho: Significa que a fazenda está BAIXA ou não é funcional.
Preto: Indica um CRÍTICA dano. Geralmente ocorre quando um farm está ATIVADO, mas não há back-end disponível ou pode estar no modo de manutenção.
Azul: Mostra quando há um PROBLEMA. O farm pode estar em execução, mas quando pelo menos um back-end está inativo.
Laranja: Representa MANUTENÇÃO. Mostra quando 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. Encontre uma explicação concisa sobre eles na seção LSLB Farm.

No perfil de farms HTTP(S), o cabeçalho HTTP X-Forwarded-For é preenchido por padrão com o endereço IP do cliente.

Assim como um proxy reverso, cada farm HTTP(S) (ou serviço virtual) gerencia diversos serviços; portanto, um único par de IP e porta virtual HTTP pode lidar com mais de um serviço web com balanceamento de carga. Assim, existe uma seção chamada " serviço" dentro do farm HTTP que oferece flexibilidade de host virtual e permite a criação de listas de backends para cada serviço.

Cada serviço HTTP(S) utiliza expressões regulares (para host virtual e padrão de URL) no PCRE para procurar padrões específicos nos cabeçalhos HTTP das conexões de entrada. Se o padrão corresponder tanto no campo de host virtual quanto no campo de padrão de URL , os servidores de backend desse serviço específico processarão essas conexões de entrada.

Configuração básica #

A seguir estão os parâmetros básicos para o perfil de farm HTTP/S.

Nome . Este é um nome que identifica facilmente uma fazenda. Para alterar o nome de uma fazenda, primeiro você precisa desativá-la. Certifique-se de que o novo nome ainda não esteja em uso.

IP e porta virtuais . Esses são os pares de endereço IP e porta virtuais a partir dos quais o farm ficará aguardando conexões de entrada. A nova combinação de endereço IP e porta deve estar livre e disponível antes de ser configurada.

Ouvinte . Este campo especifica o protocolo da camada 7 para realizar a comutação de conteúdo.

HTTP. O serviço virtual receberá apenas conteúdo HTTP simples.
HTTPS. O serviço virtual receberá conteúdo HTTP seguro, gerenciará handshakes SSL, lidará com configurações de cifras seguras, certificados SSL (curinga ou SNI), etc., para realizar o descarregamento de SSL. Isso aliviará os servidores de aplicativos reais dessas tarefas pesadas.

Parâmetros HTTPS #

Os parâmetros HTTPS podem ser encontrados abaixo.

Desativar SSLv2 , Desativar SSLv3 , Desativar TLSV1 , Desativar TLSV1.1 , Desativar TLSV1.2 . Cada um desses botões de alternância ativa ou desativa a versão SSL ou TLS correspondente. Desativar qualquer um dos protocolos não é recomendável, pois as cifras associadas também serão desativadas.

Cifras . Nesta seção, criamos listas de cifras que usamos para fortalecer uma conexão SSL. Antes que um cliente e um servidor comecem a trocar informações protegidas pelo protocolo TLS, eles devem trocar ou concordar, de forma segura, com uma chave de criptografia e uma cifra a ser usada na criptografia dos dados.

Para configurar uma cifra para uso, selecione uma das seguintes opções.

Todas as. Com esse comando selecionado, o farm HTTP(S) de escuta gerenciará todos os conjuntos de cifras disponíveis. Esta é a configuração padrão.

Alta seguranca. Este comando habilita 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

Habilitar essa opção oferece segurança robusta o suficiente para obter nota A+ no SSL Labs.

Segurança personalizada. Este comando permite que você personalize suas próprias cifras através do Cifras personalizadas campo.
Cifras personalizadas. Este comando permite personalizar cifras específicas para permitir ou proibir ao fazer uma conexão SSL. Deve ser uma string no mesmo formato que em Cifras do OpenSSL . Este comando será exibido se Segurança personalizada é definido.
Desligamento SSL. Esta opção permite que as cifras AES sejam descarregadas via hardware se o processador permitir. Isto permitirá otimizar o desempenho da tarefa de criptografia/descriptografia SSL.

Certificados disponíveis . Estes são os certificados SSL instalados no dispositivo. Para ativar cada um deles, selecione o certificado e clique no botão de seta ou simplesmente arraste e solte-o da caixa "Disponíveis" para a caixa "Ativados". Você também pode ativar/desativar vários certificados ou até mesmo todos eles.

Certificados ativados . Nesta lista, você gerenciará os certificados que estão sendo usados atualmente pelo farm. Você pode movê-los para o topo ou para o final da lista usando as setas duplas para cima/para baixo, ou até mesmo desativá-los todos. Observe a ordem dos certificados. Caso você configure um certificado curinga antes de um certificado de host, o certificado curinga será usado primeiro.

Configurações avançadas #

Reescrever cabeçalhos Location . Se ativado, o farm é forçado a modificar os cabeçalhos Location e Content-location em resposta aos clientes. Se eles contiverem 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 " Comparar backends" estiver ativada, apenas o endereço IP do backend será comparado. Isso é essencial para redirecionar uma solicitação para um listener HTTPS no mesmo servidor que o listener HTTP. Se este campo estiver configurado na seção de serviço, esta diretiva será ignorada para esse serviço.

Verbos HTTP aceitos . Este campo indica os métodos HTTP que serão usados para validar as solicitações do cliente HTTP. Se a solicitação do cliente não for permitida, um erro será exibido. Cada verbo possui níveis inferiores adicionais de verbos.

Pedido HTTP padrão. Solicitações HTTP padrão (GET, POST, HEAD).
+ solicitação HTTP estendida. solicitações HTTP estendidas (PUT, DELETE).
+ opções verbo HTTP. 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 Continue . Se marcada, a propriedade 100 Continue 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 requisição inicial. Em vez disso, este cabeçalho é enviado ao servidor web, que responde com 100 (Continue). Isso significa que o servidor recebeu os cabeçalhos da requisição e que o cliente deve prosseguir enviando o corpo da requisição (no caso de uma requisição que precise de um corpo; por exemplo, uma requisição POST). Se o corpo da requisição for grande, enviá-lo a um servidor quando uma requisição já foi rejeitada com base em cabeçalhos inadequados é ineficiente. Para que o servidor verifique se a requisição pode ser aceita com base apenas nos cabeçalhos da requisição, o cliente deve enviar o cabeçalho Expect: 100-continue em sua requisição inicial e verificar se recebe um código de status 100 Continue como resposta antes de continuar (ou receber 417 Expectation Failed e não continuar).

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

Tempo limite de conexão com o backend . Este valor indica o tempo que o farm terá que esperar por uma conexão com o backend, em segundos. Normalmente, será o tempo de espera para abertura do socket. Por padrão, este valor será definido como 20 segundos.

Frequência de verificação de servidores backend reativados . Este parâmetro define a frequência com que o balanceador de carga aguardará para verificar se um servidor backend está acessível e para remover um servidor real da lista negra, caso esteja ativo. O farm verificará o servidor backend periodicamente após o servidor real ser marcado como inativo, independentemente de haver ou não uma nova conexão de cliente. Por padrão, esse valor é definido como 10 segundos.

Tempo limite de resposta do servidor de backend . Este valor indica o tempo que o farm terá que esperar por uma resposta dos servidores de backend, em segundos. Por padrão, esse valor será definido como 45 segundos.

Tempo limite da solicitação do cliente . Este valor indica o tempo que o farm terá que esperar pela solicitação de um cliente. Assim que esse tempo limite for atingido sem que nenhum dado seja recebido do cliente, a conexão será encerrada. Por padrão, esse valor é definido como 30 segundos.

Mensagens de erro HTTP #

Mensagens de erro personalizadas. O serviço farm exibirá uma mensagem personalizada em seu site quando um erro de código da Web for detectado nos servidores reais. Uma página HTML personalizada será exibida para os códigos de erro 414, 500, 501 e 503.

414: Pedido-URI muito longo. Esta é a mensagem de erro do perfil HTTP/S se o URI atingir o número máximo de caracteres permitido. Se você receber esse erro, reduza o comprimento da URL.
500: Erro interno do servidor. Esta é a mensagem de erro do perfil HTTP/S se o back-end encontrar um comando inesperado
501: Não implementado. Esta é a mensagem de erro do perfil HTTP/S se o verbo de solicitação não for gerenciado ou conhecido pelo proxy ou back-end.
503 serviço indisponível. Esta é a mensagem de erro do perfil HTTP/S se o proxy não encontrar um back-end disponível para a solicitação. Isso pode acontecer quando todos os back-ends ou servidores estão inativos ou porque a expressão regular na solicitação não corresponde a nenhum serviço configurado.
WAF 403: Proibido. Esta é a mensagem de erro do perfil HTTP/S se o WAF estiver habilitado e o mecanismo WAF rejeitar a solicitação.

Cabeçalhos #

Nesta seção, podemos adicionar, modificar ou excluir cabeçalhos de solicitação e resposta globalmente, aplicando ações a todos os serviços configurados. Se um cabeçalho for configurado na seção de serviço, essa configuração será descartada.

As ações a serem usadas nesta seção incluem:

Criar regra. Uma regra de cabeçalho global será criada.
Apagar. Uma regra de cabeçalho global será excluída.

Esta seção permite adicionar, modificar ou criar solicitações e respostas de cabeçalho , conforme mostrado na imagem abaixo.

Tipo.

Pedido: remover cabeçalho. Padrão de cabeçalho que será removido das solicitações HTTP do cliente.
Solicitação: modificar cabeçalho. Modifique o cabeçalho das solicitações HTTP do cliente.
Pedido: adicionar cabeçalho. O cabeçalho que será adicionado às solicitações HTTP do cliente.
Resposta: remova o cabeçalho. Padrão de cabeçalho que será removido da resposta HTTP de back-end.
Resposta: modifique o cabeçalho. Modifique o cabeçalho da resposta HTTP de back-end.
Resposta: adicionar cabeçalho. O cabeçalho que será adicionado à resposta HTTP de back-end.

Configurações de serviços #

Os serviços em um farm LSLB com perfil HTTP fornecem recursos de comutação de conteúdo para serviços virtuais da web, permitindo a entrega de múltiplos serviços e aplicações web através do mesmo IP e porta virtuais . Isso ajuda a unificar aplicações web em um único domínio, gerenciar hosts virtuais , URLs , configurar redirecionamentos , persistência e backends por serviço . Cada serviço em um farm LSLB possui diversas propriedades, verificações de integridade, persistência, gerenciamento de cabeçalhos e uma lista de backends. Expressões regulares podem ser usadas para corresponder a condições que especificarão o serviço a ser utilizado por requisição.

Cada condição de correspondência de serviço será verificada pelo núcleo do perfil do farm HTTP no modo de prioridade (que pode ser alterado, se necessário). Se nenhum serviço for correspondido, o núcleo do farm retornará um erro (erro HTTP 503). Por esse motivo, são permitidas definições específicas de vários serviços. Se os campos URL e Host não forem definidos, 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, criar e adicionar pelo menos um servidor de back-end a um serviço é uma necessidade. Assim que o novo serviço for aplicado, os serviços HTTP serão avaliados de cima para baixo na ordem da lista. O primeiro serviço correspondente no campo Host e/ou URL processará a solicitação. Essas condições de serviço são determinadas por padrões de URL ou host.

As condições de serviço a combinar são:

Host Virtual . Este recurso permite definir uma condição com base no nome de domínio, utilizando o mesmo IP virtual e porta em um farm HTTP. Se desejar remover essa condição, deixe o campo vazio. Expressões regulares no formato PCRE são suportadas neste campo.

Padrão de URL . O objetivo deste campo é identificar um serviço web com base no caminho da URL solicitada pelo cliente. A URL será avaliada em relação a um padrão predefinido, garantindo que sua sintaxe esteja correta. Se desejar ignorar essa condição, você pode deixar o campo vazio. Expressões regulares no formato PCRE são suportadas neste campo, permitindo uma correspondência de padrões mais precisa.

Os valores de Host Virtual e Padrão de URL são expressões regulares. Se deixados em branco, qualquer valor será aceito. Ambos os campos devem corresponder, caso contrário, o sistema passará para o próximo serviço. Recomenda-se usar pelo menos um deles, que servirá como padrão se nenhuma correspondência for detectada na parte inferior.

Reescrever cabeçalhos Location . Se ativado, o serviço é forçado a modificar os cabeçalhos Location e Content-location nas respostas dos clientes. Se eles contiverem 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 "Ativar e comparar backends" estiver habilitada, apenas o endereço IP do backend será comparado. Isso é essencial ao redirecionar solicitações para um listener HTTPS no mesmo servidor que o listener HTTP. Quando a opção "Ativar e comparar backends" estiver selecionada, uma flag chamada " Ativar caminho para reescrever cabeçalhos Location" estará disponível. Habilite esta flag se estiver trabalhando com a opção "Reescrever URLs" . Este valor forçará a verificação das respostas de URL e alterará a resposta para a original se uma regra estiver configurada em "Reescrever URLs" . Se este campo estiver habilitado, ele substituirá a mesma diretiva na seção global.

Redirecionar #

Se o serviço tiver a opção de redirecionamento ativada, os servidores de back-end não poderão ser usados, pois todas as solicitações serão enviadas para o URL especificado.

Tipo de redirecionamento . Existem dois tipos de redirecionamento: Padrão e Anexar . Com o tipo Padrão , a URL é considerada como um host e caminho absolutos para o qual o redirecionamento será feito. Com o tipo Anexar , o caminho da solicitação original será anexado ao host e ao caminho especificados.

URL de redirecionamento . Este parâmetro controla para onde o cliente será redirecionado após a resposta a uma solicitação. A solicitação do cliente é respondida automaticamente com um redirecionamento para uma nova URL. Se você configurar um valor de redirecionamento, NÃO configure back-ends neste serviço. Se o Host Virtual e o padrão da URL corresponderem, o dispositivo enviará uma resposta de cabeçalho HTTP Location para o cliente, a fim de redirecioná-lo para a URL configurada.

Código de redirecionamento . Vários códigos HTTP de redirecionamento 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 conexão HTTP deve ser controlada para manter sessões seguras. Quando um tipo de sessão persistente é selecionado, seu Tempo de Vida (TTL, na sigla em inglês) em segundos será exibido.

Sem persistência. O serviço de farm não controlará as sessões do cliente. 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 as sessões do cliente abertas 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 do cliente, um cabeçalho HTTP conterá uma string como a seguinte:
```
		HTTP/1.1 401 Autorização necessária Servidor: HTTPd/1.0 Data: Sábado, 27 de novembro de 2011 10:18:15 GMT
		WWW-Authenticate: Reino Básico = “Área Segura”
		Tipo de conteúdo: texto/HTML Comprimento do conteúdo: 31
```
Então o cliente responde com o cabeçalho:
```
                GET /private/index.html Host HTTP/1.1: localhost
		Autorização: QWxhZGRpbjpvcGVuIHNlc2FtZQ básico==
```
Essa sequência de autenticação básica é usada como um ID para a sessão para identificar a sessão do cliente.
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.
URL: um parâmetro de solicitação. Quando o ID da sessão é enviado através de um parâmetro GET com a URL, este parâmetro indica que o nome associado ao ID da sessão do cliente será possível. Por exemplo, uma solicitação de cliente como http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 deve ser configurado com o parâmetro Identificador de Sessão de Persistência (valor sid neste exemplo) e o tempo de vida útil da sessão de persistência (TTL)
BOLACHA: . Você poderá selecionar uma variável de cookie HTTP para ler os cabeçalhos HTTP e usá-la para manter as sessões do cliente por um determinado tempo. O nome do cookie configurado no identificador de sessão de persistência campo é criado por um programador e inserido em uma página da Web para identificar a sessão do cliente, por exemplo:
```
                GET /spec.html Host HTTP/1.1: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte
```
Além disso, a sessão de persistência Time To Life(TTL) deve ser configurada. Esse valor gerencia o tempo que o balanceador de carga economiza quando o cliente e o back-end ficam sem nenhuma atividade.
HEADER: um cabeçalho de solicitação. Um campo personalizado de cabeçalho HTTP pode ser usado para identificar a sessão do cliente. É necessário configurar o Time To Life da sessão de persistência e o identificador de sessão de persistência. Por exemplo:
```
               GET /index.html Host HTTP/1.1: www.example.org
               Sessão X: 75HRSd4356SDBfrte
```

Cookie #

Inserção de cookie . Se definida, o balanceador de carga criará um cookie em cada resposta com a chave apropriada do backend. Mesmo que a tabela de sessões seja limpa ou as sessões estejam desativadas, o backend correto será escolhido. Esse recurso evita a necessidade de alterar o código real do servidor para criar um cookie de sessão.

O Nome do Cookie é o nome de um cookie que será criado e adicionado à solicitação do cliente/resposta do servidor. O Caminho do Cookie é o URI ou caminho relativo onde o novo cookie será criado. Para domínios completos, o caractere precisa ser definido. O Domínio do Cookie é o domínio onde o cookie será criado. Por fim, o TTL do Cookie é o número de segundos que o cookie será mantido na memória entre o cliente e o servidor. Este campo deve ser maior que 0. Este tempo se refere ao período sem atividade. Após o tempo indicado como inativo, a sessão de persistência será excluída.

Farmguardian #

Os farms HTTP fornecem uma verificação de integridade de back-end básica e nativa, mas a configuração do Farmguardian é recomendada para verificações de integridade de back-end heurísticas mais inteligentes para garantir que o aplicativo esteja íntegro.

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 obter mais informações sobre o Farmguardian, acesse a seção Monitoramento >> Farmguardian .

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

Servidores de back-end HTTPS . Esta caixa de seleção indica ao farm que os servidores de back-end definidos no serviço atual estão usando o protocolo HTTPS, portanto, os dados serão criptografados antes de serem enviados.

Backends #

Com relação aos backends , o perfil de farm HTTP permite a configuração das seguintes propriedades: Todos os backends devem ser IPv4 ou IPv6 e com a mesma versão de IP que o VIP do farm.

AÇÕES. Use as seguintes ações para gerenciar os back-ends:
Para back-ends já criados:

Ativar manutenção. Use esta ação se o back-end foi desabilitado anteriormente. Colocar um servidor real em modo de manutenção significa que nenhuma nova conexão será redirecionada para ele. Existem dois métodos 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. Use esta ação quando o back-end estiver no modo de manutenção. Habilite novas conexões com o servidor real novamente após desabilitar o modo de manutenção.
Apagar. Remova as configurações de um serviço virtual selecionado. O alias não será excluído se houver algum.

ALIAS. Alias de back-end, se algum alias foi selecionado.
IP. O endereço IP de um determinado back-end.
PORT. O número da porta do servidor real atual.
TIMEOUT. O tempo que um back-end leva para responder. Esse valor substitui o parâmetro do tempo limite de conexão de back-end global, mas é limitado a este farm selecionado.
PESO. O valor de peso para o servidor real atual. Mais peso indica mais conexões entregues ao back-end atual. Por padrão, um valor de peso de 1 será definido. A faixa de valores disponível é de 1 a 9.
STATUS. Os valores possíveis são:

Up. O farm está em execução e o back-end está pronto para receber conexões.
Para baixo. O farm está em execução e o serviço detectou que o back-end não está funcionando
Manutenção. O backend está marcado como não pronto para receber conexões pelo administrador, esta opção é útil para tarefas de manutenção do backend
Indefinido. O status do back-end não foi verificado.

PRIORIDADE. O valor de prioridade para o servidor real atual. Valores mais baixos têm mais prioridade. O valor de prioridade de serviço padrão é 1. Quando um back-end falha, a prioridade do serviço é aumentada em 1. Quando o back-end está ativo novamente, o valor de prioridade do serviço é reduzido em 1. Back-ends ativos contêm valores de prioridade menores ou iguais à prioridade do serviço .
LIMITE DE CONEXÃO. O número máximo de conexões simultâneas que o back-end manipulará. Se esse valor for atingido, novas conexões com o back-end serão bloqueadas e o cliente receberá um erro HTTP 503.

Adicionar formulário de back-end:

Através de Ação botão de menu, as seguintes ações estão disponíveis para um ou mais back-ends selecionados:
Adicionar back-end. Este comando abre o formulário de criação de back-end.
As ações mencionadas acima: Ativar manutenção (Drenar e Cortar modo), Desativar a manutenção e Apagar.

Reescrever URLs #

Ele verifica um padrão para obter strings de URLs e substituí-las. Várias configurações podem ser adicionadas. Todos eles serão aplicados sequencialmente ao URL de entrada, a menos que o último sinalizador seja definido que terminará a fase de reescrita de URL e os outros padrões de reescrita de URLs não serão avaliados.

Nesta seção, a solicitação de URL é analisada pelo mecanismo de proxy HTTP. Se a solicitação de URL corresponder ao padrão , ela será enviada ao cliente com a expressão regular de substituição configurada. Quando a resposta for recebida pelo balanceador de carga do servidor, a alteração para a URL real será feita, caso o cabeçalho de reescrita de localização esteja ativado para o serviço com o valor " Enable path for Rewrite location Headers".

Por exemplo, se o parâmetro Pattern estiver configurado com o valor /media/(.+)$ e o parâmetro Replace com o valor /svc1/$1 , a solicitação do cliente https://vhost.domain.com/media/console será enviada ao servidor com o valor https://vhost.domain.com/svc1/console.

Regras do IPDS para farms HTTP #

Esta seção permite ativar regras do IPDS. A lista exibe diferentes tipos de proteção e uma caixa de seleção para ativá-los. Para obter mais informações, consulte a documentação específica de IPDS >> Regras de listas negras , IPDS >> Regras de DoS , IPDS >> Regras de RBL ou IPDS >> Regras de WAF.

Para cada um dos quatro tipos de regras IPDS — Blacklist, DoS, WAF e RBL — existem duas tabelas: Disponíveis e Ativadas. Há também um ícone de corrente. Na tabela Disponíveis, você verá que todas as regras disponíveis são do mesmo tipo e podem ser aplicadas a um determinado farm. Na tabela Ativadas, você verá que as regras aplicadas ao farm selecionado são do mesmo tipo. Há também um símbolo de status para cada regra que indica se a regra está parada (cor vermelha) ou em execução (cor verde).

É possível acessar cada regra clicando no ícone de edição, que permite alterar os parâmetros da regra ou até mesmo iniciá-la/pará-la. Não é possível criar uma nova regra nesta visualização do farm. Altere-a na seção IPDS.

Adicione uma regra clicando na regra desejada e depois clicando na seta única à direita. Ou você pode selecionar mais de uma teclando simultaneamente a tecla shift e selecionando as regras que deseja adicionar. Você então clicará na seta única direita. Você também pode adicionar todas as listas negras disponíveis clicando na seta dupla para a direita.

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