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. 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 hospedaje tienen diferentes niveles de aislamiento de red disponibles. Elegir el correcto le ayuda a cumplir los requisitos de aislamiento de red que tenga.

Puede hospedar aplicaciones de funciones de dos formas:

  • Puede elegir entre un conjunto de opciones de plan que se ejecutan en una infraestructura multiinquilino, con distintos niveles de conectividad de red virtual y opciones de escalado:
    • El plan de consumo se escala dinámicamente como respuesta a la carga y ofrece opciones de aislamiento de red mínimo.
    • El plan Premium también se escala dinámicamente y ofrece un aislamiento de red más completo.
    • El plan de Azure App Service funciona en una escala fija y ofrece un aislamiento de red similar al del plan Premium.
  • Puede ejecutar funciones en un App Service Environment. Este método implementa la función en la red virtual y ofrece aislamiento y control de la red completos.

Matriz de las características de redes

Característica Plan de consumo Plan Premium Plan dedicado Azure App Service Environment Kubernetes
Restricciones de IP de entrada y acceso al sitio privado ✅Sí ✅Sí ✅Sí ✅Sí ✅Sí
Integración de redes virtuales ❌No ✅Sí (regional) ✅Sí (regional y puerta de enlace) ✅Sí ✅Sí
Desencadenadores de red virtual (no HTTP) ❌No ✅Sí ✅Sí ✅Sí ✅Sí
Conexiones híbridas (solo Windows) ❌No ✅Sí ✅Sí ✅Sí ✅Sí
Restricciones de IP de salida ❌No ✅Sí ✅Sí ✅Sí ✅Sí

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 para Premium, Consumo y 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.

Conexiones de punto de conexión privado

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.

Al crear una conexión de punto de conexión privado entrante para las funciones, también necesitará un registro DNS para resolver la dirección privada. De manera predeterminada, se creará automáticamente un registro DNS privado al crear un punto de conexión privado mediante Azure Portal.

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.

Uso de puntos de conexión de servicio

Con los puntos de conexión de servicio, puede restringir el acceso a las subredes de Azure Virtual Network. 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 habilitarán 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 configurará para los puntos de conexión de servicio en previsión de que se habiliten posteriormente en la subred.

Captura de pantalla del panel "Agregar restricción de IP" con el tipo Virtual Network seleccionado.

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 con 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 con red virtual se comporta de forma distinta cuando se usa con redes virtuales de la misma región y con redes virtuales de otras regiones. La característica de integración con red virtual tiene dos variantes:

  • 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 con red virtual:

  • Necesita un plan de precios Estándar, 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.
  • Integración 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 Integración con red virtual

  1. Vaya a la hoja Redes en el portal de aplicación de funciones. En Integración de red virtual, 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 VNet con la que quiere realizar la integración.

    Seleccione la red virtual.

    • El plan premium de funciones solo admite la integración de red virtual regional. Si la VNet está en la misma región, cree una nueva subred o seleccione una subred vacía existente.
    • Para seleccionar una VNet de otra región, debe tener una puerta de enlace de VNet aprovisionada con la conectividad de punto a sitio habilitada. La integración de red virtual entre regiones solo se admite para los planes dedicados.

Durante la integración, la aplicación se reinicia. Una vez finalizada la integración, verá los detalles de la VNet con la que está integrada. De forma predeterminada, la opción Enrutar todo estará habilitada y todo el tráfico se enrutará 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 versión regional de Integración con red virtual, la aplicación puede acceder a:

  • Recursos en una VNet de la misma región que la aplicación.
  • Recursos de las VNet emparejadas con la VNet 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 de la VNet con la que está integrado.
  • Recursos en conexiones emparejadas, lo que incluye conexiones de Azure ExpressRoute.
  • Puntos de conexión privados

Si Integración con red virtual se utiliza con redes virtuales de la misma región, se pueden usar 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 Integración con 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

Si enruta todo el tráfico de salida a la VNet, 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 VNet, 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.

Existen algunas limitaciones cuando se la característica Integración con red virtual se utiliza con redes virtuales que están en la misma región:

  • No se puede acceder a los recursos en las conexiones de emparejamiento global.
  • La característica está disponible en todas las unidades de escalado de App Service de nivel Premium V2 y Premium V3. También está disponible en Estándar, pero solo desde las unidades de escalado de App Service más recientes. Si está en una unidad de escalado 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. Estos planes solo se admiten en las unidades de escalado 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.
  • La aplicación y la VNet deben estar en la misma región.
  • No puede eliminar una VNet con una aplicación integrada. Quite la integración antes de eliminar la VNet.
  • Solo se puede tener una característica Integración con red virtual regional por plan de App Service. Varias aplicaciones en el mismo plan de App Service pueden usar la misma red virtual.
  • No se puede cambiar la suscripción de una aplicación o un plan mientras haya una aplicación que use Integración con red virtual regional.
  • La aplicación no puede resolver direcciones en Azure DNS Private Zones sin que se realicen cambios en la configuración.

Subredes

La integración con red virtual depende de una subred dedicada. Al aprovisionar una subred, la subred de Azure pierde cinco direcciones IP desde el inicio. Se usa una dirección de la subred de integración para cada instancia del plan. Si escala la aplicación a cuatro instancias, se usan cuatro direcciones.

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 tendrá 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 Premium de Functions, debe usar un /24 con 256 direcciones para Windows y un /26 con 64 direcciones para Linux.

Si quiere que las aplicaciones de otro plan lleguen a una VNet a la que ya están conectadas aplicaciones de otro plan, seleccione una subred distinta a la usada por la característica Integración con VNet 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.

Puntos de conexión del servicio

Con el fin de proporcionar un mayor nivel de seguridad, puede restringir una serie de servicios de Azure a una red virtual mediante puntos de conexión de servicio. La integración con red virtual regional permite que la aplicación de funciones llegue a los servicios de Azure 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.

Grupos de seguridad de red

Puede usar grupos de seguridad de red para bloquear el tráfico de entrada y salida de los recursos de una VNet. Una aplicación que emplee la versión regional de Integración con red virtual puede usar un grupo de seguridad de red para bloquear el tráfico de salida a los recursos de la VNet 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 Integración con 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 VNet 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 con la red virtual, usa el mismo servidor DNS que el configurado para la red virtual. De forma predeterminada, la aplicación no funcionará con zonas privadas de Azure DNS. Para que lo haga es preciso agregar la siguiente configuración de la aplicación:

  • WEBSITE_VNET_ROUTE_ALL con el valor 1

Esta configuración envía todas las llamadas salientes desde la aplicación a la red virtual y permite que la aplicación tenga acceso a una zona privada de Azure DNS. Con esta configuración, su aplicación puede usar Azure DNS consultando la zona DNS privada en el nivel de trabajo.

Puntos de conexión privados

Si quiere realizar llamadas a 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.

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

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 se admite para todas las SKU compatibles con la red virtual de Windows en el plan dedicado (App Service) y para el plan Premium. También se admite con DNS privado para SKU compatibles con la red virtual Linux. El plan de consumo y el DNS personalizado en los planes Linux no son compatibles. 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 y habilite la compatibilidad con el desencadenador de red virtual.
  • Ejecute una aplicación de funciones en un plan de App Service o App Service Environment.

Plan Premium con desencadenadores de red virtual

Cuando cuenta con un plan Premium, puede conectar funciones de desencadenador no HTTP a los servicios que se ejecutan en una red virtual. Para ello, debe habilitar la compatibilidad con el desencadenador de red virtual para la aplicación de funciones. La configuración Supervisión de la escala en tiempo de ejecución se encuentra en Azure Portal, en Configuración > Configuración del tiempo de ejecución de la función.

VNETToggle

También puede habilitar los desencadenadores de red virtual mediante el siguiente comando de la CLI de Azure:

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

Sugerencia

Habilitar los desencadenadores de red virtual puede afectar al rendimiento de la aplicación, ya que las instancias del plan de App Service deberán supervisar los desencadenadores para determinar cuándo se debe escalar. Es probable que este impacto sea muy pequeño.

Los desencadenadores de red virtual se admiten en la versión 2.x y superior del tiempo de ejecución de Functions. Se admiten los siguientes tipos de desencadenador no HTTP.

Extensión Versión mínima
Microsoft.Azure.WebJobs.Extensions.Storage 3.0.10 o superior
Microsoft.Azure.WebJobs.Extensions.EventHubs 4.1.0 o superior
Microsoft.Azure.WebJobs.Extensions.ServiceBus 3.2.0 o superior
Microsoft.Azure.WebJobs.Extensions.CosmosDB 3.0.5 o superior
Microsoft.Azure.WebJobs.Extensions.DurableTask 2.0.0 o superior

Importante

Cuando se habilita la compatibilidad con desencadenadores de red virtual, solo los tipos de desencadenador incluidos en la tabla anterior se escalan dinámicamente con la aplicación. Podrá seguir usando desencadenadores que no figuran en la tabla, pero no se escalarán más allá de su recuento de instancias activadas previamente. Consulte la lista completa de los desencadenadores en Enlaces admitidos.

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 solo están disponibles para el plan Premium, el 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.

Cuando se integra una aplicación de funciones de un plan 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 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:

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, nslookup y 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 de 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 de 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.

Pasos siguientes

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