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 v1 y v2 se retiran a partir del 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 v1, siga los pasos descritos en este artículo para migrar a la nueva versión.
A partir del 31 de agosto de 2024, el Acuerdo de Nivel de Servicio (SLA) y los créditos de servicio ya no se aplican a las cargas de trabajo de App Service Environment v1 y v2 que siguen en producción, ya que son productos retirados. Se ha iniciado la retirada del hardware de App Service Environment v1 y v2, lo que puede afectar a la disponibilidad y el rendimiento de las aplicaciones y los datos.
Debe completar la migración a App Service Environment v3 inmediatamente o las aplicaciones y los recursos podrían ser eliminados. Intentaremos migrar automáticamente cualquier instancia restante de App Service Environment v1 y v2 en la medida de lo posible mediante la característica de migración local, pero Microsoft no ofrece ninguna garantía sobre la disponibilidad de la aplicación después de la migración automática. Es posible que tenga que realizar la configuración manual para completar la migración y optimizar la opción de SKU del plan de App Service para satisfacer sus necesidades. Si la migración automática no es factible, se eliminarán los recursos y los datos de la aplicación asociados. Le instamos encarecidamente a que actúe ahora para evitar cualquiera de estos escenarios extremos.
Si necesita más tiempo, podemos ofrecerle un único periodo de gracia de 30 días para que complete la migración. Para obtener más información y solicitar este período de gracia, consulte la información general del período de gracia, y a continuación, vaya a Azure Portal y visite la hoja Migración para cada uno de los entornos de App Service.
Para obtener la información más actualizada sobre la retirada de App Service Environment v1/v2, consulte la Actualización de retirada de App Service Environment v1 y v2.
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:
- Externa: este tipo de implementación expone las aplicaciones hospedadas mediante una dirección IP accesible en Internet. Para más información, consulte Creación de una instancia externa de App Service Environment.
- Equilibrador de carga interno: este tipo de implementación expone las aplicaciones hospedadas en una dirección IP dentro de la red virtual. El punto de conexión interno es un equilibrador de carga interno. Para obtener más información, consulte Creación y uso de una instancia de Azure App Service Environment de Load Balancer.
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.
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
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.
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
AppServiceManagementen 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
Sqlen 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 |
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.
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:
Vaya a Azure portal y seleccione Redes>Tablas de rutas.
Cree una nueva tabla de rutas en la misma región que la red virtual.
En la interfaz de usuario de la tabla de rutas, seleccione Rutas>Agregar.
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:
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.
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.
