Configuração de definições HTTP do Application Gateway
O gateway de aplicativo roteia o tráfego para os servidores back-end usando a configuração especificada aqui. Depois de criar uma configuração HTTP, você deve associá-la a uma ou mais regras de roteamento de solicitação.
Afinidade com base no cookie
O Gateway de Aplicativo do Azure usa cookies gerenciados por gateway para manter sessões de usuário. Quando um utilizador envia o primeiro pedido para o Gateway de Aplicação, define um cookie de afinidade na resposta com um valor hash que contém os detalhes da sessão, pelo que os pedidos subsequentes que transportam o cookie de afinidade serão encaminhados para o mesmo servidor de back-end para manter a persistência.
Esse recurso é útil quando você deseja manter uma sessão de usuário no mesmo servidor e quando o estado da sessão é salvo localmente no servidor para uma sessão de usuário. Se o aplicativo não puder lidar com a afinidade baseada em cookies, você não poderá usar esse recurso. Para usá-lo, certifique-se de que os clientes suportam cookies.
Nota
Algumas verificações de vulnerabilidade podem sinalizar o cookie de afinidade do Application Gateway porque os sinalizadores Secure ou HttpOnly não estão definidos. Essas verificações não levam em conta que os dados no cookie são gerados usando um hash unidirecional. O cookie não contém nenhuma informação do usuário e é usado exclusivamente para roteamento.
A atualização do navegadorChromium v80 trouxe um mandato onde os cookies HTTP sem o atributo SameSite devem ser tratados como SameSite=Lax. Para solicitações CORS (Cross-Origin Resource Sharing), se o cookie tiver que ser enviado em um contexto de terceiros, ele terá que usar SameSite=None; Atributos seguros e deve ser enviado apenas por HTTPS. Caso contrário, em um cenário somente HTTP, o navegador não envia os cookies no contexto de terceiros. O objetivo desta atualização do Chrome é melhorar a segurança e evitar ataques CSRF (Cross-Site Request Forgery).
Para suportar essa alteração, a partir de 17 de fevereiro de 2020, o Application Gateway (todos os tipos de SKU) injetará outro cookie chamado ApplicationGatewayAffinityCORS além do cookie ApplicationGatewayAffinity existente. O cookie ApplicationGatewayAffinityCORS tem mais dois atributos adicionados a ele ("SameSite=None; Secure") para que as sessões adesivas sejam mantidas mesmo para pedidos de origem cruzada.
Observe que o nome do cookie de afinidade padrão é ApplicationGatewayAffinity e você pode alterá-lo. Caso esteja a utilizar um nome de cookie de afinidade personalizado, é adicionado um cookie adicional com CORS como sufixo. Por exemplo, CustomCookieNameCORS.
Nota
Se o atributo SameSite=None estiver definido, é obrigatório que o cookie também contenha o sinalizador Secure e deve ser enviado por HTTPS. Se a afinidade de sessão for necessária sobre CORS, você deverá migrar sua carga de trabalho para HTTPS. Consulte o descarregamento de TLS e a documentação de TLS de ponta a ponta para o Application Gateway aqui – Visão geral, Configurar um gateway de aplicativo com terminação TLS usando o portal do Azure, Configurar TLS de ponta a ponta usando o Application Gateway com o portal.
Drenagem de ligação
A drenagem da conexão ajuda você a remover normalmente os membros do pool de back-end durante as atualizações de serviço planejadas. Aplica-se a instâncias de back-end que são
- explicitamente removido do pool de back-end,
- removidos durante operações de expansão, ou
- notificados como insalubres pelas sondas de saúde.
Você pode aplicar essa configuração a todos os membros do pool de back-end habilitando a Drenagem de Conexões na Configuração de Back-end. Ele garante que todas as instâncias de cancelamento de registro em um pool de back-end não recebam novas solicitações/conexões enquanto mantém as conexões existentes até o valor de tempo limite configurado. Isso também é verdade para conexões WebSocket.
| Tipo de Configuração | Valor |
|---|---|
| Valor padrão quando a Drenagem de Conexão não está habilitada na Configuração de Back-end | 30 segundos |
| Valor definido pelo usuário quando a Drenagem de Conexão está habilitada na Configuração de Back-end | 1 a 3600 segundos |
A única exceção a isso são solicitações vinculadas para cancelamento de registro de instâncias devido à afinidade de sessão gerenciada pelo gateway e continuarão a ser encaminhadas para as instâncias de cancelamento de registro.
Protocolo
O Application Gateway suporta HTTP e HTTPS para rotear solicitações para os servidores back-end. Se você escolher HTTP, o tráfego para os servidores back-end não será criptografado. Se a comunicação não criptografada não for aceitável, escolha HTTPS.
Essa configuração combinada com HTTPS no ouvinte oferece suporte a TLS de ponta a ponta. Isso permite que você transmita com segurança dados confidenciais criptografados para o back-end. Cada servidor back-end no pool de back-end que tem TLS de ponta a ponta habilitado deve ser configurado com um certificado para permitir uma comunicação segura.
Porta
Essa configuração especifica a porta onde os servidores back-end escutam o tráfego do gateway de aplicativo. Você pode configurar portas que variam de 1 a 65535.
Certificado raiz confiável
Se você selecionar HTTPS como o protocolo de back-end, o Application Gateway exigirá um certificado raiz confiável para confiar no pool de back-end para SSL de ponta a ponta. Por padrão, a opção Usar certificado de autoridade de certificação conhecido está definida como Não. Se você planeja usar um certificado autoassinado ou um certificado assinado por uma Autoridade de Certificação interna, deverá fornecer ao Gateway de Aplicativo o certificado público correspondente que o pool de back-end usará. Esse certificado deve ser carregado diretamente no Application Gateway em . Formato CER.
Se você planeja usar um certificado no pool de back-end assinado por uma Autoridade de Certificação pública confiável, poderá definir a opção Usar certificado de CA conhecido como Sim e ignorar o carregamento de um certificado público.
Tempo limite do pedido
Essa configuração é o número de segundos que o gateway de aplicativo aguarda para receber uma resposta do servidor back-end.
Substituir caminho de back-end
Essa configuração permite configurar um caminho de encaminhamento personalizado opcional para usar quando a solicitação for encaminhada para o back-end. Qualquer parte do caminho de entrada que corresponda ao caminho personalizado no campo de caminho de back-end de substituição é copiada para o caminho encaminhado. A tabela a seguir mostra como esse recurso funciona:
Quando a configuração HTTP é anexada a uma regra básica de roteamento de solicitação:
Pedido original Substituir caminho de back-end Solicitação encaminhada para back-end /Casa/ /substituição/ /substituição/home/ /home/secondhome/ /substituição/ /substituição/home/secondhome/ Quando a configuração HTTP é anexada a uma regra de roteamento de solicitação baseada em caminho:
Pedido original Regra de caminho Substituir caminho de back-end Solicitação encaminhada para back-end /pathrule/home/ /pathrule* /substituição/ /substituição/home/ /pathrule/home/secondhome/ /pathrule* /substituição/ /substituição/home/secondhome/ /Casa/ /pathrule* /substituição/ /substituição/home/ /home/secondhome/ /pathrule* /substituição/ /substituição/home/secondhome/ /pathrule/home/ /pathrule/início* /substituição/ /substituição/ /pathrule/home/secondhome/ /pathrule/início* /substituição/ /substituição/secondhome/ /pathrule/ /pathrule/ /substituição/ /substituição/
Usar sonda personalizada
Essa configuração associa uma sonda personalizada a uma configuração HTTP. Você pode associar apenas um teste personalizado a uma configuração HTTP. Se você não associar explicitamente uma sonda personalizada, a sonda padrão será usada para monitorar a integridade do back-end. Recomendamos que você crie uma sonda personalizada para maior controle sobre o monitoramento de integridade de seus back-ends.
Nota
O teste personalizado não monitora a integridade do pool de back-end, a menos que a configuração HTTP correspondente esteja explicitamente associada a um ouvinte.
Configurando o nome do host
O Application Gateway permite que a conexão estabelecida com o back-end use um nome de host diferente daquele usado pelo cliente para se conectar ao Application Gateway. Embora essa configuração possa ser útil em alguns casos, substituir o nome do host para ser diferente entre o cliente e o gateway de aplicativo e o gateway de aplicativo para o destino de back-end deve ser feito com cuidado.
Na produção, é recomendável manter o nome do host usado pelo cliente para o gateway de aplicativo como o mesmo nome de host usado pelo gateway de aplicativo para o destino de back-end. Isso evita possíveis problemas com URLs absolutos, URLs de redirecionamento e cookies vinculados ao host.
Antes de configurar o Application Gateway que se desvia disso, revise as implicações de tal configuração, conforme discutido em mais detalhes no Centro de arquitetura: Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end
Há dois aspetos de uma configuração HTTP que influenciam o Host cabeçalho HTTP usado pelo Application Gateway para se conectar ao back-end:
- "Escolha o nome do host do endereço de back-end"
- "Substituição do nome do anfitrião"
Escolha o nome do host do endereço de back-end
Esse recurso define dinamicamente o cabeçalho do host na solicitação como o nome do host do pool de back-end. Ele usa um endereço IP ou FQDN.
Esse recurso ajuda quando o nome de domínio do back-end é diferente do nome DNS do gateway de aplicativo e o back-end depende de um cabeçalho de host específico para resolver para o ponto de extremidade correto.
Um exemplo de caso são os serviços multilocatários como back-end. Um serviço de aplicativo é um serviço multilocatário que usa um espaço compartilhado com um único endereço IP. Portanto, um serviço de aplicativo só pode ser acessado por meio dos nomes de host configurados nas configurações de domínio personalizadas.
Por padrão, o nome de domínio personalizado é example.azurewebsites.net. Para acessar seu serviço de aplicativo usando um gateway de aplicativo por meio de um nome de host que não esteja explicitamente registrado no serviço de aplicativo ou por meio do FQDN do gateway de aplicativo, você pode substituir o nome do host na solicitação original pelo nome de host do serviço de aplicativo. Para fazer isso, habilite a configuração de escolha do nome do host no endereço de back-end.
Para um domínio personalizado cujo nome DNS personalizado existente é mapeado para o serviço de aplicativo, a configuração recomendada não é habilitar o nome de host de seleção do endereço de back-end.
Nota
Essa configuração não é necessária para o Ambiente do Serviço de Aplicativo, que é uma implantação dedicada.
Substituição do nome do host
Esse recurso substitui o cabeçalho do host na solicitação de entrada no gateway de aplicativo pelo nome do host especificado.
Por exemplo, se www.contoso.com for especificado na configuração Nome do host, a solicitação original * será alterada para *https://appgw.eastus.cloudapp.azure.com/path1https://www.contoso.com/path1 quando a solicitação for encaminhada para o servidor back-end.