Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Observação
Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.
Um ouvinte é uma entidade lógica que verifica as solicitações de conexão de entrada usando porta, protocolo, host e endereço IP. Ao configurar o ouvinte, você deve inserir valores para essas configurações que correspondam aos valores correspondentes na requisição recebida no gateway.
Quando você cria 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 listener, você escolhe entre basic e multi-site. A escolha depende se o roteamento depende do nome do host na solicitação recebida.
| O roteamento depende do nome do host | Tipo de ouvinte | Behavior |
|---|---|---|
| No | Básico | Aceite e encaminhe todas as solicitações de qualquer domínio para pools de backend. Saiba como criar um gateway de aplicação com um escutador básico. |
| Yes | Vários sites | Encaminhe solicitações para diferentes pools de backend com base no cabeçalho host ou nos nomes de host. O Gateway de Aplicativo depende de cabeçalhos de host HTTP 1.1 para hospedar mais de um site na mesma porta e endereço IP público. Para diferenciar as requisições na mesma porta, você deve especificar um nome de host que corresponda à solicitação recebida. |
Para saber mais sobre ouvintes multi-site, veja hospedar múltiplos sites usando o Application Gateway.
Ordem de ouvintes de processamento
Para a SKU v1, a correspondência das solicitações são feitas de acordo com a ordem das regras e o tipo de ouvinte. Se uma regra com um ouvinte básico vier primeiro na ordem, ela processa primeiro e aceita qualquer solicitação para essa combinação de porta e IP. Para evitar esse comportamento, configure primeiro as regras com receptores multisite e mova a regra com o receptor básico para a última posição da lista.
Para o SKU v2, a prioridade da regra define a ordem na qual os ouvintes são processados. Defina ouvintes curinga e básicos com um número de prioridade maior que ouvintes específicos do local e multi-site. Essa configuração garante que os listeners específicos do site e de vários sites sejam executados antes dos listeners com curinga e dos listeners básicos.
A tabela a seguir 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 ouvinte básico que vem primeiro na ordem é processada primeiro e aceitará qualquer solicitação para essa porta e combinação de IP. | Configure as regras com os ouvintes multissite primeiro e envie por push a regra com o ouvinte básico para a última posição na lista. |
| v2 | Prioridade da regra. | Defina ouvintes coringa e básicos com um número de prioridade maior do que o número usado para ouvintes específicos do local e de vários locais, para que os ouvintes específicos do local e de vários locais sejam executados primeiro. |
Endereço IP de Frontend
Escolha o endereço IP de front-end que pretende associar a este ouvinte. O ouvinte ouve as solicitações recebidas nesse IP.
Escolha um endereço IP público de front-end quando os clientes acessarem o aplicativo por trás deste listener pela Internet. Escolha um endereço IP de frontend privado para um ponto de extremidade interno que não esteja exposto à Internet, como um aplicativo interno de linha de negócios ou um nível de um aplicativo de várias camadas que ainda exija distribuição de carga, fixação de sessão ou terminação TLS. Para as combinações suportadas, veja Configuração de endereços IP frontend.
Observação
O front-end do Gateway de Aplicativo agora dá suporte a endereços IP de pilha dupla. Você pode criar até quatro endereços IP de front-end: dois endereços IPv4 (públicos e privados) e dois endereços IPv6 (públicos e privados).
Porta de front-end
Associe uma porta de front-end. 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 bem conhecidas, como 80 e 443, mas qualquer porta personalizada 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 sua aplicação precisar de uma e confirme que o valor está dentro do intervalo permitido para seu SKU, pois o intervalo suportado difere entre os SKUs v1 e v2.
Observação
Ao usar ouvintes públicos e privados com o mesmo número de porta, o gateway de aplicativo altera o "destino" do fluxo de entrada para os IPs de front-end do seu gateway. Dependendo da configuração do seu Grupo de Segurança de Rede, talvez você precise de uma regra de entrada com endereços IP de destino como os IPs de frontend públicos e privados do seu gateway de aplicativo.
Regra de entrada:
- Origem: (de acordo com seus requisitos)
- Endereços IP de destino: IPs de front-end públicos e privados do seu gateway de aplicativo.
- Porta de destino: (de acordo com a configuração do ouvinte)
- Protocolo: TCP
Regra de saída: (nenhum requisito específico)
Protocolo
Escolha HTTP ou HTTPS. Escolha HTTPS quando o tráfego entre o cliente e o gateway de aplicativo deve ser criptografado, o que também permite ao gateway assumir o trabalho de criptografia e descriptografia, para que seus servidores de back-end não sejam sobrecarregados com a sobrecarga de processamento do TLS. Escolha HTTP quando essa criptografia não for necessária para o tráfego que esse ouvinte aceita.
Se você escolher HTTP, o tráfego entre o cliente e o gateway de aplicativo não será criptografado.
Escolha HTTPS se desejar a 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 obter a criptografia TLS de ponta a ponta para o destino de back-end, também precisará escolher HTTPS na configuração HTTP de back-end. Isso garante que o tráfego seja criptografado quando o gateway de aplicativo iniciar uma conexão com o destino de back-end.
Para configurar a terminação TLS, um certificado TLS/SSL deve ser adicionado ao ouvinte. Isso permite que o Gateway de Aplicativo descriptografe o tráfego de entrada e criptografe o tráfego de resposta para o cliente. O certificado fornecido para o Gateway de Aplicações deve estar no formato PFX (Troca de Informações Pessoais), que contém as chaves privada e pública.
Observação
Ao usar um certificado TLS do Key Vault com um ouvinte, você deve garantir que o gateway de aplicativo sempre tenha acesso a esse recurso do cofre de chaves vinculado e ao objeto de certificado dentro dele. Isso permite operações contínuas da função de terminação TLS e mantém a saúde geral do seu recurso de gateway. Se um recurso de gateway de aplicações detectar um cofre de chaves configurado incorretamente, ele colocará automaticamente os escutadores HTTPS associados em um estado desabilitado. Saiba mais.
Certificados com suporte
Veja Visão geral da terminação de TLS e TLS de ponta a ponta com Application Gateway.
Suporte a protocolo adicional
Suporte do HTTP/2
O Gateway de Aplicativo comporta o protocolo HTTP/2 para clientes que se conectam aos ouvintes do Gateway de Aplicativo. A comunicação com pools de servidores backend sempre usa HTTP/1.1. Por padrão, o suporte HTTP/2 está desabilitado. O seguinte trecho de código do Azure PowerShell mostra como habilitar esse suporte:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Importante
Quando você cria um recurso de gateway de aplicação pelo portal do Azure, a opção padrão para HTTP2 está ativada. Você pode escolher Desativado durante a criação e reativar o suporte a HTTP/2 selecionando Ativado em HTTP2 em Configuração do Gateway > de Aplicação no portal Azure.
Em casos em que um cliente não suporta HTTP/2, a conexão usa HTTP/1.1. Ativar o HTTP/2 não desativa o HTTP/1.1; permite o suporte para ambos.
Observação
O Gateway de Aplicativo só dá suporte a HTTP/2 por TLS (listeners HTTPS). O Application Gateway não suporta tentativas de atualização do protocolo HTTP/2 Cleartext (h2c) a partir do HTTP/1.1 e retorna um erro 403 Forbidden. Clientes que tentam atualizações h2c devem usar conexões nativas HTTP/2 sobre HTTPS ou permanecer em HTTP/1.1.
Suporte a HTTP/3 (QUIC)
Importante
O suporte a HTTP/3 no Gateway de Aplicativo do Azure está atualmente em pré-visualização. Durante a visualização, a funcionalidade, a disponibilidade e outros aspectos desse recurso podem mudar em resposta aos comentários.
Esta versão prévia é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou ter recursos restritos.
Para obter mais informações, consulte Termos de Uso Complementares para Versões Prévias do Microsoft Azure.
O Application Gateway suporta HTTP/3 apenas para conexões de clientes que utilizam ouvintes Basic. Um ouvinte habilitado para HTTP/3 também pode aceitar tráfego HTTP/1.1 ou HTTP/2 de clientes. A comunicação do Application Gateway para pools de servidores backend continua usando HTTP/1.1.
O suporte a HTTP/3 está desativado por padrão.
Como o suporte ao HTTP/3 é anunciado
O Application Gateway anuncia suporte a HTTP/3 usando o cabeçalho de resposta HTTP Alt-Svc. Quando você habilita o HTTP/3 em um ouvinte, o Application Gateway inclui o seguinte cabeçalho Alt-Svc nas respostas.
Alt-Svc: h3=":<listener-port>"; ma=86400
Quando você desativa o HTTP/3, o Application Gateway não inclui o cabeçalho Alt-Svc.
Clientes que suportam HTTP/3 podem usar o serviço anunciado para estabelecer uma conexão QUIC na porta do ouvinte. Clientes que não suportam HTTP/3 continuam usando HTTP/2 ou HTTP/1.1 em vez de TCP.
Suporte para WebSocket
O suporte a WebSocket é habilitado por padrão. Não há definição configurável pelo usuário para habilitá-lo ou desabilitá-lo. Você pode usar Websockets com ouvintes HTTP e HTTPS.
Páginas de erro personalizadas
Você pode definir páginas de erro personalizadas para diferentes códigos de resposta que o Application Gateway retorna. Você pode configurar páginas de erro para os códigos de resposta 400, 403, 405, 408, 500, 502, 503 e 504. Use configuração de página de erro em nível global ou específica do ouvinte para defini-las de forma granular para cada ouvinte. Para obter mais informações, confira Criar páginas de erro personalizadas do Gateway de Aplicação.
Observação
O Gateway de Aplicação repassa um erro do servidor backend para o cliente sem modificá-lo.
Política TLS
Você pode centralizar o gerenciamento de certificados TLS/SSL e reduzir a sobrecarga de criptografia e descriptografia para um farm de servidores backend. O tratamento centralizado de TLS também permite que você especifique uma política central de TLS que atenda aos seus requisitos de segurança. Você pode escolher uma política TLS pré-definida ou personalizada .
Você configura a política TLS para controlar as versões do protocolo TLS. Você pode configurar um gateway de aplicação para usar uma versão mínima do protocolo para handshakes TLS a partir do TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3. Por padrão, o SSL 2.0 e 3.0 estão desabilitados e não são configuráveis. Confira mais informações em Visão geral da política TLS do Gateway de Aplicativo.
Depois de criar um ouvinte, você o associa a uma regra de roteamento de solicitação. Essa regra determina como as requisições que o ouvinte recebe são roteadas para o back-end.