Compartir por

Implementación de la instancia de Azure API Management en una red virtual: modo interno

  • Artigo

SE APLICA A: Desarrollador | Premium

Azure API Management se puede implementar (insertar) dentro de una red virtual (VNet) de Azure para acceder a los servicios back-end dentro de la red. Para ver las opciones, los requisitos y las consideraciones de conectividad de red virtual, consulte:

En este artículo se explica cómo configurar la conectividad de red virtual para la instancia de API Management en el modo interno. En este modo solo puede acceder a los siguientes puntos de conexión de API Management dentro de una red virtual cuyo acceso controle.

  • La puerta de enlace de API
  • Portal para desarrolladores
  • Administración directa
  • Git

Nota

  • Ninguno de los puntos de conexión de API Management está registrado en el DNS público. Los puntos de conexión permanecen inaccesibles hasta que configura DNS para la red virtual.
  • Para usar la puerta de enlace autohospedada en este modo, habilite también la conectividad privada con el punto de conexión de configuración de puerta de enlace autohospedado.

Use API Management en modo interno para:

  • Conseguir que las API hospedadas en el centro de datos privado sean accesibles para terceros desde fuera de este centro si usa conexiones de VPN de Azure o Azure ExpressRoute.
  • Puede permitir escenarios de nube híbrida exponiendo las API basadas en la nube y las API locales a través de una puerta de enlace común.
  • Administrar las API hospedadas en diversas ubicaciones geográficas, mediante un único punto de conexión de puerta de enlace.

Conexión a una red virtual interna

Para conocer las configuraciones específicas del modo externo, en el que los puntos de conexión de API Management son accesibles desde la red pública de Internet y los servicios back-end se encuentran en la red, consulte Implementación de la instancia de Azure API Management en una red virtual: modo externo.

Nota:

Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para comenzar, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Requisitos previos

Revise los requisitos de recursos de red para la inserción de API Management en una red virtual antes de empezar.

Algunos requisitos previos varían en función de la versión (stv2 o stv1) de la plataforma de proceso que hospeda la instancia de API Management.

Sugerencia

Cuando se usa el portal para crear o actualizar la conexión de red de una instancia de API Management existente, la instancia se hospeda en la plataforma de proceso stv2.

  • Una red virtual y una subred en la misma región y suscripción que la instancia de API Management.

    • La subred usada para conectarse a la instancia de API Management puede contener otros tipos de recursos de Azure.
    • La subred no debe tener ninguna delegación habilitada. La configuración Delegar subred en un servicio de la subred debe establecerse en Ninguno.

  • Un grupo de seguridad de red asociado a la subred anterior. Se requiere un grupo de seguridad de red para permitir explícitamente la conectividad de entrada, ya que el equilibrador de carga usado internamente por API Management es seguro de forma predeterminada y rechaza todo el tráfico entrante. Para obtener una configuración específica, vea Configuración de reglas de NSG más adelante en este artículo.

  • En determinados escenarios, habilite puntos de conexión de servicio en la subred a servicios dependientes, como Azure Storage o Azure SQL. Para obtener más información, vea Forzar el tráfico de túnel al firewall local mediante ExpressRoute o la aplicación virtual de red, más adelante en este artículo.

  • (Opcional) Una dirección IPv4 pública de SKU estándar.

    Importante

    • A partir de mayo de 2024, un recurso de dirección IP pública ya no es necesario al implementar (insertar) una instancia de API Management en una red virtual en modo interno o migrar la configuración de red virtual interna a una nueva subred. En el modo de red virtual externa, especificar una dirección IP pública es opcional; si no proporciona una, se configura automáticamente una dirección IP pública administrada por Azure y se usa para el tráfico de API en tiempo de ejecución. Proporcione solo la dirección IP pública si desea poseer y controlar la dirección IP pública que se usa para la comunicación entrante o saliente a Internet.

    • Si se proporciona, la dirección IP debe estar en la misma región y suscripción que la instancia de API Management y la red virtual.

    • Al crear un recurso de dirección IP pública, asegúrese de asignarle una etiqueta de nombre DNS. Normalmente, se debería usar el mismo nombre DNS que la instancia de API Management. Si lo cambia, vuelva a implementar la instancia para que se aplique la nueva etiqueta DNS.

    • Para obtener el mejor rendimiento de red, se recomienda usar la preferencia de enrutamiento predeterminada: red de Microsoft.

    • Al crear una dirección IP pública en una región en la que planea habilitar la redundancia de zona para la instancia de API Management, configure la opción Con redundancia de zona.

    • El valor de la dirección IP se asigna como la dirección IPv4 pública virtual de la instancia de API Management en esa región.

  • En el caso de las implementaciones de API Management en varias regiones, configure los recursos de la red virtual por separado para cada ubicación.

Habilitar la conexión de VNet

Habilitación de la conectividad de VNet mediante Azure Portal (plataforma stv2)

  1. Vaya a Azure Portal para buscar la instancia API Management. Busque y seleccione Servicios API Management.

  2. Elija su instancia de API Management.

  3. Seleccione Red>Red virtual.

  4. Seleccione el tipo de acceso Interno.

  5. En la lista de ubicaciones (regiones) en las que se aprovisiona el servicio API Management:

    1. Elija una ubicación.
    2. Seleccione red virtual y subred.
      • La lista de redes virtuales se rellena con redes virtuales de Resource Manager disponibles en las suscripciones a Azure configuradas en la región que va a configurar.

  6. Seleccione Aplicar. La página Red virtual de la instancia de API Management se actualiza con las opciones de red virtual y subred nueva. Configuración de una red virtual interna en Azure Portal

  7. Siga configurando los valores de red virtual para las ubicaciones restantes de la instancia de API Management.

  8. En la barra de navegación superior, seleccione Guardar.

    La instancia de API Management puede tardar entre 15 y 45 minutos en actualizarse. El nivel Desarrollador tiene tiempo de inactividad durante el proceso. Las SKU Básico y superiores no tienen tiempo de inactividad durante el proceso.

Después de que la implementación se realice correctamente, debería ver la dirección IP virtual privada y la dirección IP virtual pública del servicio API Management en el panel Información general. Para más información sobre las direcciones IP, consulte Enrutamiento en este artículo.

Direcciones IP públicas y privadas en Azure Portal

Nota

Como la dirección URL de puerta de enlace no está registrada en el DNS público, la consola de prueba disponible en Azure Portal no funcionará con un servicio implementado en una red virtual interna. En su lugar, use la consola de prueba que se ofrece en el Portal para desarrolladores.

Habilitación de la conectividad mediante una plantilla de Resource Manager (plataforma stv2)

  • Plantilla de ARM (versión de API 2021-08-01)

    Botón para implementar la plantilla de Resource Manager en Azure.

Habilitación de la conectividad mediante cmdlets de Azure PowerShell (plataforma stv1)

Cree o actualice una instancia de API Management en una red virtual.

Configuración de reglas de NSG

Configure reglas de red personalizadas en la subred de API Management para filtrar el tráfico hacia y desde la instancia de API Management. Se recomienda lo siguiente reglas mínimas de grupo de seguridad de red para garantizar el funcionamiento adecuado y el acceso a la instancia. Revise cuidadosamente el entorno para determinar más reglas que podrían ser necesarias.

Importante

En función del uso del almacenamiento en caché y otras características, es posible que tenga que configurar reglas de NSG adicionales más allá de las reglas mínimas de la tabla siguiente. Para obtener una configuración detallada, consulte Referencia de configuración de red virtual.

  • En la mayoría de los escenarios, use las etiquetas de servicio indicadas en lugar de las direcciones IP de servicio para especificar orígenes y destinos de red.
  • Establezca la prioridad de estas reglas mayor que la de las reglas predeterminadas.
Puertos de origen/destino Dirección Protocolo de transporte Etiquetas de servicio
Origen/destino		 Propósito Tipo de red virtual
* / [80], 443 Entrada TCP Internet / VirtualNetwork Comunicación de cliente con Administración de API Solo externo
* / 3443 Entrada TCP ApiManagement / VirtualNetwork Punto de conexión de administración para Azure Portal y PowerShell Externa e interna
* / 6390 Entrada TCP AzureLoadBalancer / VirtualNetwork Equilibrador de carga de la infraestructura de Azure Externa e interna
* / 443 Entrada TCP AzureTrafficManager/VirtualNetwork Enrutamiento de Azure Traffic Manager para la implementación en varias regiones Solo externo
* / 443 Salida TCP VirtualNetwork / Storage Dependencia de Azure Storage para la funcionalidad de servicio principal Externa e interna
* / 1433 Salida TCP VirtualNetwork / SQL Acceso a puntos de conexión de Azure SQL para la funcionalidad de servicio principal Externa e interna
* / 443 Salida TCP VirtualNetwork / AzureKeyVault Acceso a Azure Key Vault para la funcionalidad de servicio principal Externa e interna
* / 1886, 443 Salida TCP VirtualNetwork / AzureMonitor Publicar métricas y registros de diagnóstico, Resource Health y Application Insights Externa e interna

Configuración de DNS

En el modo de red virtual interna, tiene que administrar su propio DNS para habilitar el acceso entrante a los puntos de conexión de API Management.

Es recomendable que:

  1. Configure una zona privada de Azure DNS.
  2. Vincule la zona privada de Azure DNS a la red virtual en la que ha implementado el servicio API Management.

Aprenda a configurar una zona privada en Azure DNS.

Nota

El servicio API Management no escucha las solicitudes de sus direcciones IP. Solo responde a las solicitudes dirigidas al nombre de host establecido en los puntos de conexión. Estos puntos de conexión incluyen lo siguiente:

  • Puerta de enlace de API
  • El Portal de Azure
  • Portal para desarrolladores
  • Punto de conexión de administración directa
  • Git

Acceso de nombres de host predeterminados

Al crear un servicio de API Management (por ejemplo, contosointernalvnet) se configuran de forma predeterminada los siguientes puntos de conexión:

Punto de conexión Configuración de punto de conexión
API Gateway contosointernalvnet.azure-api.net
Portal para desarrolladores contosointernalvnet.portal.azure-api.net
Nuevo portal para desarrolladores contosointernalvnet.developer.azure-api.net
Punto de conexión de administración directa contosointernalvnet.management.azure-api.net
Git contosointernalvnet.scm.azure-api.net

Acceso de nombres de dominio personalizados

Si no quiere acceder al servicio API Management con los nombres de host predeterminados, defina nombres de dominio personalizados para todos los puntos de conexión, tal y como se indica en la siguiente ilustración:

Configuración de nombres de dominios personalizados

Configuración de los registros DNS

Cree registros en el servidor DNS para acceder a los puntos de conexión accesibles desde la red virtual. Asigne los registros de punto de conexión a la dirección IP virtual privada del servicio.

Con fines de prueba, puede actualizar el archivo de hosts en una máquina virtual de una subred conectada a la red virtual en la que se implementa API Management. Si la dirección IP virtual privada del servicio es 10.1.0.5, puede asignar el archivo de hosts de esta forma. El archivo de asignación de hosts está en %SystemDrive%\drivers\etc\hosts (Windows) /etc/hosts o (Linux, macOS).

Dirección IP virtual interna Configuración de punto de conexión
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

Así, podrá tener acceso a todos los puntos de conexión de API Management desde la máquina virtual que ha creado.

Enrutamiento

Las siguientes direcciones IP virtuales se configuran para una instancia de API Management de una red virtual interna.

Dirección IP virtual Descripción
Dirección IP virtual privada Una dirección IP con equilibrio de carga desde el intervalo de subred (DIP) de la instancia de API Management, a través de la cual puede acceder a la puerta de enlace de API, al portal para desarrolladores, a la administración y a los puntos de conexión de Git.

Registre esta dirección con los servidores DNS que usa la red virtual.
Dirección IP virtual pública Solo se usa para el tráfico del plano de control al punto de conexión de administración a través del puerto 3443. Se puede bloquear a la etiqueta de servicio ApiManagement.

Las direcciones IP privadas y públicas con equilibrio de carga pueden encontrarse en la hoja de información general de Azure Portal.

Para obtener más información y consideraciones, consulte Direcciones IP de Azure API Management.

Direcciones VIP y DIP

Se asignarán direcciones IP dinámicas (DIP) a todas las máquinas virtuales subyacentes del servicio y se usarán para acceder a los puntos de conexión y recursos en la red virtual y en las redes virtuales emparejadas. La dirección IP virtual (VIP) pública del servicio API Management se usará para acceder a recursos orientados al público.

Si los recursos dentro de la red virtual o en redes virualtes emparejadas se protegen mediante listas de restricciones de IP, recomendamos que se especifique el intervalo completo de la subred donde se implementa el servicio API Management para conceder o restringir el acceso desde el servicio.

Más información acerca del tamaño de subred recomendado.

Ejemplo

Si implementa una unidad de capacidad de API Management en el nivel Premium de una red virtual interna, se usarán tres direcciones IP: una para la IP virtual privada y una para cada uno de los DIP de dos máquinas virtuales. Si escala horizontalmente a 4 unidades, se usarán más direcciones IP para DIP adicionales de la subred.

Si el punto de conexión de destino solo tiene permitido un conjunto fijo de DIP, se producirán errores de conexión si agrega nuevas unidades en el futuro. Por este motivo y dado que la subred está totalmente bajo su control, se recomienda permitir la enumeración de toda la subred en el back-end.

Forzar la tunelización del tráfico al firewall en el entorno local mediante ExpressRoute o una aplicación virtual de red

La tunelización forzada permite redirigir o “forzar” de nuevo todo el tráfico vinculado a Internet de la subred al entorno local mediante para inspección y auditoría. Normalmente, puede configurar y definir su propia ruta predeterminada (0.0.0.0/0) que fuerza a todo el tráfico de la subred de API Management a pasar a través de un firewall local o a una aplicación virtual de red. El flujo de tráfico interrumpe la conectividad con API Management porque el tráfico saliente está bloqueado de forma local o porque se usa NAT para convertirlo en un conjunto de direcciones irreconocibles que no funcionan con varios puntos de conexión de Azure. Este problema se puede resolver con los siguientes métodos:

  • Habilite los puntos de conexión de servicio en la subred en la que se ha implementado el servicio API Management para:

    • Azure SQL (solo se requiere en la región primaria si el servicio API Management se implementa en varias regiones)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (obligatorio cuando API Management se implementa en la plataforma stv2)

    Al habilitar los puntos de conexión directamente desde la subred de API Management a estos servicios, puede utilizar la red troncal de Microsoft Azure, que proporciona un enrutamiento óptimo para el tráfico de los servicios. Si usa puntos de conexión de servicio con una API Management con túnel forzado, el tráfico de los servicios de Azure anteriores no se enruta a través de tunelización forzada. Sin embargo, el resto del tráfico de dependencia del servicio API Management se enruta con tunelización forzada. Asegúrese de que el firewall o la aplicación virtual no bloqueen este tráfico o es posible que el servicio API Management no funcione correctamente.

    Nota

    Es muy recomendable habilitar los puntos de conexión de servicio directamente desde la subred de API Management a servicios dependientes compatibles, como Azure SQL y Azure Storage. Sin embargo, algunas organizaciones pueden tener requisitos para la tunelización forzada de todo el tráfico de la subred de API Management. En este caso, asegúrese de configurar el firewall o la aplicación virtual para permitir este tráfico. Deberá permitir el intervalo de direcciones IP completo de cada servicio dependiente y mantener esta configuración actualizada cuando cambie la infraestructura de Azure. El servicio API Management también puede experimentar latencia o tiempos de espera inesperados debido a la tunelización forzada de este tráfico de red.

  • Todo el tráfico del plano de control desde Internet hasta el punto final de administración de su servicio API Management se enruta a través de un conjunto específico de direcciones IP entrantes, alojadas por API Management, abarcadas por la etiqueta de servicio de ApiManagement. Cuando el tráfico se enruta mediante tunelización forzada, las respuestas no se asignarán simétricamente a estas direcciones IP de origen entantes y se perderá la conectividad con el punto de conexión de administración. Para superar esta limitación, configure una ruta definida por el usuario (UDR) para la etiqueta del servicio ApiManagement con el tipo de próximo salto establecido en "Internet" para dirigir el tráfico a Azure.

    Nota:

    Permitir que el tráfico de administración de API Management omita un firewall en el entorno local o una aplicación virtual de red no se considera un riesgo de seguridad significativo. La configuración recomendada para la subred de API Management permite el tráfico de administración de entrada en el puerto 3443 solo desde el conjunto de direcciones IP de Azure que abarca la etiqueta de servicio ApiManagement. La configuración de UDR recomendada solo es para la ruta de acceso de retorno de este tráfico de Azure.

  • (Modo de red virtual externa) El tráfico del plano de datos de los clientes que intentan llegar desde Internet a la puerta de enlace de API Management y al portal para desarrolladores también se anulará de forma predeterminada debido al enrutamiento asimétrico introducido por la tunelización forzada. Para cada cliente que requiera acceso, configure una UDR explícita con el tipo de próximo salto establecido en “Internet” para omitir el firewall o la aplicación de red virtual.

  • Para otras dependencias del servicio API Management con tunelización forzada, resuelva el nombre de host y llegue hasta el punto de conexión. Entre ellas se incluyen las siguientes:

    • Supervisión de métricas y estado
    • Diagnósticos de Azure Portal
    • Retransmisión de SMTP
    • CAPTCHA del portal para desarrolladores
    • Servidor de KMS de Azure

Para obtener más información, consulte Referencia de configuración de Virtual Network.

Problemas comunes de configuración de red

Esta sección se ha movido. Consulte Referencia de configuración de red virtual.

Solución de problemas

Implementación inicial incorrecta del servicio API Management en una subred

  • Implemente una máquina virtual en la misma subred.
  • Conéctese a la máquina virtual y compruebe que hay conectividad a cada uno de los siguientes recursos de la suscripción de Azure:
    • Azure Storage Blob
    • Azure SQL Database
    • Tabla de Azure Storage
    • Azure Key Vault (para una instancia de API Management hospedada en la plataforma stv2)

Importante

Después de validar la conectividad, quite todos los recursos de la subred antes de implementar API Management en la subred (necesario cuando API Management se hospeda en la plataforma stv1).

Comprobación del estado de la red

  • Después de implementar API Management en la subred, use el portal para comprobar la conectividad de la instancia a dependencias como Azure Storage.

  • En el portal, en el menú izquierdo, en Implementación e infraestructura, seleccione Red>Estado de red.

    Captura de pantalla de verificación del estado de conectividad de la red en el portal.

Filter Descripción
Obligatorio Seleccione esta opción para revisar la conectividad a los servicios de Azure necesarios para API Management. Un error indica que la instancia no puede realizar operaciones básicas para administrar las API.
Opcional Seleccione esta opción para revisar la conectividad a servicios opcionales. Un error indica únicamente que la funcionalidad específica no funcionará (por ejemplo, SMTP). Un error puede provocar una degradación en la capacidad de usar y supervisar la instancia de API Management y proporcionar el Acuerdo de Nivel de Servicio confirmado.

Para ayudar a solucionar problemas de conectividad, seleccione:

  • Métricas: para revisar las métricas de estado de conectividad de red

  • Diagnóstico: para ejecutar un comprobador de red virtual durante un período de tiempo especificado

Para solucionar problemas de conectividad, revise las opciones de configuración de red y corrija la configuración de red necesaria.

Actualizaciones incrementales

Al realizar cambios en la red, consulte NetworkStatus API para validar si el servicio API Management no ha perdido el acceso a los recursos críticos. El estado de conectividad debe actualizarse cada 15 minutos.

Para aplicar un cambio de configuración de red a la instancia de API Management mediante el portal:

  1. En el menú de la izquierda de su instancia, en Implementación e infraestructura, seleccione Red>Red virtual.
  2. Seleccione Aplicar configuración de red.

Una instancia de API Management hospedada en la plataforma de proceso stv1, cuando se implementa en una subred de red virtual de Resource Manager, reserva la subred mediante la creación de un vínculo de navegación de recursos. Si la subred ya contiene un recurso de un proveedor distinto, la implementación producirá un error. De forma similar, al eliminar un servicio API Management o moverlo a una subred diferente, se quitará el vínculo de navegación de recursos.

Desafíos encontrados en la reasignación de la instancia de API Management a la subred anterior

  • Bloqueo de red virtual: al mover una instancia API Management de nuevo a su subred original, puede que no sea posible una reasignación inmediata debido al bloqueo de la red virtual, que tarda hasta una hora en quitarse. Si la subred original tiene otros servicios de API Management basados en plataforma stv1 (basados en servicios en la nube), es necesario eliminarlos y esperar para implementar un servicio basado en plataforma stv2 en la misma subred.
  • Bloqueo de grupo de recursos: otro escenario a tener en cuenta es la presencia de un bloqueo de ámbito a nivel de grupo de recursos o superior, que dificulte el proceso de eliminación de vínculos de navegación de recursos. Para resolverlo, elimine el bloqueo de ámbito y espere entre 4 y 6 horas para que el servicio API Management se desvincule de la subred original antes de eliminar el bloqueo, lo que permitirá la implementación en la subred deseada.

Solución de problemas de conexión a Microsoft Graph desde dentro de una red virtual

La conectividad de red a Microsoft Graph es necesaria para características que incluyen el inicio de sesión de usuario en el portal para desarrolladores mediante el proveedor de identidades de Microsoft Entra.

Para solucionar problemas de conectividad con Microsoft Graph desde dentro de una red virtual:

  • Asegúrese de que el grupo de seguridad de red y otras reglas de red estén configurados para la conectividad saliente desde la instancia de API Management a Microsoft Graph (mediante la etiqueta de servicio AzureActiveDirectory).

  • Compruebe la resolución DNS y el acceso a la red graph.microsoft.com desde la red virtual. Por ejemplo, aprovisione una nueva máquina virtual dentro de la red virtual, conéctese a ella e intente GET https://graph.microsoft.com/v1.0/$metadata desde un explorador o mediante cURL, PowerShell u otras herramientas.

Pasos siguientes

Más información sobre: