Perguntas frequentes sobre o Application Gateway

Nota

Recomendamos que utilize o módulo do Azure Az PowerShell para interagir com o Azure. Veja Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.

As perguntas comuns a seguir são feitas sobre o Gateway de Aplicativo do Azure.

Geral

O que é o Gateway de Aplicação?

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.

Quais recursos são compatíveis com o Application Gateway?

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.

Qual é a diferença entre o Application Gateway e o Azure Load Balancer?

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

Quais protocolos são compatíveis com o Application Gateway?

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

Como o Application Gateway suporta HTTP/2?

Consulte Suporte HTTP/2.

Quais recursos são suportados como parte de um pool de back-end?

Consulte Recursos de back-end suportados.

Em que regiões o Application Gateway está disponível?

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.

Essa implantação é dedicada à minha assinatura ou é compartilhada entre os clientes?

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

O Application Gateway suporta redirecionamento HTTP-to-HTTPS?

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

Em que ordem os ouvintes são processados?

Veja a ordem de processamento do ouvinte.

Onde posso encontrar o IP e o DNS do Application Gateway?

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.

Quais são as configurações para o tempo limite do Keep-Alive e o tempo limite ocioso do TCP?

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.

O Keep-Alive tempo limite no SKU do Application Gateway v1 é de 120 segundos e no SKU v2 é de 75 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.

O Application Gateway reutiliza a conexão TCP estabelecida com um servidor back-end?

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

Posso renomear meu recurso do Application Gateway?

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

Existe uma maneira de restaurar um recurso do Application Gateway e seu IP público se ele tiver sido excluído?

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.

O nome IP ou DNS muda ao longo do tempo de vida do gateway de aplicativo?

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.

O Application Gateway suporta IP estático?

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.

O Application Gateway suporta vários IPs públicos no gateway?

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.

Qual deve ser o tamanho da minha sub-rede para o Application Gateway?

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

Posso implantar mais de um recurso do Application Gateway em uma única sub-rede?

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.

O Application Gateway v2 suporta rotas definidas pelo usuário?

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

O Application Gateway suporta cabeçalhos x-forwarded-for?

Quanto tempo leva para implantar uma instância do Application Gateway? Meu gateway de aplicativo funcionará enquanto estiver sendo atualizado?

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.

Como o Application Gateway lida com a manutenção de rotina?

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

Posso usar o Exchange Server como back-end com o Application Gateway?

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

Há orientação disponível para migrar do SKU v1 para o SKU v2?

O Application Gateway v1 SKU é suportado?

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.

O Application Gateway v2 suporta solicitações de proxy com autenticação NTLM ou Kerberos?

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

Por que alguns valores de cabeçalho não estão presentes quando as solicitações são encaminhadas para meu aplicativo?

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

O que é considerado um ouvinte ativo versus um ouvinte inativo?

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.

Desempenho

Como o Application Gateway oferece suporte a alta disponibilidade e escalabilidade?

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.

Como faço para obter um cenário de recuperação de desastres em datacenters usando o Application Gateway?

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

O Application Gateway suporta drenagem de conexão?

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.

O Application Gateway suporta dimensionamento automático?

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.

O aumento ou redução manual ou automático causa tempo de inatividade?

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

Posso mudar de um padrão para um WAF SKU sem interrupção?

Sim.

Posso alterar o tamanho da instância de médio para grande sem interrupção?

Sim.

Configuração

O Application Gateway é sempre implantado em uma rede virtual?

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.

O Application Gateway pode se comunicar com instâncias fora de sua rede virtual ou fora de sua assinatura?

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 é atualizado o endereço IP de um servidor back-end baseado em FQDN?

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.

Por que estou vendo erros 502 ou servidores back-end não íntegros depois que alterei os servidores DNS para a rede virtual?

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.

Posso implantar qualquer outra coisa na sub-rede do Application Gateway?

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

Posso alterar a rede virtual ou a sub-rede de um gateway de aplicativo existente?

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>

Há suporte para grupos de segurança de rede na sub-rede do Application Gateway?

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

A sub-rede do Application Gateway suporta rotas definidas pelo usuário?

Há suporte para políticas de ponto de extremidade de serviço 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.

Quais são os limites do Application Gateway? Posso aumentar estes limites?

Consulte Limites do Application Gateway.

Posso usar simultaneamente o Application Gateway para tráfego externo e interno?

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

O Application Gateway oferece suporte ao emparelhamento de rede virtual?

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

Posso falar com servidores locais quando eles estão conectados por túneis do Azure ExpressRoute ou VPN?

Sim, desde que o tráfego seja permitido.

Um pool de back-end pode servir muitos aplicativos em portas diferentes?

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

As sondas personalizadas suportam curingas ou regex em dados de resposta?

N.º

Como as regras de roteamento são processadas no Application Gateway?

Consulte Ordem das regras de processamento.

Para testes personalizados, o que significa o campo **Host**?

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

Posso permitir o acesso do Application Gateway a apenas alguns endereços IP de origem?

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

Posso usar a mesma porta para ouvintes voltados para o público e para o privado?

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 suporta IPv6?

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.

O Application Gateway suporta FIPS?

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.

Como posso usar o Application Gateway v2 apenas com um endereço IP frontend privado?

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: Configuração NSG do Application Gateway v2 apenas para acesso IP privado

Como posso parar e iniciar o Application Gateway?

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

Configuração: TLS

Quais certificados são suportados pelo Application Gateway?

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.

Quais pacotes de codificação são compatíveis com o Application Gateway?

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.

O Application Gateway suporta a recriptografia do tráfego para o back-end?

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

Posso configurar a política TLS para controlar versões do protocolo TLS?

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.

Posso configurar pacotes de codificação e ordem de políticas?

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.

Quantos certificados TLS/SSL o Application Gateway suporta?

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

O Application Gateway tem suporte para grampeamento OCSP e OCSP?

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

Quantos certificados de autenticação para recriptografia de back-end o Application Gateway suporta?

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

O Application Gateway se integra nativamente ao Azure Key Vault?

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.

Como configuro ouvintes HTTPS para sites .com e .net?

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.

Posso usar caracteres especiais na minha senha de arquivo .pfx?

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

Meu certificado EV é emitido pela DigiCert e meu certificado intermediário foi revogado. Como faço para renovar meu certificado no Application Gateway?

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:

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.

Configuração - Proxy TLS/TCP

A Camada 7 e a Camada 4 do Application Gateway usam os mesmos endereços IP frontend?

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.

Posso usar o proxy TCP ou TLS para tráfego HTTP(S)?

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.

Quais são os nomes de propriedade para proxy de Camada 4?

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.

Property Propósito
ouvinte Para ouvintes baseados em TLS ou TCP
Regra de roteamento Para associar um ouvinte de camada 4 a uma configuração de back-end de camada 4
backendSettingsCollection Para configurações de back-end baseadas em TLS ou TCP

Nota

Não é possível usar nenhuma propriedade de camada 4 para configurações de protocolo HTTP ou HTTPS.

Posso mapear um ouvinte do protocolo TCP/TLS com uma configuração de back-end do protocolo HTTP(S)?

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.

As propriedades L7 e L4 podem ter os mesmos nomes?

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.

Posso adicionar ponto de extremidade privado a um pool de back-end ao usar a Camada 4 (protocolos TCP ou TLS)?

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.

O Application Gateway usa a conexão Keepalive para servidores back-end?

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.

Qual endereço IP o servidor back-end vê quando uma conexão é estabelecida com o Application Gateway?

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.

Como posso definir a política SSL para ouvintes TLS?

A mesma configuração de política SSL é aplicável tanto para a Camada 7 (HTTPS) quanto para a Camada 4 (TLS). Atualmente, não suportamos Perfil SSL (política SSL específica do ouvinte ou Autenticação Mútua) para ouvintes TLS.

O Application Gateway suporta afinidade de sessão para roteamento de Camada 4?

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.

O recurso de dimensionamento automático funciona com proxy de Camada 4?

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

O Web Application Firewall (WAF) é suportado para o tráfego da Camada 4?

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

O proxy de Camada 4 do Application Gateway suporta o protocolo UDP?

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

Configuração - controlador de ingresso para AKS

O que é um controlador de ingresso?

O Kubernetes permite a criação e deploymentservice 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.

Uma única instância do controlador de entrada pode gerenciar vários gateways de aplicativos?

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

Porque é que o meu cluster AKS com kubenet não está a funcionar com o AGIC?

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.

Posso conectar meu cluster AKS e gateway de aplicativo em redes virtuais separadas?

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.

Quais recursos não são suportados no complemento AGIC?

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.

Quando devo usar o complemento versus a implantação do Helm?

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.

Posso controlar qual versão do AGIC é implantada com o complemento?

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.

Configuração: Autenticação mútua

O que é a autenticação mútua?

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.

A autenticação mútua está disponível entre o Application Gateway e seus pools de back-end?

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.

Diagnóstico e registos

Que tipos de logs o Application Gateway fornece?

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.

Como posso saber se os membros da minha piscina de back-end estão saudáveis?

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

Qual é a política de retenção para os logs de diagnóstico?

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.

Como faço para obter logs de auditoria para o Application Gateway?

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

Posso definir alertas com o Application Gateway?

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.

Como analiso as estatísticas de tráfego do Application Gateway?

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.

O que poderia fazer com que a integridade do back-end retornasse um status desconhecido?

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.

Há suporte para logs de fluxo NSG em NSGs associados à sub-rede do Application Gateway v2?

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.

Onde o Application Gateway armazena os dados dos clientes?

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

Próximos passos