Perguntas frequentes sobre Gateway de Aplicação

Nota

Recomendamos que utilize o módulo Azure Az PowerShell para interagir com o Azure. Consulte a instalaçã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.

Seguem-se perguntas comuns sobre Gateway de Aplicação do Azure.

Geral

O que é o Gateway de Aplicação?

Gateway de Aplicação do Azure fornece um controlador de entrega de aplicações (ADC) como um serviço. Oferece várias capacidades de equilíbrio de carga de camada 7 para as suas aplicações. Este serviço é altamente disponível, escalável e totalmente gerido pela Azure.

Quais as funcionalidades que Gateway de Aplicação suporta?

Gateway de Aplicação suporta autoscaling, descarregamento de TLS e TLS de ponta a ponta, uma firewall de aplicação web (WAF), afinidade de sessão baseada em cookies, encaminhamento baseado em caminhos de URL, hospedagem multissíope, e outras funcionalidades. Para obter uma lista completa de funcionalidades suportadas, consulte Introdução a Gateway de Aplicação.

Em que diferem Gateway de Aplicação e Balanceador de Carga do Azure?

Gateway de Aplicação é um equilibrador de carga de camada 7, o que significa que funciona apenas com tráfego web (HTTP, HTTPS, WebSocket e HTTP/2). Suporta capacidades como rescisão de TLS, afinidade da sessão baseada em cookies e robin redondo para o tráfego de equilíbrio de carga. Balanceador de Carga o tráfego de equilíbrios de carga na camada 4 (TCP ou UDP).

Que protocolos Gateway de Aplicação suporta?

Gateway de Aplicação suporta HTTP, HTTPS, HTTP/2 e WebSocket.

Como suporta Gateway de Aplicação HTTP/2?

Consulte o suporte HTTP/2.

Que recursos são suportados como parte de uma piscina de backend?

Em que regiões está Gateway de Aplicação disponível?

Gateway de Aplicação v1 (Standard e WAF) está disponível em todas as regiões do Azure global. Também está disponível no Azure China 21Vianet e Azure Government.

Para Gateway de Aplicação disponibilidade de v2 (Standard_v2 e WAF_v2), consulte regiões apoiadas para Gateway de Aplicação v2

Esta implementação é dedicada à minha subscrição, ou é partilhada entre os clientes?

Gateway de Aplicação é uma implementação dedicada na sua rede virtual.

A Gateway de Aplicação suporta a reorientação HTTP-to-HTTPS?

A reorientação é suportada. Consulte Gateway de Aplicação redirecionar a visão geral.

Em que ordem são processados os ouvintes?

Onde encontro o Gateway de Aplicação IP e DNS?

Se estiver a utilizar um endereço IP público como ponto final, encontrará as informações sobre IP e DNS no recurso de endereço IP público. Ou encontrá-lo no portal, na página geral para o gateway de aplicações. Se estiver a utilizar endereços IP internos, encontre as informações na página geral.

Para o v2 SKU, abra o recurso IP público e selecione Configuração. O campo de marca DENS (opcional) está disponível para configurar o nome DNS.

Quais são as definições para Keep-Alive tempo limite e tempo de inatividade da TCP?

O tempo limite keep-alive rege o tempo que o Gateway de Aplicação esperará que um cliente envie outro pedido HTTP sobre uma ligação persistente antes de o reutilizar ou fechar. O tempo limite de marcha lenta TCP regula o tempo de duração da ligação TCP se não houver atividade.

O tempo limite Keep-Alive no Gateway de Aplicação v1 SKU é de 120 segundos e no V2 SKU são 75 segundos. O tempo limite de marcha lenta (TCP) é um padrão de 4 minutos no IP virtual frontal (VIP) de v1 e v2 SKU de Gateway de Aplicação. Pode configurar o valor de tempo de inatividade da TCP em V1 e V2 Application Gateways para estar entre 4 minutos e 30 minutos. Para os gateways de aplicação V1 e V2, terá de navegar para o IP público do Gateway de Aplicação e alterar o tempo limite de marcha lenta por inatividade da TCP sob a lâmina "Configuração" do IP público no Portal. Alterar o valor do endereço IP privado não é suportado. Pode definir o valor de tempo limite de marcha lenta do ip público através do PowerShell executando os seguintes comandos:

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

Para ligações HTTP/2 ao endereço IP frontend no Gateway de Aplicação v2 SKU, o tempo limite de marcha lenta está definido para 180 segundos e não é configurável.

Posso mudar o nome do meu recurso Gateway de Aplicação?

Não. Não há como mudar o nome de um recurso Gateway de Aplicação. Deve criar um novo recurso com um nome diferente.

Existe uma forma de restabelecer uma Gateway de Aplicação e o seu PI público se tiver sido eliminado?

N.º Não há como restaurar um recurso Gateway de Aplicação ou o seu IP público uma vez eliminado. Tens de criar um novo recurso.

O nome IP ou DNS muda ao longo do tempo de vida do gateway de aplicações?

Em Gateway de Aplicação V1 SKU, o VIP pode mudar se parar e iniciar o gateway de aplicações. Mas o nome DNS associado ao gateway de aplicações não muda ao longo da vida do portal. Como o nome DNS não muda, deve usar um pseudónimo CNAME e apontá-lo para o endereço DNS do gateway de aplicações. Em Gateway de Aplicação V2 SKU, pode definir o endereço IP como estático, para que o nome IP e DNS não se altere ao longo do tempo de vida útil do gateway de aplicações.

O Gateway de Aplicação suporta IP estático?

Sim, o Gateway de Aplicação v2 SKU suporta endereços IP públicos estáticos e IP internos estáticos. O V1 SKU suporta iPs internos estáticos.

A Gateway de Aplicação suporta vários IPs públicos no portal?

Uma porta de aplicação suporta apenas um endereço IP público.

Qual o tamanho que devo fazer para Gateway de Aplicação?

Posso implantar mais de um Gateway de Aplicação recurso para uma única sub-rede?

Sim. Além de múltiplas instâncias de uma determinada Gateway de Aplicação implantação, você pode providenciar outro recurso Gateway de Aplicação único a uma sub-rede existente que contém um recurso Gateway de Aplicação diferente.

Uma única sub-rede não suporta tanto v2 como v1 Gateway de Aplicação SKUs.

A Gateway de Aplicação v2 suporta rotas definidas pelo utilizador (UDR)?

Sim, mas apenas cenários específicos. Para mais informações, consulte Gateway de Aplicação configuração da infraestrutura.

O Gateway de Aplicação suporta cabeçalhos x-forward-for?

Sim. Consulte alterações a um pedido.

Quanto tempo demora a implantar uma porta de aplicação? O meu portal de aplicações funcionará enquanto está a ser atualizado?

As novas Gateway de Aplicação v1 SKU podem demorar até 20 minutos a ser disponibilizada. As alterações ao tamanho ou contagem de casos não são disruptivas, e o gateway permanece ativo durante este tempo.

A maioria das implementações que utilizam o V2 SKU demoram cerca de 6 minutos a providenciar. No entanto, pode demorar mais tempo dependendo do tipo de implantação. Por exemplo, as implementações em vários Zonas de Disponibilidade com muitas instâncias podem demorar mais de 6 minutos.

Como é que o gateway de aplicação lida com a manutenção de rotina?

Atualizações iniciados para Gateway de Aplicação são aplicados um domínio de atualização de cada vez, durante o horário de trabalho para a região em que o gateway é implantado. À medida que os casos de cada domínio de atualização estão a ser atualizados, as restantes instâncias noutros domínios de atualização continuarão a servir o tráfego. As ligações ativas são drenadas graciosamente das instâncias que estão a ser atualizadas até 5 minutos para ajudar a estabelecer conectividade com casos num domínio de atualização diferente antes do início da atualização. Durante a atualização, Gateway de Aplicação funcionará temporariamente a uma capacidade máxima reduzida, o que é determinado pelo número de casos configurados. O processo de atualização só irá proceder ao próximo conjunto de instâncias se o conjunto atual de instâncias tiver sido atualizado com sucesso.

Posso usá Exchange Server como apoio com Gateway de Aplicação?

Gateway de Aplicação não suporta protocolos de e-mail como SMTP, IMAP e POP3. Serviços HTTP/HTTPS como OWA, ActiveSync e AutoDiscovery podem fluir através de Gateway de Aplicação, no entanto podem ser necessárias exclusões waf se utilizar o sku WAF.

Existe orientação disponível para migrar do V1 SKU para o V2 SKU?

Será que o Gateway de Aplicação v1 SKU continuará a ser apoiado?

Sim. O Gateway de Aplicação v1 SKU continuará a ser apoiado. No entanto, é fortemente recomendado passar para v2 para tirar partido das atualizações de funcionalidades nesse SKU. Para obter mais informações sobre as diferenças entre as características V1 e V2, consulte Autoscaling e zone-redundante Gateway de Aplicação v2. Pode migrar manualmente Gateway de Aplicação v1 sku para v2 seguindo o nosso documento de migração v1-v2.

A Gateway de Aplicação V2 suporta pedidos de procuração com autenticação NTLM?

Não. Gateway de Aplicação V2 não suporta pedidos de procuração com autenticação NTLM.

Porque é que alguns valores de cabeçalho não estão presentes quando os pedidos são reencaminhados para o meu pedido?

Os nomes dos cabeçalhos de pedido podem conter caracteres alfanuméricos e hífenes. Os nomes dos cabeçalhos que contenham outros caracteres serão descartados quando um pedido for enviado para o alvo de backend. Os nomes dos cabeçalhos de resposta podem conter quaisquer caracteres alfanuméricos e símbolos específicos, tal como definidos no RFC 7230, com exceção dos sublinhados (_).

Sim, a atualização v80 donavegador Chromium introduziu um mandato em cookies HTTP sem atributo SameSite para ser tratado como SameSite=Lax. Isto significa que o cookie de afinidade Gateway de Aplicação não será enviado pelo navegador num contexto de terceiros.

Para suportar este cenário, Gateway de Aplicação injeta outro cookie chamado ApplicationGatewayAffinityCORS, além do cookie applicationGatewayAffinity existente. Estes cookies são semelhantes, mas o cookie ApplicationGatewayAffinityCORS tem mais dois atributos adicionados: SameSite=Nenhum; Está seguro. Estes atributos mantêm sessões pegajosas mesmo para pedidos de origem cruzada. Consulte a secção de afinidade baseada em cookies para mais informações.

O que é considerado um ouvinte ativo contra ouvinte inativo?

Um ouvinte ativo é um ouvinte que está associado a uma regra e envia tráfego para uma piscina de backend. Qualquer ouvinte que redirecione apenas 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 uma regra baseada em caminhos, então todos os caminhos dessa regra de redirecionamento devem ser redirecionando o tráfego, caso contrário o ouvinte é considerado ativo. Consulte os limites de subscrição e serviço da Azure, quotas e restrições para detalhes de limites de componentes individuais.

Desempenho

Como é que Gateway de Aplicação suporta alta disponibilidade e escalabilidade?

O Gateway de Aplicação v1 SKU suporta cenários de alta disponibilidade quando se implanta dois ou mais casos. O Azure distribui estas instâncias por domínios de atualização e falhas para garantir que as instâncias não falham todas ao mesmo tempo. O V1 SKU suporta a escalabilidade adicionando múltiplas instâncias da mesma porta de entrada para partilhar a carga.

O V2 SKU garante automaticamente que novas instâncias são espalhadas por domínios de falhas e domínios de atualização. Se optar pela redundância da zona, as instâncias mais recentes também são distribuídas por zonas de disponibilidade para oferecer resiliência de falha zonal.

Como devo proceder para alcançar um cenário dr através dos datacenters usando Gateway de Aplicação?

Utilize o Traffic Manager para distribuir tráfego por vários gateways de aplicações em diferentes datacenters.

A Gateway de Aplicação suporta a drenagem da ligação?

Sim. Pode configurar a drenagem de ligação para alterar os membros dentro de uma piscina de backend sem interrupções. Para mais informações, consulte a secção de drenagem de ligação de Gateway de Aplicação.

A Gateway de Aplicação suporta a autoscalagem?

Sim, o Gateway de Aplicação v2 SKU suporta autoscaling. Para obter mais informações, consulte Autoscaling e Gateway de Aplicação redundante de zona.

A escala manual ou automática para cima ou para baixo causa tempo de inatividade?

N.º As instâncias são distribuídas por domínios de upgrade e domínios de falhas.

Posso mudar de Standard para WAF sku sem interrupções?

Sim.

Posso mudar o tamanho da instância de médio para grande sem perturbações?

Sim.

Configuração

O Gateway de Aplicação está sempre implantado numa rede virtual?

Sim. Gateway de Aplicação é sempre implantado numa sub-rede de rede virtual. Esta sub-rede pode conter apenas portais de aplicação. Para mais informações, consulte os requisitos de rede virtual e sub-rede.

Pode Gateway de Aplicação comunicar com casos fora da sua rede virtual ou fora da sua subscrição?

Desde que tenha conectividade IP, Gateway de Aplicação podem comunicar com casos fora da rede virtual em que está. Gateway de Aplicação também podem comunicar com casos fora da subscrição em que está. Se planeia utilizar os IPs internos como membros do pool backend, utilize o espreitamento de rede virtual ou o Azure Gateway de VPN.

Posso colocar mais alguma coisa na sub-rede de gateway de aplicação?

N.º Mas pode implementar outros gateways de aplicações na sub-rede.

Posso alterar a rede virtual ou a sub-rede para uma Gateway de Aplicação existente?

Pode mover uma Gateway de Aplicação através de sub-redes apenas dentro da mesma rede virtual. É suportado com V1 com frontend público e privado, e V2 apenas com frontend público. É igualmente importante notar que o Gateway de Aplicação deve estar num estado parado para realizar esta ação. Tenha em mente que parar/iniciar o V1 irá alterar o IP público. Esta operação só pode ser feita utilizando Azure PowerShell e Azure CLI 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>

Os grupos de segurança da rede são suportados na sub-rede de gateway de aplicação?

A sub-rede do gateway de aplicação suporta rotas definidas pelo utilizador?

As políticas de ponto final de serviço são apoiadas na sub-rede Gateway de Aplicação?

N.º As políticas de ponto final de serviço para contas de armazenamento não são suportadas na sub-rede Gateway de Aplicação e configurar-se-á para bloquear o tráfego de infraestruturas Azure.

Quais são os limites Gateway de Aplicação? Posso aumentar estes limites?

Posso simultaneamente utilizar Gateway de Aplicação para o tráfego externo e interno?

Sim. Gateway de Aplicação suporta um IP interno e um IP externo por gateway de aplicação.

A Gateway de Aplicação suporta o espreitamento da rede virtual?

Sim. O espreitamento de rede virtual ajuda o tráfego de equilíbrio de carga em outras redes virtuais.

Posso falar com servidores no local quando estiverem ligados por túneis ExpressRoute ou VPN?

Sim, desde que o tráfego seja permitido.

Uma piscina de backend pode servir muitas aplicações em diferentes portas?

A arquitetura do microserviço é suportada. Para sondar diferentes portas, é necessário configurar várias definições HTTP.

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

Não.

Como são processadas as regras de encaminhamento em Gateway de Aplicação?

Para sondas personalizadas, o que significa o campo Host?

O campo Host especifica o nome para enviar a sonda para quando configurar vários local no Gateway de Aplicação. Caso contrário, utilize '127.0.0.1'. Este valor é diferente do nome do anfitrião da máquina virtual. O seu formato é <protocol>://<host>:<port><path>.

Posso permitir Gateway de Aplicação acesso a apenas alguns endereços IP de origem?

Posso usar o mesmo porto para os ouvintes virados para o público e para os privados?

Não.

O Gateway de Aplicação suporta o IPv6?

Gateway de Aplicação v2 não suporta atualmente o IPv6. Pode funcionar numa VNet de dupla pilha usando apenas IPv4, mas a sub-rede gateway deve ser apenas IPv4. Gateway de Aplicação v1 não suporta VNets de pilha dupla.

Como devo proceder para utilizar Gateway de Aplicação V2 com apenas endereço IP frontend privado?

Gateway de Aplicação V2 atualmente não suporta apenas o modo IP privado. Suporta as seguintes combinações

  • IP privado e IP Público
  • APENAS IP público

Mas se quiser usar Gateway de Aplicação V2 apenas com IP privado, pode seguir o processo abaixo:

  1. Criar um Gateway de Aplicação com endereço IP de frontend público e privado

  2. Não crie nenhum ouvinte para o endereço IP do frontend público. Gateway de Aplicação não ouvirá nenhum tráfego no endereço IP público se não forem criados ouvintes para o mesmo.

  3. Criar e anexar um Grupo de Segurança de Rede para a sub-rede Gateway de Aplicação com a seguinte configuração na ordem de prioridade:

    a. Permitir o tráfego a partir da Source como etiqueta de serviço GatewayManager e destino como porta Qualquer e Destino como 65200-65535. Este intervalo de portas é necessário para a comunicação da infraestrutura do Azure. Estas portas estão protegidas (bloqueadas) por autenticação de certificados. Entidades externas, incluindo os administradores de utilizadores gateway, não podem iniciar alterações nesses pontos finais sem certificados adequados em vigor

    b. Permitir tráfego a partir de Source como AzureLoadBalancer tag e porto de destino como Qualquer

    c. Negue todo o tráfego de entrada da Source como etiqueta de serviço de Internet e porto de destino como Qualquer. Dê a esta regra a menor prioridade nas regras de entrada

    d. Mantenha as regras padrão como permitir a entrada da 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, enfrentará problemas com a exploração madeireira, métricas, etc.

Configuração NSG de amostra apenas para acesso ip privado: Gateway de Aplicação Configuração V2 NSG apenas para acesso IP privado

Como posso parar e começar Gateway de Aplicação do Azure?

Pode utilizar Azure PowerShell ou o CLI Azure para parar e começar Gateway de Aplicação do Azure. Quando paras e começas Gateway de Aplicação, a faturação também para e começa.

# 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

Que certificados Gateway de Aplicação suporta?

Gateway de Aplicação suporta certificados auto-assinados, certificados da autoridade de certificados (CA), certificados de validação estendida (EV), certificados de vários domínios (SAN) e certificados wildcard.

Que suítes cifras suportam Gateway de Aplicação?

Gateway de Aplicação suporta as seguintes suítes cifra.

  • 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 as opções TLS, consulte versões de política configure TLS e suítes de cifra no Gateway de Aplicação.

O Gateway de Aplicação suporta a reencriptação do tráfego para o backend?

Sim. Gateway de Aplicação suporta o descarregamento TLS e o TLS de ponta a ponta, que reencriptam o tráfego para o backend.

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

Sim. Pode configurar Gateway de Aplicação para negar TLS1.0, TLS1.1 e TLS1.2. Por padrão, os SSL 2.0 e 3.0 já estão desativadas e não são configuráveis.

Posso configurar suítes de cifra e ordem política?

Sim. Em Gateway de Aplicação, pode configurar suítes cifra. Para definir uma política personalizada, ative pelo menos uma das seguintes suítes cifra.

  • 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

Gateway de Aplicação usa SHA256 para gestão de backend.

Quantos certificados TLS/SSL suportam Gateway de Aplicação?

Gateway de Aplicação suporta até 100 certificados TLS/SSL.

Os Gateway de Aplicação têm apoio para a agrafamento oCSP e o OCSP?

Sim, Gateway de Aplicação suporta certificados com extensões OCSP e agrafamento oCSP para certificados de servidor.

Quantos certificados de autenticação para reencriptação de backend suporta Gateway de Aplicação?

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

A Gateway de Aplicação integra-se de forma nativa com o Azure Key Vault?

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

Como devo proceder para configurar os ouvintes HTTPS para sites .com e .net?

Para o roteamento de vários domínios (baseado em anfitriões), pode criar ouvintes multisite, configurar os ouvintes que usam HTTPS como protocolo e associar os ouvintes às regras de encaminhamento. Para obter mais informações, consulte hospedar vários sites utilizando Gateway de Aplicação.

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

Não, utilize apenas caracteres alfanuméricos na sua senha de ficheiro .pfx.

O meu certificado EV é emitido pela DigiCert e o meu certificado intermédio foi revogado. Como devo proceder para renovar o meu certificado no Gateway de Aplicação?

Os membros do Browser Da Autoridade de Certificados (CA) publicaram recentemente relatórios que detalham vários certificados emitidos por fornecedores de CA que são utilizados pelos nossos clientes, Microsoft, e pela maior comunidade tecnológica que estavam fora do cumprimento dos padrões da indústria para CAs de confiança pública. Os relatórios relativos aos AC não conformes podem ser consultados aqui:

De acordo com os requisitos de conformidade da indústria, os fornecedores de CA começaram a revogar os AA não conformes e a emitir CAs conformes, o que exige que os clientes tenham os seus certificados reemitidos. A Microsoft está em estreita parceria com estes fornecedores para minimizar o impacto potencial para os Serviços Azure, no entanto os seus certificados ou certificados auto-emitidos utilizados em cenários "Bring Your Own Certificate" (BYOC) ainda estão em risco de serem revogados inesperadamente.

Para verificar se os certificados utilizados pelo seu pedido foram revogados referência o Anúncio da DigiCert e o Rastreador de Revogação de Certificados. Se os seus certificados tiverem sido revogados ou forem revogados, terá de solicitar novos certificados ao fornecedor ca utilizado nas suas aplicações. Para evitar que a disponibilidade da sua aplicação seja interrompida devido à revogação inesperada de certificados ou à atualização de um certificado que tenha sido revogado, consulte o nosso post de atualizações do Azure para obter links de remediação de vários serviços da Azure que suportem o BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Para obter informações Gateway de Aplicação específicas, consulte abaixo -

Se estiver a utilizar um certificado emitido por uma das ICAs revogadas, a disponibilidade da sua aplicação poderá ser interrompida e, dependendo da sua aplicação, poderá receber uma variedade de mensagens de erro, incluindo, mas não se limitando a:

  1. Certificado inválido/certificado revogado
  2. Excedido o limite de tempo da ligação
  3. HTTP 502

Para evitar qualquer interrupção da sua aplicação devido a este problema, ou para reeditar uma AC que foi revogada, tem de tomar as seguintes ações:

  1. Contacte o seu fornecedor de certificados sobre como reeditar os seus certificados.
  2. Uma vez reeditado, atualize os seus certificados no Gateway de Aplicação do Azure/WAF com a cadeia completa de confiança (folha, intermediária, certificado de raiz). Com base no local onde está a utilizar o seu certificado, quer no ouvinte, quer nas definições HTTP do Gateway de Aplicação, siga os passos abaixo para atualizar os certificados e verificar os links de documentação mencionados para obter mais informações.
  3. Atualize os servidores de aplicações backend para utilizar o certificado reemitido. Dependendo do servidor de backend que está a utilizar, os passos de atualização do certificado podem variar. Por favor, verifique a documentação do seu fornecedor.

Para atualizar o certificado no seu ouvinte:

  1. No portal do Azure, abra o seu recurso Gateway de Aplicação.
  2. Abra as definições do ouvinte que estão associadas ao seu certificado.
  3. Clique em "Renovar ou editar o certificado selecionado".
  4. Faça upload do seu novo certificado PFX com a palavra-passe e clique em Guardar.
  5. Aceda ao site e verifique se o site está funcionando como esperado. Para mais informações, consulte os certificados renovar Gateway de Aplicação.

Se estiver a fazer referência aos certificados da Azure KeyVault no seu ouvinte Gateway de Aplicação, recomendamos os seguintes passos para uma mudança rápida –

  1. Na portal do Azure, navegue para as definições Azure KeyVault que estão associadas à Gateway de Aplicação.
  2. Adicione/importe o certificado reeditado na sua loja. Consulte aqui a documentação para obter mais informações sobre como fazer.
  3. Uma vez importado o certificado, navegue para as definições do seu ouvinte Gateway de Aplicação e em "Escolha um certificado a partir de Key Vault", clique na queda do "Certificado" e escolha o certificado recentemente adicionado
  4. Clique em Guardar Para mais informações sobre a rescisão de TLS em Gateway de Aplicação com certificados de Key Vault, consulte a rescisão de TLS com certificados Key Vault.

Para atualizar o certificado nas definições HTTP:

Se estiver a utilizar o Serviço V1 SKU do serviço Gateway de Aplicação/WAF, então terá de carregar o novo certificado como certificado de autenticação de backend.

  1. No portal do Azure, abra o seu recurso Gateway de Aplicação.
  2. Abra as definições HTTP que estão associadas ao seu certificado.
  3. Clique em "Adicionar certificado" e carre faça o upload do certificado reeditado e clique em guardar.
  4. Pode remover o certificado antigo mais tarde clicando no "..." botão de opções ao lado do certificado antigo e selecione eliminar e clicar em guardar. Para obter mais informações, consulte configurar o TLS de ponta a ponta utilizando Gateway de Aplicação com o portal.

Se estiver a utilizar o V2 SKU do serviço Gateway de Aplicação/WAF, não precisa de carregar o novo certificado nas definições HTTP, uma vez que o V2 SKU utiliza "certificados de raiz fidedignos" e não é necessário tomar medidas aqui.

Configuração - controlador de entrada para AKS

O que é um Controlador de Entrada?

Kubernetes permite a criação deployment e service recurso para expor um grupo de cápsulas internamente no cluster. Para expor o mesmo serviço externamente, é definido um Ingress recurso que proporciona equilíbrio de carga, rescisão TLS e hospedagem virtual baseada em nome. Para satisfazer este Ingress recurso, é necessário um Controlador de Entrada que ouça quaisquer alterações aos Ingress recursos e configura as políticas do balanceador de carga.

O Controlador de Ingress (AGIC) Gateway de Aplicação permite que Gateway de Aplicação do Azure sejam usadas como entrada para um Azure Kubernetes Service também conhecido como um cluster AKS.

Pode um único controlador de entrada gerir vários Gateways de aplicação?

Atualmente, um caso de Controlador de Ingress só pode ser associado a um Gateway de Aplicação.

Porque é que o meu cluster AKS com a Kubenet não está a trabalhar com a AGIC?

A AGIC tenta associar automaticamente o recurso da tabela de rotas à sub-rede Gateway de Aplicação, mas pode não o fazer por falta de permissões da AGIC. Se a AGIC não conseguir associar a tabela de rotas à sub-rede Gateway de Aplicação, haverá um erro nos registos AGIC a dizer isso, caso em que terá de associar manualmente a tabela de rotas criada pelo cluster AKS à sub-rede do Gateway de Aplicação. Para obter mais informações, consulte rotas definidas pelo utilizador suportados.

Posso ligar o meu cluster AKS e Gateway de Aplicação em redes virtuais separadas?

Sim, desde que as redes virtuais sejam espreitadas e não tenham espaços de endereço sobrepostos. Se estiver a executar AKS com kubenet, então não se esqueça de associar a tabela de rotas gerada pela AKS à sub-rede Gateway de Aplicação.

Quais as funcionalidades que não são suportadas no addon AGIC?

Por favor, veja as diferenças entre a AGIC implantada através do Helm versus implantada como um add-on AKS aqui

Quando devo usar o addon contra a implantação do Helm?

Por favor, veja as diferenças entre a AGIC implantada através do Helm versus implementadas como um add-on AKS aqui, especialmente as tabelas que documentam quais os cenários(s) que são suportados pela AGIC implantada através do Helm em oposição a um addon AKS. Em geral, a implantação através do Helm permitir-lhe-á testar funcionalidades beta e lançar candidatos antes de um lançamento oficial.

Posso controlar qual a versão da AGIC que será implantada com o addon?

Não, o add-on AGIC é um serviço gerido, o que significa que a Microsoft irá atualizar automaticamente o add-on para a versão mais recente estável.

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

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

A autenticação mútua é a autenticação bidirecciona entre um cliente e um servidor. A autenticação mútua com Gateway de Aplicação permite atualmente verificar a porta de entrada para verificar o cliente que envia o pedido, que é a autenticação do cliente. Normalmente, o cliente é o único que autentica o Gateway de Aplicação. Como Gateway de Aplicação pode agora também autenticar o cliente, torna-se a autenticação mútua sempre que Gateway de Aplicação e o cliente estão a autenticar-se mutuamente.

A autenticação mútua está disponível entre Gateway de Aplicação e as suas piscinas de backend?

Não, a autenticação mútua é atualmente apenas entre o cliente frontal e o Gateway de Aplicação. A autenticação mútua de backend não é suportada atualmente.

Diagnóstico e registos

Que tipos de registos Gateway de Aplicação fornece?

Gateway de Aplicação fornece três registos:

  • ApplicationGatewayAccessLog: O registo de acesso contém cada pedido submetido ao frontend do gateway de aplicação. Os dados incluem o IP do autor da chamada, URL solicitado, latência de resposta, código de devolução e bytes dentro e fora. Contém um registo por porta de aplicação.
  • ApplicationGatewayPerformanceLog: O registo de desempenho captura informações de desempenho para cada gateway de aplicação. A informação inclui o produção em bytes, o total de pedidos servidos, a contagem de pedidos falhadas e a contagem de casos de backend saudável e pouco saudável.
  • ApplicationGatewayFirewallLog: Para os gateways de aplicações que configura com WAF, o registo de firewall contém pedidos que são registados através do modo de deteção ou do modo de prevenção.

Todos os registos são recolhidos a cada 60 segundos. Para obter mais informações, consulte a saúde backend, registos de diagnóstico e métricas para Gateway de Aplicação.

Como devo proceder para saber se os meus membros da piscina estão saudáveis?

Verifique a saúde utilizando o cmdlet Get-AzApplicationGatewayBackendHealth PowerShell ou o portal. Para mais informações, consulte Gateway de Aplicação diagnósticos.

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

Os registos de diagnóstico fluem para a conta de armazenamento do cliente. Os clientes podem definir a política de retenção com base na sua preferência. Os registos de diagnóstico também podem ser enviados para um centro de eventos ou registos do Azure Monitor. Para mais informações, consulte Gateway de Aplicação diagnósticos.

Como devo proceder para obter registos de auditoria para Gateway de Aplicação?

No portal, na lâmina do menu de um gateway de aplicações, selecione Registo de Atividades para aceder ao registo de auditoria.

Posso estabelecer alertas com Gateway de Aplicação?

Sim. Em Gateway de Aplicação, os alertas são configurados em métricas. Para mais informações, consulte Gateway de Aplicação métricas e receba notificações de alerta.

Como devo proceder para analisar estatísticas de tráfego para Gateway de Aplicação?

Pode visualizar e analisar registos de acesso de várias maneiras. Utilize registos do Monitor Azure, Excel, Power BI, e assim por diante.

Também pode utilizar um modelo de Resource Manager que instala e executa o popular analisador de registo GoAccess para Gateway de Aplicação registos de acesso. O GoAccess fornece valiosas estatísticas de tráfego HTTP, tais como visitantes únicos, ficheiros solicitados, anfitriões, sistemas operativos, navegadores e códigos de estado HTTP. Para obter mais informações, no GitHub, consulte o ficheiro Readme na pasta de modelo Resource Manager.

O que poderia fazer com que a saúde de backend devolvesse um estatuto desconhecido?

Normalmente, vê-se um estado desconhecido quando o acesso ao backend é bloqueado por um grupo de segurança de rede (NSG), DNS personalizado ou encaminhamento definido pelo utilizador (UDR) na sub-rede do gateway de aplicação. Para obter mais informações, consulte a saúde do Backend, o registo de diagnósticos e as métricas para Gateway de Aplicação.

Os registos de fluxo NSG são suportados em NSGs associados a Gateway de Aplicação sub-rede V2?

Devido às limitações atuais da plataforma, se tiver um NSG na sub-rede Gateway de Aplicação V2 (Standard_v2, WAF_v2) e se tiver ativado registos de fluxo NSG na sua, verá um comportamento não determinado e este cenário não é suportado atualmente.

Onde Gateway de Aplicação armazena os dados dos clientes?

Gateway de Aplicação não move nem armazena os dados dos clientes para fora da região onde está implantado.

Passos seguintes

Para saber mais sobre Gateway de Aplicação, veja o que é Gateway de Aplicação do Azure? Para saber mais sobre a rescisão de TLS e o fim do TLS com Gateway de Aplicação, consulte Enableing end to end TLS on Gateway de Aplicação do Azure.