Partilhar via

Implantar sua instância de Gerenciamento de API do Azure em uma rede virtual - modo interno

  • Artigo

APLICA-SE A: Developer | Prémio

O Gerenciamento de API do Azure pode ser implantado (injetado) dentro de uma rede virtual do Azure (VNet) para acessar serviços de back-end dentro da rede. Para opções, requisitos e considerações de conectividade de rede virtual, consulte:

Este artigo explica como configurar a conectividade VNet para sua instância de Gerenciamento de API no modo interno . Nesse modo, você só pode acessar os seguintes pontos de extremidade de Gerenciamento de API dentro de uma VNet cujo acesso você controla.

  • O gateway da API
  • O portal do desenvolvedor
  • Gestão direta
  • Git

Nota

  • Nenhum dos pontos de extremidade de Gerenciamento de API está registrado no DNS público. Os pontos de extremidade permanecem inacessíveis até que você configure o DNS para a rede virtual.
  • Para usar o gateway auto-hospedado nesse modo, habilite também a conectividade privada para o ponto de extremidade de configuração do gateway auto-hospedado.

Use o Gerenciamento de API no modo interno para:

  • Torne as APIs hospedadas em seu datacenter privado acessíveis com segurança por terceiros fora dele usando conexões de VPN do Azure ou a Rota Expressa do Azure.
  • Habilite cenários de nuvem híbrida expondo suas APIs baseadas em nuvem e APIs locais por meio de um gateway comum.
  • Gerencie suas APIs hospedadas em vários locais geográficos, usando um único ponto de extremidade de gateway.

Conectar-se à rede virtual interna

Para configurações específicas para o modo externo , onde os pontos de extremidade de Gerenciamento de API são acessíveis a partir da Internet pública e os serviços de back-end estão localizados na rede, consulte Implantar sua instância de Gerenciamento de API do Azure em uma rede virtual - modo externo.

Nota

Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.

Pré-requisitos

Analise os requisitos de recursos de rede para injeção de gerenciamento de API em uma rede virtual antes de começar.

Alguns pré-requisitos diferem dependendo da versão (stv2 ou stv1) da plataforma de computação que hospeda sua instância de Gerenciamento de API.

Gorjeta

Quando você usa o portal para criar ou atualizar a conexão de rede de uma instância de Gerenciamento de API existente, a instância é hospedada stv2 na plataforma de computação.

  • Uma instância de gerenciamento de API. Para obter mais informações, consulte Criar uma instância de Gerenciamento de API do Azure.

  • Uma rede virtual e uma sub-rede na mesma região e assinatura que sua instância de 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 Nenhum.

  • 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, porque o balanceador de carga usado internamente pelo Gerenciamento de API é seguro por padrão e rejeita todo o tráfego de entrada. Para configuração específica, consulte Configurar regras NSG, mais adiante neste artigo.

  • Para determinados cenários, habilite pontos de extremidade de serviço na sub-rede para serviços dependentes, como o Armazenamento do Azure ou o Azure SQL. Para obter mais informações, consulte Forçar tráfego de túnel para firewall local usando a Rota Expressa ou o dispositivo virtual de rede, mais adiante neste artigo.

  • (Opcional) Um endereço IPv4 público SKU padrão.

    Importante

    • A partir de maio de 2024, um recurso de endereço IP público não será mais necessário ao implantar (injetar) uma instância de Gerenciamento de API em uma VNet no modo interno ou ao migrar a configuração de VNet interna para uma nova sub-rede. No modo VNet externo, 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 o tráfego da API de tempo de execução. Forneça o endereço IP público apenas se quiser possuir e controlar o endereço IP público usado para comunicação de entrada ou 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, certifique-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á-lo, 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 de roteamento padrão: rede 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, configure a configuração Redundante 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 implantações de Gerenciamento de API de várias regiões, configure os recursos de rede virtual separadamente para cada local.

Habilitar conexão VNet

Habilitar a conectividade VNet usando o portal do Azure (stv2 plataforma)

  1. Vá para o portal do Azure para localizar sua instância de gerenciamento de API. Pesquise e selecione serviços de Gerenciamento de API.

  2. Escolha sua instância de Gerenciamento de API.

  3. Selecione Rede>Virtual de rede.

  4. Selecione o tipo de acesso interno .

  5. Na lista de locais (regiões) onde o serviço de Gerenciamento de API é provisionado:

    1. Escolha uma Localização.
    2. Selecione Rede virtual e Sub-rede.
      • A lista de VNet é preenchida com VNets do Resource Manager disponíveis em suas assinaturas do Azure, configuradas na região que você está configurando.

  6. Selecione Aplicar. A página Rede virtual da sua instância de Gerenciamento de API é atualizada com suas novas opções de VNet e sub-rede. Configurar a rede virtual interna no portal do Azure

  7. Continue definindo as configurações de VNet para os locais restantes da sua instância de Gerenciamento de API.

  8. Na barra de navegação superior, selecione Guardar.

    Pode levar de 15 a 45 minutos para atualizar a instância de Gerenciamento de API. A camada de desenvolvedor tem tempo de inatividade durante o processo. Os SKUs do escalão Básico e superior não têm tempo de inatividade durante o processo.

Após a implantação bem-sucedida, você verá o endereço IP virtual privado e o endereço IP virtual público do serviço de Gerenciamento de API na folha Visão geral. Para obter mais informações sobre os endereços IP, consulte Roteamento neste artigo.

IP público e privado endereçado no portal do Azure

Nota

Como a URL do gateway não está registrada no DNS público, o console de teste disponível no portal do Azure não funcionará para um serviço implantado de VNet interno . Em vez disso, use o console de teste fornecido no portal do desenvolvedor.

Habilitar a conectividade usando um modelo do Gerenciador de Recursos (stv2 plataforma)

Habilitar a conectividade usando cmdlets do Azure PowerShell (stv1 plataforma)

Crie ou atualize uma instância de Gerenciamento de API em uma rede virtual.

Configurar as regras do NSG

Configure regras de rede personalizadas na sub-rede Gerenciamento de API para filtrar o tráfego de e para sua instância de Gerenciamento de API. Recomendamos as seguintes regras mínimas do NSG para garantir a operação e o acesso adequados à sua instância. Analise seu ambiente cuidadosamente para determinar mais regras que podem ser necessárias.

Importante

Dependendo do uso de cache e outros recursos, talvez seja necessário configurar regras NSG adicionais além das regras mínimas na tabela a seguir. Para obter definições detalhadas, consulte Referência de configuração de rede virtual.

  • Para a maioria dos cenários, use as tags de serviço indicadas em vez de endereços IP de serviço para especificar fontes e destinos de rede.
  • Defina a prioridade dessas regras maior do que a das regras padrão.
Porta(s) de Origem/Destino Direção Protocolo de transporte Etiquetas de serviço
Origem / Destino		 Propósito Tipo de VNet
* / [80], 443 Interna TCP Internet / VirtualNetwork Comunicação do cliente com o Gerenciamento de API Apenas externo
* / 3443 Interna TCP ApiManagement / Rede Virtual Ponto de extremidade de gerenciamento para o portal do Azure e o PowerShell Externo e Interno
*/6390 Entrada TCP AzureLoadBalancer/VirtualNetwork Azure Infrastructure Load Balancer Externo e Interno
*/443 Interna TCP AzureTrafficManager / VirtualNetwork Roteamento do Azure Traffic Manager para implantação em várias regiões Apenas externo
*/443 Saída TCP VirtualNetwork/Armazenamento Dependência do Armazenamento do Azure para a funcionalidade de serviço principal Externo e Interno
*/1433 Saída TCP VirtualNetwork/SQL Acesso aos pontos de extremidade SQL do Azure para a funcionalidade de serviço principal Externo e Interno
*/443 Saída TCP VirtualNetwork / AzureKeyVault Acesso ao Cofre da Chave do Azure para a funcionalidade principal do serviço Externo e Interno
* / 1886, 443 Saída TCP VirtualNetwork / AzureMonitor Publique logs e métricas de diagnóstico, integridade de recursos e insights de aplicativos Externo e Interno

Configuração do DNS

No modo de VNet interna, tem de gerir o seu próprio DNS para permitir o acesso de entrada aos pontos finais da Gestão de API.

É recomendável:

  1. Configure uma zona privada do DNS do Azure.
  2. Associe a zona privada do DNS do Azure à VNet na qual implementou o serviço de Gestão de API.

Saiba como configurar uma zona privada no DNS do Azure.

Nota

O serviço de Gerenciamento de API não escuta solicitações em seus endereços IP. Ele só responde a solicitações para o nome do host configurado em seus pontos de extremidade. Estes parâmetros de avaliação incluem:

  • Gateway de API
  • O portal do Azure
  • O portal do desenvolvedor
  • Ponto final de gerenciamento direto
  • Git

Acesso em nomes de host padrão

Quando você cria um serviço de Gerenciamento de API (contosointernalvnet, por exemplo), os seguintes pontos de extremidade são configurados por padrão:

Ponto final Configuração do ponto final
Gateway de API contosointernalvnet.azure-api.net
Portal do programador contosointernalvnet.portal.azure-api.net
O novo portal do desenvolvedor contosointernalvnet.developer.azure-api.net
Ponto final de gerenciamento direto contosointernalvnet.management.azure-api.net
Git contosointernalvnet.scm.azure-api.net

Acesso em nomes de domínio personalizados

Se você não quiser acessar o serviço de Gerenciamento de API com os nomes de host padrão, configure nomes de domínio personalizados para todos os seus pontos de extremidade, conforme mostrado na imagem a seguir:

Configurar nome de domínio personalizado

Configurar registos DNS

Crie registos no servidor DNS para aceder aos pontos finais acessíveis a partir da sua VNet. Mapeie os registros de ponto de extremidade para o endereço IP virtual privado do seu serviço.

Para fins de teste, você pode atualizar o arquivo hosts em uma máquina virtual em uma sub-rede conectada à VNet na qual o Gerenciamento de API é implantado. Supondo que o endereço IP virtual privado para o seu serviço é 10.1.0.5, você pode mapear o arquivo hosts da seguinte maneira. O arquivo de mapeamento de hosts está em %SystemDrive%\drivers\etc\hosts (Windows) ou /etc/hosts (Linux, macOS).

Endereço IP virtual interno Configuração do ponto final
10.1.0.5 contosointernalvnet.azure-api.net
10.1.0.5 contosointernalvnet.portal.azure-api.net
10.1.0.5 contosointernalvnet.developer.azure-api.net
10.1.0.5 contosointernalvnet.management.azure-api.net
10.1.0.5 contosointernalvnet.scm.azure-api.net

Em seguida, você pode acessar todos os pontos de extremidade do Gerenciamento de API a partir da máquina virtual que você criou.

Encaminhamento

Os seguintes endereços IP virtuais são configurados para uma instância de Gerenciamento de API em uma rede virtual interna.

Endereço IP virtual Description
Endereço IP virtual privado Um endereço IP com balanceamento de carga dentro do intervalo de sub-redes (DIP) da instância de Gerenciamento de API, no qual você pode acessar o gateway de API, o portal do desenvolvedor, o gerenciamento e os pontos de extremidade Git.

Registe este endereço com os servidores DNS utilizados pela rede virtual.
Endereço IP virtual público Usado apenas para controlar o tráfego do plano para o ponto de extremidade de gerenciamento pela porta 3443. Pode ser bloqueado para a tag de serviço ApiManagement .

Os endereços IP públicos e privados com balanceamento de carga podem ser encontrados na folha Visão geral 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 IP dinâmicos (DIP) serão atribuídos a cada máquina virtual subjacente no serviço e usados para acessar pontos de extremidade e recursos na VNet e em VNets emparelhadas. O endereço IP virtual público (VIP) do serviço de Gerenciamento de API será usado para acessar recursos voltados para o público.

Se a restrição de IP listar recursos seguros dentro da VNet ou VNets emparelhadas, recomendamos especificar todo o intervalo de sub-redes onde o serviço de Gerenciamento de API é implantado para conceder ou restringir o acesso do serviço.

Saiba mais sobre o tamanho de sub-rede recomendado.

Exemplo

Se você implantar 1 unidade de capacidade de Gerenciamento de API na camada Premium em uma VNet interna, 3 endereços IP serão usados: 1 para o VIP privado e um para cada DIPs para duas VMs. Se você expandir para 4 unidades, mais IPs serão consumidos para DIPs adicionais da sub-rede.

Se o ponto de extremidade de destino tiver permitido listar apenas um conjunto fixo de DIPs, falhas de conexão resultarão se você adicionar novas unidades no futuro. Por esse motivo e como a sub-rede está inteiramente sob seu controle, recomendamos permitir a listagem de toda a sub-rede no back-end.

Forçar o tráfego do túnel para o firewall local usando a Rota Expressa ou o dispositivo virtual de rede

O tunelamento forçado permite redirecionar ou "forçar" todo o tráfego ligado à Internet da sua sub-rede de volta para o local para inspeção e auditoria. Geralmente, você configura e define sua própria rota padrão (0.0.0.0/0), forçando todo o tráfego da sub-rede de Gerenciamento de API a fluir através de um firewall local ou para um dispositivo virtual de rede. Esse fluxo de tráfego interrompe a conectividade com o Gerenciamento de API, já que o tráfego de saída é bloqueado no local ou NAT para um conjunto irreconhecível de endereços que não funcionam mais com vários pontos de extremidade do Azure. Você pode resolver esse problema através dos seguintes métodos:

  • Habilite pontos de extremidade de serviço na sub-rede na qual o serviço de Gerenciamento de API é implantado para:

    • Azure SQL (necessário apenas na região primária se o serviço de Gerenciamento de API for implantado em várias regiões)
    • Armazenamento do Azure
    • Azure Event Hubs
    • Azure Key Vault (necessário quando o Gerenciamento de API é implantado stv2 na plataforma)

    Ao habilitar pontos de extremidade diretamente da sub-rede Gerenciamento de API para esses serviços, você pode usar a rede de backbone do Microsoft Azure, fornecendo roteamento ideal para o tráfego de serviço. Se você usar pontos de extremidade de serviço com um Gerenciamento de API com túnel forçado, o tráfego para os serviços anteriores do Azure não será encapsulado à força. No entanto, o outro tráfego de dependência do serviço de Gerenciamento de API permanece forçado em túnel. Verifique se o firewall ou o dispositivo virtual não bloqueia esse tráfego ou se o serviço de Gerenciamento de API pode não funcionar corretamente.

    Nota

    É altamente recomendável habilitar pontos de extremidade de serviço diretamente da sub-rede de Gerenciamento de API para serviços dependentes, como o SQL do Azure e o Armazenamento do Azure, que oferecem 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 de Gerenciamento de API. Nesse caso, certifique-se de configurar seu firewall ou dispositivo virtual para permitir esse tráfego. Você precisará permitir o intervalo completo de endereços IP de cada serviço dependente e manter essa configuração atualizada quando a infraestrutura do Azure for alterada. Seu serviço de Gerenciamento de API também pode enfrentar latência ou tempos limite inesperados devido ao túnel de força desse tráfego de rede.

  • Todo o tráfego do plano de controle da Internet para o ponto de extremidade de gerenciamento do seu serviço de Gerenciamento de API é roteado por meio de um conjunto específico de IPs de entrada, hospedados pelo Gerenciamento de API, englobado pela tag de serviço ApiManagement. Quando o tráfego é forçado a fazer um túnel, as respostas não serão mapeadas simetricamente para estes IPs de origem de entrada e a conectividade ao ponto final de gestão é perdida. Para superar essa limitação, configure uma rota definida pelo usuário (UDR) 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.

    Nota

    Permitir que o tráfego de gerenciamento do Gerenciamento de API ignore um firewall local ou um dispositivo virtual 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 incluídos pela marca de serviço ApiManagement. A configuração UDR recomendada é apenas para o caminho de retorno desse tráfego do Azure.

  • (Modo VNet externo) O tráfego de 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 um UDR explícito com o próximo salto tipo "Internet" para ignorar o firewall ou o dispositivo de rede virtual.

  • Para outras dependências do serviço Force Tunneled API Management, resolva o nome do host e entre em contato com o ponto de extremidade. Estes são, entre outros:

    • Métricas e monitoramento de integridade
    • Diagnóstico do portal do Azure
    • Retransmissão SMTP
    • Portal do desenvolvedor CAPTCHA
    • Servidor 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 secção mudou-se. Consulte Referência de configuração de rede virtual.

Resoluçã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-se à máquina virtual e valide a conectividade com um de cada um dos seguintes recursos em sua assinatura do Azure:
    • Blob de armazenamento do Azure
    • Base de Dados SQL do Azure
    • Tabela de Armazenamento do Azure
    • Azure Key Vault (para uma instância de Gerenciamento de API hospedada stv2 na plataforma)

Importante

Depois de validar a conectividade, remova todos os recursos na sub-rede antes de implantar o Gerenciamento de API na sub-rede (necessário quando o stv1 Gerenciamento de API estiver hospedado na plataforma).

Verificar o estado da rede

  • Depois de implantar o Gerenciamento de API na sub-rede, use o portal para verificar a conectividade da sua instância com dependências, como o Armazenamento do Azure.

  • No portal, no menu à esquerda, em Implantação e infraestrutura, selecione >Status da rede de rede.

    Captura de ecrã a mostrar a verificação do estado da conectividade de rede no portal.

Filtro Description
Obrigatório Selecione esta opção para revisar a conectividade de serviços do Azure necessária para o Gerenciamento de API. Falha indica que a instância não consegue executar operações principais para gerenciar APIs.
Opcional Selecione esta opção para revisar a conectividade de serviços opcionais. Falha indica apenas que a funcionalidade específica não funcionará (por exemplo, SMTP). Uma falha pode levar à degradação no uso e 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 revisar 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 definições de configuração de rede e corrija as definições de rede necessárias.

Atualizações incrementais

Ao fazer alterações na 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 da 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:

  1. No menu à esquerda da sua instância, em Implantação e infraestrutura, selecione Rede>virtual.
  2. Selecione Aplicar configuração de rede.

Uma instância de Gerenciamento de API hospedada na plataforma de computação, quando implantada stv1 em uma sub-rede VNet do Resource Manager, reserva a sub-rede criando um link de navegação de recursos. Se a sub-rede já contiver um recurso de um provedor diferente, a implantação falhará. Da mesma forma, quando você exclui um serviço de Gerenciamento de API ou o move para uma sub-rede diferente, o link de navegação de recursos será removido.

Desafios encontrados na reatribuição da instância de Gerenciamento de API à sub-rede anterior

  • Bloqueio de VNet - Ao mover uma instância de Gerenciamento de API de volta para sua sub-rede original, a reatribuição imediata pode não ser possível devido ao bloqueio de VNet, que leva até uma hora para ser removido. Se a sub-rede original tiver outros stv1 serviços de Gerenciamento de API baseados em plataforma (baseados em serviço de nuvem), excluí-los e aguardar será necessário para implantar um stv2 serviço baseado em plataforma na mesma sub-rede.
  • Bloqueio de grupo de recursos - Outro cenário a considerar é a presença de um bloqueio de escopo no nível do grupo de recursos ou superior, dificultando o processo de Exclusão de Link de Navegação de Recursos. Para resolver isso, remova o bloqueio de escopo e permita um atraso de aproximadamente 4 a 6 horas para que o serviço de Gerenciamento de API seja desvinculado da sub-rede original antes da remoção do bloqueio, permitindo a implantação na sub-rede desejada.

Solucionar problemas de conexão com o Microsoft Graph de dentro de uma rede virtual

A conectividade de rede com o Microsoft Graph é necessária para recursos, incluindo a entrada do usuário no portal do desenvolvedor usando o provedor de identidade Microsoft Entra.

Para solucionar problemas de conectividade com o Microsoft Graph de dentro de uma rede virtual:

  • Certifique-se de que o NSG e outras regras de rede estejam configurados para conectividade de saída da sua instância de Gerenciamento de API para o Microsoft Graph (usando a marca de serviço AzureActiveDirectory ).

  • Garanta a resolução de DNS e o acesso à rede a graph.microsoft.com partir da rede virtual. Por exemplo, provisione uma nova VM dentro da VNet, conecte-se a ela e tente fazê-lo a GET https://graph.microsoft.com/v1.0/$metadata partir de um navegador ou usando cURL, PowerShell ou outras ferramentas.

Próximos passos

Saiba mais sobre: