Perguntas frequentes sobre o Application Gateway

O Gateway de Aplicativo do Azure fornece um controlador de entrega de aplicativo como um serviço. Ele oferece vários recursos de balanceamento de carga de camada 7 para seus aplicativos. Esse serviço é altamente disponível, escalável e totalmente gerenciado pelo Azure.

O Application Gateway suporta dimensionamento automático, descarregamento de TLS e TLS de ponta a ponta, um firewall de aplicativo Web (WAF), afinidade de sessão baseada em cookie, roteamento baseado em caminho de URL, hospedagem multissite e outros recursos. Para obter uma lista completa dos recursos suportados, consulte Introdução ao Application Gateway.

O Application Gateway é um balanceador de carga de camada 7, o que significa que ele funciona apenas com tráfego da Web (HTTP, HTTPS, WebSocket e HTTP/2). Ele suporta recursos como terminação TLS, afinidade de sessão baseada em cookies e round robin para tráfego de balanceamento de carga. O balanceador de carga equilibra o tráfego na camada 4 (TCP ou UDP).

O Application Gateway suporta HTTP, HTTPS, HTTP/2 e WebSocket.

Consulte Suporte HTTP/2.

Consulte Recursos de back-end suportados.

O Application Gateway v1 (Standard e WAF) está disponível em todas as regiões do Azure global. Também está disponível no Microsoft Azure operado pela 21Vianet e Azure Government.

Para disponibilidade do Application Gateway v2 (Standard_v2 e WAF_v2), consulte Regiões suportadas para o Application Gateway v2.

O Application Gateway é uma implantação dedicada em sua rede virtual.

O redirecionamento é suportado. Consulte Visão geral do redirecionamento do Application Gateway.

Veja a ordem de processamento do ouvinte.

Se você estiver usando um endereço IP público como ponto de extremidade, encontrará as informações de IP e DNS no recurso de endereço IP público. Ou você pode encontrá-lo no portal do Azure, na página de visão geral do gateway de aplicativo. Se você estiver usando endereços IP internos, encontre as informações na página de visão geral. Para a SKU v1, os gateways criados após 1º de maio de 2023 não terão um nome DNS padrão automaticamente associado ao recurso IP público. Para o SKU v2, abra o recurso IP público e selecione Configuração. O campo Rótulo de nome DNS (opcional) está disponível para configurar o nome DNS.

Keep-Alive O tempo limite controla quanto tempo o gateway de aplicativo espera que um cliente envie outra solicitação HTTP em uma conexão persistente antes de reutilizá-la ou fechá-la. O tempo limite de inatividade TCP controla por quanto tempo uma conexão TCP é mantida aberta se não houver atividade.

Para conexões HTTP/1.1, o Keep-Alive tempo limite no SKU do Application Gateway v1 e v2 é de 120 segundos. Para endereços IP privados, o valor não é configurável com um tempo limite de inatividade TCP de 5 minutos. O tempo limite de ociosidade TCP é um padrão de 4 minutos no IP virtual de frontend (VIP) de SKU v1 e v2 do Application Gateway. Você pode configurar o valor de tempo limite ocioso TCP nas instâncias do Application Gateway v1 e v2 para ficar entre 4 minutos e 30 minutos. Para instâncias do Application Gateway v1 e v2, você precisa ir para o IP público do gateway de aplicativo e alterar o tempo limite ocioso do TCP no painel Configuração do IP público no portal. Você pode definir o valor de tempo limite de ociosidade TCP do IP público por meio do PowerShell executando os seguintes comandos:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Para conexões HTTP/2 com o endereço IP frontend no SKU do Application Gateway v2, o tempo limite de inatividade é definido como 180 segundos e não é configurável.

Para evitar conflitos e comportamentos inesperados, certifique-se de que o tempo limite de inatividade do TCP está definido para ser igual ou superior ao tempo limite de keep-alive.

Sim. O Application Gateway reutiliza as conexões TCP existentes com um servidor back-end.

N.º Não há como renomear um recurso do Application Gateway. Você deve criar um novo recurso com um nome diferente.

N.º Não há como restaurar um recurso do Application Gateway ou seu IP público após a exclusão. Você deve criar um novo recurso.

No Application Gateway v1 SKU, o VIP pode mudar se você parar e iniciar o gateway de aplicativo. Mas o nome DNS associado ao gateway de aplicativo não muda ao longo do tempo de vida do gateway. Como o nome DNS não é alterado, você deve usar um alias CNAME e apontá-lo para o endereço DNS do gateway de aplicativo. Na SKU do Application Gateway v2, os endereços IP são estáticos, portanto, o endereço IP e o nome DNS não serão alterados ao longo do tempo de vida do gateway de aplicativo.

Sim. O SKU do Application Gateway v2 suporta endereços IP públicos estáticos e IPs internos estáticos. O SKU v1 suporta IPs internos estáticos.

Um gateway de aplicativo suporta apenas um endereço IP público por protocolo IP. Se o gateway de aplicativo estiver configurado como DualStack, ele poderá suportar dois IPs públicos, um para IPv4 e outro para IPv6.

Consulte Considerações sobre o tamanho da sub-rede do Application Gateway.

Sim. Além de várias instâncias de uma determinada implantação do Application Gateway, você pode provisionar outro recurso exclusivo do Application Gateway para uma sub-rede existente que contenha um recurso diferente do Application Gateway.

Uma única sub-rede não pode suportar SKUs do Application Gateway v2 e v1.

Sim, mas apenas cenários específicos. Para obter mais informações, consulte Configuração da infraestrutura do Application Gateway.

Sim. Consulte Modificações a um pedido.

As implantações de SKU do New Application Gateway v1 podem levar até 20 minutos para serem provisionadas. As alterações no tamanho ou na contagem da instância não causam interrupções e o gateway permanece ativo durante esse período.

A maioria das implantações que usam o SKU v2 leva cerca de 6 minutos para provisionar. No entanto, o processo pode levar mais tempo, dependendo do tipo de implantação. Por exemplo, implantações em várias zonas de disponibilidade com muitas instâncias podem levar mais de 6 minutos.

As atualizações iniciadas no Application Gateway são aplicadas um domínio de atualização de cada vez. À medida que as instâncias de cada domínio de atualização estão sendo atualizadas, as instâncias restantes em outros domínios de atualização continuam a servir o tráfego¹. As conexões ativas são normalmente drenadas das instâncias que estão sendo atualizadas por até 5 minutos para ajudar a estabelecer conectividade com instâncias em um domínio de atualização diferente antes do início da atualização. Durante a atualização, o Application Gateway é executado temporariamente com capacidade máxima reduzida, que é determinada pelo número de instâncias configuradas. O processo de atualização prossegue para o próximo conjunto de instâncias somente se o conjunto atual de instâncias tiver sido atualizado com êxito.

1 Recomendamos que uma contagem mínima de instâncias de 2 seja configurada para implantações de SKU do Application Gateway v1 para garantir que pelo menos uma instância possa atender ao tráfego enquanto as atualizações são aplicadas.

O Application Gateway suporta proxy de protocolo TLS/TCP por meio de seu proxy de Camada 4 na visualização.

O proxy de Camada 7 do gateway de aplicativo com protocolos HTTP(S) não suportará protocolos de e-mail como SMTP, IMAP e POP3. No entanto, para alguns serviços de email de suporte, como o Outlook Web Access (OWA), o ActiveSync e o tráfego de Descoberta Automática que usa protocolos HTTP(S), você pode usar o proxy da Camada 7 e seu tráfego deve fluir. (Nota: Exclusões nas regras do WAF podem ser necessárias ao usar um WAF SKU).

Sim. Para obter mais informações, consulte Migrar o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web da v1 para a v2.

Sim. O Application Gateway v1 SKU continua a ser suportado. É altamente recomendável mudar para a v2 para aproveitar as atualizações de recursos nessa SKU. Para obter mais informações sobre as diferenças entre os recursos v1 e v2, consulte Autoscaling and zone-redundant Application Gateway v2. Você pode migrar manualmente implantações de SKU do Application Gateway v1 para v2 seguindo nosso documento de migração v1-v2.

N.º O Application Gateway v2 não suporta solicitações de proxy com autenticação NTLM ou Kerberos.

Os nomes dos cabeçalhos de solicitação podem conter caracteres alfanuméricos e hífenes. Os nomes de cabeçalho de solicitação que contêm outros caracteres são descartados quando uma solicitação é enviada para o destino de back-end. Os nomes dos cabeçalhos de resposta podem conter caracteres alfanuméricos e símbolos específicos, conforme definido na RFC 7230.

Sim. A atualização do navegador Chromium v80 introduziu um mandato sobre cookies HTTP sem o atributo SameSite para ser tratado como SameSite=Lax. Isso significa que o cookie de afinidade do Application Gateway não será enviado pelo navegador em um contexto de terceiros.

Para dar suporte a esse cenário, o Application Gateway injeta outro cookie chamado ApplicationGatewayAffinityCORS além do cookie existente ApplicationGatewayAffinity . Estes cookies são semelhantes, mas o ApplicationGatewayAffinityCORS cookie tem mais dois atributos adicionados: SameSite=None e Secure. Esses atributos mantêm sessões adesivas mesmo para solicitações de origens cruzadas. Para obter mais informações, consulte a seção Afinidade baseada em cookies.

Um ouvinte ativo é um ouvinte associado a uma regra e que envia tráfego para um pool de back-end. Qualquer ouvinte que apenas redirecione o tráfego não é um ouvinte ativo. Os ouvintes associados a regras de redirecionamento não são considerados ativos. Se a regra de redirecionamento for uma regra baseada em caminho, todos os caminhos nessa regra de redirecionamento deverão estar redirecionando o tráfego ou o ouvinte será considerado ativo. Para obter detalhes sobre limites de componentes individuais, consulte Limites, cotas e restrições de assinatura e serviço do Azure.

A SKU do Application Gateway v1 oferece suporte a cenários de alta disponibilidade quando você implanta duas ou mais instâncias. O Azure distribui essas instâncias entre domínios de atualização e falha para garantir que as instâncias não falhem todas ao mesmo tempo. O SKU v1 suporta escalabilidade adicionando várias instâncias do mesmo gateway para compartilhar a carga.

O SKU v2 garante automaticamente que novas instâncias sejam espalhadas entre domínios de falha e domínios de atualização. Se você escolher redundância de zona, as instâncias mais recentes também serão distribuídas pelas zonas de disponibilidade para oferecer resiliência a falhas zonais.

Use o Gerenciador de Tráfego do Azure para distribuir o tráfego entre vários gateways de aplicativos em diferentes datacenters.

Sim. Você pode configurar a drenagem de conexão para alterar membros dentro de um pool de back-end sem interrupção. Para obter mais informações, consulte a seção Drenagem de conexão do Application Gateway.

Sim, o SKU do Application Gateway v2 suporta dimensionamento automático. Para obter mais informações, consulte Autoscaling e gateway de aplicativo com redundância de zona.

N.º As instâncias são distribuídas entre domínios de atualização e domínios de falha.

Sim.

Sim.

Sim. O Application Gateway é sempre implantado em uma sub-rede de rede virtual. Essa sub-rede pode conter apenas gateways de aplicativos. Para obter mais informações, consulte Requisitos de rede virtual e sub-rede.

Se você tiver conectividade IP, o Application Gateway poderá se comunicar com instâncias fora da rede virtual em que está. O Application Gateway também pode se comunicar com instâncias fora da assinatura em que está. Se você planeja usar IPs internos como membros do pool de back-end, use o emparelhamento de rede virtual ou o Gateway de VPN do Azure.

Como qualquer resolvedor de DNS, o recurso do Application Gateway honra o valor TTL (Time to Live) do registro DNS do servidor back-end. Depois que o TTL expira, o gateway executa uma pesquisa para atualizar essas informações de DNS. Durante essa pesquisa, se o gateway de aplicativo encontrar um problema para obter uma resposta (ou nenhum registro DNS for encontrado), o gateway continuará usando o último valor DNS em boas condições para atender ao tráfego. Para obter mais informações, consulte Como funciona um gateway de aplicativo.

As instâncias do gateway de aplicativo usam a configuração DNS da rede virtual para resolução de nomes. Depois de alterar qualquer configuração de servidor DNS, você precisa reiniciar (Parar e Iniciar) o gateway de aplicativo para que os novos servidores DNS sejam atribuídos. Até lá, as resoluções de nomes baseadas em FQDN para conectividade de saída poderiam falhar.

N.º Mas você pode implantar outros gateways de aplicativos na sub-rede.

Você pode mover um gateway de aplicativo entre sub-redes somente dentro da mesma rede virtual. É suportado com v1 com um frontend público e privado (alocação dinâmica) e v2 com um frontend público apenas. Não podemos mover o gateway de aplicativo para outra sub-rede se a configuração IP do front-end privado estiver alocada estaticamente. O gateway de aplicativo deve estar em um estado interrompido para executar essa ação. Parar ou iniciar a v1 altera o IP público. Essa operação só pode ser feita usando o Azure PowerShell e a CLI do Azure executando os seguintes comandos:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Para obter mais informações, consulte Set-AzApplicationGatewayIPConfiguration.

CLI do Azure

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Consulte Grupos de segurança de rede na sub-rede do Application Gateway.

Consulte Rotas definidas pelo usuário suportadas na sub-rede do Application Gateway.

N.º As políticas de ponto de extremidade de serviço para contas de armazenamento não são suportadas na sub-rede do Gateway de Aplicativo e configurá-la bloqueia o tráfego de infraestrutura do Azure.

Consulte Limites do Application Gateway.

Sim. O Application Gateway suporta um IP interno e um IP externo por gateway de aplicativo.

Sim. O emparelhamento de rede virtual ajuda a balancear a carga do tráfego em outras redes virtuais.

Sim, desde que o tráfego seja permitido.

A arquitetura de microsserviços é suportada. Para investigar em portas diferentes, você precisa definir várias configurações de back-end.

N.º

Consulte Ordem das regras de processamento.

O campo Host especifica o nome para o qual enviar a sonda quando você tiver configurado multissite no Application Gateway. Caso contrário, use 127.0.0.1. Esse valor é diferente do nome do host da máquina virtual. Seu formato é <protocol>://<host>:<port><path>.

Sim. Consulte Restringir o acesso a IPs de origem específicos.

Sim, você pode usar ouvintes voltados para público e privado com o mesmo número de porta para oferecer suporte simultâneo a clientes públicos e privados. Se um NSG (grupo de segurança de rede) estiver associado à sub-rede do gateway de aplicativo, uma regra de entrada específica poderá ser necessária, dependendo de sua configuração. Saiba mais.

O Application Gateway v2 suporta front-ends IPv4 e IPv6. Atualmente, o suporte a IPv6 está disponível apenas para novos gateways de aplicativos. Para suportar IPv6, a rede virtual deve ser de pilha dupla. O Application Gateway v1 não suporta redes virtuais de pilha dupla.

Os SKUs do Application Gateway v1 podem ser executados em um modo de operação aprovado pelo FIPS 140-2, que é comumente chamado de "modo FIPS". O modo FIPS chama um módulo criptográfico validado pelo FIPS 140-2 que garante algoritmos compatíveis com FIPS para criptografia, hash e assinatura quando habilitado. Para garantir que o modo FIPS esteja habilitado, a configuração deve ser configurada por meio do PowerShell, do FIPSMode modelo do Azure Resource Manager ou da API REST após a assinatura ter sido registrada para habilitar a configuração do FIPSmode.

Nota: Como parte da conformidade com o FedRAMP, o Governo dos EUA exige que os sistemas operem em modo aprovado pelo FIPS após agosto de 2024.

Etapas para ativar o Modo FIPS no SKU V1:

Etapa 1: Registre o recurso 'AllowApplicationGatewayEnableFIPS' para registrar a assinatura para a configuração do modo FIPS.

Para se registrar usando o Azure PowerShell, abra um prompt do Cloud Shell e insira o seguinte:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Para se registrar usando o portal do Azure:

• Entre no portal do Azure e procure recursos de visualização.
• Digite AllowApplicationGatewayEnableFIPS na caixa de filtro. Selecione Application Gateway V1 Allow FIPS Mo e, em seguida, selecione Register.

Etapa 2: defina a propriedade enableFips como True usando o PowerShell, o modelo do Azure Resource Manager ou a API REST.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

A alteração do modo FIPS não afeta a disponibilidade geral dos pacotes de codificação em gateways V1. No entanto, ao usar criptografia de curva elíptica para cifras, com o modo FIPS desabilitado, você pode usar curve25519, NistP256 e NistP384, enquanto com o modo FIPS habilitado apenas NistP256 e NistP384 são permitidos e curve25519 está desabilitado. Como a curva25519 fica indisponível no modo FIPS, certifique-se de que seus clientes suportem NistP256 ou NistP384 para comunicação segura antes de ativar o FIPS.

Atualmente, o Application Gateway v2 suporta apenas a configuração de frontend IP privado (sem IP público) via visualização pública. Para obter mais informações, consulte Implantação do Private Application Gateway (visualização).

Para suporte de disponibilidade geral atual, o Application Gateway v2 suporta as seguintes combinações:

• IP privado e IP público
• Apenas IP público

Para restringir o tráfego apenas a endereços IP privados com funcionalidade atual, siga este processo:

1. Crie um gateway de aplicativo com endereço IP frontend público e privado.

2. Não crie ouvintes para o endereço IP de frontend público. O Application Gateway não ouvirá nenhum tráfego no endereço IP público se nenhum ouvinte for criado para ele.

3. Crie e anexe um grupo de segurança de rede para a sub-rede do Application Gateway com a seguinte configuração na ordem de prioridade:

   1. Permita o tráfego de Origem como a etiqueta de serviço GatewayManager, Destino como Qualquer e a Porta de destino como 65200-65535. Este intervalo de portas é necessário para a comunicação da infraestrutura do Azure. Essas portas são protegidas (bloqueadas) pela autenticação de certificado. Entidades externas, incluindo os administradores de usuários do gateway, não podem iniciar alterações nesses pontos de extremidade sem certificados apropriados em vigor.

   2. Permita o tráfego de Source como a marca de serviço AzureLoadBalancer e a Porta de destino como Any.

   3. Negar todo o tráfego de entrada da Origem como a etiqueta de serviço Internet e a Porta de destino como Qualquer. Dê a esta regra a menor prioridade nas regras de entrada.

   4. Mantenha as regras padrão, como AllowVNetInBound , para que o acesso em um endereço IP privado não seja bloqueado.

   5. A conectividade de saída com a Internet não pode ser bloqueada. Caso contrário, você enfrentará problemas com registro em log e métricas.

Exemplo de configuração NSG para acesso privado somente IP:

Você pode usar o Azure PowerShell ou a CLI do Azure para parar e iniciar o Application Gateway. Quando você para e inicia o Application Gateway, a cobrança também é interrompida e iniciada. Qualquer operação PUT feita em um gateway de aplicativo interrompido (como adicionar tag, teste de integridade ou ouvinte) dispara uma inicialização. Recomendamos que você pare o gateway de aplicativo depois que a configuração for atualizada.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

O Application Gateway oferece suporte a certificados autoassinados, certificados de autoridade de certificação (CA), certificados de Validação Estendida (EV), certificados de vários domínios (SAN) e certificados curinga.

O Application Gateway suporta os seguintes pacotes de codificação:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Para obter informações sobre como personalizar opções de TLS, consulte Configurar versões de política TLS e pacotes de codificação no Application Gateway.

Sim. O Application Gateway suporta descarregamento de TLS e TLS de ponta a ponta, que criptografa novamente o tráfego para o back-end.

Sim. Você pode configurar o Application Gateway para negar TLS1.0, TLS1.1 e TLS1.2. Por padrão, o SSL 2.0 e 3.0 já estão desativados e não são configuráveis.

Sim. No Application Gateway, você pode configurar pacotes de codificação. Para definir uma política personalizada, habilite pelo menos um dos seguintes pacotes de codificação:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

O Application Gateway usa SHA256 para gerenciamento de back-end.

O Application Gateway suporta até 100 certificados TLS/SSL.

Sim, o Application Gateway oferece suporte a certificados com extensões OCSP e grampeamento OCSP para certificados de servidor.

O Application Gateway suporta até 100 certificados de autenticação.

Sim, o SKU do Application Gateway v2 suporta o Cofre de Chaves. Para obter mais informações, veja Terminação TLS com certificados do Key Vault.

Para roteamento baseado em vários domínios (baseado em host), você pode criar ouvintes multissite, configurar ouvintes que usam HTTPS como protocolo e associar os ouvintes às regras de roteamento. Para obter mais informações, consulte Hospedagem de vários sites usando o Application Gateway.

N.º Use apenas caracteres alfanuméricos na senha do arquivo .pfx.

Os membros da CA/Browser publicaram recentemente relatórios detalhando vários certificados emitidos por fornecedores de CA que são usados por nossos clientes, pela Microsoft e pela comunidade de tecnologia em geral que não estavam em conformidade com os padrões do setor para CAs confiáveis publicamente. Os relatórios relativos às autoridades de certificação não conformes podem ser consultados aqui:

• Bug 1649951
• Bug 1650910

De acordo com os requisitos de conformidade do setor, os fornecedores de CA começaram a revogar CAs não compatíveis e a emitir CAs compatíveis, o que exige que os clientes tenham seus certificados reemitidos. A Microsoft está fazendo uma parceria estreita com esses fornecedores para minimizar o impacto potencial nos serviços do Azure. No entanto, seus certificados autoemitidos ou certificados usados em cenários Bring Your Own Certificate (BYOC) ainda correm o risco de serem revogados inesperadamente.

Para verificar se os certificados utilizados pelo seu aplicativo foram revogados, consulte o anúncio da DigiCert e o Certificate Revocation Tracker. Se seus certificados foram revogados ou serão revogados, você precisará solicitar novos certificados do fornecedor da autoridade de certificação utilizado em seus aplicativos. Para evitar que a disponibilidade do seu aplicativo seja interrompida devido a certificados que foram revogados inesperadamente ou para atualizar um certificado que foi revogado, consulte Revogação de Autoridades de Certificação não compatíveis que podem afetar os serviços do Azure do cliente.

Para obter informações específicas do Application Gateway:

Se você estiver usando um certificado emitido por um dos ICAs revogados, a disponibilidade do seu aplicativo poderá ser interrompida. Dependendo do seu aplicativo, você pode receber várias mensagens de erro, incluindo, mas não limitado a:

• Certificado inválido/certificado revogado
• Excedido o limite de tempo da ligação
• HTTP 502

Para evitar qualquer interrupção no seu aplicativo devido a esse problema, ou para reemitir uma autoridade de certificação que foi revogada, você precisa executar as seguintes ações:

1. Entre em contato com seu provedor de certificados para saber como reemitir seus certificados.
2. Depois que eles forem reemitidos, atualize seus certificados no Application Gateway/WAF com a cadeia completa de confiança (certificado folha, intermediário e raiz). Com base em onde você está usando seu certificado, seja no ouvinte ou nas configurações HTTP do gateway de aplicativo, siga as etapas aqui para atualizar os certificados. Para obter mais informações, consulte os links de documentação mencionados.
3. Atualize seus servidores de aplicativos de back-end para usar o certificado reemitido. Dependendo do servidor back-end que você está usando, as etapas de atualização do certificado podem variar. Verifique a documentação do seu fornecedor.

Para atualizar o certificado em seu ouvinte:

1. No portal do Azure, abra o recurso do Gateway de Aplicativo.
2. Abra as configurações de ouvinte associadas ao seu certificado.
3. Selecione Renovar ou editar certificado selecionado.
4. Carregue seu novo certificado PFX com a senha e selecione Salvar.
5. Acesse o site e verifique se o site está funcionando conforme o esperado. Para obter mais informações, consulte Renovar certificados do Application Gateway.

Se você estiver fazendo referência a certificados do Cofre da Chave em seu ouvinte do Application Gateway, recomendamos as seguintes etapas para uma alteração rápida:

1. No portal do Azure, vá para as configurações do Cofre da Chave associadas ao gateway de aplicativo.
2. Adicione ou importe o certificado reemitido na sua loja. Para obter mais informações, consulte Guia de início rápido: criar um cofre de chaves usando o portal do Azure.
3. Depois que o certificado for importado, vá para as configurações de ouvinte do Application Gateway e, em Escolha um certificado do Cofre da Chave, selecione a lista suspensa Certificado e selecione o certificado adicionado recentemente.
4. Selecione Guardar. Para obter mais informações sobre a terminação TLS no Application Gateway com certificados do Key Vault, consulte Terminação TLS com certificados do Key Vault.

Para atualizar o certificado nas configurações HTTP:

Se você estiver usando a SKU v1 do serviço Application Gateway/WAF, será necessário carregar o novo certificado como seu certificado de autenticação de back-end.

1. No portal do Azure, abra o recurso do Gateway de Aplicativo.
2. Abra as configurações HTTP associadas ao seu certificado.
3. Selecione Adicionar certificado, carregue o certificado reemitido e selecione Salvar.
4. Você pode remover o certificado antigo mais tarde, selecionando o botão de opções ... ao lado do certificado antigo. Selecione Excluir e, em seguida, selecione Salvar. Para obter mais informações, consulte Configurar TLS de ponta a ponta usando o Application Gateway com o portal.

Se você estiver usando o SKU V2 do serviço Application Gateway/WAF, não precisará carregar o novo certificado nas configurações HTTP, pois o SKU V2 usa "certificados raiz confiáveis" e nenhuma ação precisa ser tomada aqui.

Sim. O roteamento de Camada 7 e Camada 4 por meio do gateway de aplicativo usa a mesma configuração de IP frontend. Dessa forma, você pode direcionar todos os seus clientes para um único endereço IP (público ou privado) e o mesmo recurso de gateway os encaminhará com base nos protocolos de ouvinte configurados e nas portas.

Embora o tráfego HTTP(S) também possa ser servido através de protocolos de proxy L4, não recomendamos fazê-lo. A solução de proxy L7 do Application Gateway oferece maior controle e segurança sobre os protocolos HTTP(S) através de recursos avançados como Rewrites, Session Affinity, Redirection, WebSockets, WAF e muito mais.

As propriedades de recurso para os recursos da Camada 4 são diferentes das da Camada 7. Assim, ao usar a API REST ou a CLI, você deve usar as seguintes propriedades.

• API REST
• CLI

N.º Não é possível vincular as propriedades da Camada 4 e da Camada 7. Portanto, uma regra de roteamento só permitirá que você vincule um ouvinte do tipo Camada 4 a uma configuração de Back-end do tipo Camada 4.

Não é possível usar o mesmo nome para um L7 (httpListeners) e L4 (ouvintes). Isso também se aplica a outras propriedades L4, como backendSettingsCollection e routingRules.

Com certeza. Semelhante ao proxy de Camada 7, você pode adicionar um ponto de extremidade privado ao pool de back-end do gateway de aplicativo. Esse ponto de extremidade privado deve ser implantado em uma sub-rede adjacente da mesma rede virtual do gateway de aplicativo.

Ele não usa Keepalive para conexões de back-end. Para cada solicitação de entrada na conexão de ouvinte frontend, o Application Gateway inicia uma nova conexão de back-end para atender a essa solicitação.

O servidor back-end vê o endereço IP do gateway de aplicativo. Atualmente, não suportamos a "preservação de IP do cliente" através da qual o aplicativo de back-end pode ser informado do endereço IP do cliente original.

A mesma configuração de política TLS/SSL é aplicável tanto para a Camada 7 (HTTPS) quanto para a Camada 4 (TLS). Agora você pode usar o Perfil SSL (para política TLS específica do ouvinte e Autenticação Mútua) para ouvintes TLS. No entanto, atualmente um perfil SSL pode ser associado a um ouvinte TLS somente por meio de CLI, PowerShell ou API REST.

N.º O roteamento de um cliente para o mesmo servidor back-end não é suportado no momento. As conexões serão distribuídas de forma round-robin para os servidores em um pool de back-end.

Sim, o recurso de dimensionamento automático também funcionará para picos e reduções no tráfego para o protocolo TLS ou TCP.

Os recursos do Web Application Firewall (WAF) não funcionarão para uso da Camada 4.

N.º O suporte UDP não está disponível no momento.

A mesma lista de intervalo de portas permitidas e exceções também se aplica ao proxy de Camada 4.

O uso de uma porta comum para ouvintes TLS/TCP não é suportado no momento.

O Kubernetes permite a criação e deployment service recursos para expor um grupo de pods internamente no cluster. Para expor o mesmo serviço externamente, é definido um Ingress recurso que fornece balanceamento de carga, terminação TLS e hospedagem virtual baseada em nome. Para satisfazer esse Ingress recurso, é necessário um controlador de entrada, que escuta quaisquer alterações nos Ingress recursos e configura as políticas do balanceador de carga.

O Application Gateway Ingress Controller (AGIC) permite que o Application Gateway seja usado como a entrada para um Serviço Kubernetes do Azure, também conhecido como cluster AKS.

Não há suporte para a configuração direta do Application Gateway.

Se houver necessidade de alterar as configurações no Application Gateway, faça a alteração usando a configuração exposta no controlador de entrada ou em outros objetos do Kubernetes, como usando anotações suportadas. Depois que um Application Gateway é vinculado ao Application Gateway Ingress Controller (AGIC), quase toda a configuração desse gateway será sincronizada e controlada pelo controlador de entrada. Se você estiver tentando configurar diretamente o Application Gateway imperativamente ou por meio da infraestrutura como código, essas alterações serão eventualmente substituídas pelo controlador de entrada.

Atualmente, uma instância de um controlador de entrada só pode ser associada a um gateway de aplicativo.

O AGIC tenta associar automaticamente o recurso da tabela de rotas à sub-rede do Application Gateway, mas pode não conseguir fazê-lo devido à falta de permissões do AGIC. Se a AGIC não conseguir associar a tabela de rotas à sub-rede do Application Gateway, um erro será exibido nos logs da AGIC. Nesse caso, você precisa associar manualmente a tabela de rotas criada pelo cluster AKS à sub-rede do Application Gateway. Para obter mais informações, consulte Rotas definidas pelo usuário suportadas.

Sim, desde que as redes virtuais sejam emparelhadas e não tenham espaços de endereço sobrepostos. Se você estiver executando o AKS com kubenet, associe a tabela de rotas gerada pelo AKS à sub-rede do Application Gateway.

Para saber as diferenças entre o AGIC implantado por meio do Helm e o implantado como um complemento do AKS, consulte Diferença entre a implantação do Helm e o complemento do AKS.

Para saber as diferenças entre o AGIC implantado por meio do Helm versus implantado como um complemento do AKS, consulte Diferença entre a implantação do Helm e o complemento do AKS, especialmente as tabelas que documentam quais cenários são suportados pelo AGIC implantado por meio do Helm em vez de um complemento do AKS. Em geral, a implantação através do Helm permite que você teste recursos beta e candidatos de lançamento antes de um lançamento oficial.

N.º O complemento AGIC é um serviço gerenciado, o que significa que a Microsoft atualiza automaticamente o complemento para a versão estável mais recente.

A autenticação mútua é a autenticação bidirecional entre um cliente e um servidor. Atualmente, a autenticação mútua com o Application Gateway permite que o gateway verifique o cliente que está enviando a solicitação, que é a autenticação do cliente. Normalmente, o cliente é o único que autentica o gateway de aplicativo. Como o Application Gateway agora também pode autenticar o cliente, ele se torna autenticação mútua onde o Application Gateway e o cliente estão se autenticando mutuamente.

Não, atualmente a autenticação mútua é apenas entre o cliente frontend e o gateway de aplicativo. Atualmente, não há suporte para autenticação mútua de back-end.

O Application Gateway fornece três logs:

• ApplicationGatewayAccessLog: O log de acesso contém cada solicitação enviada ao front-end do gateway de aplicativo. Os dados incluem o IP do chamador, URL solicitado, latência de resposta, código de retorno e bytes de entrada e saída. Ele contém um registro por gateway de aplicativo.
• ApplicationGatewayPerformanceLog: O log de desempenho captura informações de desempenho para cada gateway de aplicativo. As informações incluem a taxa de transferência em bytes, o total de solicitações atendidas, a contagem de solicitações com falha e a contagem de instâncias de back-end íntegras e não íntegras.
• ApplicationGatewayFirewallLog: Para gateways de aplicativos que você configura com o WAF, o log do firewall contém solicitações que são registradas no modo de deteção ou no modo de prevenção.

Todos os logs são coletados a cada 60 segundos. Para obter mais informações, consulte Integridade do back-end, logs de diagnóstico e métricas para o Application Gateway.

Verifique a integridade usando o cmdlet Get-AzApplicationGatewayBackendHealth do PowerShell ou o portal. Para obter mais informações, consulte Application Gateway diagnostics.

Os logs de diagnóstico fluem para a conta de armazenamento do cliente. Os clientes podem definir a política de retenção com base em suas preferências. Os logs de diagnóstico também podem ser enviados para um hub de eventos ou para os Logs do Azure Monitor. Para obter mais informações, consulte Application Gateway diagnostics.

No portal, no painel de menu de um gateway de aplicativo, selecione Log de atividades para acessar o log de auditoria.

Sim. No Application Gateway, os alertas são configurados em métricas. Para obter mais informações, consulte Métricas do Application Gateway e Receber notificações de alerta.

Você pode visualizar e analisar os logs de acesso de várias maneiras. Use o Azure Monitor Logs, Excel, Power BI e assim por diante.

Você também pode usar um modelo do Gerenciador de Recursos que instala e executa o popular analisador de logs GoAccess para logs de acesso do Application Gateway. O GoAccess fornece estatísticas valiosas de tráfego HTTP, como visitantes únicos, arquivos solicitados, hosts, sistemas operacionais, navegadores e códigos de status HTTP. Para obter mais informações, no GitHub, consulte o arquivo Leiame na pasta de modelo do Gerenciador de Recursos.

Normalmente, você vê um status desconhecido quando o acesso ao back-end é bloqueado por um NSG, DNS personalizado ou roteamento definido pelo usuário na sub-rede do Application Gateway. Para obter mais informações, consulte Integridade do back-end, log de diagnóstico e métricas para o Application Gateway.

Devido às limitações atuais da plataforma, se você tiver um NSG na sub-rede do Application Gateway v2 (Standard_v2, WAF_v2) e tiver habilitado os logs de fluxo do NSG nele, verá um comportamento não determinístico. Este cenário não é suportado no momento.

O Application Gateway não move nem armazena dados de clientes para fora da região em que é implantado.

Próximos passos

• Para saber mais sobre o Gateway de Aplicativo, consulte O que é o Gateway de Aplicativo do Azure.
• Para saber mais sobre a terminação TLS e o TLS de ponta a ponta com o Application Gateway, consulte Habilitar TLS de ponta a ponta no Gateway de Aplicativo do Azure.