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

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:

• Uso de una red virtual con Azure API Management
• Requisitos de recursos de red para la inserción de API Management en una red virtual

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

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.

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.

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.

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.

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.

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

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

  

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.

• 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.

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.

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:

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 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).

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.

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)

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.

  

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.

Vínculos de navegación de recursos

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:

• Referencia de configuración de redes virtuales
• Preguntas más frecuentes sobre la red virtual
• Creating a record in DNS (Creación de un registro en DNS)