Configuración de la infraestructura de Azure Application Gateway
La infraestructura de Azure Application Gateway incluye la red virtual, las subredes, los grupos de seguridad de red (NSG) y las rutas definidas por el usuario (UDR).
Red virtual y subred dedicada
Una puerta de enlace de aplicaciones es una implementación dedicada en su red virtual. Dentro de la red virtual, es necesaria una subred dedicada para la puerta de enlace de aplicaciones. Puede tener varias instancias de una implementación específica de Application Gateway en una subred. También se pueden implementar otras puertas de enlace de aplicaciones en la subred. Pero no puede implementar ningún otro recurso en la subred de Application Gateway. No se pueden mezclar las SKU de Application Gateway v1 y v2 en la misma subred.
Nota:
Actualmente, no se admiten directivas de punto de conexión de servicio de red virtual en una subred de Application Gateway.
Tamaño de la subred
Application Gateway usa una dirección IP privada por instancia, más otra dirección IP privada si se configura una dirección IP de front-end privada.
Azure también reserva cinco direcciones IP en cada subred para su uso interno. Son las cuatro primeras direcciones y las últimas direcciones IP. Por ejemplo, considere 15 instancias de Application Gateway sin ninguna dirección IP de front-end privada. Necesita al menos 20 direcciones IP para esta subred. Necesita 5 para uso interno y 15 para las instancias de Application Gateway.
Considere una subred que tenga 27 instancias de Application Gateway y una dirección IP para una dirección IP de front-end privada. En este caso, necesita 33 direcciones IP. Necesita 27 para las instancias de Application Gateway, una para el front-end privado y 5 para uso interno.
Application Gateway (SKU estándar o WAF) puede admitir hasta 32 instancias (32 direcciones IP de instancia + 1 configuración de IP de front-end privada + 5 reservadas de Azure). Se recomienda un tamaño mínimo de subred /26.
Application Gateway (SKU Standard_v2 o WAF_v2) puede admitir hasta 125 instancias (125 instancias de direcciones IP + 1 configuración de IP de front-end privada + 5 instancias reservadas de Azure). Se recomienda un tamaño mínimo de subred /24.
Para determinar la capacidad disponible de una subred que tiene las puertas de enlace de aplicaciones existentes aprovisionadas, tome el tamaño de la subred y reste las cinco direcciones IP reservadas de la subred reservadas por la plataforma. A continuación, tome cada puerta de enlace y reste el número máximo de instancias. Para cada puerta de enlace que tenga una configuración IP de front-end privada, resta una dirección IP más por puerta de enlace.
Por ejemplo, a continuación se muestra cómo calcular el direccionamiento disponible para una subred con tres puertas de enlace de distintos tamaños:
- Puerta de enlace 1: máximo de 10 instancias. Usa una configuración de IP de front-end privada.
- Puerta de enlace 2: máximo de 2 instancias. No hay ninguna configuración de IP de front-end privada.
- Puerta de enlace 3: máximo de 15 instancias. Usa una configuración de IP de front-end privada.
- Tamaño de subred: /24
- Tamaño de subred /24 = 256 direcciones IP: 5 reservadas en la plataforma = 251 direcciones disponibles
- 251: puerta de enlace 1 (10): 1 configuración IP de front-end privada = 240
- 240: puerta de enlace 2 (2) = 238
- 238: puerta de enlace 3 (15): 1 configuración IP de front-end privada = 222
Importante
Aunque no se requiere una subred /24 por implementación de SKU de Application Gateway v2, se recomienda encarecidamente. Una subred /24 garantiza que Application Gateway v2 tenga suficiente espacio para la expansión del escalado automático y las actualizaciones de mantenimiento.
Debe asegurarse de que la subred Application Gateway v2 tenga suficiente espacio de direcciones para dar cabida al número de instancias necesarias para atender el tráfico máximo esperado. Si especifica el recuento máximo de instancias, la subred debe tener capacidad para al menos esas muchas direcciones. Para planear la capacidad según el recuento de instancias, consulte Detalles del recuento de instancias.
La subred denominada GatewaySubnet está reservada para las puertas de enlace de VPN. Los recursos de Application Gateway v1 que usan la subred GatewaySubnet deben moverse a otra subred o migrarse a la SKU v2 antes del 30 de septiembre de 2023 para evitar errores de plano de control e incoherencias de plataforma. Para obtener información sobre cómo cambiar la subred de una instancia de Application Gateway existente, consulte Preguntas más frecuentes sobre Application Gateway.
Sugerencia
Las direcciones IP se asignan desde el principio del espacio de subred definido para las instancias de puerta de enlace. A medida que se crean y quitan instancias debido a la creación de puertas de enlace o eventos de escalado, puede resultar difícil comprender cuál es la siguiente dirección disponible en la subred. Para poder determinar la siguiente dirección que se va a usar para una puerta de enlace futura y tener un tema de direccionamiento contiguo para direcciones IP de front-end, considere la posibilidad de asignar direcciones IP de front-end desde la mitad superior del espacio del subconjunto definido.
Por ejemplo, si el espacio de direcciones de subred es 10.5.5.0/24, considere la posibilidad de establecer la configuración de IP de front-end privada de las puertas de enlace a partir de 10.5.5.254 y seguir con 10.5.5.253, 10.5.5.252, 10.5.5.251, etc., para futuras puertas de enlace.
Es posible cambiar la subred de una instancia de Application Gateway existente dentro de la misma red virtual. Para realizar este cambio, use Azure PowerShell o la CLI de Azure. Para obtener más información, vea las preguntas más frecuentes sobre Application Gateway.
Servidores DNS para la resolución de nombres
El recurso de red virtual admite configuración del servidor DNS, lo que le permite elegir entre los servidores DNS predeterminados o personalizados proporcionados por Azure. Las instancias de la puerta de enlace de aplicaciones también respetan esta configuración DNS para cualquier resolución de nombres. Después de cambiar esta configuración, debe reiniciar (Detener e Iniciar) la puerta de enlace de aplicaciones para que estos cambios surtan efecto en las instancias.
Cuando una instancia de Application Gateway emite una consulta DNS, usa el valor del servidor que responde primero.
Nota:
Si usa servidores DNS personalizados en la red virtual de Application Gateway, el servidor DNS debe poder resolver los nombres de Internet públicos. Application Gateway requiere esta funcionalidad.
Permiso de red virtual
El recurso de Application Gateway se implementa dentro de una red virtual, por lo que también se realizan comprobaciones para comprobar el permiso en el recurso de red virtual proporcionado. Esta validación se realiza durante las operaciones de creación y administración, y también se aplica a las identidades administradas para el controlador de entrada de Application Gateway.
Compruebe el control de acceso basado en roles de Azure para comprobar que los usuarios y entidades de servicio que operan las puertas de enlace de aplicaciones también tienen al menos los siguientes permisos en la red virtual o subred.
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
Puede usar los roles integrados, como colaborador de red, que ya admiten estos permisos. Si un rol integrado no proporciona el permiso adecuado, puede crear y asignar un rol personalizado. Obtenga más información sobre la administración de permisos de subred.
Permisos
En función de si va a crear nuevos recursos o usar los existentes, agregue los permisos adecuados de la lista siguiente:
| Resource | Estado del recurso | Permisos de Azure necesarios |
|---|---|---|
| Subnet | Crear nuevo | Microsoft.Network/virtualNetworks/subnets/write Microsoft.Network/virtualNetworks/subnets/join/action |
| Subnet | Utilizar existente | Microsoft.Network/virtualNetworks/subnets/read Microsoft.Network/virtualNetworks/subnets/join/action |
| Direcciones IP | Crear nuevo | Microsoft.Network/publicIPAddresses/write Microsoft.Network/publicIPAddresses/join/action |
| Direcciones IP | Utilizar existente | Microsoft.Network/publicIPAddresses/read Microsoft.Network/publicIPAddresses/join/action |
| ApplicationGatewayWebApplicationFirewallPolicies | Crear nuevo o actualizar existente | Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/write Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/join/action |
Para obtener más información, consulte Permisos de Azure para redes y Permisos de red virtual.
Ámbito de roles
En el proceso de definición de roles personalizados, puede especificar un ámbito de asignación de roles en cuatro niveles: grupo de administración, suscripción, grupo de recursos y recursos. Para conceder acceso, debe asignar roles a usuarios, grupos, entidades de servicio o identidades administradas en un ámbito determinado. Estos ámbitos se estructuran en una relación de elementos primarios y secundarios, donde cada nivel de jerarquía hace que el ámbito sea más específico. Puede asignar roles en cualquiera de estos niveles de ámbito y el nivel que seleccione determina la amplitud de la aplicación del rol. Por ejemplo, un rol asignado en el nivel de suscripción se puede propagar a todos los recursos de esa suscripción, mientras que un rol asignado en el nivel de grupo de recursos solo se aplicará a los recursos de ese grupo específico. Obtenga más información sobre el nivel de ámbito. Para obtener más información, consulte Niveles de ámbito.
Nota:
Es posible que tenga que permitir tiempo suficiente para la actualización de la memoria caché de Azure Resource Manager después de que cambie la asignación de roles.
Identificación de usuarios o entidades de servicio afectados para la suscripción
Si visita Azure Advisor para su cuenta, puede comprobar si la suscripción tiene usuarios o entidades de servicio con permisos insuficientes. Los detalles de esa recomendación son:
Título: actualizar el permiso de red virtual de los usuarios de Application Gateway
Categoría:
de impacto de confiabilidad: alto
Uso de la marca temporal de Control de exposición de características de Azure (AFEC)
Como extensión temporal, se introdujo un control de exposición de características de Azure (AFEC). Puede registrarse para AFEC y usarlo hasta que corrija los permisos de todos los usuarios y entidades de servicio. Regístrese para la característica siguiendo los mismos pasos que un registro de características en versión preliminar para la suscripción de Azure.
Nombre: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Descripción: Deshabilitar la comprobación de permisos de subred de Application Gateway
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Nota:
Se recomienda usar el aprovisionamiento de AFEC solo como mitigación provisional hasta que asigne el permiso correcto. Debe priorizar la corrección de los permisos de todos los usuarios aplicables (y entidades de servicio) y, a continuación, anular el registro de esta marca de AFEC para volver a introducir la comprobación de permisos en el recurso de red virtual. Se recomienda no depender de este método AFEC de forma permanente porque se quitará en el futuro.
Azure Virtual Network Manager
Azure Virtual Network Manager es un servicio de administración que permite agrupar, configurar, implementar y administrar redes virtuales globalmente entre suscripciones. Con Virtual Network Manager, puede definir grupos de redes para identificar y segmentar lógicamente las redes virtuales. Después, puede determinar las configuraciones de conectividad y seguridad que desee y aplicarlas a todas las redes virtuales seleccionadas en grupos de red a la vez.
La configuración de reglas de administración de seguridad en Azure Virtual Network Manager permite definir directivas de seguridad a escala y aplicarlas a varias redes virtuales a la vez.
Nota:
Las reglas de administración de seguridad de Azure Virtual Network Manager solo se aplican a las subredes de Application Gateway que solo contienen puertas de enlace de aplicaciones que tienen Aislamiento de red habilitado. Las subredes con puertas de enlace de aplicaciones que tienen Aislamiento de red deshabilitado no tienen reglas de administración de seguridad.
Grupos de seguridad de red
Puede usar grupos de seguridad de red para la subred de Application Gateway, pero tenga en cuenta algunos puntos clave y restricciones.
Importante
Estas limitaciones del grupo de seguridad de red se relajan cuando se usa implementación de Application Gateway privada (versión preliminar).
Reglas de seguridad necesarias
Para usar un grupo de seguridad de red con la puerta de enlace de aplicaciones, debe crear o conservar algunas reglas de seguridad esenciales. Puede establecer su prioridad en el mismo orden.
Reglas de entrada
tráfico de cliente: permita el tráfico entrante de los clientes esperados (como IP de origen o intervalo IP) y para el destino como prefijo IP de subred completo de la puerta de enlace de aplicaciones y puertos de acceso entrante. Por ejemplo, si tiene agentes de escucha configurados para los puertos 80 y 443, debe permitir estos puertos. También puede establecer esta regla en Any.
| Source | Puertos de origen | Destination | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|
<as per need> |
Any | <Subnet IP Prefix> |
<listener ports> |
TCP | Permitir |
Después de configurar agentes de escucha públicos y privados activos (con reglas) con el mismo número de puerto, la puerta de enlace de aplicaciones cambia el destino de todos los flujos entrantes a las direcciones IP de front-end de la puerta de enlace. Este cambio se produce incluso para los agentes de escucha que no comparten ningún puerto. Debe incluir las direcciones IP públicas y privadas de la puerta de enlace en la Destino de la regla de entrada cuando se usa la misma configuración de puerto.
| Source | Puertos de origen | Destination | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|
<as per need> |
Any | <Public and Private frontend IPs> |
<listener ports> |
TCP | Permitir |
Puertos de infraestructura: permite las solicitudes entrantes desde el origen como etiqueta de servicio GatewayManager y Cualquier destino. El intervalo de puertos de destino difiere en función de la SKU y es necesario para comunicar el estado del back-end. Estos puertos están protegidos o bloqueados por certificados de Azure. Las entidades externas no pueden iniciar cambios en esos puntos de conexión sin los certificados adecuados.
- V2: puertos 65200-65535
- V1: puertos 65503-65534
| Source | Puertos de origen | Destination | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|
| GatewayManager | Any | Any | <as per SKU given above> |
TCP | Permitir |
Sondeos de Azure Load Balancer: permitir el tráfico entrante desde el origen como la etiqueta de servicio AzureLoadBalancer. Esta regla se crea de forma predeterminada para grupos de seguridad de red. No debe invalidarlo con una regla de denegar manual para garantizar operaciones fluidas de la puerta de enlace de aplicaciones.
| Source | Puertos de origen | Destination | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|
| AzureLoadBalancer | Any | Any | Any | Any | Allow |
Puede bloquear el resto del tráfico entrante mediante una regla de Denegar todo.
Reglas de salida
Saliente a Internet: permitir el tráfico saliente a Internet para todos los destinos. Esta regla se crea de forma predeterminada para grupos de seguridad de red. No debe invalidarlo con una regla de denegar manual para garantizar operaciones fluidas de la puerta de enlace de aplicaciones. No se deben crear reglas de NSG de salida que denieguen ninguna conectividad saliente.
| Source | Puertos de origen | Destination | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|
| Any | Any | Internet | Any | Any | Allow |
Nota:
Las instancias de Application Gateway que no tienen habilitado el aislamiento de red no permiten enviar tráfico entre redes virtuales emparejadas cuando se deshabilita Permitir el tráfico a la red virtual remota.
Rutas definidas por el usuario admitidas
El control específico sobre la subred de Application Gateway a través de reglas de tabla de rutas es posible en versión preliminar pública. Para obtener más información, consulte Implementación de Private Application Gateway (versión preliminar).
Con la funcionalidad actual, hay algunas restricciones:
Importante
El uso de UDR en la subred de Application Gateway podría hacer que el estado de mantenimiento en la vista de mantenimiento de back-end se muestre como Desconocido. También podría provocar un error en la generación de registros y métricas de Application Gateway. Se recomienda no usar UDR en la subred de Application Gateway para que pueda ver el estado del back-end, los registros y las métricas.
v1: para la SKU v1, las UDR se admiten en la subred de Application Gateway si no modifican la comunicación de solicitud y respuesta de un extremo a otro. Por ejemplo, puede configurar una ruta definida por el usuario en la subred de Application Gateway para que apunte a un dispositivo de firewall para la inspección de paquetes. Debe asegurarse de que el paquete puede llegar a su destino previsto después de la inspección. El no hacerlo podría resultar en un sondeo del estado o en un comportamiento de enrutamiento de tráfico incorrectos. También se incluyen rutas aprendidas o rutas 0.0.0.0/0 predeterminadas propagadas por Azure ExpressRoute o puertas de enlace de VPN en la red virtual.
v2: para la SKU v2, hay escenarios admitidos y no admitidos.
Escenarios admitidos de v2
Advertencia
Una configuración incorrecta de la tabla de rutas podría dar lugar a un enrutamiento asimétrico en Application Gateway v2. Asegúrese de que todo el tráfico del plano de control o administración se envía directamente a Internet y no a través de una aplicación virtual. El registro, las métricas y las comprobaciones de CRL también podrían verse afectados.
Escenario 1: UDR para deshabilitar la propagación de rutas del Protocolo de puerta de enlace de borde (BGP) a la subred de Application Gateway
A veces, la ruta de puerta de enlace predeterminada (0.0.0.0/0) se anuncia mediante las puertas de enlace de VPN o ExpressRoute asociadas con la red virtual de Application Gateway. Este comportamiento interrumpe el tráfico del plano de administración, que requiere una ruta de acceso directa a Internet. En estos escenarios, puede usar una UDR para deshabilitar la propagación de rutas BGP.
Para deshabilitar la propagación de rutas BGP:
- Cree un recurso de tabla de rutas en Azure.
- Deshabilite el parámetro Propagación de rutas de puerta de enlace de red virtual.
- Asocie la tabla de rutas a la subred adecuada.
La habilitación de UDR para este escenario no debe interrumpir las configuraciones existentes.
Escenario 2: UDR para dirigir 0.0.0.0/0 a Internet
Puede crear una UDR para enviar tráfico 0.0.0.0/0 directamente a Internet.
Escenario 3: UDR para Azure Kubernetes Service (AKS) con kubenet
Si usa kubenet con AKS y el Controlador de entrada de Application Gateway, necesita una tabla de rutas para permitir que el tráfico enviado a los pods de Application Gateway se enrute al nodo correcto. No es necesario usar una tabla de rutas si usa Azure Container Networking Interface.
Para usar la tabla de rutas para permitir que kubenet funcione:
Vaya al grupo de recursos creado por AKS. El nombre del grupo de recursos debe comenzar por
MC_.Busque la tabla de rutas creada por AKS en ese grupo de recursos. La tabla de rutas se debe rellenar con la siguiente información:
- El prefijo de dirección debe ser el intervalo IP de los pods a los que quiere acceder en AKS.
- El tipo de próximo salto debe ser aplicación virtual.
- La dirección del próximo salto debe ser la dirección IP del nodo que hospeda los pods.
Asocie esta tabla de rutas a la subred de Application Gateway.
Escenarios incompatibles de v2
Escenario 1: UDR para aplicaciones virtuales
Cualquier escenario en el que se deba redirigir 0.0.0.0/0 a través de una aplicación virtual, una red virtual en estrella tipo hub-and-spoke o local (tunelización forzada) no se admite para v2.
Servicios adicionales
Para ver roles y permisos para otros servicios, consulte los vínculos siguientes: