Configuração do ouvinte do Gateway de Aplicativo
Observação
Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Confira Instalar o Azure PowerShell para começar. 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ê deverá inserir valores para que eles correspondam aos valores na solicitação de entrada no gateway.
Ao criar um gateway de aplicativo usando o portal do Azure, você também escolhe o protocolo e a porta para criar um ouvinte padrão. 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.
Para 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.
Caso deseje encaminhar as solicitações para diferentes pools de back-end com base no cabeçalho do host ou nos nomes do host, escolha o ouvinte multissite. 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 solicitações na mesma porta, você precisa especificar um nome de host que corresponda à solicitação de entrada. Saiba mais em Hospedagem de vários sites usando o Gateway de Aplicativo.
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 será processada primeiro e aceitará qualquer solicitação para essa porta e combinação de IP. Para evitar isso, configure as regras com os ouvintes multissite primeiro e envie por push a regra com o ouvinte básico para o último na lista.
Para o SKU v2, os ouvintes de vários sites são processados antes dos ouvintes básicos, a menos que a prioridade da regra seja definida. Se você estiver usando a prioridade de regra, os ouvintes curinga deverão ser definidos como uma prioridade com um número maior que ouvintes não curinga, para garantir que ouvintes não curinga sejam executados antes dos ouvintes curinga.
Endereço IP de front-end
Escolha o endereço IP de front-end que pretende associar a este ouvinte. O ouvinte ouvirá as solicitações de entrada nesse IP.
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úblico e privado) e dois endereços IPv6 (público e privado).
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.
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 de permissão com endereços IP de destino como os IPs de front-end 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:
Se você escolher HTTP, o tráfego entre o cliente e o Gateway de Aplicativo será descriptografado.
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 Aplicativo deve estar no formato PFX (Troca de Informações Pessoais), que contém as chaves pública e privada.
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 do recurso de terminação TLS e mantém a integridade geral do recurso de gateway. Se um recurso de gateway de aplicativo detectar um cofre de chaves configurado incorretamente, ele colocará automaticamente os ouvintes HTTPS associados em um estado desabilitado. Saiba mais.
Certificados com suporte
Confira Visão geral do terminação TLS e TLS de ponta a ponta com um Gateway de Aplicativo
Suporte a protocolo adicional
Suporte a HTTP2
O suporte ao protocolo HTTP/2 está disponível para clientes que se conectam somente a ouvintes do gateway de aplicativo. A comunicação com os pools de servidores back-end é sempre HTTP/1.1. Por padrão, o suporte HTTP/2 está desabilitado. O trecho de código Azure PowerShell a seguir 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 na Configuração > do Gateway de Aplicativo.
Suporte para WebSocket
O suporte a ClangFormat é 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 códigos de resposta diferentes retornados pelo Gateway de Aplicativo. 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 específica do ouvinte ou de nível global para defini-las de maneira granular para cada ouvinte. Para obter mais informações, confira Criar páginas de erro personalizadas do Gateway de Aplicativo.
Observação
Um erro proveniente do servidor back-end é transferido sem modificação pelo Gateway de Aplicativo para o cliente.
Política TLS
Você pode centralizar o gerenciamento de certificados TLS/SSL e reduzir a sobrecarga de criptografia-descriptografia para um farm de servidores back-end. O tratamento centralizado de TLS também permite que você especifique uma política TLS central adequada aos seus requisitos de segurança. Você pode escolher uma política TLS predefinida ou personalizada.
Você pode configurar a política TSL para controlar as versões do Protocolo SSL. Você pode configurar um gateway de aplicativo para usar uma versão mínima de protocolo para handshakes de TLS do TLS1.0, TLS1.1, TLS1.2 e TLS1.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 solicitações recebidas no ouvinte são roteadas para o back-end.