Opciones de redes de Azure Functions

En este artículo se describen las características de redes disponibles en las opciones de hospedaje de Azure Functions. Las siguientes opciones de red se pueden clasificar como características de red de entrada y salida. Las características de entrada permiten restringir el acceso a la aplicación, mientras que las de salida permiten conectar la aplicación a los recursos protegidos por una red virtual y controlar cómo se enruta el tráfico saliente.

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 flexible	Plan de consumo	Plan Premium	Plan dedicado/ASE	Container Apps1
Restricciones de IP de entrada	✔	✔	✔	✔	✔
Puntos de conexión privados entrantes	✔		✔	✔
Integración de redes virtuales	✔		✔2	✔3	✔
Restricciones de IP de salida	✔		✔	✔	✔

1. Para más información, consulte Redes en el entorno de Azure Container Apps.
2. Hay consideraciones especiales al trabajar con desencadenadores de red virtual.
3. Solo el plan Dedicado/ASE admite la integración de red virtual necesaria para la puerta de enlace.

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.

• Plantillas de ARM, archivos de Bicep y plantillas de Terraform:
  • Aplicación de funciones desencadenada mediante HTTP privado
  • Aplicación de funciones desencadenada mediante Event Hubs privado
• Solo plantillas de ARM:
  • Aplicación de funciones con puntos de conexión privados de Azure Storage.
  • Aplicación de funciones de Azure con integración de Virtual Network.
• Tutoriales:
  • Integración de Azure Functions con una red virtual de Azure mediante puntos de conexión privados
  • Restricción de la cuenta de almacenamiento a una red virtual.
  • Control de la IP de salida de Azure Functions mediante un servicio NAT Gateway de Azure Virtual Network.

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 de Consumo flexible, Elástico Premium y Dedicado (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 administrar un punto de conexión privado, debe conocer la dirección del punto de conexión y usar un registro A para hacer referencia al punto de conexión al que intenta acceder.
• 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. Siga estos pasos para acceder a un punto de conexión de servicio protegido:

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 está configurada para los puntos de conexión de servicio, que se habilitan más adelante en la subred.

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.

Características de red de salida

Puede usar las características de esta sección para administrar las conexiones salientes realizadas por la aplicación.

Integración de redes virtuales

En esta sección se detallan las características que Functions admite para controlar los datos de salida de la aplicación.

La integración de red virtual proporciona a la aplicación de funciones acceso a los recursos de la red virtual. Una vez integrada, la aplicación enruta el tráfico saliente a través de la red virtual. Esto permite que la aplicación acceda a puntos de conexión privados o a recursos con reglas que permiten el tráfico solo desde subredes seleccionadas. Cuando el destino es una dirección IP fuera de la red virtual, la dirección IP de origen se seguirá enviando desde una de las direcciones incluidas en las propiedades de la aplicación, a menos que haya configurado una NAT Gateway.

Azure Functions admite dos tipos de integración de redes virtuales:

• Integración de red virtual regional para aplicaciones que se ejecutan en los planes de hospedaje de Consumo flexible, Elástico Premium, Dedicado (App Service) y Container Apps (recomendado)
• Integración de red virtual necesaria para la puerta de enlace para las aplicaciones que se ejecutan en el plan de hospedaje Dedicado (App Service)

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

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.

Consideraciones para el plan de Consumo flexible:

• Asegúrese de que el proveedor de recursos de Azure Microsoft.App esté habilitado para la suscripción siguiendo estas instrucciones. Esto es necesario para la delegación de la subred.
• La delegación de subred necesaria cuando se ejecuta en un plan de Consumo flexible es Microsoft.App/environments. Esto difiere de los planes Elástico Premium y Dedicado (App Service), que tienen un requisito de delegación diferente.
• 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 15 aplicaciones de funciones con Consumo flexible integradas en la misma subred, debe planear 15 x 40 = 600 direcciones IP usadas como máximo. Este límite está sujeto a cambios y no se aplica.
• 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 comparten en estas aplicaciones de funciones, lo que puede provocar que una aplicación afecte al rendimiento de otras de la misma subred.

Consideraciones para los planes Elástico Premium, Dedicado (App Service) y Container Apps:

• La característica está disponible para 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.
• Las aplicaciones del plan Aislado que estén en una instancia de App Service Environment no pueden usar la característica.
• Tanto la aplicación como la red virtual deben estar en la misma región.
• La característica requiere una subred sin usar que sea /28 o mayor en una red virtual de Azure Resource Manager.
• La subred de integración solo puede usarla un plan de App Service.
• 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 pueden eliminar redes virtuales que tengan aplicaciones integradas. Quite la integración antes de eliminar la red virtual.
• 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.

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.

   

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.

   

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

   • 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 prefiere que solo se enrute el tráfico privado (tráfico RFC1918), siga los pasos descritos en este artículo de App Service.

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. Esto no se aplica para Consumo flexible y las instancias comparten direcciones IP.

En los planes Elástico Premium y Dedicado (App Service), el espacio de direcciones necesario se duplica durante un breve período de tiempo al escalar o reducir verticalmente en el tamaño de instancia. 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.

El plan de Consumo flexible permite que varias aplicaciones que se ejecutan en el plan de Consumo flexible se integren con la misma subred. Este no es el caso de los planes de hospedaje Elástico Premium y Dedicado (App Service). Estos planes solo permiten que dos redes virtuales se conecten con cada plan de App Service. Varias aplicaciones de un único plan de App Service pueden unirse a la misma subred, pero las aplicaciones de planes diferentes no pueden usar esa misma subred.

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 controlar el tráfico entre los recursos de la red virtual. Por ejemplo, puede crear una regla de seguridad que impide que el tráfico saliente de la aplicación llegue a un recurso de la red virtual o salga de la red. Estas reglas de seguridad se aplican a las aplicaciones que han configurado la integración de red virtual. Para bloquear el tráfico a direcciones públicas, debe tener habilitadas la integración de red virtual y la opción Enrutar todo. 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 la opción Enrutar todo habilitada, 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 NSG 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 la opción Enrutar todo está habilitada, 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.

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 la opción Enrutar todo no es necesaria.

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.

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.

Automatización

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

• CLI de Azure: use los comandos az functionapp vnet-integration para agregar, enumerar o quitar una integración de red virtual regional.
• Plantillas ARM: La integración de la red virtual regional se puede habilitar mediante una plantilla de Azure Resource Manager. Para obtener un ejemplo completo, consulte esta plantilla de inicio rápido de Functions.

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 cuando la aplicación de funciones se ejecuta en Windows. No se admiten las aplicaciones de Linux.

Conexión a los servicios de Azure a través de una red virtual

La integración de red virtual permite que la aplicación de funciones acceda a los recursos en una red virtual. En esta sección se describe lo que debe tener en cuenta al intentar conectar la aplicación a determinados servicios.

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.

Puede usar una cuenta de almacenamiento con restricción de red con aplicaciones de funciones en los planes de Consumo flexible, Elástico Premium y Dedicado (App Service); no se admite el plan de Consumo. En el caso de los planes Elástico Premium y Dedicado, debe asegurarse de que el enrutamiento de contenidos compartidos privado está configurado. Para obtener información sobre cómo configurar la aplicación de funciones con una cuenta de almacenamiento protegida con una red virtual, 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)

Es posible que la carga de trabajo requiera que la aplicación se desencadene desde un origen de eventos protegido por una red virtual. Hay dos opciones si quiere que la aplicación se escale dinámicamente en función del número de eventos recibidos de orígenes de desencadenadores que no son HTTP:

• Ejecute la aplicación de funciones en un plan de Consumo flexible.
• Ejecute la aplicación de funciones en un plan Premium de Elastic y habilite la compatibilidad con el desencadenador de red virtual.

Las aplicaciones de funciones que se ejecutan en el plan Dedicado (App Service) no se escalan dinámicamente en función de los eventos. En su lugar, el escalado horizontal viene determinado por las reglas de escalado automático que defina.

Plan Elástico Premium con desencadenadores de red virtual

El plan Elástico Premium le permite crear funciones desencadenadas por servicios protegidos por 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:

Azure Portal

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.

CLI de Azure

az resource update -g <resource_group> -n <function_app_name>/config/web --set properties.functionsRuntimeScaleMonitoringEnabled=1 --resource-type Microsoft.Web/sites

Azure PowerShell

$Resource = Get-AzResource -ResourceGroupName <resource_group> -ResourceName <function_app_name>/config/web -ResourceType Microsoft.Web/sites
$Resource.Properties.functionsRuntimeScaleMonitoringEnabled = $true
$Resource | Set-AzResource -Force

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 escribir funciones que se desencadenen por recursos protegidos por una red virtual. Para que las funciones se desencadenen correctamente, la aplicación debe estar conectada 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.

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.

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

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:

• Siga el tutorial sobre cómo empezar con la integración de red virtual
• Lea las preguntas más frecuentes de las redes de Functions
• Obtenga más información sobre la integración de red virtual con App Service o Functions
• Obtenga más información sobre las redes virtuales en Azure
• Habilite más características de redes y control con App Service Environment
• Conéctese a recursos locales individuales mediante Conexiones híbridas sin modificar el firewall