Configuração da infraestrutura do Application Gateway
A infraestrutura do Gateway de Aplicativo do Azure inclui a rede virtual, sub-redes, NSGs (grupos de segurança de rede) e UDRs (rotas definidas pelo usuário).
Rede virtual e sub-rede dedicada
Um gateway de aplicativo é uma implantação dedicada em sua rede virtual. Em sua rede virtual, uma sub-rede dedicada é necessária para o gateway de aplicativo. Você pode ter várias instâncias de uma implantação específica do Application Gateway em uma sub-rede. Você também pode implantar outros gateways de aplicativos na sub-rede. Mas você não pode implantar nenhum outro recurso na sub-rede do Application Gateway. Não é possível misturar SKUs do Application Gateway v1 e v2 na mesma sub-rede.
Nota
Atualmente, não há suporte para políticas de ponto de extremidade de serviço de rede virtual em uma sub-rede do Application Gateway.
Tamanho da sub-rede
O Application Gateway usa um endereço IP privado por instância, além de outro endereço IP privado se um IP de frontend privado estiver configurado.
O Azure também reserva cinco endereços IP em cada sub-rede para uso interno. São os quatro primeiros endereços e os últimos endereços IP. Por exemplo, considere 15 instâncias do Application Gateway sem IP frontend privado. Você precisa de pelo menos 20 endereços IP para esta sub-rede. Você precisa de 5 para uso interno e 15 para as instâncias do Application Gateway.
Considere uma sub-rede que tenha 27 instâncias do Application Gateway e um endereço IP para um IP de front-end privado. Neste caso, você precisa de 33 endereços IP. Você precisa de 27 para as instâncias do Application Gateway, uma para o frontend privado e 5 para uso interno.
O Application Gateway (Standard ou WAF SKU) pode suportar até 32 instâncias (32 endereços IP de instância + 1 configuração IP de frontend privada + 5 Azure reservado). Recomendamos um tamanho mínimo de sub-rede de /26.
O Gateway de Aplicação (Standard_v2 ou WAF_v2 SKU) pode suportar até 125 instâncias (125 endereços IP da instância + 1 configuração de IP de front-end privado + 5 reservadas do Azure). Recomendamos um tamanho mínimo de sub-rede de /24.
Para determinar a capacidade disponível de uma sub-rede que tenha gateways de aplicativos existentes provisionados, pegue o tamanho da sub-rede e subtraia os cinco endereços IP reservados da sub-rede reservada pela plataforma. Em seguida, pegue cada gateway e subtraia a contagem máxima de instâncias. Para cada gateway que tenha uma configuração IP de front-end privada, subtraia mais um endereço IP por gateway.
Por exemplo, veja como calcular o endereço disponível para uma sub-rede com três gateways de tamanhos variados:
- Gateway 1: máximo de 10 instâncias. Usa uma configuração IP de frontend privado.
- Gateway 2: Máximo de 2 instâncias. Nenhuma configuração de IP frontend privado.
- Gateway 3: máximo de 15 instâncias. Usa uma configuração IP de frontend privado.
- Tamanho da sub-rede: /24
- Tamanho da sub-rede /24 = 256 endereços IP - 5 reservados a partir da plataforma = 251 endereços disponíveis
- 251: Gateway 1 (10) - 1 configuração IP frontend privada = 240
- 240: Gateway 2 (2) = 238
- 238: Gateway 3 (15) - 1 configuração IP frontend privada = 222
Importante
Embora uma sub-rede /24 não seja necessária para a implantação de SKU do Application Gateway v2, é altamente recomendável. Uma sub-rede /24 garante que o Application Gateway v2 tenha espaço suficiente para atualizações de expansão e manutenção de dimensionamento automático.
Você deve garantir que a sub-rede do Application Gateway v2 tenha espaço de endereçamento suficiente para acomodar o número de instâncias necessárias para atender ao tráfego máximo esperado. Se você especificar a contagem máxima de instâncias, a sub-rede deverá ter capacidade para pelo menos tantos endereços. Para o planejamento de capacidade em torno da contagem de instâncias, consulte Detalhes da contagem de instâncias.
A sub-rede nomeada GatewaySubnet é reservada para gateways VPN. Os recursos do Application Gateway v1 que usam a sub-rede precisam ser movidos GatewaySubnet para uma sub-rede diferente ou migrados para a SKU v2 antes de 30 de setembro de 2023, para evitar falhas no plano de controle e inconsistências na plataforma. Para obter informações sobre como alterar a sub-rede de uma instância existente do Application Gateway, consulte Perguntas freqüentes sobre o Application Gateway.
Gorjeta
Os endereços IP são alocados desde o início do espaço de sub-rede definido para instâncias de gateway. À medida que as instâncias são criadas e removidas devido à criação de gateways ou eventos de dimensionamento, pode se tornar difícil entender qual é o próximo endereço disponível na sub-rede. Para poder determinar o próximo endereço a ser usado para um gateway futuro e ter um tema de endereçamento contíguo para IPs frontend, considere atribuir endereços IP frontend a partir da metade superior do espaço de subconjunto definido.
Por exemplo, se o espaço de endereço da sub-rede for 10.5.5.0/24, considere definir a configuração IP de frontend privado de seus gateways começando com 10.5.5.254 e seguindo com 10.5.5.253, 10.5.5.252, 10.5.5.251 e assim por diante para gateways futuros.
É possível alterar a sub-rede de uma instância existente do Application Gateway dentro da mesma rede virtual. Para fazer essa alteração, use o Azure PowerShell ou a CLI do Azure. Para obter mais informações, consulte Perguntas freqüentes sobre o Application Gateway.
Servidores DNS para resolução de nomes
O recurso de rede virtual dá suporte à configuração do servidor DNS, que permite escolher entre servidores DNS padrão ou personalizados fornecidos pelo Azure. As instâncias do gateway de aplicativo também respeitam essa configuração de DNS para qualquer resolução de nome. Depois de alterar essa configuração, você deve reiniciar (Parar e Iniciar) o gateway de aplicativo para que essas alterações entrem em vigor nas instâncias.
Quando uma instância do seu Application Gateway emite uma consulta DNS, ela usa o valor do servidor que responde primeiro.
Nota
Se você usar servidores DNS personalizados na rede virtual do Application Gateway, o servidor DNS deverá ser capaz de resolver nomes públicos da Internet. O Application Gateway requer esse recurso.
Permissão da rede virtual
O recurso do Gateway de Aplicativo é implantado dentro de uma rede virtual, portanto, as verificações também são realizadas para verificar a permissão no recurso de rede virtual. Essa validação é executada durante as operações de criação e gerenciamento e também se aplica às identidades gerenciadas para o Application Gateway Ingress Controller.
Verifique seu controle de acesso baseado em função do Azure para verificar se os usuários e entidades de serviço que operam gateways de aplicativo têm pelo menos as seguintes permissões na rede virtual ou sub-rede:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/sub-redes/leitura
Você pode usar as funções internas, como Colaborador de rede, que já oferecem suporte a essas permissões. Se uma função interna não fornecer a permissão correta, você poderá criar e atribuir uma função personalizada. Saiba mais sobre como gerenciar permissões de sub-rede.
Permissões
Dependendo se você estiver criando novos recursos ou usando os existentes, adicione as permissões apropriadas na lista a seguir:
| Recurso | Estado do recurso | Permissões do Azure necessárias |
|---|---|---|
| Sub-rede | Criar nova | Microsoft.Network/virtualNetworks/sub-redes/gravação Microsoft.Network/virtualNetworks/subnets/join/action |
| Sub-rede | Utilizar existente | Microsoft.Network/virtualNetworks/sub-redes/leitura Microsoft.Network/virtualNetworks/subnets/join/action |
| Endereços IP | Criar nova | Microsoft.Network/publicIPAddresses/write Microsoft.Network/publicIPAddresses/join/action |
| Endereços IP | Utilizar existente | Microsoft.Network/publicIPAddresses/read Microsoft.Network/publicIPAddresses/join/action |
| ApplicationGatewayWebApplicationFirewallPolicies | Criar novo / Atualizar existente | Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/write Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/join/action |
Para obter mais informações, consulte Permissões do Azure para permissões de rede e rede virtual.
Escopo de funções
No processo de definição de função personalizada, você pode especificar um escopo de atribuição de função em quatro níveis: grupo de gerenciamento, assinatura, grupo de recursos e recursos. Para conceder acesso, atribua funções a utilizadores, grupos, principais de serviço ou identidades geridas num determinado âmbito. Esses escopos são estruturados em uma relação pai-filho, com cada nível de hierarquia tornando o escopo mais específico. Você pode atribuir funções em qualquer um desses níveis de escopo, e o nível selecionado determina a extensão da função aplicada. Por exemplo, uma função atribuída no nível de assinatura pode ser transferida em cascata para todos os recursos dentro dessa assinatura, enquanto uma função atribuída no nível do grupo de recursos só se aplicará a recursos dentro desse grupo específico. Saiba mais sobre o nível de escopo Para obter mais informações, consulte Níveis de escopo.
Nota
Talvez seja necessário dar tempo suficiente para a atualização do cache do Azure Resource Manager após as alterações na atribuição de função.
Identificar utilizadores ou entidades de serviço afetadas para a sua subscrição
Ao visitar o Azure Advisor para sua conta, você pode verificar se sua assinatura tem usuários ou entidades de serviço com permissão insuficiente. Os pormenores dessa recomendação são os seguintes:
Título: Atualizar permissão de VNet de usuários
do Application Gateway Categoria: Confiabilidade
Impacto: Alto
Usar o sinalizador AFEC (Azure Feature Exposure Control) temporário
Como uma extensão temporária, introduzimos um AFEC (Azure Feature Exposure Control) de nível de assinatura. Pode registar-se na AFEC e utilizá-la até corrigir as permissões para todos os seus utilizadores e entidades de serviço. Registre-se para o recurso seguindo as mesmas etapas de um registro de recurso de visualização para sua assinatura do Azure.
Nome: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Descrição: Desabilitar verificação de permissão
de sub-rede do gateway de aplicativo ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Nota
Sugerimos usar a disposição AFEC apenas como mitigação provisória até que você atribua a permissão correta. Você deve priorizar a fixação das permissões para todos os usuários aplicáveis (e entidades de serviço) e, em seguida, cancelar o registro desse sinalizador AFEC para reintroduzir a verificação de permissão no recurso de rede virtual. Recomendamos que você não dependa deste método AFEC permanentemente porque ele será removido no futuro.
Azure Virtual Network Manager
O Azure Virtual Network Manager é um serviço de gestão que lhe permite agrupar, configurar, implementar e gerir redes virtuais globalmente através de subscrições. Com o Virtual Network Manager, você pode definir grupos de rede para identificar e segmentar logicamente suas redes virtuais. Depois disso, você pode determinar as configurações de conectividade e segurança desejadas e aplicá-las em todas as redes virtuais selecionadas em grupos de rede de uma só vez.
A configuração da regra de administração de segurança no Azure Virtual Network Manager permite definir políticas de segurança em escala e aplicá-las a várias redes virtuais de uma só vez.
Nota
As regras de administração de segurança do Azure Virtual Network Manager aplicam-se apenas a sub-redes do Gateway de Aplicação que contenham gateways de aplicação com o Isolamento de Rede ativado. As sub-redes com gateways de aplicativos com o Isolamento de Rede desabilitado não têm regras de administração de segurança.
Grupos de segurança de rede
Você pode usar NSGs para sua sub-rede do Application Gateway, mas esteja ciente de alguns pontos-chave e restrições.
Importante
Essas limitações do NSG são relaxadas quando você usa a implantação do Private Application Gateway (visualização).
Regras de segurança necessárias
Para usar um NSG com seu gateway de aplicativo, você precisa criar ou manter algumas regras de segurança essenciais. Você pode definir sua prioridade na mesma ordem.
Regras de entrada
Tráfego de cliente: permita o tráfego de entrada dos clientes esperados (como IP de origem ou intervalo de IP) e para o destino como todo o prefixo IP de sub-rede do gateway de aplicativo e portas de acesso de entrada. Por exemplo, se tiver ouvintes configurados para as portas 80 e 443, tem de permitir estas portas. Você também pode definir essa regra como Any.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
<as per need> |
Qualquer | <Subnet IP Prefix> |
<listener ports> |
TCP | Permitir |
Depois de configurar ouvintes públicos e privados ativos (com regras) com o mesmo número de porta, o gateway de aplicativo altera o Destino de todos os fluxos de entrada para os IPs de front-end do gateway. Essa alteração ocorre mesmo para ouvintes que não estão compartilhando nenhuma porta. Você deve incluir os endereços IP públicos e privados do front-end do gateway no Destino da regra de entrada quando usar a mesma configuração de porta.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
<as per need> |
Qualquer | <Public and Private frontend IPs> |
<listener ports> |
TCP | Permitir |
Portas de infraestrutura: permita solicitações de entrada da origem como a marca de serviço GatewayManager e Qualquer destino. O intervalo de portas de destino difere com base na SKU e é necessário para comunicar o status da integridade do back-end. Essas portas são protegidas/bloqueadas por certificados do Azure. As entidades externas não podem iniciar alterações nesses pontos de extremidade sem certificados apropriados em vigor.
- V2: Portas 65200-65535
- V1: Portas 65503-65534
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
| GatewayManager | Qualquer | Qualquer | <as per SKU given above> |
TCP | Permitir |
Testes do Azure Load Balancer: permita o tráfego de entrada da origem como a marca de serviço AzureLoadBalancer . Esta regra é criada por padrão para NSGs. Você não deve substituí-la por uma regra Deny manual para garantir operações suaves do gateway de aplicativo.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | Qualquer | Qualquer | Qualquer | Qualquer | Permitir |
Você pode bloquear todo o outro tráfego de entrada usando uma regra Negar tudo .
Regras de saída
Saída para a Internet: Permite o tráfego de saída para a Internet para todos os destinos. Esta regra é criada por padrão para NSGs. Você não deve substituí-la por uma regra Deny manual para garantir operações suaves do gateway de aplicativo. As regras NSG de saída que negam qualquer conectividade de saída não devem ser criadas.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
| Qualquer | Qualquer | Internet | Qualquer | Qualquer | Permitir |
Nota
Os Gateways de Aplicativos que não têm o Isolamento de Rede habilitado não permitem que o tráfego seja enviado entre VNets emparelhadas quando Permitir tráfego para rede virtual remota estiver desabilitado.
Rotas definidas pelo usuário suportadas
O controle refinado sobre a sub-rede do Application Gateway por meio de regras de tabela de rotas é possível na visualização pública. Para obter mais informações, consulte Implantação do Private Application Gateway (visualização).
Com a funcionalidade atual, existem algumas restrições:
Importante
O uso de UDRs na sub-rede do Application Gateway pode fazer com que o status de integridade na exibição de integridade do back-end apareça como Desconhecido. Isso também pode causar falha na geração de logs e métricas do Application Gateway. Recomendamos não usar UDRs na sub-rede do Application Gateway para que você possa exibir a integridade do back-end, logs e métricas.
v1: Para a SKU v1, as UDRs são suportadas na sub-rede do Application Gateway se não alterarem a comunicação de solicitação/resposta de ponta a ponta. Por exemplo, pode configurar uma UDR na sub-rede da Gateway de Aplicação para apontar para uma aplicação da firewall para inspeção de pacotes. Mas deve confirmar que o pacote consegue chegar ao destino pretendido após a inspeção. Caso contrário, pode dar origem a comportamentos incorretos na pesquisa de estado de funcionamento ou no encaminhamento de tráfego. As rotas aprendidas ou as rotas padrão 0.0.0.0/0 propagadas pelo Azure ExpressRoute ou gateways VPN na rede virtual também estão incluídas.
v2: Para o SKU v2, há cenários suportados e não suportados.
Cenários suportados pela V2
Aviso
Uma configuração incorreta da tabela de rotas pode resultar em roteamento assimétrico no Application Gateway v2. Certifique-se de que todo o tráfego do plano de gestão/controlo é enviado diretamente para a Internet e não através de uma ferramenta virtual. Registros, métricas e verificações de CRL também podem ser afetados.
Cenário 1: UDR para desabilitar a propagação de rota BGP (Border Gateway Protocol) para a sub-rede do Application Gateway
Às vezes, a rota de gateway padrão (0.0.0.0/0) é anunciada por meio dos gateways ExpressRoute ou VPN associados à rede virtual do Application Gateway. Esse comportamento interrompe o tráfego do plano de gerenciamento, que requer um caminho direto para a internet. Nesses cenários, você pode usar um UDR para desabilitar a propagação de rota BGP.
Para desativar a propagação de rota BGP:
- Crie um recurso de tabela de rotas no Azure.
- Desative o parâmetro de propagação de rota do gateway de rede virtual.
- Associe a tabela de rotas à sub-rede apropriada.
Habilitar o UDR para este cenário não deve interromper nenhuma configuração existente.
Cenário 2: UDR para direcionar 0.0.0.0/0 para a Internet
Você pode criar um UDR para enviar tráfego 0.0.0.0/0 diretamente para a Internet.
Cenário 3: UDR para o Serviço Kubernetes do Azure (AKS) com kubenet
Se você estiver usando kubenet com AKS e Application Gateway Ingress Controller, precisará de uma tabela de rotas para permitir que o tráfego enviado para os pods do Application Gateway seja roteado para o nó correto. Você não precisará usar uma tabela de rotas se usar a Interface de Rede de Contêiner do Azure.
Para usar a tabela de rotas para permitir que o kubenet funcione:
Vá para o grupo de recursos criado pelo AKS. O nome do grupo de recursos deve começar com
MC_.Encontre a tabela de rotas criada pelo AKS nesse grupo de recursos. A tabela de rotas deve ser preenchida com as seguintes informações:
- O prefixo do endereço deve ser o intervalo de IP dos pods que você deseja alcançar no AKS.
- O próximo tipo de salto deve ser o dispositivo virtual.
- O endereço do próximo salto deve ser o endereço IP do nó que hospeda os pods.
Associe esta tabela de rotas à sub-rede do Application Gateway.
Cenários sem suporte v2
Cenário 1: UDR para dispositivos virtuais
Qualquer cenário em que 0.0.0.0/0 precise ser redirecionado através de um dispositivo virtual, uma rede virtual hub/spoke ou no local (tunelamento forçado) não é suportado pela v2.
Serviços adicionais
Para exibir funções e permissões para outros serviços, consulte os seguintes links: