Perguntas frequentes sobre o Gateway de Aplicativo

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Confira Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

Veja a seguir as perguntas comuns sobre o Gateway de Aplicativo Azure.

Geral

O que é o Gateway de Aplicativo?

O Gateway de Aplicativo Azure fornece o controlador de entrega de aplicativo (ADC) 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.

Quais recursos o Gateway de Aplicativo suporta?

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 que é a diferença entre o Gateway de Aplicativo e o balanceador de carga do Azure?

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

Quais protocolos o Gateway de Aplicativo suporta?

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

Como o Gateway de aplicativo dá suporte a HTTP/2?

Confira o Suporte do HTTP/2.

Quais recursos têm suporte atualmente como parte do pool de back-end?

Em quais regiões o gateway de aplicativo está disponível?

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 Azure China 21Vianet e no 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

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

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

Como o Gateway de Aplicativo dá suporte ao redirecionamento de HTTP para HTTPS?

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

Em que ordem os ouvintes são processados?

Onde encontro o IP e o DNS do Gateway de Aplicativo?

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 encontrá-lo no portal, na página 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 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.

Quais são as configurações de tempo limite de Keep-Alive e tempo limite de ociosidade de TCP?

O tempo limite de Keep-Alive controla quanto tempo o Gateway de Aplicativo aguardará até que um cliente envie outra solicitação HTTP em uma conexão persistente antes de reusá-lo ou fechá-lo. O tempo limite ocioso de TCP define quanto tempo uma conexão TCP é mantida aberta caso não haja atividade.

O tempo limite de Keep-Alive no SKU do Gateway de Aplicativo v1 é de 120 segundos e na SKU V2 é de 75 segundos. 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 nos Gateways de Aplicativo v1 e V2 em qualquer valor entre 4 minutos e 30 minutos. Para os Gateways de Aplicativo v1 e v2, você precisará navegar até o IP público do Gateway de Aplicativo e alterar o tempo limite ocioso de TCP na folha "Configuração" do IP público no Portal. Não há suporte para a alteração do valor do endereço IP privado. 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.

Posso renomear meu recurso do Gateway de Aplicativo?

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

Há uma forma de restaurar um Gateway de Aplicativo e o IP público dele se ele tiver sido excluído?

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

O nome IP ou DNS muda durante a vida útil do Gateway de Aplicativo?

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, você pode definir o endereço IP como estático, portanto, o nome de IP e DNS não será alterado durante o tempo de vida do gateway de aplicativo.

O Gateway de Aplicativo suporta IP estático?

Sim, o SKU do Gateway de Aplicativo v2 dá suporte a endereços IP públicos estáticos e IP internos estáticos. O v1 SKU suporta IPs internos estáticos.

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

Há suporte apenas para um único endereço IP público em um Gateway de Aplicativo.

Quão grande devo criar minha sub-rede para o Application Gateway?

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

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.

O Gateway de Aplicativo v2 permite rotas definidas pelo usuário (UDR)?

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

O Gateway de aplicativo dá suporte a cabeçalhos x-forwarded-for?

Quanto tempo demora para implantar um Gateway de Aplicativo? O meu Gateway de Aplicativo ainda funciona quando está sendo atualizado?

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, pode levar mais tempo dependendo do tipo de implantação. Por exemplo, as implantações em vários Zonas de Disponibilidade com muitas instâncias podem levar mais de 6 minutos.

Como o gateway de aplicativo lida com a manutenção de rotina?

As atualizações iniciadas no Gateway de Aplicativo são aplicadas a um domínio de atualização por vez, fora do horário comercial da região em que o gateway está implantado. À 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 será executado temporariamente em capacidade máxima reduzida, que é determinada pelo número de instâncias configuradas. O processo de atualização prosseguirá para o próximo conjunto de instâncias somente se o conjunto atual tiver sido atualizado com êxito.

Posso usar o Exchange Server como um back-end com o Gateway de Aplicativo?

O Gateway de Aplicativo não dá suporte a protocolos de email como SMTP, IMAP e POP3. Os serviços HTTP/HTTPS, como OWA, ActiveSync e AutoDiscovery, podem fluir por meio do Gateway de Aplicativo, no entanto, as exclusões de WAF podem ser necessárias se usar o SKU do WAF.

Há orientações disponíveis para migrar da SKU v1 para a SKU v2?

O SKU do Gateway de Aplicativo v1 continuará a ter suporte?

Sim. O SKU do Gateway de Aplicativo v1 continuará a ter suporte. No entanto, é altamente recomendável que você passe 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.

O Gateway de Aplicativo v2 dá suporte a solicitações de proxy com autenticação NTLM?

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

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

Os nomes dos cabeçalhos de solicitação podem conter caracteres alfanuméricos e hifens. Os nomes dos cabeçalhos de solicitação que contiverem outros caracteres serão descartados quando uma solicitação for 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 em RFC 7230, com exceção de sublinhados (_).

Sim, o navegador Chromiumatualização de browserv80 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 ApplicationGatewayAffinity existente. Esses cookies são semelhantes, mas o cookie ApplicationGatewayAffinityCORS tem mais dois atributos adicionados a ele: SameSite=None; 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.

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

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.

Desempenho

Como o Application Gateway suporta alta disponibilidade e escalabilidade?

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.

Como obter o cenário de recuperação de desastres em data centers com o Gateway de Aplicativo?

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

O Gateway de Aplicativo suporta a drenagem de conexão?

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 drenagem de conexão do Gateway de Aplicativo.

Como o Gateway de Aplicativo dá suporte a dimensionamento automático?

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.

O dimensionamento manual ou automático aumenta ou reduz verticalmente a causa do tempo de inatividade?

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

Posso mudar de SKU Standard para WAF 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 está sempre implantado em uma rede virtual?

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 de sua rede virtual ou fora de sua assinatura?

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.

Posso implantar coisa na sub-rede do gateway de aplicativo?

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

Posso alterar a rede virtual ou a sub-rede de um Gateway de Aplicativo existente?

Você só pode mover um Gateway de Aplicativo entre sub-redes na mesma rede virtual. A V1 tem suporte com front-end público e privado, e a V2 tem suporte somente com front-end público. Também é importante observar que, para a execução dessa ação, o Gateway de Aplicativo deve estar em um estado Parado. Tenha em mente que parar/iniciar a V1 alterará o IP público. Essa operação só pode ser realizada 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, 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>

Os grupos de segurança de rede são compatíveis na sub-rede do gateway de aplicativos?

A sub-rede do gateway de aplicativo permite rotas definidas pelo usuário?

As políticas de ponto de extremidade de serviço têm suporte 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.

Quais são os limites no Gateway de Aplicativo? Posso aumentar esses limites?

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

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

O Gateway de Aplicativo dá suporte ao emparelhamento de rede virtual?

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

Posso falar com servidores locais quando eles estão conectados por túneis de rota expressa ou VPN?

Sim, contanto que o tráfego seja permitido.

Posso ter um pool de back-end que atende muitos aplicativos em portas diferentes?

Há suporte para arquitetura de microsserviço. Você precisaria de várias configurações http definidas para investigação em portas diferentes.

Os testes personalizados permitem curingas/expressões regulares nos dados de resposta?

Não.

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

O que significa o campo Host para investigações personalizadas?

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

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

A mesma porta pode ser usada tanto para ouvintes voltados para o público quanto para o privado?

Não.

Como o Gateway de Aplicativo dá suporte a IPv6?

O Gateway de Aplicativo v2 não dá suporte a IPv6 no momento. Ele pode operar em uma VNet de pilha dupla usando somente IPv4, mas a sub-rede de gateway deve ser somente IPv4. O Gateway de Aplicativo v1 não dá suporte a pilha dupla VNets.

Como eu uso o Gateway de Aplicativo V2 com apenas endereço IP de front-end privado?

O Gateway de Aplicativo v2 atualmente não dá suporte apenas ao modo de IP privado. Ele permite as seguintes combinações

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

Mas se você quiser usar o Gateway de Aplicativo v2 somente com o IP privado, você pode seguir o processo abaixo:

  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:

    a. Permita o tráfego da Origem como GatewayManager marca de serviço e destino como Qualquer e 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

    b. Permita o tráfego da Origem como marca de serviço e destino AzureLoadBalancer e porta de destino Qualquer

    c. Permita o tráfego da Origem como marca de serviço e destino Internet e porta de destino e portas de destino como Qualquer. Dê a essa regra menos prioridade nas regras de entrada

    d. Mantenha as regras padrão como permitir a entrada de VirtualNetwork para que o acesso no endereço IP privado não seja bloqueado

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

Exemplo de configuração de NSG para acesso somente IP privado: Configuração de NSG do Gateway de Aplicativo v2 somente para acesso IP privado

Como posso parar e iniciar o Gateway de Aplicativo Azure?

Você pode usar o Azure PowerShell ou a CLI do Azure para interromper e iniciar o Gateway de Aplicativo do Azure. Quando você parar e iniciar o Gateway de Aplicativo, a cobrança também será interrompida e iniciada.

# 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 o Gateway de Aplicativo permite?

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.

Quais conjuntos de codificação o Gateway de Aplicativo permite?

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.

O Gateway de Aplicativo também permite a re-criptografia do tráfego para o back-end?

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

Posso configurar a política TSL para controlar as versões do Protocolo SSL?

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.

Posso configurar conjuntos de criptografia e ordem de política?

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.

Quais certificados TLS/SSL o Gateway de Aplicativo permite?

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

O Gateway de Aplicativo dá suporte para a associação OCSP e OCSP?

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

Quantos certificados de autenticação para re-criptografia de back-end o Gateway de Aplicativo permite?

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

O Gateway de Aplicativo se integra ao Azure Key Vault nativamente?

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.

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

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.

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

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

Meu certificado EV foi emitido pela DigiCert e meu certificado intermediário foi revogado. Como fazer a renovação do meu certificado no Gateway de Aplicativo?

Os membros do navegador da AC (autoridade de certificação) 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 autoridade de certificação não compatíveis podem ser encontrados aqui:

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, os certificados autoassinados ou certificados usados em cenários de BYOC ("Traga Seu Próprio Certificado") ainda estão em 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 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 aplicativo seja interrompida porque certificados são revogados inesperadamente ou para atualizar um certificado que foi revogado, confira nossa postagem de atualizações do Azure para obter links de correção de vários serviços do Azure que dão suporte a BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Para obter informações específicas do Gateway de Aplicativo, consulte abaixo -

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

  1. Certificado inválido/certificado revogado
  2. A conexão atingiu o tempo limite
  3. 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 do Azur/WAF com a cadeia de confiança completa (folha, intermediária, certificado raiz). Com base em onde você está usando seu certificado, no ouvinte ou nas configurações de HTTP do Gateway de Aplicativo, siga as etapas abaixo para atualizar os certificados e verifique os links de documentação mencionados para obter mais informações.
  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 de ouvinte associadas ao seu certificado.
  3. Clique em “Renovar ou editar o certificado selecionado”.
  4. Carregue o novo certificado PFX com a senha e clique em 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 Azure KeyVault no ouvinte do Gateway de Aplicativo, recomendamos as seguintes etapas para uma alteração rápida –

  1. No portal do Azure, navegue até as configurações do Azure Key Vault que foram associadas ao Gateway de Aplicativo.
  2. Adicione/importe o certificado reemitido em seu repositório. Consulte a documentação aqui para obter mais informações sobre como fazer isso.
  3. Depois que o certificado tiver sido importado, navegue até as configurações do ouvinte do Gateway de Aplicativo e, em "Escolher um certificado no Key Vault", clique no menu suspenso "Certificado" e escolha o certificado recentemente adicionado
  4. Clique em 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. Clique em "Adicionar certificado", carregue o certificado reemitido e clique em salvar.
  4. Você pode remover o certificado antigo mais tarde clicando no botão “…” de opções ao lado do certificado antigo. Selecione excluir e clique em 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 de HTTP, já que a SKU V2 usa "certificados raiz confiáveis" e nenhuma ação precisa ser executada aqui.

Configuração - Controlador de Entrada para AKS

O que é um Controlador de Entrada?

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

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

Atualmente, uma instância do Controlador de Entrada só pode ser associada a um gateway de aplicativo.

Por que meu cluster do AKS com kubenet não está funcionando com o AGIC?

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 AGIC não puder associar a tabela de rotas à sub-rede do Gateway de Aplicativo, haverá um erro nos logs de AGIC indicando isso; nesse caso, você terá que 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.

Posso conectar meu cluster do AKS e o Gateway de Aplicativo em redes virtuais separadas?

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 kubenet, certifique-se de associar a tabela de rotas gerada pelo AKS à sub-rede do Gateway de Aplicativo.

Quais funcionalidades não têm suporte no complemento AGIC?

Consulte aquias diferenças entre o AGIC implantado por meio do Helm versus implantado como um complemento do AKS

Quando devo usar o complemento em vez da implantação do Helm?

Consulte as diferenças entre o AGIC implantado por meio do Helm versus implantado como um complemento do AKS aqui, especialmente as tabelas que documentam quais cenários são suportados pelo AGIC implantado por meio de Helm em oposição a um complemento AKS. Em geral, a implantação por meio do Helm permitirá que você teste os recursos beta e libere candidatos antes de uma versão oficial.

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

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

Configuração - autenticação mútua

O que é autenticação mútua?

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.

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

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.

Diagnóstico e registro em log

Que tipos de logs o gateway de aplicativo fornece?

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.

Como sei se meus membros do pool de back-end são saudáveis?

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.

O que é a política de retenção nos logs de diagnóstico?

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.

Como posso obter os logs de auditoria para o Gateway de aplicativo?

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

Configurar alertas com o Gateway de aplicativo?

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.

Como faço para analisar as estatísticas de tráfego do Application Gateway?

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.

O que poderia fazer com que a integridade de back-end retorne um status desconhecido?

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.

Os logs de fluxo NSG são compatíveis com o NSGs associado à sub-rede v2 do Gateway de Aplicativo?

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

Onde o Gateway de Aplicativo armazena dados do cliente?

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