Compartir vía

Opciones de redes de Azure Functions

  • Artículo

En este artículo se describen las características de redes disponibles en las opciones de hospedaje de Azure Functions. Todas las opciones de redes siguientes ofrecen la posibilidad de acceder a recursos sin usar direcciones enrutables de Internet o de restringir el acceso a Internet a una aplicación de funciones.

Los modelos de hosting tienen diferentes niveles de aislamiento de red disponibles. Elegir el correcto le ayuda a cumplir los requisitos de aislamiento de red que tenga.

Característica Plan de consumo Plan de Consumo flexible Plan Premium Plan dedicado/ASE Aplicaciones de contenedor*
Restricciones de IP de entrada ✅Sí ✅Sí ✅Sí ✅Sí ✅Sí
Puntos de conexión privados entrantes ❌No ✅Sí ✅Sí ✅Sí ❌No
Integración de redes virtuales ❌No ✅Sí (regional) ✅Sí (regional) ✅Sí (regional y puerta de enlace) ✅Sí
Desencadenadores de red virtual (no HTTP) ❌No ✅Sí ✅Sí ✅Sí ✅Sí
Conexiones híbridas (solo Windows) ❌No ❌ No ✅Sí ✅Sí ❌No
Restricciones de IP de salida ❌No ✅Sí ✅Sí ✅Sí ✅Sí

*Para más información, consulte Redes en el entorno de Azure Container Apps.

Recursos de inicio rápido

Use los siguientes recursos para empezar a trabajar rápidamente con escenarios de red de Azure Functions. Se hace referencia a estos recursos a lo largo del artículo.

Características de redes de entrada

Las siguientes características permiten filtrar las solicitudes entrantes a la aplicación de funciones.

Restricciones de acceso de entrada

Puede usar restricciones de acceso para definir una lista de direcciones IP ordenadas por prioridad a las que se les permite o deniega el acceso a la aplicación. La lista puede incluir direcciones IPv4 e IPv6, bien o subredes de red virtual específicas con puntos de conexión de servicio. Si hay una o varias entradas, existe un "denegar a todos" implícito al final de la lista. Las restricciones de IP funcionan con todas las opciones de hospedaje de funciones.

Las restricciones de acceso están disponibles en el plan de Consumo flexible, Elástico Premium, Consumoy App Service.

Nota:

Con las restricciones de red vigentes, solo puede implementar desde la red virtual o si ha incluido en la lista de destinatarios seguros la dirección IP del equipo que usa para acceder a Azure Portal. Sin embargo, todavía puede administrar la función en el portal.

Para obtener más información, consulte Restricciones de acceso estático de Azure App Service.

Puntos de conexión privados

Un punto de conexión privado de Azure es una interfaz de red que nos conecta de forma privada y segura a un servicio por medio de la tecnología Azure Private Link. Los puntos de conexión privados emplean una dirección IP privada de la red virtual, lo que hace que el servicio se incluya en la red virtual.

Puede usar el punto de conexión privado para las funciones hospedadas en los planes Premium y App Service.

Si quiere realizar llamadas a los puntos de conexión privados, debe asegurarse de que las búsquedas de DNS se resuelvan en el punto de conexión privado. Puede aplicar este comportamiento de una de las siguientes formas:

  • Realizar la integración con zonas privadas de Azure DNS. Cuando la red virtual no tiene un servidor DNS personalizado, esto se hace automáticamente.
  • Administrar el punto de conexión privado en el servidor DNS que usa la aplicación. Para ello, debe conocer la dirección del punto de conexión privado y, a continuación, apuntar el punto de conexión al que está intentando acceder a esa dirección con un registro A.
  • Configurar su propio servidor DNS para reenviarlo a zonas privadas de Azure DNS.

Para más información, consulte cómo usar puntos de conexión privados para aplicaciones web.

Para llamar a otros servicios que tienen una conexión de punto de conexión privado, como Storage Bus o Services Bus, asegúrese de configurar la aplicación para que haga llamadas salientes a puntos de conexión privados. Para obtener más información sobre el uso de puntos de conexión privados con la cuenta de almacenamiento de la aplicación de funciones, visite Restricción de la cuenta de almacenamiento a una red virtual.

Puntos de conexión del servicio

Mediante el uso de puntos de conexión de servicio, puede restringir varios servicios de Azure a las subredes de redes virtuales que se han seleccionado para proporcionar un mayor nivel de seguridad. La integración de red virtual regional le permite a la aplicación de funciones acceder a los servicios de Azure que están protegidos con puntos de conexión de servicio. Esta configuración es compatible con todos los planes que admiten la integración de redes virtuales. Para acceder a un servicio protegido mediante puntos de conexión de servicio, debe hacer lo siguiente:

  1. Configure la integración de red virtual regional con la aplicación de funciones para conectarse a una subred específica.
  2. Vaya al servicio de destino y configure los puntos de conexión de servicio en la subred de integración.

Para más información, consulte Puntos de conexión de servicio de red virtual.

Uso de los puntos de conexión de servicio

Para restringir el acceso a una subred específica, cree una regla de restricción con un tipo Virtual Network. Después, puede seleccionar la suscripción, la red virtual y la subred a las que desea permitir o denegar el acceso.

Si los puntos de conexión de servicio ya no están habilitados con Microsoft.Web para la subred seleccionada, se habilitan automáticamente a menos que active la casilla Omitir los puntos de conexión de servicio de Microsoft.Web que faltan. La situación en la que convendría habilitar puntos de conexión de servicio en la aplicación pero no en la subred depende fundamentalmente de si se tienen los permisos para habilitarlos en la subred.

Si necesita que otra persona habilite los puntos de conexión de servicio en la subred, active la casilla Omitir los puntos de conexión de servicio de Microsoft.Web que faltan. La aplicación se configura para los puntos de conexión de servicio en previsión de que se habiliten posteriormente en la subred.

Captura de pantalla del panel

No puede usar puntos de conexión de servicio para restringir el acceso a las aplicaciones que se ejecutan en un entorno App Service Environment. Si la aplicación está en un entorno App Service Environment, puede controlar el acceso a ella con reglas de acceso de IP.

Para más información sobre cómo configurar los puntos de conexión de servicio, consulte Establecimiento del acceso a un sitio privado de Azure Functions.

Integración de la red virtual

La integración de red virtual permite que la aplicación de funciones acceda a recursos dentro de una red virtual. Azure Functions admite dos tipos de integración de redes virtuales:

  • Los planes de tarifa de proceso dedicados, que incluyen los niveles Básico, Estándar, Premium, Premium v2 y Premium v3.
  • App Service Environment que se implementa directamente en la red virtual con una infraestructura de soporte técnico dedicada y usa los planes de tarifa Aislado y Aislado v2.

La característica de integración en red virtual se usa en planes de tarifa de proceso dedicado de Azure App Service. Si la aplicación está en App Service Environment, ya forma parte de una red virtual y no requiere el uso de la característica Integración con red virtual para acceder a recursos en la misma red virtual. Para más información sobre todas las características de redes, consulte Características de redes de App Service.

Integración con red virtual proporciona a la aplicación acceso a los recursos de la red virtual, pero no concede acceso privado de entrada a la aplicación desde esa red virtual. El acceso privado a sitios se refiere a que solo se puede acceder a la aplicación desde una red privada; por ejemplo, desde dentro de una red virtual de Azure. Integración de Virtual Network solo se usa para realizar llamadas salientes de la aplicación a la red virtual. La característica integración de red virtual se comporta de forma distinta con redes virtuales de la misma región que con redes virtuales de otras regiones. La característica de integración de red virtual tiene dos variaciones:

  • Integración con red virtual regional: cuando se conecta a redes virtuales de la misma región, debe tener una subred dedicada en la red virtual con la que se va a realizar la integración.
  • Integración con red virtual con requisito de puerta de enlace: cuando se conecta directamente a redes virtuales de otras regiones o a una red virtual clásica de la misma región, necesita una puerta de enlace de Azure Virtual Network creada en la red virtual de destino.

La característica de integración de red virtual:

  • Necesita un plan de precios Básico o Estándar admitido, Premium, Premium v2, Premium v3 o Elástico Premium de App Service.
  • Es compatible con TCP y UDP.
  • Funciona con aplicaciones de App Service y de Functions.

Hay algunos aspectos que la integración de red virtual no admite, como:

  • Montar una unidad.
  • Unión al dominio de Windows Server Active Directory.
  • NetBIOS.

Integración con red virtual con requisito de puerta de enlace solo proporciona acceso a los recursos de la red virtual de destino o de las redes conectadas a esta que tienen emparejamiento o redes privadas virtuales. La integración con red virtual con requisito de puerta de enlace no permite acceder a los recursos disponibles en las conexiones de Azure ExpressRoute ni trabajar con puntos de conexión de servicio.

Independientemente de la versión que se use, la integración con red virtual proporciona a la aplicación acceso a los recursos de la red virtual, pero no concede acceso privado de entrada a la aplicación desde esa red virtual. El acceso privado a sitios se refiere a que solo se puede acceder a la aplicación desde una red privada (por ejemplo, desde dentro de una red virtual de Azure). La integración de red virtual solo sirve para realizar llamadas salientes desde la aplicación a la red virtual.

La integración de red virtual de Azure Functions usa una infraestructura compartida con las aplicaciones web de App Service. Para obtener más información sobre los dos tipos de integración de red virtual, vea:

Para obtener información sobre cómo configurar la integración de red virtual, consulte Habilitación de la integración con red virtual.

Habilitación de la integración de red virtual

  1. En la aplicación de funciones, en el Azure Portal, seleccione Redes y, en Integración de VNet, seleccione Haga clic aquí para configurar.

  2. Seleccione Agregar VNET.

    Selección de Integración con red virtual

  3. La lista desplegable contiene todas las redes virtuales de Azure Resource Manager de la suscripción en la misma región. Seleccione la red virtual con la que quiere realizar la integración.

    Seleccione la red virtual.

    • Los planes de Functions Consumo flexible y Elástico Premium solo admiten la integración de redes virtuales regionales. Si la red virtual está en la misma región, cree una nueva subred o seleccione una subred vacía preexistente.

    • Para seleccionar una red virtual de otra región, necesita una puerta de enlace de red virtual aprovisionada con la conectividad de punto a sitio habilitada. La integración de red virtual entre regiones solo se admite para los Planes dedicados, pero los emparejamientos globales funcionan con la integración de red virtual regional.

Durante la integración, la aplicación se reinicia. Una vez finalizada la integración, verá los detalles de la red virtual con la que está integrado. De manera predeterminada, la opción Enrutar todo está habilitada, y todo el tráfico se enruta a la red virtual.

Si desea que solo se enrute el tráfico privado (tráfico RFC1918), siga los pasos descritos en la documentación de servicio de aplicaciones.

Integración de red virtual regional

Cuando se utiliza la integración de red virtual regional, la aplicación puede acceder a:

  • Recursos de la misma red virtual que la aplicación.
  • Recursos de las redes virtuales emparejadas con la red virtual con la que se integra la aplicación.
  • Servicios protegidos mediante puntos de conexión de servicio.
  • Recursos de diferentes conexiones de Azure ExpressRoute.
  • Recursos en conexiones emparejadas, lo que incluye conexiones de Azure ExpressRoute.
  • Puntos de conexión privados

Si usa la integración de red virtual regional, puede utilizar las siguientes características de redes de Azure:

  • Grupos de seguridad de red (NSG) : el tráfico saliente se puede bloquear con un grupo de seguridad de red que se encuentre en la subred de integración. Las reglas de entrada no se aplican, ya que la integración de red virtual no se puede usar para proporcionar acceso de entrada a la aplicación.
  • Tablas de enrutamiento (UDR) : puede colocar una tabla de enrutamiento en la subred de integración para enviar el tráfico de salida donde quiera.

Nota

Cuando enruta todo el tráfico de salida a la red virtual, este estará sujeto a los grupos de seguridad de red y las rutas definidas por los usuarios que se apliquen a la subred de integración. Cuando se integra la red virtual, el tráfico de salida de aplicación de funciones a las direcciones IP públicas sigue enviándose desde las direcciones que se muestran en las propiedades de la aplicación, a menos que proporcione rutas que dirijan el tráfico a otro lugar.

La integración de red virtual regional no puede usar el puerto 25.

Para el plan de Consumo flexible:

  1. Asegúrese de que el proveedor de recursos de Azure Microsoft.App esté habilitado para la suscripción siguiendo estas instrucciones. La delegación de subred requerida por las aplicaciones de Consumo flexible es Microsoft.App/environments.
  2. La delegación de subred requerida por las aplicaciones de Consumo flexible es Microsoft.App/environments. Se trata de un cambio de Elástico Premium y App Service que tienen un requisito de delegación diferente.
  3. Puede planificar que se usen 40 direcciones IP como máximo para una aplicación de funciones, incluso si la aplicación se escala más allá de 40. Por ejemplo, si tiene quince aplicaciones de funciones de Consumo flexible que se integrarán en la misma subred, puede planear 15x40 = 600 direcciones IP usadas como máximo. Este límite está sujeto a cambios y no se aplica.
  4. La subred aún no se puede usar para otros fines (como puntos de conexión de servicio o privados o delegados a cualquier otro plan de hosting o servicio). Aunque puede compartir la misma subred con varias aplicaciones de Consumo flexible, los recursos de red se compartirán en estas aplicaciones de funciones y esto puede provocar que una aplicación de función afecte al rendimiento de otros usuarios de la misma subred.

Existen algunas limitaciones cuando se usa la red virtual:

  • La característica está disponible en Consumo Flexible, Elástico Premium y App Service Premium V2 y Premium V3. También está disponible en Estándar, pero solo desde las implementaciones de App Service más recientes. Si está en una implementación anterior, solo puede usar la característica desde un plan de App Service Premium V2. Si quiere estar seguro de que puede usar la característica en un plan de App Service Estándar, cree la aplicación en un plan de App Service Premium V3. Esos planes solo se admiten en las implementaciones más recientes. Si quiere, después puede reducir verticalmente.
  • La subred de integración solo puede usarla un plan de App Service.
  • Las aplicaciones del plan Aislado que estén en una instancia de App Service Environment no pueden usar la característica.
  • La característica requiere una subred sin usar que sea /28 o mayor en una red virtual de Azure Resource Manager.
  • Tanto la aplicación como la red virtual deben estar en la misma región.
  • No se pueden eliminar redes virtuales que tengan aplicaciones integradas. Quite la integración antes de eliminar la red virtual.
  • Puede tener hasta dos integraciones de red virtual regional por plan de App Service. Varias aplicaciones del mismo plan de App Service pueden usar la misma subred de integración.
  • No se puede cambiar la suscripción de una aplicación o de un plan mientras haya una aplicación que use la integración de red virtual regional.

Subredes

La integración de red virtual depende de una subred dedicada. Al aprovisionar una subred, la subred de Azure pierde cinco direcciones IP desde el inicio. Para los planes Elástico Premium y App Service, se usa una dirección de la subred de integración para cada instancia de plan. Si escala la aplicación a cuatro instancias, se usan cuatro direcciones. Para Consumo Flexible, esto no se aplica y las instancias comparten direcciones IP.

Al escalar o reducir verticalmente el tamaño, el espacio de direcciones necesario se duplica durante un breve período de tiempo. Esto afecta a las instancias admitidas reales y disponibles para un tamaño de subred determinado. En la tabla siguiente se muestran las direcciones máximas disponibles por bloque CIDR y el impacto que esto tiene en la escala horizontal:

Tamaño de bloque CIDR Número máximo de direcciones disponibles Escala horizontal máxima (instancias)*
/28 11 5
/27 27 13
/26 59 29

*Se da por supuesto que tiene que escalar o reducir verticalmente el tamaño o la SKU en algún momento.

Puesto que el tamaño de la subred no se puede cambiar después de la asignación, use una subred lo suficientemente grande como para dar cabida a cualquier escala que pueda alcanzar la aplicación. Para evitar problemas con la capacidad de subred de los planes Elástico Premium de Functions, debe usar /24 con 256 direcciones para Windows y /26 con 64 direcciones para Linux. Al crear subredes en Azure Portal como parte de la integración con la red virtual, se requiere un tamaño mínimo de /24 y /26 para Windows y Linux, respectivamente.

Si quiere que las aplicaciones de otro plan se comuniquen con una red virtual a la que ya están conectadas aplicaciones de otro plan, seleccione una subred distinta a la usada por la característica de integración de red virtual ya existente.

La característica es totalmente compatible con aplicaciones para Windows y Linux, incluidos los contenedores personalizados. Todos los comportamientos actúan del mismo modo entre aplicaciones para Windows y Linux.

Grupos de seguridad de red

Puede usar grupos de seguridad de red para bloquear el tráfico de entrada y salida a los recursos de una red virtual. Una aplicación que emplee la integración de red virtual regional puede usar un grupo de seguridad de red para bloquear el tráfico de salida a los recursos de la red virtual o Internet. Para bloquear el tráfico a direcciones públicas, debe tener habilitada la integración de red virtual con la opción Enrutar todo habilitada. Las reglas de entrada de un grupo de seguridad de red no se aplican a la aplicación, ya que la integración de red virtual solo afecta al tráfico saliente de la aplicación.

Para controlar el trafico de entrada a la aplicación, use la característica Restricciones de acceso. Un grupo de seguridad de red que se aplique a la subred de integración está en vigor, con independencia de las rutas aplicadas a la subred de integración. Si la aplicación de funciones está integrada con la red virtual mediante Enrutar todo habilitado, y no tiene ninguna ruta que afecte al tráfico de direcciones públicas en la subred de integración, todo el tráfico de salida sigue estando sujeto a los grupos de seguridad de red asignados a la subred de integración. Cuando Enrutar todo no está habilitado, los NSG solo se aplican al tráfico RFC1918.

Rutas

Las tablas de enrutamiento se pueden usar para enrutar el tráfico de salida de la aplicación al lugar que se desee. De forma predeterminada, las tablas de enrutamiento solo afectan al tráfico de destino de RFC 1918. Cuando Enrutar todo está habilitado, todas las llamadas salientes se ven afectadas. Cuando Enrutar todo está deshabilitado, solo el tráfico privado (RFC1918) se ve afectado por sus tablas de enrutamiento. Las rutas que se establecen en la subred de integración no afectan a las respuestas a las solicitudes de entrada de la aplicación. Los destinos más habituales suelen ser puertas de enlace o dispositivos de firewall.

Si desea enrutar todo el tráfico de salida del entorno local, puede utilizar una tabla de rutas para enviar el tráfico de salida a la puerta de enlace de ExpressRoute. Si no enruta el tráfico a una puerta de enlace, asegúrese de establecer las rutas en la red externa para poder enviar de vuelta las respuestas.

Las rutas del Protocolo de puerta de enlace de borde (BGP) también afectan al tráfico de la aplicación. Si tiene rutas de BGP cuyo origen es algo similar a una puerta de enlace de ExpressRoute, el tráfico de salida de la aplicación se verá afectado. De forma predeterminada, las rutas de BGP solo afectan al tráfico de destino de RFC 1918. Cuando la aplicación de funciones está integrada en una red virtual y la opción Enrutar todo está habilitada, todo el tráfico saliente puede verse afectado por las rutas BGP.

Zonas privadas de Azure DNS

Una vez que la aplicación se integra en la red virtual, usa el mismo servidor DNS con el que está configurada la red virtual, y funcionará con las zonas privadas de Azure DNS vinculadas a la red virtual.

Restricción de la cuenta de almacenamiento a una red virtual

Nota

Para implementar rápidamente una aplicación de funciones con puntos de conexión privados habilitados en la cuenta de almacenamiento, consulte la plantilla siguiente: Aplicación de funciones con puntos de conexión privados de Azure Storage.

Al crear una aplicación de funciones, debe crear una cuenta de Azure Storage de uso general compatible con Blob, Queue y Table Storage, o vincular a una. Puede reemplazar esta cuenta de almacenamiento por una que esté protegida con puntos de conexión de servicio o puntos de conexión privados.

Esta característica es compatible con todas las SKU compatibles con la red virtual Windows y Linux en el plan Dedicado (App Service) y para los planes Elástico Premium, así como para el plan de Consumo Flexible. No se admite el plan de consumo. Para obtener información sobre cómo configurar una función con una cuenta de almacenamiento restringida a una red privada, consulte Restricción de la cuenta de almacenamiento a una red virtual.

Uso de referencias de Key Vault

Puede usar las referencias de Azure Key Vault para utilizar secretos de esta solución en la aplicación Azure Functions sin necesidad de realizar cambios en el código. Azure Key Vault es un servicio que proporciona administración centralizada de los secretos, con control total sobre las directivas de acceso y el historial de auditoría.

Si la integración de la red virtual está configurada para la aplicación, se pueden usar referencias de Key Vault para recuperar secretos de un almacén restringido de red.

Desencadenadores de red virtual (no HTTP)

Actualmente, puede usar funciones de desencadenador no HTTP desde una red virtual de una de estas dos formas:

  • Ejecute la aplicación de funciones en un plan Premium de Elastic y habilite la compatibilidad con el desencadenador de red virtual.
  • Ejecute la aplicación de funciones en un plan de Consumo Flexible, plan de App Service o App Service Environment.

Plan Elástico Premium con desencadenadores de red virtual

El plan Elástico Premium le permite crear funciones desencadenadas por servicios dentro de una red virtual. Estos desencadenadores que no son HTTP se conocen como desencadenadores de red virtual.

De forma predeterminada, los desencadenadores de red virtual no hacen que la aplicación de funciones se escale más allá de su recuento de instancias previamente activadas. Sin embargo, ciertas extensiones admiten desencadenadores de red virtual que hacen que la aplicación de funciones se escale dinámicamente. Puede habilitar esta supervisión de escalado dinámico en la aplicación de funciones para extensiones admitidas de una de estas maneras:

  1. Vaya a la aplicación de funciones en Azure Portal.

  2. En Configuración, seleccione Configuración y, a continuación, en la pestaña Configuración del entorno de ejecución de la función, establezca Supervisión de escalado en tiempo de ejecución en Activado.

  3. Seleccione Guardar para actualizar la configuración de la aplicación de funciones y reiniciar la aplicación.

VNETToggle

Sugerencia

La habilitación de la supervisión de desencadenadores de red virtual puede tener un impacto en el rendimiento de la aplicación, aunque es probable que este impacto sea muy pequeño.

La compatibilidad con la supervisión de escalado dinámico de desencadenadores de red virtual no está disponible en la versión 1.x del entorno de ejecución de Functions.

Las extensiones de esta tabla admiten la supervisión dinámica de escalado de desencadenadores de red virtual. Para obtener el mejor rendimiento de escalado, debe actualizar a las versiones que también admiten el escalado basado en destino.

Extensión (versión mínima) Solo supervisión de escalado del entorno de ejecución Con escalado basado en el destino
Microsoft.Azure.WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure.WebJobs.Extensions.DurableTask > 2.0.0 N/D
Microsoft.Azure.WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure.WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Solo almacenamiento en cola

Importante

Al habilitar la supervisión de desencadenadores de red virtual, solo los desencadenadores para estas extensiones pueden hacer que la aplicación se escale dinámicamente. Podrá seguir usando desencadenadores de extensiones que no figuran en esta tabla, pero no provocarán el escalado más allá de su recuento de instancias activadas previamente. Para obtener una lista completa de todas las extensiones de desencadenadores y enlaces, consulte Desencadenadores y enlaces.

Plan de App Service y App Service Environment con desencadenadores de red virtual

Cuando la aplicación de funciones se ejecuta en un plan de App Service o en App Service Environment, puede usar funciones de desencadenador no HTTP. Para que las funciones se desencadenen correctamente, debe estar conectado a una red virtual con acceso al recurso definido en la conexión del desencadenador.

Por ejemplo, imagine que quiere configurar Azure Cosmos DB para aceptar el tráfico solo desde una red virtual. En este caso, debe implementar la aplicación de funciones en un plan de App Service que proporcione integración de red virtual con esa red virtual. La integración permite que un recurso de Azure Cosmos DB desencadene una función.

conexiones híbridas

Conexiones híbridas es una característica de Azure Relay que se puede usar para acceder a recursos de la aplicación en otras redes. Proporciona acceso desde la aplicación a un punto de conexión de la aplicación. No se puede usar para acceder a la aplicación. Las conexiones híbridas están disponibles en funciones que se ejecutan Windows con todos los planes, excepto el plan Consumo.

Dado que se usa en Azure Functions, cada conexión híbrida se correlaciona con una combinación única de host y puerto TCP. Esto significa que el punto de conexión de la conexión híbrida puede estar en cualquier sistema operativo y en cualquier aplicación, siempre que se acceda a un puerto de escucha TCP. La característica Conexiones híbridas no sabe lo que es el protocolo de aplicación ni a qué se accede. Simplemente ofrece acceso a la red.

Para obtener más información, vea la documentación de App Service para Conexiones híbridas. Estos mismos pasos de configuración sirven para Azure Functions.

Importante

Las conexiones híbridas solo se admiten en los planes de Windows. Linux no se admite.

Restricciones de IP de salida

Las restricciones de IP de salida están disponibles en un plan de Consumo Flexible, plan Elástico Premium, plan de App Service o App Service Environment. Puede configurar las restricciones de salida de la red virtual en la que está implementado el App Service Environment.

Al integrar una aplicación de funciones en un plan de Elástico Premium o un plan de App Service con una red virtual, la aplicación todavía puede realizar llamadas salientes a Internet de forma predeterminada. Al integrar la aplicación de funciones con una red virtual con Enrutar todo habilitado, se fuerza el envío de todo el tráfico saliente a la red virtual, donde se pueden usar reglas de grupo de seguridad de red para restringir el tráfico. Para Consumo Flexible, todo el tráfico ya está enrutado a través de la red virtual y no es necesario enrutar todo.

Para obtener información sobre cómo controlar la IP de salida mediante una red virtual, consulte Tutorial: Control de la IP de salida de Azure Functions mediante un servicio NAT Gateway de Azure Virtual Network.

Automation

Las siguientes API permiten administrar mediante programación las integraciones de redes virtuales regionales:

Consideraciones sobre las pruebas

Al probar funciones en una aplicación de funciones con puntos de conexión privados, debe realizar las pruebas desde dentro de la misma red virtual, como en una máquina virtual (VM) de esa red. Para usar la opción Código y prueba en el portal desde esa máquina virtual, debe agregar los siguientes orígenes de CORS a la aplicación de funciones:

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

Si ha restringido el acceso a la aplicación de funciones con puntos de conexión privados o cualquier otra restricción de acceso, también debe agregar la etiqueta de servicio AzureCloud a la lista de permitidos. Para actualizar la lista de permitidos:

  1. Vaya a la aplicación de funciones y seleccione Configuración>Redes y a continuación, seleccione Configuración de acceso de entrada>Acceso a red pública.

  2. Asegúrese de que el Acceso a la red pública está establecido en Seleccionar redes virtuales y direcciones IP.

  3. Agregue una regla en Acceso al sitio y reglas:

    1. Seleccione Service Tag como configuración de origen Tipo y AzureCloud como Etiqueta de servicio.

    2. Asegúrese de que la acción sea Permitir, y establezca el nombre y la prioridad deseados.

Solución de problemas

La característica es fácil de configurar, aunque eso no quiere decir que no presente problemas con el uso. Si encuentra problemas para acceder al punto de conexión que quiere, existen varias utilidades que sirven para probar la conectividad desde la consola de la aplicación. Dispone de dos consolas que puede usar. Una es la consola Kudu y la otra es la consola a la que se accede en Azure Portal. Para acceder a la consola Kudu desde la aplicación, vaya a Herramientas>Kudu. También puede tener acceso a la consola de Kudo en [sitename].scm.azurewebsites.net. Después de que se cargue el sitio web, vaya a la pestaña Consola de depuración. Para llegar a la consola hospedada en Azure Portal desde su aplicación, vaya a Herramientas>Consola.

Herramientas

En las aplicaciones nativas de Windows, las herramientas ping, nslookupy tracert no funcionarán a través de la consola debido a las restricciones de seguridad (funcionan en contenedores de Windows personalizados). Para suplir esta carencia, se agregaron dos herramientas diferentes. Para probar la funcionalidad de DNS, se agregó una herramienta denominada nameresolver.exe. La sintaxis es:

nameresolver.exe hostname [optional: DNS Server]

Puede usar nameresolver para comprobar los nombres de host de los que depende la aplicación. De este modo, puede probar si hay algo mal configurado en el DNS o si no tiene acceso al servidor DNS. Para ver el servidor DNS que la aplicación usa en la consola, examine las variables de entorno WEBSITE_DNS_SERVER y WEBSITE_DNS_ALT_SERVER.

Nota

La herramienta nameresolver.exe no funciona actualmente en contenedores de Windows personalizados.

Puede usar la siguiente herramienta para probar la conectividad de TCP en una combinación de host y puerto. Esta herramienta se llama tcpping y la sintaxis es:

tcpping.exe hostname [optional: port]

La utilidad tcpping indica si se puede llegar a un host y puerto específicos. Puede mostrar un resultado correcto solo si hay una aplicación que escucha en la combinación de host y puerto, y existe acceso a la red desde la aplicación hacia el host y puerto especificados.

Depuración del acceso a recursos hospedados en la red virtual

Varias situaciones pueden impedir que la aplicación se comunique con un host y un puerto específicos. La mayoría de las veces se debe a una de estas causas:

  • Existe un firewall que lo impide. Si tiene un firewall que lo impide, se agota el tiempo de espera de TCP. El tiempo de espera de TCP es de 21 segundos en este caso. Utilice la herramienta tcpping para probar la conectividad. Los tiempos de espera agotados de TCP pueden tener muchas causas además de los firewalls, pero comience por comprobar los firewalls.
  • El DNS no es accesible. El tiempo de espera de DNS es de 3 segundos por cada servidor DNS. Si tiene dos servidores DNS, el tiempo de espera es de seis segundos. Utilice nameresolver para ver si funciona el DNS. No puede usar nslookup, ya que este no usa el DNS con el que se ha configurado la red virtual. Si no puede acceder, podría haber un firewall o NSG bloqueando el acceso a DNS, o este puede estar inactivo.

Si estos elementos no resuelven el problema, plantéese cuestiones como las siguientes:

Integración de red virtual regional

  • ¿El destino no es una dirección RFC 1918 y no tiene la opción Enrutar todo habilitada?
  • ¿Hay un NSG que bloquea la salida de la subred de integración?
  • Si está usando una VPN o Azure ExpressRoute, ¿la puerta de enlace local está configurada para enrutar el tráfico de vuelta a Azure? Si puede acceder a los puntos de conexión de la red virtual pero no a los del entorno local, compruebe las rutas.
  • ¿Tiene permisos suficientes para configurar la delegación en la subred de integración? Al configurar la integración de la red virtual regional, la subred de integración se delega en Microsoft.Web/serverFarms. La interfaz de usuario de integración de la red virtual delega la subred en Microsoft.Web/serverFarms automáticamente. Si la cuenta no tiene suficientes permisos de red para establecer la delegación, necesitará que un usuario que pueda configurar atributos en la subred de integración delegue la subred. Para delegar manualmente la subred de integración, vaya a la interfaz de usuario de la subred de Azure Virtual Network y establezca la delegación para Microsoft.Web/serverFarms.

Integración de red virtual con requisito de puerta de enlace

  • ¿El intervalo de direcciones de punto a sitio se encuentra en los intervalos de RFC 1918 (10.0.0.0-10.255.255.255/172.16.0.0-172.31.255.255/192.168.0.0-192.168.255.255)?
  • ¿La puerta de enlace aparece como activa en el portal? Si la puerta de enlace está inactiva, vuelva a activarla.
  • ¿Los certificados aparecen como sincronizados o sospecha que la configuración de red ha cambiado? Si los certificados no están sincronizados o sospecha que se produjo un cambio en la configuración de red virtual que no se ha sincronizado con sus planes de App Service, seleccione Sincronizar red.
  • Si está usando una VPN, ¿la puerta de enlace local está configurada para enrutar el tráfico de vuelta a Azure? Si puede acceder a los puntos de conexión de la red virtual pero no del entorno local, compruebe las rutas.
  • ¿Está intentando usar una puerta de enlace de coexistencia que admite tanto una conexión de punto a sitio como ExpressRoute? Las puertas de enlace de coexistencia no son compatibles con la integración de la red virtual.

Depurar problemas de red es todo un reto porque no se puede ver lo que está bloqueando el acceso en una combinación de host y puerto específica. Entre las causas se incluyen las siguientes:

  • Tiene un firewall en el host que bloquea el acceso al puerto de la aplicación desde el intervalo IP de punto a sitio. A menudo se requiere acceso público para establecer conexiones entre subredes.
  • El host de destino está fuera de servicio.
  • La aplicación está fuera de servicio.
  • La dirección IP o el nombre de host son incorrectos.
  • La aplicación escucha en un puerto diferente al esperado. Puede hacer coincidir el id. de proceso con el puerto de escucha usando "netstat -aon" en el host del punto de conexión.
  • Los grupos de seguridad de red están configurados de tal manera que evitan el acceso al host y al puerto de la aplicación desde el intervalo IP de punto a sitio.

No se sabe qué dirección usa realmente la aplicación. Podría ser cualquier dirección en el intervalo de direcciones de punto a sitio o de subred de integración, por lo que será necesario permitir el acceso desde el intervalo de direcciones completo.

Entre otros pasos de depuración se incluyen los siguientes:

  • Conectarse a una máquina virtual de la red virtual e intentar acceder al recurso host:puerto desde allí. Para probar el acceso TCP, use el comando Test-NetConnection de PowerShell. La sintaxis es:
Test-NetConnection hostname [optional: -Port]
  • Abra una aplicación en una máquina virtual y pruebe el acceso a ese host y ese puerto desde la consola de la aplicación mediante tcpping.

Recursos locales

Si la aplicación no puede acceder a un recurso local, compruebe si puede hacerlo desde su red virtual. Use el comando Test-NetConnection de PowerShell para comprobar el acceso TCP. Si la máquina virtual no puede acceder al recurso local, puede que la conexión de VPN o ExpressRoute no esté configurada correctamente.

Si la máquina virtual hospedada en la red virtual puede acceder a su sistema local, pero la aplicación no, la causa es probablemente una de las razones siguientes:

  • Las rutas no están configuradas con los intervalos de direcciones de punto a sitio o subred en la puerta de enlace local.
  • Los grupos de seguridad de red están bloqueando el acceso del intervalo IP de punto a sitio.
  • Los firewalls locales están bloqueando el tráfico del intervalo IP de punto a sitio.
  • Está intentando acceder a una dirección que no es de RFC 1918 mediante la característica de integración de la red virtual regional.

Eliminación del plan App Service o aplicación web antes de desconectar la integración de red virtual

Si eliminó la aplicación web o el plan de App Service sin desconectar primero la integración de red virtual, no podrá realizar ninguna operación de actualización o eliminación en la red virtual o subred que se usó para la integración con el recurso eliminado. Una delegación de subred "Microsoft.Web/serverFarms" permanecerá asignada a la subred y evitará las operaciones de actualización o eliminación.

Para actualizar o eliminar la subred o la red virtual de nuevo, debe volver a crear la integración de red virtual y, a continuación, desconectarla:

  1. Vuelva a crear el plan App Service y la aplicación web (es obligatorio usar exactamente el mismo nombre de aplicación web que antes).
  2. Vaya a la hoja "Redes" de la aplicación web y configure la integración de red virtual.
  3. Una vez configurada la integración de red virtual, seleccione el botón "Desconectar".
  4. Elimine el plan App Service o la aplicación web.
  5. Actualice o elimine la subred o red virtual.

Si sigue teniendo problemas con la integración con la red virtual después de seguir los pasos anteriores, póngase en contacto con Soporte técnico de Microsoft.

Solucionador de problemas de red

También puede usar el solucionador de problemas de red para resolver problemas de conexión. Para abrir el solucionador de problemas de red, vaya a la aplicación en el Azure Portal. Seleccione Diagnóstico y solución de problemas y busque Solucionador de problemas de red.

Problemas de conexión : comprueba el estado de la integración de red virtual, incluida la comprobación de si la dirección IP privada se ha asignado a todas las instancias del plan y la configuración de DNS. Si no se configura un DNS personalizado, se aplica el DNS predeterminado de Azure. El solucionador de problemas también comprueba si hay dependencias comunes de la aplicación de funciones, incluida la conectividad para Azure Storage y otras dependencias de enlace.

Captura de pantalla que muestra la ejecución del solucionador de problemas para encontrar problemas de conexión.

Problemas de configuración : este solucionador de problemas comprueba si la subred es válida para la integración de red virtual.

Captura de pantalla que muestra la ejecución del solucionador de problemas para encontrar problemas de configuración.

Problema de eliminación de subred o red virtual: este solucionador de problemas comprueba si la subred tiene bloqueos y si tiene algún vínculo de asociación de servicio sin usar que podría estar bloqueando la eliminación de la red virtual o subred.

Pasos siguientes

Para obtener más información sobre las redes y Azure Functions: