Configuração do serviço de escuta do Gateway de Aplicação
Nota
Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o 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. Ao configurar o ouvinte, você deve inserir valores para eles que correspondam aos valores correspondentes na solicitação de entrada no 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.
Se quiser que todas as suas solicitações (para qualquer domínio) sejam aceitas e encaminhadas para pools de back-end, escolha básico. Saiba como criar um gateway de aplicativo com um ouvinte básico.
Se você quiser encaminhar solicitações para diferentes pools de back-end com base no cabeçalho do host ou nos nomes do host, escolha ouvinte multissite. O Gateway de Aplicação conta com os cabeçalhos de anfitrião HTTP 1.1 para alojar mais do que um site no mesmo endereço IP público e porta. Para diferenciar solicitações na mesma porta, você deve especificar um nome de host que corresponda à solicitação de entrada. Para saber mais, consulte Hospedagem de vários 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 ouvinte básico vier em primeiro lugar na ordem, ela será processada primeiro e aceitará qualquer solicitação para essa combinação de porta e IP. Para evitar isso, configure as regras com ouvintes multissite primeiro e empurre a regra com o ouvinte básico para o último da lista.
Para a SKU v2, os ouvintes multissite são processados antes dos ouvintes básicos, a menos que a prioridade da regra seja definida. Se estiver usando a prioridade da regra, os ouvintes curinga devem ser definidos com um número maior do que os ouvintes não curinga, para garantir que os ouvintes não curinga sejam executados antes dos ouvintes curinga.
Endereço IP de front-end
Escolha o endereço IP frontend que você planeja associar a esse ouvinte. O ouvinte ouvirá as solicitações recebidas neste IP.
Nota
O frontend do Application Gateway suporta endereços IP de pilha dupla. Você pode criar até quatro endereços IP frontend: dois endereços IPv4 (público e privado) e dois endereços IPv6 (público e privado).
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.
Nota
Ao usar ouvintes privados e públicos 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 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:
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 criptografado quando o gateway de aplicativo inicia 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 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.
Nota
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 aplicativo detetar um cofre de chaves configurado incorretamente, ele colocará automaticamente o(s) ouvinte(s) HTTPS associado(s) em um estado desabilitado. Mais informações.
Certificados suportados
Consulte Visão geral da terminação TLS e TLS de ponta a ponta com o Application Gateway
Suporte a protocolos adicionais
Suporte HTTP2
O suporte ao protocolo HTTP/2 está disponível apenas para clientes que se conectam a ouvintes do gateway de aplicativo. A comunicação com pools de servidores back-end é sempre HTTP/1.1. Por padrão, o suporte a HTTP/2 está desativado. O seguinte trecho de código do Azure PowerShell mostra como habilitar isso:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Você também pode habilitar o suporte a HTTP2 usando o portal do Azure selecionando Habilitado em HTTP2 em Configuração do gateway > de aplicativo.
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 erros personalizadas
Você pode definir páginas de erro personalizadas para diferentes códigos de resposta retornados pelo Application Gateway. Os códigos de resposta para os quais você pode configurar páginas de erro são 400, 403, 405, 408, 500, 502, 503 e 504. Você pode usar a configuração de página de erro de nível global ou específica do ouvinte para defini-los granularmente para cada ouvinte. Para obter mais informações, consulte Criar páginas de erro personalizadas do Gateway de Aplicação.
Nota
Um erro originado do servidor back-end é passado sem modificações pelo Application Gateway para o cliente.
Política TLS
Você pode centralizar o gerenciamento de certificados TLS/SSL e reduzir a sobrecarga de descriptografia de criptografia para um farm de servidores back-end. O tratamento centralizado de TLS também permite especificar uma política central de TLS adequada aos seus requisitos de segurança. Você pode escolher uma política TLS predefinida ou personalizada .
Você configura a política TLS para controlar versões do protocolo TLS. Você pode configurar um gateway de aplicativo para usar uma versão mínima de protocolo para handshakes TLS de TLS1.0, TLS1.1, TLS1.2 e TLS1.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 as solicitações recebidas no ouvinte são roteadas para o back-end.