Perguntas frequentes sobre o Gateway de Aplicativo

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

O Gateway de Aplicativo dá suporte para dimensionamento automático, descarregamento de TSL e TSL de ponta a ponta, firewall do aplicativo Web (WAF), afinidade de sessão baseada em cookies, roteamento baseado em caminho de URL, hospedagem em vários sites e outros. Para obter uma lista completa dos recursos com suporte, confira Introdução ao Gateway de Aplicativo.

O Gateway de Aplicativo é 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 oferece suporte a recursos como terminação TSL, a afinidade de sessão baseada em cookie e rodízio para tráfego de balanceamento de carga. O Load Balancer balanceia o tráfego na camada 4 (TCP ou UDP).

O Gateway de Aplicativo fornece suporte HTTP, HTTPS, HTTP/2 e WebSocket.

Confira o Suporte do HTTP/2.

Consulte recursos de back-end com suporte.

O Gateway de Aplicativo v1 (Standard e WAF) está disponível em todas as regiões do Azure global. Ele também está disponível no Microsoft Azure operado pela 21Vianet e pelo Azure Governamental.

Para disponibilidade do Gateway de Aplicativo v2 (Standard_v2 e WAF_v2), consulte regiões com suporte para o Gateway de Aplicativo v2.

O Gateway de Aplicativo é uma implementação dedicada em sua rede virtual.

Há suporte para redirecionamento. Consulte a Visão geral do redirecionamento do Gateway de Aplicativo.

Consulte a ordem de processamento de ouvinte.

Se você estiver usando um endereço IP público como um 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, localize as informações na página Visão geral. Para o 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 a SKU v2, abra o recurso IP público e selecione Configuração. O campo de Rótulo de nome DNS (opcional) está disponível para configurar o nome DNS.

O tempo limite de Keep-Alive rege por quanto tempo o gateway de aplicativo aguarda um cliente enviar outra solicitação HTTP em uma conexão persistente antes de reutilização ou fechamento. O tempo limite ocioso de TCP define quanto tempo uma conexão TCP é mantida aberta caso não haja atividade.

Para conexões HTTP/1.1, o tempo limite de Keep-Alive no SKU do Gateway de Aplicativo v1 e v2 é de 120 segundos. Para endereços IP privados, o valor não é configurável com um tempo limite ocioso TCP de 5 minutos. O tempo limite de ociosidade de TCP é um padrão de 4 minutos no IP virtual de front-end (VIP) do SKU v1 e v2 do Gateway de Aplicativo. Você pode configurar o valor do tempo limite ocioso de TCP nas instâncias do Gateway de Aplicativo v1 e v2 em qualquer valor entre 4 minutos e 30 minutos. Para as instâncias do Gateway de Aplicativo v1 e v2, você precisa acessar 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 do tempo limite ocioso de 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 de front-end no Gateway de Aplicativo SKU v2, o tempo limite ocioso é definido como 180 segundos e não é configurável.

Para evitar conflitos e comportamentos inesperados, verifique se o tempo limite ocioso do TCP está definido como igual ou maior que o tempo limite de keep-alive.

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

Não. Não é possível renomear um recurso do Gateway de Aplicativo. Você precisa criar um recurso com o nome desejado.

Não. Não é possível restaurar um recurso do Gateway de Aplicativo ou seu IP público depois da exclusão. Você deve criar outro recurso.

No SKU do Gateway de Aplicativo v1, o VIP pode ser alterado se você parar e iniciar o gateway de aplicativo. Mas o nome DNS associado ao Gateway de Aplicativo não é alterado ao longo do ciclo de vida do gateway. Como o nome DNS não muda, é recomendado usar um alias do CNAME e apontá-lo para o endereço DNS do Gateway de Aplicativo. No SKU do Gateway de Aplicativo 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 Gateway de Aplicativo v2 dá suporte a endereços IP públicos estáticos e IPs internos estáticos. O v1 SKU suporta IPs internos estáticos.

Há suporte apenas para um único endereço IP público em um Gateway de Aplicativo por protocolo IP. Se o gateway de aplicativo estiver configurado como DualStack, ele poderá dar suporte a dois IPs públicos, um para IPv4 e outro para IPv6.

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

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

Uma única sub-rede não dá suporte a SKUs de Gateway de Aplicativo v2 e v1.

Sim, mas apenas cenários específicos. Confira mais informações em Configuração da infraestrutura do Gateway de Aplicativo.

Sim. Consulte Modificações a uma solicitação.

As novas implantações de SKU do Application Gateway v1 podem levar até 20 minutos para provisionar. Alterações de tamanho/contagem de instâncias não são interrompidas, e o gateway permanece ativo durante esse tempo.

A maioria das implantações que usam a SKU v2 levam cerca de 6 minutos para serem provisionadas. 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 Gateway de Aplicativo são aplicadas a um domínio de atualização por 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 continuarão a atender ao tráfego¹. As conexões ativas são normalmente descarregadas das instâncias que estão sendo atualizadas por até 5 minutos para ajudar a estabelecer a conectividade com instâncias em um domínio de atualização diferente antes do início da atualização. Durante a atualização, o Gateway de Aplicativo é executado temporariamente em capacidade máxima reduzida, que é determinada pelo número de instâncias configuradas. O processo de atualização prossegue ara o próximo conjunto de instâncias somente se o conjunto atual tiver sido atualizado com êxito.

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

O Gateway de Aplicativo dá suporte ao proxy de protocolo TLS/TCP, por meio do proxy de Camada 4 na Versão Prévia.

O proxy de Camada 7 do Gateway de aplicativo com protocolos HTTP(S) não oferecerá suporte a protocolos de email, como SMTP, IMAP e POP3. No entanto, para alguns serviços de email de suporte, como OWA (Acesso via Web do Outlook), ActiveSync e tráfego de Descoberta Automática que usa protocolos HTTP(S), é possível usar o proxy de Camada 7 e o tráfego deve fluir. (Observação: as exclusões nas regras do WAF podem ser necessárias ao usar um SKU do WAF).

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

Sim. O SKU do Gateway de Aplicativo v1 continua com suporte. É altamente recomendável migrar para a v2 para aproveitar as atualizações de recursos nesse SKU. Para obter mais informações sobre as diferenças entre os recursos v1 e v2, consulte Autoscaling e Gateway de Aplicativo com redundância de zona v2. Você pode migrar manualmente implantações de SKU do gateway de aplicativo v1 para v2 seguindo nossodocumento de migração V1-V2.

Não. O Gateway de Aplicativo v2 ainda não dá suporte a solicitações de proxy com autenticação NTLM ou Kerberos.

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

Sim. A atualização v80 do navegador Chromium introduziu uma exigência em cookies HTTP sem que o atributo SameSite seja tratado como SameSite=Lax. Isso significa que o cookie de afinidade do Gateway de Aplicativo não será enviado pelo navegador em um contexto de terceiros.

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

Um ouvinte ativo é um ouvinte associado a uma regra e que envia o tráfego para um pool de back-end. Qualquer ouvinte que apenas redireciona o tráfego não é um ouvinte ativo. Os ouvintes associados às regras de redirecionamento não são considerados ativos. Se a regra de redirecionamento for baseada em caminho, todos os caminhos na regra de redirecionamento deverão redirecionar o tráfego, ou o ouvinte será considerado ativo. Confira Assinatura do Azure e limites de serviço, cotas e restrições para conhecer os detalhes sobre o limite dos componentes individuais.

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

A SKU v2 garante automaticamente que novas instâncias sejam distribuídas entre domínios de falha e domínios de atualização. Se a redundância de zona for escolhida, as instâncias mais recentes também serão distribuídas entre as zonas de disponibilidade para oferecer resiliência zonal em caso de falha.

Use o Gerenciador de Tráfego do Azure para distribuir o tráfego entre vários Gateways de Aplicativo em data centers diferentes.

Sim. Você pode configurar o descarregamento de conexão para alterar os membros dentro de um pool de back-end sem interrupções. Para obter mais informações, confira a seção Esvaziamento de conexões do Gateway de Aplicativo.

Sim, o SKU Application Gateway v2 suporta escalonamento automático. Para obter mais informações, confira Dimensionamento automático e o Gateway de Aplicativo com redundância de zona.

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

Sim.

Sim.

Sim. O Gateway de Aplicativo é sempre implantado em uma sub-rede de rede virtual. Essa sub-rede só pode conter Gateways de Aplicativos. Para saber mais, confira Exigências de rede virtual e requisitos de sub-rede.

O Gateway de Aplicativo pode se comunicar com instâncias fora da rede virtual em que está, desde que exista conectividade de IP. O Gateway de Aplicativo também pode se comunicar com instâncias fora da assinatura em que ele está. Se você planeja usar IPs internos como membros de pool de back-end, será necessário usar o emparelhamento de rede virtual ou o Gateway de VPN da Azure.

Como qualquer resolvedor DNS, o recurso do Gateway de Aplicativo respeita o valor de TTL (Vida Útil) do registro DNS do servidor de 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 ao obter uma resposta (ou nenhum registro DNS for encontrado), o gateway continuará usando o último valor DNS válido para atender ao tráfego. Para obter mais informações, consulte Como funciona o 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 podem falhar.

Não. Mas você pode implantar outros gateways de aplicativo na sub-rede.

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

PowerShell do Azure

$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, confira 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 Gateway de Aplicativo.

Consulte As rotas definidas pelo usuário são permitidas na sub-rede do Gateway de Aplicativo?.

Não. As políticas de ponto de extremidade de serviço para contas de armazenamento não têm suporte na sub-rede do Gateway de Aplicativo e configurá-las bloqueará o tráfego de infraestrutura do Azure.

Confira os Limites do Gateway de Aplicativo.

Sim. O Gateway de Aplicativo dá suporte a um endereço IP interno e a um IP externo por Gateway de Aplicativo.

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

Sim, contanto que o tráfego seja permitido.

Há suporte para arquitetura de microsserviço. Para investigar portas diferentes, você precisa definir várias configurações de back-end.

Não.

Consulte a Ordem das regras de processamento.

O campo Host especifica o nome para o qual enviar a investigação quando você configurou vários sites no Gateway de Aplicativo. Caso contrário, use 127.0.0.1. Este valor é diferente do nome do host de máquina virtual. Seu formato é <protocolo>://<host>:<porta><caminho>.

Sim. Confira Restringir o acesso a intervalos de IP específicos.

Sim, você pode usar ouvintes voltados para o público e privado com o mesmo número de porta para dar suporte simultaneamente 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 Gateway de Aplicativo v2 dá suporte a front-ends IPv4 e IPv6. Atualmente, o suporte ao IPv6 está disponível apenas para novos gateways de aplicativo. Para dar suporte ao IPv6, a rede virtual deve ser uma pilha dupla. O Gateway de Aplicativo v1 não dá suporte a redes virtuais de pilha dupla.

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

Observação: Como parte da conformidade do FedRAMP, o governo dos EUA determina que os sistemas operem em um modo aprovado pelo FIPS após agosto de 2024.

Etapas para habilitar 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:

• Acesse o portal do Azure e pesquise por Versão prévia dos recursos.
• Digite AllowApplicationGatewayEnableFIPS na caixa de filtro. Selecione Gateway de Aplicativo V1 Permitir Modo FIPS e, em seguida, selecione Registrar.

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 de conjuntos de criptografia em gateways V1. No entanto, ao usar a criptografia de curva elíptica para criptografias, 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 curve25519 fica indisponível no modo FIPS, verifique se seus clientes dão suporte a NistP256 ou NistP384 para comunicação segura antes de habilitar o FIPS.

Atualmente, o Gateway de Aplicativo v2 dá suporte à configuração de front-end ip privado (sem IP público) por meio de versão prévia pública. Para obter mais informações, confira Implantação do Gateway de Aplicativo Privado (versão prévia).

Para o suporte de disponibilidade geral atual, o Gateway de Aplicativo v2 dá suporte às seguintes combinações:

• IP privado e IP público
• Somente IP público

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

1. Criar um gateway de aplicativo com o endereço IP de front-end público e privado.

2. Não crie nenhum ouvinte para o endereço IP de front-end público. O Gateway de Aplicativo não escutará 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 Gateway de Aplicativo com a seguinte configuração na ordem de prioridade:

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

   2. Permitir o tráfego da Origem como a marca de serviço AzureLoadBalancer e a Porta de destino como Qualquer.

   3. Negar todo o tráfego de entrada da Origem como a marca de serviço Internet e a Porta de destino como Qualquer. Dê a essa regra menos 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 internet de saída não pode ser bloqueada. Caso contrário, você enfrenta problemas com registro em log e métricas.

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

Você pode usar o Azure PowerShell ou a CLI do Azure para interromper e iniciar o Gateway de Aplicativo. Quando você parar e iniciar o Gateway de Aplicativo, a cobrança também será interrompida e iniciada. Qualquer operação PUT feita em um gateway de aplicativo parado (como adicionar marca, investigação de integridade ou ouvinte) dispara uma inicialização. Recomendamos que você interrompa 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 Gateway de Aplicativo dá suporte a certificados autoassinados, certificados de AC (autoridade de certificação), certificados EV (Validação Estendida), certificados de vários domínios (SAN) e certificados curinga.

O Gateway de Aplicativo dá suporte aos seguintes conjuntos 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 mais informações sobre como personalizar opções de TLS, confira Configurar versões de política SSL e conjuntos de codificação no Gateway de Aplicativo.

Sim. O Gateway de Aplicativo oferece suporte ao descarregamento TSL, TSL de ponta a ponta, que criptografa novamente o tráfego para o back-end.

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

Sim. No Gateway de Aplicativo, você pode configurar conjuntos de codificação. Ao definir uma política personalizada, pelo menos um dos seguintes pacotes de codificação deve ser habilitado:

• 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 Gateway de Aplicativo usa SHA256 para gerenciamento de back-end.

O Gateway de Aplicativo permite até 100 certificados TLS/SSL.

Sim, o Gateway de Aplicativo dá suporte a certificados com extensões OCSP e associação de OCSP para certificados de servidor.

O Gateway de Aplicativo permite até 100 certificados TLS/SSL.

Sim, o SKU de Gateway de Aplicativo v2 permite Key Vault. Para obter mais informações, confira Encerramento de TLS com certificados do Key Vault.

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

Não. Use apenas caracteres alfanuméricos em sua senha de arquivo. pfx.

Os membros do AC/Navegador publicaram recentemente relatórios que detalham vários certificados emitidos por fornecedores de autoridade de certificação que são usados por nossos clientes, pela Microsoft e pela maior comunidade de tecnologia que estavam fora de conformidade com os padrões do setor para autoridades de certificação publicamente confiáveis. Os relatórios sobre as ACs não compatíveis podem ser encontrados aqui:

• Bug 1649951
• Bug 1650910

De acordo com os requisitos de conformidade do setor, os fornecedores de AC começaram a revogar ACs não compatíveis e a emitir ACs em conformidade, 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 ou certificados auto-emitidos usados em cenários BYOC (Traga Seu Próprio Certificado) 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 Rastreador de Revogação de Certificado. Se os certificados tiverem sido 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 aplicativo seja interrompida devido à revogação inesperada de certificados ou à atualização de um certificado revogado, consulte a 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 Gateway de Aplicativo:

Se você estiver usando um certificado emitido por uma das ICAs revogadas, a disponibilidade do aplicativo poderá ser interrompida. Dependendo do aplicativo, você pode receber várias mensagens de erro, incluindo, mas não se limitando a:

• Certificado inválido/certificado revogado
• A conexão atingiu o tempo limite
• HTTP 502

Para evitar qualquer interrupção em seu aplicativo devido a esse problema, ou para emitir novamente uma AC que foi revogada, você precisa executar as seguintes ações:

1. Entre em contato com seu provedor de certificados para emitir novamente seus certificados.
2. Depois de reemitido, atualize seus certificados no Gateway de Aplicativo/WAF com a cadeia de confiança completa (folha, intermediária, certificado raiz). Com base no local em que você está usando seu certificado, no ouvinte ou nas configurações HTTP do gateway de aplicativo, siga as etapas aqui para atualizar os certificados. Para obter mais informações, verifique os links de documentação mencionados.
3. Atualize seus servidores de aplicativos de back-end para usar o certificado reemitido. Dependendo do servidor de 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 seu recurso no Gateway de Aplicativo.
2. Abra as configurações do ouvinte associadas ao seu certificado.
3. Selecione Renovar ou editar certificado selecionado.
4. Carregue o novo certificado PFX com a senha e selecione Salvar.
5. Acesse o site e verifique se está funcionando como deveria. Para obter mais informações, confira Renovar certificados do Gateway de Aplicativo.

Se você estiver fazendo referência a certificados do KeyVault no ouvinte do Gateway de Aplicativo, recomendamos as seguintes etapas para uma alteração rápida:

1. No portal do Azure, vá para as configurações do Key Vault associadas ao gateway de aplicativo.
2. Adicione/importe o certificado reemitido em seu repositório. Para obter mais informações, consulte Início Rápido: criar um cofre de chaves usando o portal do Azure.
3. Depois que o certificado tiver sido importado, vá até as configurações do ouvinte do Gateway de Aplicativo e, em Escolher um certificado no Key Vault, selecione o menu suspenso Certificado e escolha o certificado recentemente adicionado.
4. Selecione Salvar. Para obter mais informações sobre a terminação TLS no Gateway de Aplicativo com certificados do Key Vault, confira Terminação TLS com certificados do Key Vault.

Para atualizar o certificado nas suas Configurações de HTTP:

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

1. No portal do Azure, abra o seu recurso no Gateway de Aplicativo.
2. Abra as configurações de HTTP associadas ao seu certificado.
3. Selecione Adicionar certificado, carregue o certificado relançado 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, confira Como configurar o TLS de ponta a ponta usando o Gateway de Aplicativo com o portal.

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

Sim. O roteamento da Camada 7 e da Camada 4 por meio do gateway de aplicativo usa a mesma configuração do IP de front-end. 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 e portas de ouvinte configurados.

Embora o tráfego HTTP(S) também possa ser atendido através de protocolos proxy L4, isso não é recomendado. A solução de proxy L7 do Gateway de Aplicativo oferece maior controle e segurança sobre os protocolos HTTP(S) por meio de recursos avançados como Reescritas, Afinidade de sessão, Redirecionamento, WebSockets, WAF e muito mais.

As propriedades de recursos para recursos da Camada 4 são diferentes das da Camada 7. Da mesma forma, ao usar a API REST ou a CLI, você deve usar as propriedades a seguir.

• REST API
• CLI

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

Você não pode usar o mesmo nome para L7 (httpListeners) e L4 (ouvintes). Isso também se aplica a outras propriedades L4, como backendSettingsCollection e routingRules.

Com certeza. Semelhante ao proxy da 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 do ouvinte de front-end, o Gateway de Aplicativo inicia uma nova conexão de back-end para atender a essa solicitação.

O servidor de back-end vê o endereço IP do gateway de aplicativo. Atualmente, não oferecemos suporte “à preservação de IP do cliente” por meio da qual o aplicativo de back-end pode tomar conhecimento 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 do TLS. No entanto, atualmente, um perfil SSL pode ser associado a um ouvinte TLS apenas por meio da CLI, do PowerShell ou da API REST.

Não. No momento, não há suporte para roteamento de um cliente para o mesmo servidor de back-end. 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 protocolo TLS ou TCP.

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

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

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

No momento, não há suporte para o uso de uma porta comum para ouvintes TLS/TCP.

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

O AGIC (Controlador de entrada do Gateway de Aplicativo) permite usar o Gateway de Aplicativo do Azure como a entrada para um Serviço de Kubernetes do Azure, conhecido como cluster do AKS.

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

Se houver a necessidade de alterar as configurações no Gateway de Aplicativo, faça a alteração usando a configuração exposta no controlador de entrada ou em outros objetos do Kubernetes, como usando anotações com suporte. Depois que um Gateway de Aplicativo é vinculado ao Controlador de Entrada do Gateway de Aplicativo (AGIC), quase toda a configuração desse gateway será sincronizada e controlada pelo controlador de entrada. Se você estiver tentando configurar diretamente o Gateway de Aplicativo de maneira imperativa 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 de tabela de rotas à sub-rede do Gateway de Aplicativo, mas pode falhar ao fazer isso devido à falta de permissões do AGIC. Se o AGIC não puder associar a tabela de rotas à sub-rede do Gateway de Aplicativo, um erro será exibido nos logs do AGIC. Nesse caso, você precisa associar manualmente a tabela de rotas criada pelo cluster do AKS à sub-rede do Gateway de Aplicativo. Para saber mais, consulte Rotas definidas pelo usuário compatíveis.

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

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

Para obter 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 por meio do Helm permite que você teste os recursos beta e libere candidatos antes de uma versão oficial.

Não. 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. A autenticação mútua com o Gateway de Aplicativo permite atualmente 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 Gateway de Aplicativo agora também pode autenticar o cliente, ele se torna a autenticação mútua onde o Gateway de Aplicativo e o cliente estão autenticando mutuamente um ao outro.

Não, a autenticação mútua no momento ocorre apenas entre o cliente de front-end e o Gateway de Aplicativo. Não há suporte atualmente para a autenticação mútua de back-end.

O gateway de aplicativo 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, a URL solicitada, latência da resposta, o código de retorno, bytes de entrada e saída. Esse log contém um registro por instância do 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, total de solicitações atendidas, contagem de solicitações com falha e contagem de instâncias de back-end íntegras e não íntegras.
• ApplicationGatewayFirewallLog: Para gateways de aplicativo que você configura com o WAF, o log do firewall contém solicitações que são registradas por meio do modo de detecção ou do modo de prevenção.

O log de acesso é coletado a cada 60 segundos. Confira Integridade do back-end, registro em log de diagnóstico e métricas do Gateway de Aplicativo para saber mais.

Verifique a integridade usando o cmdlet do PowerShell Get-AzApplicationGatewayBackendHealth ou o Portal. Para obter mais informações, consulte Diagnósticos do Gateway de Aplicativo.

Logs de diagnóstico se encaminham para a conta de armazenamento do cliente. Os clientes podem definir a política de retenção com base em sua preferência. Os logs de diagnóstico também podem ser enviados para o Hub de Eventos ou os logs do Azure Monitor. Para obter mais informações, consulte Diagnósticos do Gateway de Aplicativo.

No portal, clique em Log de Atividades no painel do menu de um Gateway de Aplicativo para acessar o log de auditoria.

Sim. No Gateway de aplicativo, os alertas são configurados nas métricas. Para obter mais informações, consulte métricas do gateway de aplicativo e receber notificações de alerta.

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

Usamos um modelo do Resource Manager que instala e executa o popular analisador de logs GoAccess para logs de acesso do Gateway de Aplicativo. O GoAccess fornece valiosas estatísticas de tráfego HTTP, tais como visitantes exclusivos, arquivos solicitados, hosts, sistemas operacionais, navegadores, códigos de status HTTP e muito mais. Para obter mais detalhes, consulte o arquivo Leiame na pasta de modelo do Resource Manager no GitHub.

Normalmente, você vê um status desconhecido quando o acesso ao back-end é bloqueado por um NSG (grupo de segurança de rede), DNS personalizado ou UDR (roteamento definido pelo usuário) na sub-rede do Gateway de Aplicativo. Confira Integridade do back-end, registro em log de diagnóstico e métricas do Gateway de Aplicativo para saber mais.

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

O Gateway de Aplicativo não move nem armazena dados do cliente fora da região em que ele está implantado.

Próximas etapas

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