Implantar sua instância de Gerenciamento de API do Azure em uma rede virtual – modo externo
APLICA-SE A: Desenvolvedor | Premium
O Gerenciamento de API do Azure pode ser implantado (injetado) dentro de uma VNet (rede virtual) do Azure para acessar serviços de back-end na rede. Para conhecer as opções de conectividade VNet, os requisitos e as considerações, consulte:
- Usando uma rede virtual com o Gerenciamento de API do Azure
- Requisitos de recursos de rede para injeção de Gerenciamento de API em uma rede virtual
Este artigo explica como configurar a conectividade de VNet para sua instância de gerenciamento de API no modo externo, em que o portal do desenvolvedor, o gateway de API e outros pontos de extremidade de gerenciamento de API podem ser acessados pela Internet pública.
Para configurações específicas do modo interno, em que pontos de extremidade são acessíveis somente na VNet, confira Implantar sua instância de Gerenciamento de API do Azure em uma rede virtual – modo interno.
Observação
Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.
Pré-requisitos
Revise os requisitos de recursos de rede para injeção do Gerenciamento de API em uma rede virtual antes de começar.
Alguns pré-requisitos são diferentes, dependendo da versão (stv2
ou stv1
) da stv2
hospedando a instância do Gerenciamento de API.
Dica
Quando você usa o portal para criar ou atualizar a conexão de rede de uma instância existente do Gerenciamento de API, a instância é hospedada na plataforma de computação stv2
.
- Uma instância de Gerenciamento de API. Para obter mais informações, consulte Criar uma instância do Gerenciamento de API do Azure.
Uma rede virtual e a sub-rede na mesma região e assinatura da instância do Gerenciamento de API.
- A sub-rede usada para se conectar à instância de gerenciamento de API pode conter outros tipos de recursos do Azure.
- A sub-rede não deve ter nenhuma delegação habilitada. A configuração Delegar sub-rede a um serviço para a sub-rede deve ser definida como Nenhuma.
Um grupo de segurança de rede anexado à sub-rede acima. Um NSG (grupo de segurança de rede) é necessário para permitir explicitamente a conectividade de entrada, pois o balanceador de carga usado internamente pelo Gerenciamento de API é seguro por padrão e rejeita todo o tráfego de entrada. Para uma configuração específica, consulte Configurar regras NSG, abaixo neste artigo.
Para determinados cenários, habilite pontos de extremidade de serviço na sub-rede para serviços dependentes, como o Armazenamento do Microsoft Azure ou o SQL do Azure. Para obter mais informações, consulte Forçar o tráfego de túnel para o firewall local usando o ExpressRoute ou o dispositivo virtual de rede posteriormente neste artigo.
(Opcional) Um endereço IPv4 público de SKU Padrão.
Importante
- A partir de maio de 2024, um recurso de endereço IP público não é mais necessário ao implantar (injetar) uma instância de Gerenciamento de API em uma VNet no modo interno ou migrar a configuração de VNet interna para uma nova sub-rede. No modo de VNet externa, especificar um endereço IP público é opcional; se você não fornecer um, um endereço IP público gerenciado pelo Azure será configurado automaticamente e usado para tráfego de API de runtime. Forneça apenas o endereço IP público se você quiser possuir e controlar o endereço IP público usado para comunicação de entrada ou de saída para a Internet.
Se fornecido, o endereço IP deve estar na mesma região e assinatura que a instância de Gerenciamento de API e a rede virtual.
Ao criar um recurso de endereço IP público, lembre-se de atribuir um rótulo de nome DNS a ele. Em geral, você deve usar o mesmo nome DNS que sua instância de Gerenciamento de API. Se você alterá-la, reimplante sua instância para que o novo rótulo DNS seja aplicado.
Para obter o melhor desempenho de rede, é recomendável usar a Preferência padrão de roteamento: Rede da Microsoft.
Ao criar um endereço IP público em uma região onde você planeja habilitar a redundância de zona para sua instância de Gerenciamento de API, defina a configuração com redundância de zona.
O valor do endereço IP é atribuído como o endereço IPv4 público virtual da instância de gerenciamento de API nessa região.
Para implementações de Gerenciamento de API em várias regiões, configure os recursos da rede virtual separadamente para cada local.
Habilitar conexão de VNET
Habilitar a conectividade VNET usando o portal do Azure (plataforma de computação stv2
)
Vá para o portal do Azure para encontrar sua instância de gerenciamento de API. Procure e selecione serviços de gerenciamento de API.
Escolha sua instância de gerenciamento de API.
Selecionar Rede.
Selecione o tipo de acesso Externo.
Na lista de localizações (regiões) em que o serviço de Gerenciamento de API é provisionado:
- Escolha um Local.
- Selecione Rede virtual, Sub-rede e (opcionalmente) endereço IP.
A lista de VNets é preenchida com as VNets do Resource Manager disponíveis em suas assinaturas do Azure e definidas na região que você está configurando.
Escolha Aplicar. A página Rede da instância de Gerenciamento de API é atualizada com suas novas opções de VNet e sub-rede.
Continue definindo as configurações de VNet para os locais restantes da instância de Gerenciamento de API.
Na barra de navegação superior, selecione Salvar.
A atualização da instância do Gerenciamento de API pode levar de 15 a 45 minutos. As instâncias na camada de Desenvolvedor têm tempo de inatividade durante o processo. As instâncias na camada Premium não têm tempo de inatividade durante o processo.
Habilitar a conectividade usando um modelo do Resource Manager (plataforma de computaçãostv2
)
Modelo do Azure Resource Manager (versão da API 2021-08-01)
Habilitar a conectividade usando cmdlets do Azure PowerShell (plataforma stv1
)
Criar ou atualizar uma instância do Gerenciamento de API em uma VNET.
Configurar regras de NSG
Configure regras de rede personalizadas na sub-rede de gerenciamento de API para filtrar o tráfego de e para a instância de gerenciamento de API. Recomendamos as regras de NSG mínimas a seguir para garantir a operação adequada e o acesso à sua instância. Examine seu ambiente cuidadosamente para determinar mais regras que podem ser necessárias.
Importante
Dependendo do uso do cache e de outros recursos, talvez seja necessário configurar regras de NSG adicionais além das regras mínimas na tabela a seguir. Para obter configurações detalhadas, consultereferência de configuração de rede virtual.
- Para a maioria dos cenários, use asmarcas de serviço indicadas em vez de endereços IP de serviço para especificar fontes de rede e destinos.
- Defina a prioridade dessas regras como maior do que as regras padrão.
Porta(s) de Origem/Destino | Direção | Protocolo de transporte | Marcas de serviço Origem/Destino |
Finalidade | Tipo de VNet |
---|---|---|---|---|---|
* / [80], 443 | Entrada | TCP | Internet / VirtualNetwork | Comunicação do cliente com o Gerenciamento de API | Apenas externo |
* / 3443 | Entrada | TCP | ApiManagement / VirtualNetwork | Ponto de extremidade de gerenciamento para o Portal do Azure e o Powershell | Interno e externo |
* / 6390 | Entrada | TCP | AzureLoadBalancer / VirtualNetwork | Balanceador de carga de infraestrutura do Azure | Interno e externo |
*/443 | Entrada | TCP | AzureTrafficManager / VirtualNetwork | Roteamento do Gerenciador de Tráfego do Azure para implantação em várias regiões | Apenas externo |
*/443 | Saída | TCP | VirtualNetwork / Armazenamento | Dependência do Armazenamento do Microsoft Azure para a funcionalidade principal do serviço | Interno e externo |
* / 1433 | Saída | TCP | VirtualNetwork / SQL | Acesso aos pontos de extremidade do SQL do Azure para a funcionalidade principal do serviço | Interno e externo |
*/443 | Saída | TCP | VirtualNetwork / AzureKeyVault | Acesso ao Azure Key Vault para funcionalidade principal do serviço | Interno e externo |
* / 1886, 443 | Saída | TCP | VirtualNetwork / AzureMonitor | Publicar logs e métricas de diagnóstico, integridade de recursos e Application Insights | Interno e externo |
Conectar-se a um serviço Web hospedado em uma rede virtual
Depois de conectar o serviço de Gerenciamento de API à VNET, será possível acessar os serviços de back-end dentro dela da mesma forma que com os serviços públicos. Ao criar ou editar uma API, digite o endereço IP local ou o nome do host (se um servidor DNS estiver configurado para a VNet) do seu serviço Web no campo URL do serviço Web.
Configuração de servidor DNS personalizado
No modo VNET externo, o Azure gerencia o DNS como padrão. Opcionalmente, você pode configurar um servidor DNS personalizado.
O serviço de Gerenciamento de API depende de vários serviços do Azure. Quando o Gerenciamento de API estiver hospedado em uma VNET com um servidor DNS personalizado, será necessário resolver os nomes de host desses serviços do Azure.
- Para obter diretrizes sobre a configuração de DNS personalizada, incluindo o encaminhamento para nomes de host fornecidos pelo Azure, consulte Resolução de nomes para recursos em redes virtuais do Azure.
- O acesso de saída na porta
53
é necessário para a comunicação com servidores DNS. Para mais configurações, consulteReferência de configuração de rede virtual.
Importante
Para usar servidores DNS personalizados para a VNet, configure-a antes de implantar um serviço de Gerenciamento de API nela. Caso contrário, será necessário atualizar o serviço de Gerenciamento de API sempre que você alterar os servidores DNS executando a operação de aplicação de configuração de rede.
Roteamento
- Um VIP (endereço IP público) com carga balanceada é reservado para fornecer acesso aos pontos de extremidade de Gerenciamento de API e recursos fora da VNet.
- O endereço IP público com carga balanceada podem ser encontrados na folha Visão Geral/Essentials no portal do Azure.
Para obter mais informações e considerações, consulte endereços IP do gerenciamento de API do Azure.
Endereços VIP e DIP
Os endereços DIP (IP Dinâmico) serão atribuídos a cada máquina virtual subjacente no serviço e usados para acessar os pontos de extremidade e recursos na VNet e em VNets emparelhadas. O endereço VIP (IP virtual público) do serviço de Gerenciamento de API será usado para acessar os recursos voltados para o público.
Se as listas de restrição de IP protegem recursos na VNet ou VNets emparelhadas, recomendamos especificar todo o intervalo para a sub-rede onde o serviço de Gerenciamento de API for implantado para conceder ou restringir acesso ao serviço.
Saiba mais sobre o tamanho de sub-rede recomendado.
Forçar o tráfego de túnel para o firewall local usando o ExpressRoute ou o dispositivo virtual de rede
Um túnel forçado permite redirecionar ou "forçar" todo o tráfego direcionado à Internet de sua sub-rede de volta para o local para inspeção e auditoria. Normalmente, você configura e define sua própria rota padrão (0.0.0.0/0
), forçando todo o tráfego da sub-rede do Gerenciamento de API a fluir por meio de um firewall local ou para um dispositivo virtual de rede. Esse fluxo de tráfego interrompe a conectividade com o Gerenciamento de API, uma vez que o tráfego de saída é bloqueado no local ou convertido por NAT para um conjunto irreconhecível de endereços que não funcionam mais com diversos pontos de extremidade do Azure. Você pode solucionar esse problema através dos seguintes métodos:
Habilite os pontos de extremidade de serviço na sub-rede em que o serviço de Gerenciamento de API está implantado para:
- SQL do Azure (necessário somente na região primária se o serviço de Gerenciamento de API estiver implantado em várias regiões)
- Armazenamento do Azure
- Hubs de eventos do Azure
- Azure Key Vault (necessário quando o Gerenciamento de API é implantado na plataforma
stv2
)
Ao habilitar pontos de extremidade diretamente da sub-rede pelo Gerenciamento de API para esses serviços, é possível usar a rede de backbone do Microsoft Azure, fornecendo roteamento ideal para o tráfego do serviço. No caso de pontos de extremidade de serviço com um Gerenciamento de API por túnel forçado, o tráfego para os serviços anteriores do Azure não é forçado por túnel. No entanto, o outro tráfego de dependência do serviço de Gerenciamento de API permanece em túnel forçado. Verifique se o firewall ou a solução de virtualização não bloqueia esse tráfego ou se o serviço de Gerenciamento de API pode não funcionar corretamente.
Observação
É altamente recomendável habilitar pontos de extremidade de serviço diretamente da sub-rede do Gerenciamento de API para serviços dependentes, como o SQL do Azure e o Armazenamento do Azure que dão suporte a eles. No entanto, algumas organizações podem ter requisitos para forçar o túnel de todo o tráfego da sub-rede do Gerenciamento de API. Nesse caso, configure o seu firewall ou dispositivo virtual para permitir esse tráfego. Você precisará permitir o intervalo de endereços IP completo de cada serviço dependente e manter essa configuração atualizada quando a infraestrutura do Azure for alterada. Seu serviço Gerenciamento de API também pode ter latência ou tempos limite inesperados devido ao túnel de força desse tráfego de rede.
Todo o tráfego do painel de controle da Internet para o ponto de extremidade de gerenciamento de seu serviço de Gerenciamento de API é roteado por um conjunto específico de IPs de entrada, hospedados pela marca de serviço ApiManagement. Quando o tráfego for feito por túnel forçado, as respostas não serão mapeadas simetricamente de volta a esses IPs de origem de entrada e a conectividade com o ponto de extremidade de gerenciamento será perdida. Para superar essa limitação, configure uma UDR (rota definida pelo usuário) para a marca de serviço ApiManagement com o tipo de próximo salto definido como "Internet" para direcionar o tráfego de volta para o Azure.
Observação
Permitir que o tráfego de gerenciamento do Gerenciamento de API ignore um firewall local ou uma solução de virtualização de rede não é considerado um risco de segurança significativo. A configuração recomendada para sua sub-rede de Gerenciamento de API permite o tráfego de gerenciamento de entrada na porta 3443 somente do conjunto de endereços IP do Azure abrangidos pela marca de serviço ApiManagement. A configuração de UDR recomendada é apenas para o caminho de retorno desse tráfego do Azure.
No (Modo VNet externo) o tráfego do plano de dados para clientes que tentam acessar o gateway de Gerenciamento de API e o portal do desenvolvedor da Internet também será descartado por padrão devido ao roteamento assimétrico introduzido pelo túnel forçado. Para cada cliente que requer acesso, configure uma UDR explícita com o tipo de próximo salto "Internet" para ignorar o firewall ou o dispositivo de rede virtual.
Para outras dependências do serviço de Gerenciamento de API em túnel forçado, resolva o nome do host e comunique-se com o ponto de extremidade. Estão incluídos:
- Monitoramento de integridade e métricas
- Diagnósticos do portal do Azure
- Retransmissão de SMTP
- CAPTCHA do portal do desenvolvedor
- Servidor de KMS do Azure
Para obter mais informações, consulte Referência de configuração de rede virtual.
Problemas comuns de configuração de rede
Esta seção foi movida. Confira configuração de rede virtual.
Solução de problemas
Implantação inicial malsucedida do serviço de Gerenciamento de API em uma sub-rede
- Implante uma máquina virtual na mesma sub-rede.
- Conecte na máquina virtual e valide a conectividade com um dos seguintes recursos em sua assinatura do Azure:
- Azure Storage Blob
- Banco de Dados SQL do Azure
- Tabela de armazenamento do Azure
- Azure Key Vault (para uma instância de gerenciamento de API hospedada na
stv2
plataforma)
Importante
Depois de validar a conectividade, remova todos os recursos da sub-rede antes de implantar o Gerenciamento de API nela (necessário quando o API Management está hospedado na plataforma stv1
).
Verificar status de rede
Depois de implantar o Gerenciamento de API na sub-rede, use o portal para verificar a conectividade de sua instância com dependências, como o Armazenamento do Azure.
No portal, no menu à esquerda, em Implantação e infraestrutura, selecione Rede>Status de rede.
Filtrar | Descrição |
---|---|
Obrigatório | Selecione para revisar a conectividade de serviços do Azure necessária para o Gerenciamento de API. A falha indica que a instância não é capaz de realizar operações centrais para gerenciar APIs. |
Opcional | Selecione para revisar a conectividade de serviços opcionais. A falha apenas indica que a funcionalidade específica não funcionará (por exemplo, SMTP). A falha pode levar à degradação no uso e no monitoramento da instância de Gerenciamento de API e no fornecimento do SLA comprometido. |
Para ajudar a solucionar problemas de conectividade, selecione:
Métricas: para examinar as métricas de status de conectividade de rede
Diagnosticar: para executar um verificador de rede virtual durante um período de tempo especificado
Para resolver problemas de conectividade, reveja as configurações de rede e corrija as configurações de rede necessárias.
Atualizações incrementais
Ao fazer alterações em sua rede, consulte a API NetworkStatus para verificar se o serviço de Gerenciamento de API não perdeu o acesso a recursos críticos. O status de conectividade deve ser atualizado a cada 15 minutos.
Para aplicar uma alteração de configuração de rede à instância de gerenciamento de API usando o portal:
- No menu à esquerda de sua instância, em Implementação e infraestrutura, selecione Rede>Rede virtual.
- Selecione Aplicar configuração de rede.
Links de navegação de recurso
Uma instância de APIM hospedada na stv1
plataforma de computação, quando implantada em uma sub-rede da VNet do Resource Manager, reserva a sub-rede criando um link de navegação de recurso. Se a sub-rede já contiver um recurso de outro provedor, a implantação falhará. Da mesma forma, ao excluir um serviço de Gerenciamento de API ou movê-lo para uma sub-rede diferente, o link de navegação do recurso é removido.
Desafios encontrados na reatribuição da instância do APIM para a sub-rede anterior
- Bloqueio da VNet — Ao mover uma instância do Gerenciamento de API de volta para sua sub-rede original, a reatribuição imediata pode não ser possível devido ao bloqueio da VNet, que leva até uma hora para ser removido. Se a sub-rede original tiver outros serviços
stv1
de Gerenciamento de API baseados em plataforma (baseados em serviço de nuvem), será necessário excluí-los e aguardar para implantar um serviçostv2
baseado em plataforma na mesma sub-rede. - Bloqueio de grupo de recursos - Outro cenário a ser considerado é a presença de um bloqueio de escopo no nível do grupo de recursos ou superior, dificultando o processo de Exclusão do Link de Navegação de Recursos. Para resolver isso, remova o bloqueio de escopo e espere de quatro a seis horas para que o serviço APIM desvincule-se da sub-rede original antes da remoção do bloqueio, habilitando a implantação na sub-rede desejada.
Solucionar problemas de conexão com o Microsoft Graph de dentro de uma VNet
A conectividade de rede com o Microsoft Graph é necessária para os recursos que incluem a entrada do usuário no portal do desenvolvedor usando o provedor de identidade do Microsoft Entra.
Para solucionar problemas de conectividade com o Microsoft Graph de dentro de uma VNet:
Certifique-se de que o NSG e outras regras de rede estão configuradas para conectividade de saída da sua instância de Gerenciamento de API para o Microsoft Graph (usando a marca de serviço AzureActiveDirectory).
Verifique se a resolução de DNS e o acesso à rede para
graph.microsoft.com
de dentro da VNet. Por exemplo, provisione uma nova VM dentro da VNet, conecte-se a ela e tenteGET https://graph.microsoft.com/v1.0/$metadata
de um navegador ou usando cURL, PowerShell ou outras ferramentas.
Próximas etapas
Saiba mais sobre: