Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Observação
Recomendamos que utilize o módulo Azure Az PowerShell para interagir com o Azure. Para começar, veja Install Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, veja Migrate Azure PowerShell from AzureRM to Az.
Um ouvinte é uma entidade lógica que verifica se há solicitações de conexão de entrada usando a porta, o protocolo, o host e o endereço IP. Quando configura o escutador, deve introduzir nestas definições valores que correspondam aos valores no pedido recebido pelo gateway.
Ao criar um gateway de aplicativo usando o portal do Azure, você também cria um ouvinte padrão escolhendo o protocolo e a porta para o ouvinte. Você pode escolher se deseja habilitar o suporte a HTTP2 no ouvinte. Depois de criar o gateway de aplicativo, você pode editar as configurações desse ouvinte padrão (appGatewayHttpListener) ou criar novos ouvintes.
Tipo de ouvinte
Ao criar um novo ouvinte, você escolhe entre básico e multissite. A escolha depende se o encaminhamento depende do nome do host no pedido recebido.
| O encaminhamento depende do nome do host | Tipo de ouvinte | Comportamento |
|---|---|---|
| No | Básico | Aceite e encaminhe todos os pedidos de qualquer domínio para pools de backend. Saiba como criar um gateway de aplicação com um escutador básico. |
| Yes | Multissítio | Encaminhe pedidos para diferentes pools de backend com base no cabeçalho do host ou nos nomes do host. O Gateway de Aplicação conta com os cabeçalhos de host HTTP 1.1 para hospedar mais do que um site no mesmo endereço IP público e porta. Para diferenciar pedidos na mesma porta, deve especificar um nome de host que corresponda ao pedido recebido. |
Para saber mais sobre ouvintes multi-site, consulte alojar múltiplos sites usando o Application Gateway.
Ordem de processamento dos ouvintes
Para o SKU v1, as solicitações são correspondidas de acordo com a ordem das regras e o tipo de ouvinte. Se uma regra com um ouvinte básico vier primeiro na ordem, processa primeiro e aceita qualquer pedido para essa combinação de porta e IP. Para evitar este comportamento, configure primeiro as regras com ouvintes multi-site e empurra a regra com o ouvinte básico para o último lugar da lista.
Para o SKU v2, a prioridade da regra define a ordem na qual os ouvintes são processados. Defina ouvintes wildcard e básicos com um número de prioridade superior ao de ouvintes site-specific e multi-site. Esta configuração garante que ouvintes site-specific e multi-site sejam executados antes dos ouvintes curinga e básicos.
A tabela seguinte resume como a ordem de processamento é determinada em cada SKU.
| SKU | O que determina a ordem | Configuração recomendada |
|---|---|---|
| v1 | A ordem das regras e o tipo de ouvinte. Uma regra com um listener básico que surge primeiro na ordem é processada em primeiro lugar e aceita qualquer pedido para essa combinação de porta e endereço IP. | Configura primeiro as regras com ouvintes multi-site e empurra a regra com o ouvinte básico para a última posição da lista. |
| v2 | Prioridade da regra. | Defina processos de escuta universais e básicos com um número de prioridade superior ao número utilizado para processos de escuta específicos do site e multissite, para que os processos de escuta específicos do site e multissite sejam executados em primeiro lugar. |
Endereço IP de Frontend
Escolha o endereço IP frontend que você planeja associar a esse ouvinte. O ouvinte ouve pedidos recebidos neste IP.
Escolha um endereço IP público frontend quando os clientes acedam à aplicação por trás desse ouvinte através da internet. Escolha um endereço IP privado de front-end para um endpoint interno que não esteja exposto à Internet, como uma aplicação de negócio interna ou uma camada de uma aplicação multicamadas que continua a exigir distribuição de carga, persistência de sessão ou terminação de TLS. Para as combinações suportadas, veja Configuração de endereços IP do frontend.
Observação
O frontend do Application Gateway suporta endereços IP de pilha dupla. Pode criar até quatro endereços IP frontend: dois endereços IPv4 (públicos e privados) e dois endereços IPv6 (públicos e privados).
Porta frontend
Associe uma porta frontend. Você pode selecionar uma porta existente ou criar uma nova. Escolha qualquer valor do intervalo permitido de portas. Você pode usar não apenas portas conhecidas, como 80 e 443, mas qualquer porta personalizada permitida que seja adequada. A mesma porta pode ser usada para ouvintes públicos e privados.
A porta 80 é a escolha típica para um ouvinte HTTP, e a porta 443 é a escolha típica para um ouvinte HTTPS. Use uma porta personalizada quando a sua aplicação precisar de uma e confirme que o valor está dentro do intervalo permitido para o seu SKU, porque o intervalo suportado difere entre os SKUs v1 e v2.
Observação
Ao usar ouvintes privados e públicos com o mesmo número de porta, o gateway de aplicações altera o "destino" do tráfego de entrada para os endereços IP de front-end do seu gateway. Portanto, dependendo da configuração do seu Grupo de Segurança de Rede, você pode precisar de uma regra de entrada com endereços IP de destino como IPs de front-end públicos e privados do seu gateway de aplicativo.
Regra de entrada:
- Fonte: (conforme sua exigência)
- Endereços IP de destino: IPs frontend públicos e privados do gateway de aplicativo.
- Porta de destino: (conforme configuração do ouvinte)
- Protocolo: TCP
Regra de saída: (sem requisito específico)
Protocolo
Escolha HTTP ou HTTPS. Escolha HTTPS quando o tráfego entre o cliente e o gateway de aplicação tiver de ser encriptado, o que também permite ao gateway descarregar o trabalho de encriptação e desencriptação para que os seus servidores backend não fiquem sobrecarregados com o overhead de computação TLS. Escolha HTTP quando essa encriptação não for necessária para o tráfego que este ouvinte aceita.
Se você escolher HTTP, o tráfego entre o cliente e o gateway de aplicativo não será criptografado.
Escolha HTTPS se quiser terminação TLS ou criptografia TLS de ponta a ponta. O tráfego entre o cliente e o gateway de aplicativo é criptografado e a conexão TLS será encerrada no gateway de aplicativo. Se você quiser criptografia TLS de ponta a ponta para o destino de back-end, você deve escolher HTTPS dentro da configuração HTTP de back-end também. Isso garante que o tráfego seja encriptado quando o gateway de aplicações estabelece uma ligação com o alvo do backend.
Para configurar a terminação TLS, um certificado TLS/SSL deve ser adicionado ao ouvinte. Isso permite que o Application Gateway descriptografe o tráfego de entrada e criptografe o tráfego de resposta para o cliente. O certificado fornecido ao Application Gateway deve estar no formato PFX (Personal Information Exchange), que contém as chaves privada e pública.
Observação
Ao usar um certificado TLS do Cofre da Chave para um ouvinte, você deve garantir que seu Application Gateway sempre tenha acesso a esse recurso do cofre de chaves vinculado e ao objeto de certificado dentro dele. Isso permite operações perfeitas do recurso de terminação TLS e mantém a integridade geral do seu recurso de gateway. Se um recurso de gateway de aplicação detetar um cofre de chaves configurado incorretamente, ele colocará automaticamente o(s) ouvinte(s) HTTPS associado(s) num estado desativado. Mais informações.
Certificados suportados
Consulte a descrição geral da terminação de TLS e do TLS ponto a ponto com o Application Gateway.
Suporte a protocolos adicionais
Suporte HTTP/2
O Application Gateway suporta o protocolo HTTP/2 para clientes que se ligam aos listeners do Application Gateway. A comunicação com pools de servidores backend utiliza sempre HTTP/1.1. Por padrão, o suporte a HTTP/2 está desativado. O seguinte excerto de código Azure PowerShell mostra como ativar este suporte:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Importante
Quando crias um recurso de gateway de aplicação através do portal do Azure, a opção padrão para o HTTP2 está ativada. Pode escolher Desativado durante a criação e reativar o suporte a HTTP/2 selecionando Ativado em HTTP2 na Configuração do Gateway > de Aplicação no portal Azure.
Em casos em que um cliente não suporta HTTP/2, a ligação usa HTTP/1.1. Ativar o HTTP/2 não desativa o HTTP/1.1; permite o suporte para ambos.
Observação
O Application Gateway só suporta HTTP/2 sobre TLS (ouvintes HTTPS). O Application Gateway não suporta tentativas de atualização do protocolo HTTP/2 Cleartext (h2c) a partir do HTTP/1.1 e devolve um erro 403 Forbidden. Os clientes que tentem atualizações h2c devem usar ligações nativas HTTP/2 sobre HTTPS ou permanecer em HTTP/1.1.
Suporte HTTP/3 (QUIC)
Importante
O suporte a HTTP/3 no Gateway de Aplicação do Azure está atualmente em pré-visualização. Durante a pré-visualização, a funcionalidade, disponibilidade e outros aspetos desta funcionalidade podem mudar em resposta ao feedback.
Esta versão de pré-visualização é fornecida sem um acordo de nível de serviço e não é recomendada para cargas de trabalho em produção. Certas funcionalidades podem não ser suportadas ou ter capacidades limitadas.
Para mais informações, consulte Termos Suplementares de Utilização para Microsoft Azure Previews.
O Application Gateway suporta HTTP/3 apenas para ligações de clientes que utilizam ouvintes Basic. Um ouvinte habilitado para HTTP/3 pode também aceitar tráfego HTTP/1.1 ou HTTP/2 de clientes. A comunicação do Application Gateway para os pools de servidores backend continua a usar HTTP/1.1.
O suporte a HTTP/3 está desativado por defeito.
Como o suporte HTTP/3 é anunciado
O Application Gateway anuncia suporte a HTTP/3 usando o cabeçalho de resposta HTTP Alt-Svc. Quando ativa o HTTP/3 num ouvinte, o Application Gateway inclui o seguinte cabeçalho de Alt-Svc nas respostas.
Alt-Svc: h3=":<listener-port>"; ma=86400
Quando desativas o HTTP/3, o Application Gateway não inclui o cabeçalho Alt-Svc.
Os clientes que suportam HTTP/3 podem usar o serviço anunciado para estabelecer uma ligação QUIC na porta do ouvinte. Os clientes que não suportam HTTP/3 continuam a usar HTTP/2 ou HTTP/1.1 em vez de TCP.
Suporte do WebSocket
O suporte a WebSocket está habilitado por padrão. Não há nenhuma configuração configurável pelo usuário para ativá-lo ou desativá-lo. Você pode usar WebSockets com ouvintes HTTP e HTTPS.
Páginas de erro personalizadas
Pode definir páginas de erro personalizadas para diferentes códigos de resposta que o Application Gateway devolve. Pode configurar páginas de erro para os códigos de resposta 400, 403, 405, 408, 500, 502, 503 e 504. Use configuração global ou de página de erro específica para o ouvinte para os definir de forma granular para cada ouvinte. Para obter mais informações, consulte Criar páginas de erro personalizadas do Application Gateway.
Observação
O Application Gateway transmite um erro do servidor backend para o cliente sem o modificar.
Política TLS
Você pode centralizar a gestão de certificados TLS/SSL e reduzir a sobrecarga de criptografia e descriptografia para um conjunto de servidores back-end. O tratamento centralizado de TLS também permite especificar uma política central de TLS que se adeque aos seus requisitos de segurança. Pode escolher uma política TLS pré-definida ou personalizada .
Configuras a política TLS para controlar as versões do protocolo TLS. Pode configurar um gateway de aplicação para usar uma versão mínima de protocolo para handshakes TLS a partir do TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3. Por padrão, SSL 2.0 e 3.0 são desativados e não são configuráveis. Para obter mais informações, consulte Visão geral da política TLS do Application Gateway.
Depois de criar um ouvinte, associe-o a uma regra de roteamento de solicitação. Essa regra determina como os pedidos que o ouvinte recebe são encaminhados para o back-end.