Consideraciones de red para una instancia de App Service Environment

Importante

En este artículo se aborda App Service Environment v2, que se usa con planes de App Service aislado. App Service Environment v2 se retirará el 31 de agosto de 2024. Hay una nueva versión de App Service Environment que resulta más fácil de usar y se ejecuta en una infraestructura más eficaz. Para aprender más sobre la nueva versión, empiece por consultar la Introducción a App Service Environment. Si actualmente usa App Service Environment v2, siga los pasos descritos en este artículo para migrar a la nueva versión.

App Service Environment es una implementación de Azure App Service en una subred de Azure Virtual Network. En una instancia de App Service Environment, hay dos tipos de implementación:

Nota

En este artículo se aborda App Service Environment v2, que se usa con planes de App Service aislados.

Independientemente del tipo de implementación, todas las instancias de App Service Environment tienen una dirección IP virtual (VIP) pública. Esta VIP se usa para el tráfico de administración entrante y como dirección cuando se realiza una llamada desde la instancia de App Service Environment a Internet. Estas llamadas salen de la red virtual a través de la VIP asignada a la instancia de App Service Environment.

Si las aplicaciones realizan llamadas a los recursos de la red virtual o a través de una VPN, la dirección IP de origen es una de las de la subred. Dado que la instancia de App Service Environment está dentro de la red virtual, también puede tener acceso a los recursos dentro de esta red sin ninguna configuración adicional. Si la red virtual está conectada a la red local, las aplicaciones también tienen acceso a los recursos disponibles allí sin configuración adicional.

Diagram that shows the elements of an external deployment. 

Si tiene una instancia de App Service Environment con una implementación externa, la VIP pública también es el punto de conexión en el que las aplicaciones resuelven lo siguiente:

  • HTTP/S
  • FTP/S
  • Implementación web
  • Depuración remota

Diagram that shows the elements of an internal load balancer deployment.

Si tiene una instancia de App Service Environment con una implementación de equilibrador de carga interno, la dirección de la dirección interna es el punto de conexión para HTTP/S, FTP/S, implementación web y depuración remota.

Tamaño de la subred

Una vez implementada la instancia de App Service Environment, no se puede modificar el tamaño de la subred que se usa para hospedarla. App Service Environment utiliza una dirección para cada rol de la infraestructura, así como para cada instancia del plan de App Service en entorno aislado. Además, las redes de Azure usan cinco direcciones para cada subred que se crea.

Una instancia de App Service Environment que no tenga ningún plan de App Service utilizará 12 direcciones antes de que se cree una aplicación. Si usa la implementación del equilibrador de carga interno, usará 13 direcciones antes de crear una aplicación. A medida que escale horizontalmente, los roles de infraestructura se agregan a cada múltiplo de 15 y 20 de las instancias del plan de App Service.

Importante

No puede haber nada más en la subred que la instancia de App Service Environment. Asegúrese de elegir un espacio de direcciones que pueda crecer en el futuro. No puede cambiar esta configuración posteriormente. Se recomienda un tamaño de /24 con doscientas cincuenta y seis direcciones.

Al escalar o reducir verticalmente, se agregan nuevos roles del tamaño adecuado y, a continuación, las cargas de trabajo se migran del tamaño actual al tamaño de destino. Las máquinas virtuales originales no se quitan hasta que las cargas de trabajo se hayan migrado. Por ejemplo, si tenía una instancia de App Service Environment con 100 instancias del plan de App Service, hay un período de tiempo en el que necesita duplicar el número de VM.

Dependencias de entrada y salida

En las secciones siguientes se tratan las dependencias que debe tener en cuenta para su instancia de App Service Environment. En otra sección se describe la configuración de DNS.

Dependencias de entrada

Solo para que la instancia de App Service Environment funcione, deben estar abiertos los siguientes puertos:

Uso De A
Administración Direcciones de administración de App Service Subred de App Service Environment: 454, 455
Comunicación interna de App Service Environment Subred de App Service Environment: todos los puertos Subred de App Service Environment: todos los puertos
Permitir entrada de Azure Load Balancer Azure Load Balancer Subred de App Service Environment: 16001

Los puertos 7564 y 1221 se pueden mostrar como abiertos en un examen de puertos. Estos puertos responden con una dirección IP y nada más. Puede bloquearlos si quiere.

El tráfico de administración de entrada proporciona el comando y control de la instancia de App Service Environment, además de supervisión del sistema. Las direcciones de origen para este tráfico se incluyen en Direcciones de administración de App Service Environment. La configuración de seguridad de red debe permitir el acceso desde las direcciones de administración de la instancia de App Service Environment en los puertos 454 y 455. Si se bloquea el acceso desde esas direcciones, la instancia de Azure App Service Environment entrará en un estado incorrecto y se suspenderá. El tráfico TCP que entra por los puertos 454 y 455 debe salir de la misma VIP o tendrá un problema de enrutamiento asimétrico.

Dentro de la subred hay muchos puertos usados para la comunicación de componentes interna, y pueden cambiar. Esto requiere que todos los puertos de la subred sean accesibles desde la subred.

Para la comunicación entre el equilibrador de carga de Azure y la subred de la instancia de App Service Environment, los puertos mínimos que deben abrirse son el 454, el 455 y el 16001. Si usa una implementación de equilibrador de carga interno, puede bloquear el tráfico con la única excepción de los puertos 454, 455 y 16001. Si usa una implementación externa, debe tener en cuenta los puertos normales de acceso a las aplicaciones. En concreto, son:

Uso Puertos
HTTP/HTTPS 80, 443
FTP/FTPS 21, 990, 10001-10020
Depuración remota en Visual Studio 4020, 4022, 4024
Servicio Web Deploy 8172

Si bloquea los puertos de aplicación, la instancia de App Service Environment puede seguir funcionando, pero es posible que la aplicación no. Si usa direcciones IP asignadas a las aplicaciones con una implementación externa, debe permitir el tráfico de las direcciones IP asignadas a sus aplicaciones en la subred. En el portal de App Service Environment, vaya a Direcciones IP y consulte los puertos desde los que debe permitir el tráfico.

Dependencias de salida

Para el acceso de salida, una instancia de App Service Environment depende de varios sistemas externos. Muchas de estas dependencias del sistema se definen con nombres DNS y no se asignan a un conjunto fijo de direcciones IP. Por tanto, la instancia de App Service Environment requiere acceso de salida desde la subred a todas las direcciones IP externas en varios puertos.

App Service Environment se comunica con direcciones accesibles de Internet en los siguientes puertos:

Usos Puertos
DNS 53
NTP 123
CRL, actualizaciones de Windows, dependencias de Linux, servicios de Azure 80/443
Azure SQL 1433
Supervisión 12000

Las dependencias de salida se muestran en Bloqueo de una instancia de App Service Environment. Si la instancia de App Service Environment pierde el acceso a sus dependencias, deja de funcionar. Cuando esto sucede durante un período de tiempo suficientemente largo, se suspende.

DNS del cliente

Si la red virtual se configura con un servidor DNS definido por el cliente, las cargas de trabajo del inquilino lo utilizan. La instancia de App Service Environment usa Azure DNS con fines de administración. Si la red virtual se configura con un servidor DNS seleccionado por el cliente, este servidor tiene que ser accesible desde la subred.

Nota

Los montajes de almacenamiento o las extracciones de imágenes de contenedor en App Service Environment v2 no pueden usar el DNS definido por el cliente en la red virtual ni a través de la configuración de la aplicación WEBSITE_DNS_SERVER.

Para probar la resolución DNS de la aplicación web, puede usar el comando de consola nameresolver. Vaya a la ventana de depuración en el sitio de scm para su aplicación o vaya a la aplicación en el portal y seleccione la consola. Desde el símbolo del shell puede enviar el comando nameresolver junto con el nombre DNS que quiera buscar. El resultado que se obtiene es el mismo que el que obtendría la aplicación al hacer la misma búsqueda. Si se usa nslookup, se realiza una búsqueda mediante Azure DNS.

Si cambia la configuración de DNS de la red virtual en la que se encuentra la instancia de App Service Environment, tendrá que reiniciarla. Para evitar el reinicio, es una buena idea configurar los valores de DNS para la red virtual antes de crear la instancia de App Service Environment.

Dependencias del portal

Además de las dependencias descritas en las secciones anteriores, hay algunas consideraciones adicionales que debe tener en cuenta que están relacionadas con la experiencia del portal. Algunas de las funcionalidades en Azure Portal dependen de un acceso directo al sitio del administrador de control de servicios (SCM). Para cada aplicación en Azure App Service, hay dos direcciones URL. La primera dirección URL es para acceder a la aplicación. La segunda dirección URL es para el acceso al sitio SCM, que también se denomina el consola Kudu. Algunas de las características que usan el sitio SCM incluyen:

  • Trabajos web
  • Functions
  • Secuencias de registro
  • Kudu
  • Extensiones
  • Explorador de procesos
  • Consola

Cuando se usa un equilibrador de carga interno, el sitio de SCM no es accesible desde fuera de la red virtual. Algunas funcionalidades no funcionarán desde el portal de la aplicación porque requieren acceso al sitio de SCM de una aplicación. Puede conectarse al sitio de SCM directamente en lugar de usar el portal.

Si el equilibrador de carga interno es el nombre de dominio y el nombre de la aplicación es contoso.appserviceenvironment.nettestapp, se llega a la aplicación en testapp.contoso.appserviceenvironment.net. El sitio de SCM correspondiente se encuentra en testapp.scm.contoso.appserviceenvironment.net.

Direcciones IP

Una instancia de App Service Environment tiene algunas direcciones IP que debe tener en cuenta. Son las siguientes:

  • Dirección IP pública de entrada: se usa para el tráfico de la aplicación en una implementación externa y para el tráfico de administración tanto en implementaciones externas como internas.
  • Dirección IP pública de salida: se usa como dirección IP de procedencia para las conexiones de salida que salen de la red virtual. Estas conexiones no se enrutan a una VPN.
  • Dirección IP del equilibrador de carga interno: esta dirección solo existe en una implementación interna.
  • Direcciones TSL/SSL basadas en IP asignadas por la aplicación: solo son posibles con una implementación externa y cuando hay configurado un enlace TLS/SSL basado en IP.

Todas estas direcciones IP estarán visibles en Azure Portal desde la interfaz de usuario de App Service Environment. Si tiene una implementación interna, se muestra la dirección IP del equilibrador de carga interno.

Nota

Estas direcciones IP no cambian, siempre y cuando la instancia de App Service Environment esté en ejecución. Si la instancia de App Service Environment se suspende y, a continuación, se restaura, las direcciones usadas cambiarán. La causa normal de una suspensión es si bloquea el acceso de administración entrante o bloquea el acceso a una dependencia.

Screenshot that shows IP addresses.

Direcciones IP asignadas a la aplicación

Con una implementación externa, puede asignar direcciones IP a aplicaciones individuales. No puede hacer esto con una implementación interna. Para más información sobre cómo configurar la aplicación para que tenga su propia dirección IP, consulte Protección de un nombre DNS personalizado con un enlace de TLS/SSL en Azure App Service.

Cuando una aplicación tiene su propia dirección SSL basada en IP, la instancia de App Service Environment reserva dos puertos para asignarlos a esa dirección IP. Un puerto es para el tráfico HTTP y el otro es para HTTPS. Esos puertos se enumeran en la sección Direcciones IP del portal de la instancia de App Service Environment. El tráfico debe poder acceder a esos puertos desde la dirección VIP. De lo contrario, las aplicaciones no son accesibles. Es importante recordar este requisito al configurar grupos de seguridad de red (NSG).

Grupos de seguridad de red

Los NSG permiten controlar el acceso a la red dentro de una red virtual. Cuando usa el portal, hay una regla de denegación implícita con la prioridad más baja que deniega todo. Lo que crea son las reglas de permiso.

No tiene acceso a las VM que se usan para hospedar la instancia de App Service Environment en sí. Están en una suscripción que administra Microsoft. Si quiere limitar el acceso a las aplicaciones, tiene que establecer NSG en la subred. Al hacerlo, tiene que prestar mucha atención a las dependencias. Si bloquea las dependencias, la instancia de App Service Environment deja de funcionar.

Los NSG pueden configurarse mediante Azure Portal o a través de PowerShell. Esta información muestra Azure Portal. Puede crear y administrar los NSG en el portal como un recurso de nivel superior en Redes.

Las entradas necesarias en un NSG son para permitir el tráfico:

Entrante

  • TCP de la etiqueta del servicio IP AppServiceManagement en los puertos 454 y 455.
  • TCP desde el equilibrador de carga en el puerto 16001.
  • Desde la subred de App Service Environment a la subred de App Service Environment en todos los puertos

Outbound

  • UDP a todas las direcciones IP en el puerto 53.
  • UDP a todas las direcciones IP en el puerto 123.
  • TCP a todas las direcciones IP en los puertos 80 y 443.
  • TCP a la etiqueta del servicio IP Sql en el puerto 1433.
  • TCP a todas las direcciones IP en el puerto 12000.
  • A la subred de App Service Environment en todos los puertos

Estos puertos no incluyen los puertos que las aplicaciones requieren para usarse correctamente. Por ejemplo, supongamos que la aplicación necesita llamar a un servidor MySQL en el puerto 3306. El protocolo de tiempo de redes (NTP) del puerto 123 es el protocolo de sincronización de hora que usa el sistema operativo. Los puntos de conexión NTP no son específicos de App Service, pueden variar con el sistema operativo y no se encuentran en una lista bien definida de direcciones. Para evitar problemas de sincronización de hora, debe permitir el tráfico UDP a todas las direcciones en el puerto 123. El tráfico saliente del TCP al puerto 12000 es para el análisis y el soporte del sistema. Los puntos de conexión son dinámicos y no están en un conjunto bien definido de direcciones.

Los puertos de acceso de aplicación normales son:

Uso Puertos
HTTP/HTTPS 80, 443
FTP/FTPS 21, 990, 10001-10020
Depuración remota en Visual Studio 4020, 4022, 4024
Servicio Web Deploy 8172

Cuando los requisitos de entrada y salida se tienen en cuenta, los NSG deben ser similares a lo que se muestra en la captura de pantalla siguiente:

Screenshot that shows inbound security rules.

Una regla predeterminada permite que las direcciones IP en la red virtual se comuniquen con la subred. Otra regla predeterminada permite que el equilibrador de carga, también conocido como VIP pública, se comunique con la instancia de App Service Environment. Para ver las reglas predeterminadas, seleccione Reglas predeterminadas (junto al icono Agregar).

Si coloca una regla para denegar todo lo demás antes de las reglas predeterminadas, evitará el tráfico entre la IP virtual y la instancia de App Service Environment. Para impedir el tráfico procedente de dentro de la red virtual, agregue su propia regla para permitir la entrada. Utilice un origen igual que AzureLoadBalancer con cualquier destino y un intervalo de puertos de *. Puesto que la regla NSG se aplica a la subred, no es necesario que sea específico en el destino.

Si ha asignado una dirección IP a la aplicación, asegúrese de mantener los puertos abiertos. Para ver los puertos, seleccione App Service Environment>Direcciones IP.  

Se necesitan todos los elementos que se muestran en las siguientes reglas de salida, excepto la regla denominada ASE-internal-outbound. Estos elementos habilitan el acceso de red a las dependencias de App Service Environment que se han indicado anteriormente en este artículo. Si bloquea cualquiera de ellos, la instancia de App Service Environment deja de funcionar. La regla denominada ASE-internal-outbound de la lista permite que la instancia de App Service Environment se comunique con otros recursos de la red virtual.

Screenshot that shows outbound security rules.

Nota:

El intervalo IP de la regla ASE-internal-outbound es solo un ejemplo y debe cambiarse para que coincida con el intervalo de subred de la subred de App Service Environment.

Una vez que haya definido los NSG, asígnelos a la subred. Si no recuerda la red virtual o la subred, puede verla desde la página del portal de la instancia de App Service Environment. Para asignar el NSG a la subred, vaya a la interfaz de usuario de la subred y seleccione el NSG.

Rutas

La tunelización forzada es cuando se establecen rutas en la red virtual para que el tráfico saliente no vaya directamente a Internet. En su lugar, el tráfico va a otro lugar, como una puerta de enlace de Azure ExpressRoute o una aplicación virtual. Si necesita configurar su instancia de App Service Environment de esta manera, consulte Configuración de App Service Environment con tunelización forzada.

Cuando se crea una instancia de App Service Environment en el portal, se crea automáticamente un conjunto de tablas de rutas en la subred. Esas rutas sencillamente indican que se envíe el tráfico saliente directamente a Internet.

Para crear manualmente las mismas rutas, siga estos pasos:

  1. Vaya a Azure portal y seleccione Redes>Tablas de rutas.

  2. Cree una nueva tabla de rutas en la misma región que la red virtual.

  3. En la interfaz de usuario de la tabla de rutas, seleccione Rutas>Agregar.

  4. Establezca Tipo del próximo salto en Internet y Prefijo de dirección en 0.0.0.0/0. Seleccione Guardar.

    Verá algo parecido a lo siguiente:

    Screenshot that shows functional routes.

  5. Después de crear la nueva tabla de rutas, vaya a la subred. Seleccione la tabla de rutas de la lista en el portal. Después de guardar el cambio, debería ver los NSG y las rutas anotadas con la subred.

    Screenshot that shows NSGs and routes.

Puntos de conexión del servicio

Los puntos de conexión de servicio le permiten restringir el acceso de los servicios multiinquilino a un conjunto de subredes y redes virtuales de Azure. Para obtener más información, consulte Puntos de conexión de servicio de red virtual.

Cuando se habilitan puntos de conexión de servicio en un recurso, hay rutas que se crean con prioridad más alta que las demás. Si usa puntos de conexión de servicio en cualquier servicio de Azure, con una instancia de App Service Environment con tunelización forzada, el tráfico a esos servicios no está sujeto a la tunelización forzada.

Cuando se habilitan puntos de conexión de servicio en una subred con una instancia de Azure SQL, todas las instancias de Azure SQL conectadas desde esa subred deben tener habilitados también los puntos de conexión de servicio. Si quiere acceder a varias instancias de Azure SQL desde la misma subred, debe habilitar los puntos de conexión de servicio en todas ellas y no solo en una. Ningún otro servicio de Azure se comporta como Azure SQL en lo relativo a los puntos de conexión de servicio. Al habilitar puntos de conexión de servicio con Azure Storage, se bloquea el acceso a ese recurso desde la subred. Sin embargo, puede acceder a otras cuentas de Azure Storage, incluso si no tienen habilitados los puntos de conexión de servicio.

Diagram that shows service endpoints.