Perguntas frequentes sobre o Application Gateway

O Gateway de Aplicação do Azure fornece um controlador de entrega de aplicações como serviço. Ele oferece vários recursos de balanceamento de carga de camada 7 para seus aplicativos. Este serviço está altamente disponível, é escalável e totalmente gerido pela 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 funcionalidades como terminação TLS, afinidade de sessão baseada em cookies e round robin para balanceamento de carga de tráfego. 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 em 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 pode encontrá-lo no portal do Azure, na página de visão geral do portal de candidaturas. 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 de inatividade TCP é de 4 minutos como padrão no IP virtual (VIP) de frontend das SKUs 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, uma implantação em zonas de disponibilidade múltiplas com muitas instâncias pode levar mais de 6 minutos.

O Application Gateway suporta o proxy de protocolo TLS/TCP através do seu proxy de Camada 4 em versão prévia.

O proxy de Camada 7 do gateway de aplicações com protocolos HTTP(S) não suportará protocolos de email, tais como SMTP, IMAP e POP3. No entanto, para alguns serviços de email de suporte, como o Outlook Web Access (OWA), ActiveSync e o tráfego de AutoDiscovery que utilizam protocolos HTTP(S), pode usar o proxy de Camada 7, e o tráfego deverá fluir através dele. (Nota: Exclusões nas regras do WAF podem ser necessárias ao usar um WAF SKU).

Sim. Para mais informações, veja Migrar Gateway de Aplicação do Azure e Firewall de Aplicações 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.

Sim. O Application Gateway v2 agora suporta pedidos de proxy com autenticação NTLM ou Kerberos. Para mais informações, consulte Ligação dedicada de back-end.

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 para a versão v80 introduziu uma exigência para que os cookies HTTP sem o atributo SameSite sejam tratados como . 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 persistentes 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 detalhes sobre limites individuais de componentes, consulte Azure limites de subscrição e serviços, quotas e restrições.

A SKU do Application Gateway v1 oferece suporte a cenários de alta disponibilidade quando são implementadas duas ou mais instâncias. O Azure distribui estas instâncias entre os domínios de atualização e falha para garantir que as instâncias não falham 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 Gestor de Tráfego do Azure para distribuir tráfego entre múltiplos gateways de aplicações em diferentes centros de dados.

Sim. Você pode configurar a drenagem de conexão para alterar os membros dentro de um grupo de backend sem qualquer 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 Aplicação 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.

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. 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.

O Gateway de Aplicação do Azure também suporta o MaxSurge, uma funcionalidade que permite que novas instâncias sejam provisionadas durante atualizações contínuas sem desligar as existentes. Ele permite que os clientes façam a transição para versões mais recentes do gateway sem qualquer degradação de capacidade. O MaxSurge é ativado automaticamente no Application Gateway e não requer configuração.

Observação: Espaço IP adicional é necessário para provisionar as instâncias temporárias usadas pelo MaxSurge. Se não houver espaço IP suficiente disponível durante uma atualização, o Application Gateway voltará ao método de atualização tradicional, o que pode resultar em capacidade máxima reduzida com base no número de instâncias.

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 pretender usar IPs internos como membros do pool de backend, use virtual network peering ou 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 esta pesquisa, se o gateway de aplicação encontrar um problema ao obter uma resposta (ou nenhum registo DNS for encontrado), o gateway continuará a usar o último valor DNS válido para atender o tráfego. Para obter mais informações, consulte Como funciona um gateway de aplicativo.

As instâncias do gateway de aplicações usam a configuração DNS da rede virtual para a resolução de nomes de domínio. 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 podiam falhar.

Sim. O Application Gateway pode resolver nomes curtos (como server1 ou backend) em pools backend se o seu servidor DNS os conseguir resolver. Isto funciona em qualquer configuração de rede, incluindo on-premises, redes virtuais Azure ou ambientes híbridos.

Para que a resolução de nomes curtos funcione:

• O servidor DNS da sua rede virtual deve ser capaz de converter o nome curto num endereço IP
• Nomes curtos funcionam tal como nomes de domínio totalmente qualificados (FQDNs) – o gateway pede ao servidor DNS o endereço IP e usa-o

Nota: Se estiver a usar o DNS padrão do Azure (168.63.129.16), ele só pode resolver nomes curtos para recursos na mesma rede virtual. Para resolver nomes curtos locais, configure um servidor DNS personalizado que possa gerir os seus nomes de domínio internos.

Para mais informações, consulte Compreender a resolução DNS no Application Gateway.

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. É compatível com a v1, que possui um frontend público e privado (alocação dinâmica), e com a v2, que possui apenas um frontend público. 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. Esta operação só pode ser realizada usando o Azure PowerShell e o 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.º Políticas de endpoint de serviço para contas de armazenamento não são suportadas na sub-rede do Application Gateway e a sua configuração 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 redes virtuais ajuda a equilibrar o 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 da Gateway de Aplicação podem funcionar em modo de operação aprovado pelo FIPS 140-2, que é comumente referido como "modo FIPS". O modo FIPS chama um módulo criptográfico validado FIPS 140-2, que assegura algoritmos compatíveis com FIPS para encriptação, hashing e assinatura quando ativado. Para garantir que o modo FIPS está ativado, a definição FIPSMode deve ser configurada através do Portal (para a V2), PowerShell, Azure Resource Manager template ou API REST.

Passos para ativar o Modo FIPS na SKU V2: Ver Ativar o modo FIPS para Gateway de Aplicação do Azure V2 SKU.

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 registar usando Azure PowerShell, abra um prompt do Cloud Shell e introduza o seguinte:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Para se registar usando o portal Azure:

• Inicie sessão no portal Azure e pesquise por funcionalidades de pré-visualização .
• Digite AllowApplicationGatewayEnableFIPS na caixa de filtro. Selecione Application Gateway V1 Permitir o Modo FIPS e, em seguida, selecione Registar.

Passo 2: Defina a propriedade enableFips para True usando PowerShell, template Azure Resource Manager ou 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.

O Application Gateway v2 agora suporta apenas a configuração de frontend IP privado. Para obter mais informações, consulte Implantação do Private Application Gateway.

O Application Gateway v2 suporta as seguintes combinações:

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

Pode usar o Azure PowerShell ou o 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 (Protocolo de criptografia TLS com DHE, RSA, AES 128 GCM e 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 (Protocolo de criptografia TLS com DHE, RSA, AES 128 GCM e 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 Application Gateway v2 suporta Key Vault. Para obter mais informações, consulte finalização de TLS com certificados do Key Vault.

O portal Azure permite atualmente selecionar cofres de chaves apenas a partir da mesma subscrição do Application Gateway. Esta é uma limitação conhecida do portal. No entanto, o Application Gateway suporta a utilização de um cofre de chaves de uma subscrição diferente (dentro do mesmo inquilino do Microsoft Entra ID), configurando o certificado através do CLI do Azure ou do PowerShell com o uso do ID secreto do cofre de chaves. Isto será possível desde que a identidade gerida pelo Gateway de Aplicações tenha as permissões necessárias no cofre de chaves.

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 múltiplos certificados emitidos por fornecedores de CA que são usados pelos nossos clientes, pela Microsoft e pela comunidade tecnológica em geral, que estavam fora de conformidade com os padrões da indústria para CAs de confiança pública. 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á a colaborar estreitamente com estes fornecedores para minimizar o impacto potencial nos serviços 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 da sua aplicação seja interrompida devido à revogação inesperada de certificados, ou para atualizar um certificado que tenha sido revogado, consulte Revogação de Autoridades Certificadoras Não Conformes que potencialmente afetam os serviços 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. Assim que forem reemitidos, atualize os seus certificados no Application Gateway/WAF com a cadeia completa de confiança (certificado final, 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 Azure, abra o seu recurso Application Gateway.
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 estiver a referenciar certificados do Key Vault no seu ouvinte do Gateway de Aplicação, recomendamos os seguintes passos para uma alteração rápida:

1. No portal do Azure, vá para as definições de Key Vault associadas ao gateway de aplicação.
2. Adicione ou importe o certificado reemitido na sua loja. Para mais informações, consulte Quickstart: Criar um cofre de chaves usando o portal Azure.
3. Depois de o certificado ser importado, vá às definições do ouvinte do seu Application Gateway e, em Escolha um certificado de Key Vault, selecione o menu suspenso Certificate e selecione o certificado recentemente adicionado.
4. Selecione Guardar. Para mais informações sobre terminação de TLS no Application Gateway com certificados do Key Vault, veja Terminação de 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 Azure, abra o seu recurso Application Gateway.
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 escutador do tipo Camada 4 a uma configuração de backend do tipo Camada 4.

Não é possível usar o mesmo nome para um L7 (httpListeners) e L4 (listeners). 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 numa sub-rede adjacente da mesma rede virtual do gateway de aplicações.

Ele não usa Keepalive para conexões de back-end. Para cada pedido recebido na conexão do ouvinte frontal, o Application Gateway inicia uma nova conexão de back-end para atender a esse pedido.

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 circular para os servidores num pool de servidores de suporte.

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

As capacidades do Firewall de Aplicações Web (WAF) não funcionam para uso na 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.

Kubernetes permite a criação de deployment e service recursos para expor internamente um grupo de pods 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 Controlador de Entrada do Gateway de Aplicações (AGIC) permite que o Gateway de Aplicação seja usado como entrada para um Azure Kubernetes Service, 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 gerido, o que significa que a Microsoft atualiza automaticamente o complemento para a versão estável mais recente.

Sim, a atualização do cluster AKS de Kubenet ou CNI para CNI Overlay é detetada automaticamente pelo Application Gateway Ingress Controller. Recomenda-se agendar a atualização durante uma janela de manutenção, pois pode ocorrer interrupção do tráfego. O controlador pode levar alguns minutos após a atualização do cluster para detetar e configurar o suporte para a sobreposição de CNI.

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 largura de banda em bytes, o total de solicitações atendidas, a contagem de solicitações com falha e a contagem de instâncias de back-end funcionais e não funcionais.
• 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 Saúde do back-end, registos 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 event hub ou para o Azure Monitor Logs. Para obter mais informações, consulte Application Gateway diagnostics.

No portal, no painel de menu do gateway de aplicação, selecione Registo de Atividades para acessar o registo 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 Azure Monitor Logs, Excel, Power BI, e assim por diante.

Também pode usar um modelo de Resource Manager que instala e executa o popular analisador de registos GoAccess para registos de acesso ao Gateway de Aplicação. 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 mais informações, em GitHub, consulte o ficheiro Readme na pasta de modelos Resource Manager.

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, registo de diagnóstico e métricas do 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 Application Gateway, consulte O que é Gateway de Aplicação do Azure.
• Para saber mais sobre terminação TLS e TLS de ponta a ponta com o Application Gateway, consulte Ative TLS de ponta a ponta em Gateway de Aplicação do Azure.