Integración de su aplicación con una instancia de Azure Virtual Network

En este artículo, se describe la característica de integración con red virtual de Azure App Service y cómo configurarla con aplicaciones en Azure App Service. Con las redes virtuales de Azure (VNet), puede colocar muchos de los recursos de Azure en una red que se puede enrutar, distinta de Internet. La característica de integración con red virtual permite a las aplicaciones acceder a los recursos de una red virtual o mediante esta. No se permite el acceso privado a las aplicaciones.

Azure App Service adopta dos variantes:

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

Descubra cómo habilitar la integración con red virtual.

Integración con red virtual regional

La integración con red virtual regional admite la conexión a una red virtual de la misma región y no requiere una puerta de enlace. Cuando se utiliza la integración con red virtual regional, la aplicación puede acceder a:

• Recursos de la VNet con la que está integrado.
• Recursos de las VNet emparejadas con la VNet con la que se integra la aplicación, incluidas conexiones de emparejamiento global.
• Recursos de diferentes conexiones de Azure ExpressRoute.
• Servicios protegidos mediante puntos de conexión de servicio.
• Servicios habilitados para puntos de conexión privados.

Si usa la integración con red virtual regional, puede usar las siguientes características de red 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 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.

Funcionamiento de la integración con red virtual regional

Las aplicaciones en App Service se hospedan en roles de trabajo. La integración con red virtual regional lo que hace es montar interfaces virtuales en los roles de trabajo con las direcciones de la subred delegada. Como la dirección de origen está en la VNet, tiene acceso a la mayoría de las cosas que están en esa VNet o a las que se puede acceder a través de ella, como cualquier máquina virtual que estuviera en la VNet. La implementación de redes es diferente de la ejecución de una máquina virtual en la VNet. Este es el motivo por el que algunas características de red todavía no están disponibles para esta característica.

Cuando la integración con red virtual regional está habilitada, su aplicación realiza llamadas salientes a través de la red virtual. Las direcciones salientes que se muestran en el portal de propiedades de la aplicación siguen siendo las direcciones usadas por la aplicación. Pero si la llamada saliente es a una máquina virtual o un punto de conexión privado en la red virtual de integración o en la red virtual emparejada, la dirección saliente será una dirección de la subred de integración. La dirección IP privada asignada a una instancia se expone por medio de la variable de entorno WEBSITE_PRIVATE_IP.

Si todo el enrutamiento de tráfico está habilitado, todo el tráfico saliente se envía a la red virtual. Si no está habilitado todo el enrutamiento de tráfico, solo se enviarán a la red virtual el tráfico privado (RFC1918) y los puntos de conexión de servicio configurados en la subred de integración y el tráfico saliente a Internet pasará por los mismos canales normales.

La característica solo admite una interfaz virtual por trabajo. Una interfaz virtual por trabajo se traduce en una integración con red virtual regional por plan de App Service. Todas las aplicaciones del mismo plan de App Service pueden usar la misma integración con red virtual. Si necesita que una aplicación se conecte a otra red virtual, debe crear otro plan de App Service. La interfaz virtual utilizada no es un recurso al que los clientes tengan acceso directo.

Dada la forma en que funciona esta tecnología, el tráfico que se usa con la integración con red virtual no se muestra en los registros de flujos de NSG o Azure Network Watcher.

Requisitos de subred

La integración con red virtual depende de una subred dedicada. Al crear 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:

^*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 la subred, debe usar /26 con 64 direcciones.

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

Rutas

Hay dos tipos de enrutamiento que se deben tener en cuenta al configurar la integración con red virtual regional. El enrutamiento de aplicaciones define qué tráfico se enruta desde la aplicación y hacia la red virtual. El enrutamiento de red es la capacidad de controlar cómo se enruta y sale el tráfico desde la red virtual.

Enrutamiento de aplicaciones

Al configurar el enrutamiento de aplicaciones, puede enrutar todo el tráfico o solo el tráfico privado (también conocido como tráfico RFC1918) a la red virtual. Este comportamiento se configura mediante la opción Enrutar todo. Si la opción Enrutar todo está deshabilitada, la aplicación solo enruta el tráfico privado a la red virtual. Si desea enrutar todo el tráfico saliente a la red virtual, asegúrese de que Enrutar todo está habilitado.

Descubra cómo configurar el enrutamiento de aplicaciones.

La opción de configuración Enrutar todo es la manera recomendada de habilitar el enrutamiento de todo el tráfico. El uso de la opción de configuración permite auditar el comportamiento con una directiva integrada. Todavía se puede usar la configuración de aplicación WEBSITE_VNET_ROUTE_ALL existente y se puede habilitar todo el enrutamiento del tráfico con cualquiera de estas opciones.

Enrutamiento de red

Las tablas de enrutamiento se pueden usar para enrutar el tráfico de salida de la aplicación al lugar que se desee. Las tablas de enrutamiento afectan al tráfico de destino. Cuando Enrutar todo está deshabilitado en el enrutamiento de aplicaciones, solo el tráfico privado (RFC1918) se ve afectado por sus tablas de enrutamiento. Los destinos más habituales suelen ser puertas de enlace o dispositivos de firewall. 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.

Si quiere enrutar todo el tráfico saliente del entorno local, puede utilizar una tabla de rutas para enviarlo todo 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 similar a las rutas definidas por el usuario, las rutas BGP afectan al tráfico según la configuración del ámbito de enrutamiento.

Grupos de seguridad de red

Una aplicación que emplee la integración con red virtual regional puede usar un grupo de seguridad de red para bloquear el tráfico saliente a los recursos de la red virtual o de Internet. Para bloquear el tráfico a las direcciones públicas, debe asegurarse de habilitar la opción Enrutar todo en la red virtual. Cuando Enrutar todo no está habilitado, los NSG solo se aplican al tráfico RFC1918.

Un grupo de seguridad de red que se aplique a la subred de integración está en vigor, con independencia de las tablas de enrutamiento aplicadas a la subred de integración.

Las reglas de entrada de un grupo de seguridad de red no incumben a la aplicación, ya que la 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.

Puntos de conexión del servicio

La integración con red virtual regional le permite acceder a los servicios de Azure que están protegidos con puntos de conexión de servicio. Para acceder a un servicio protegido mediante puntos de conexión de servicio, siga estos pasos:

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

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. Si la red virtual no tiene un servidor DNS personalizado, esta integración se lleva a cabo automáticamente cuando las zonas están vinculadas a ella.
• Administrar el punto de conexión privado en el servidor DNS que usa la aplicación. Para administrar la configuración, debe conocer la dirección IP del punto de conexión privado y, después, apuntar el punto de conexión al que está intenta acceder a esa dirección con un registro D.
• Configurar su propio servidor DNS para reenviarlo a zonas privadas de Azure DNS.

Zonas privadas de Azure DNS

Una vez que la aplicación se integra con la red virtual, usa el mismo servidor DNS con el que está configurada la red virtual y, si no se especifica ningún DNS personalizado, usará DNS predeterminado de Azure y cualquier zona privada vinculada a la red virtual.

Limitaciones

Existen algunas limitaciones cuando se usa la integración con red virtual regional:

• 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, puede reducir verticalmente después de crear el plan.
• Las aplicaciones del plan Aislado que estén en una instancia de App Service Environment no pueden usar la característica.
• No puede acceder a los recursos a través de conexiones de emparejamiento con redes virtuales clásicas.
• La característica requiere una subred sin usar que sea un bloque IPv4 /28 o mayor en una red virtual de Azure Resource Manager.
• La aplicación y la VNet deben estar en la misma región.
• La red virtual de integración no puede tener definidos espacios de direcciones IPv6.
• La subred de integración solo puede usarla un plan de App Service.
• No puede eliminar una VNet con una aplicación integrada. Quite la integración antes de eliminar la VNet.
• Solo se puede tener una 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 esta característica.

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

La integración con red virtual con requisito de puerta de enlace permite conectarse a una red virtual de otra región o a una red virtual clásica. Integración con red virtual con requisito de puerta de enlace

• Permite que una aplicación se conecte solo a una VNet a la vez.
• Permite la integración de hasta cinco VNet dentro de un plan de App Service.
• Permite que varias aplicaciones de un mismo plan de App Service usen la misma VNet sin que ello afecte al número total que se puede utilizar en un plan de App Service. Si tiene seis aplicaciones que usan la misma VNet en el mismo plan de App Service, solo se contabilizará una sola VNet en uso.
• Admite un SLA del 99,9 % debido al SLA de la puerta de enlace.
• Permite que las aplicaciones utilicen el DNS con el que se ha configurado la VNet.
• Para poder conectarse a una aplicación, se necesita una puerta de enlace basada en rutas de red virtual que esté configurada con una VPN de punto a sitio SSTP.

No se puede usar la integración con red virtual con requisito de puerta de enlace en las siguientes circunstancias:

• Con una VNet conectada a Azure ExpressRoute.
• Desde una aplicación Linux.
• Desde un contenedor de Windows.
• Para acceder a recursos protegidos por puntos de conexión de servicio.
• Con una puerta de enlace coexistente que admita tanto VPN de ExpressRoute como VPN de punto a sitio o de sitio a sitio.

Configuración de una puerta de enlace en Azure Virtual Network

Para crear una puerta de enlace:

1. Cree la puerta de enlace de red virtual y la subred. Seleccione un tipo de VPN basada en rutas.

2. Establezca las direcciones de punto a sitio. Si la puerta de enlace no está en la SKU básica, IKEV2 debe estar deshabilitado en la configuración de punto a sitio y SSTP debe estar seleccionado. El espacio de direcciones de punto a sitio debe especificarse en bloques de direcciones de RFC 1918 (10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16).

Si crea la puerta de enlace para usarla con la integración con red virtual con requisito de puerta de enlace, no es necesario cargar un certificado. La creación de la puerta de enlace puede tardar 30 minutos. No podrá integrar su aplicación con la red virtual hasta que se cree la puerta de enlace.

Funcionamiento de la integración con red virtual con requisito de puerta de enlace

La integración con red virtual con requisito de puerta de enlace se basa en la tecnología de VPN de punto a sitio. Las VPN de punto a sitio limitan el acceso de red a la máquina virtual que hospeda la aplicación. Las aplicaciones están restringidas para enviar tráfico a Internet solo a través de conexiones híbridas o de la integración con red virtual. Cuando la aplicación se ha configurado con el portal para que utilice la integración con red virtual con requisito de puerta de enlace, se entabla una compleja negociación en su nombre para crear y asignar certificados en la puerta de enlace y en la aplicación. El resultado es que los trabajos que se usan para hospedar las aplicaciones pueden conectarse directamente a la puerta de enlace de red virtual de la VNet seleccionada.

Acceso a recursos locales

Las aplicaciones pueden acceder a los recursos locales mediante la integración con redes virtuales que tengan conexiones de sitio a sitio. Si usa la integración con red virtual con requisito de puerta de enlace, actualice las rutas de puerta de enlace de red virtual locales con los bloques de direcciones de punto a sitio. En la configuración inicial de la VPN de sitio a sitio, los scripts que se usan para configurarla deben configurar las rutas correctamente. Si agrega las direcciones de punto a sitio después de crear la VPN de sitio a sitio, deberá actualizar las rutas manualmente. El procedimiento varía según la puerta de enlace y no se describe aquí. No se puede tener BGP configurado con una conexión VPN de sitio a sitio.

No se requiere ninguna configuración adicional para que la característica de integración con red virtual regional acceda a los recursos locales mediante la red virtual. Basta con conectar la red virtual a los recursos de entorno local mediante ExpressRoute o una VPN de sitio a sitio.

Emparejamiento

Si usa el emparejamiento con integración con red virtual regional, no es necesario configurar nada más.

Si usa la integración con red virtual con requisito de puerta de enlace con el emparejamiento, deberá configurar algunos elementos más. Para configurar el emparejamiento para que funcione con su aplicación:

1. Agregue una conexión de emparejamiento en la red virtual a la que se conecta su aplicación. Al agregar la conexión de emparejamiento, habilite Permitir acceso a red virtual y active Permitir tráfico reenviado y Permitir tránsito de puerta de enlace.
2. Agregue una conexión de emparejamiento en la VNet que se está emparejando con la VNet a la que está conectado. Al agregar la conexión de emparejamiento en la VNet de destino, habilite Permitir acceso a red virtual y seleccione Permitir tráfico reenviado y Allow remote gateways (Permitir puertas de enlace remotas).
3. Vaya a la interfaz de usuario Plan de App Service > Redes > Integración con red virtual en el portal. Seleccione la red virtual a la que está conectada su aplicación. En la sección de enrutamiento, agregue el intervalo de direcciones de la VNet que está emparejada con la VNet a la que está conectada su aplicación.

Administración de integración con red virtual

La conexión y la desconexión con una red virtual tiene lugar en el nivel de la aplicación. Las operaciones que pueden afectar a la integración con red virtual en varias aplicaciones se encuentran en el nivel de plan de App Service. En el portal de la aplicación > Redes > Integración con red virtual, puede obtener detalles sobre la red virtual. Puede encontrar información similar en el nivel del plan de App Service en el portal Plan de App Service > Redes > Integración con red virtual.

La única operación que puede realizar en la vista de aplicación de la instancia de integración con red virtual es desconectar la aplicación de la red virtual si está conectada a ella. Para desconectar la aplicación de una red virtual, seleccione Desconectar. La aplicación se reinicia cuando se desconecta de una red virtual. La desconexión no cambia la red virtual. La subred o la puerta de enlace no se quitan. Si después quiere eliminar la red virtual, primero desconecte la aplicación de la red virtual y elimine los recursos que hay en ella, como las puertas de enlace.

La interfaz de usuario de integración con red virtual del plan de App Service muestra todas las integraciones con redes virtuales usadas por las aplicaciones de su plan de App Service. Para ver más detalles sobre cada red virtual, seleccione la red virtual que le interese. Hay dos acciones que puede realizar aquí en relación con la integración con red virtual con requisito de puerta de enlace:

• Sincronización de red: la operación de sincronización de red solo se usa con la característica de integración con red virtual con requisito de puerta de enlace. Realizar una operación de sincronización de red garantiza que los certificados y la información de red estén sincronizados. Si agrega o cambia el DNS de la red virtual, debe ejecutar una operación de sincronización de la red. Esta operación reinicia todas las aplicaciones que usen esta red virtual. Esta operación no funcionará si usa una aplicación y una red virtual que pertenezcan a distintas suscripciones.
• Agregar rutas: la adición de rutas impulsa el tráfico de salida a la red virtual.

La dirección IP privada asignada a la instancia se expone por medio de la variable de entorno, WEBSITE_PRIVATE_IP. La interfaz de usuario de la consola de Kudu también muestra la lista de variables de entorno disponibles para la aplicación web. Esta dirección IP se asigna desde el intervalo de direcciones de la subred integrada. En el caso de la integración con red virtual regional, el valor de WEBSITE_PRIVATE_IP es una dirección IP del intervalo de direcciones de la subred delegada y, en el de la integración con red virtual con requisito de puerta de enlace, el valor es una dirección IP del intervalo de direcciones del grupo de direcciones de punto a sitio configurado en la puerta de enlace de red virtual. Esta es la dirección IP que va a usar la aplicación web para conectarse a los recursos a través de la red virtual de Azure.

Enrutamiento de la integración con red virtual con requisito de puerta de enlace

Las rutas definidas en la red virtual se usan para dirigir el tráfico desde la aplicación hacia la red virtual. Para enviar más tráfico de salida a la red virtual, agregue aquí esos bloques de direcciones. Esta característica solo funciona con la integración con red virtual con requisito de puerta de enlace. Las tablas de rutas no afectan del mismo modo al tráfico de la aplicación cuando se utiliza la integración con red virtual con requisito de puerta de enlace que cuando se utiliza la integración con red virtual regional.

Certificados de integración con red virtual con requisito de puerta de enlace

Cuando la integración con red virtual con requisito de puerta de enlace está habilitada, existe un intercambio necesario de certificados para garantizar la seguridad de la conexión. Junto con los certificados, se incluyen la configuración de DNS, las rutas y otros elementos similares que describen la red.

Si los certificados o la información de red cambian, es necesario hacer clic en Sincronizar red. Al seleccionar Sincronizar red, se producirá una breve interrupción en la conectividad entre la aplicación y la red virtual. Aunque no se reinicia la aplicación, la pérdida de conectividad podría hacer que su sitio no funcione correctamente.

Detalles de precios

El uso de la característica de integración con red virtual regional no conlleva ningún cargo adicional aparte de los cargos del plan de tarifa del plan de App Service.

Hay tres cargos relacionados con el uso de la característica de integración con red virtual con requisito de puerta de enlace:

• Cargos de plan de tarifa del plan de App Service: Las aplicaciones deben estar en un plan de App Service Estándar, Premium, PremiumV2 o PremiumV3. Para obtener más información sobre estos costes, consulte Precios de App Service.
• Costos de la transferencia de datos: Se aplica un cargo de salida de datos, aunque la red virtual esté en el mismo centro de datos. Estos cargos se describen en la página de detalles de precios de Transferencia de datos.
• Costos de VPN Gateway: Existe un costo para la puerta de enlace de red virtual necesario para la VPN de punto a sitio. Para obtener más información, vea Precios de VPN Gateway.

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.

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.