Preguntas más frecuentes sobre Azure Firewall

Azure Firewall es un servicio de seguridad de red administrado basado en la nube que protege los recursos de Azure Virtual Network. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en suscripciones y redes virtuales.

Para obtener una lista detallada de las características de Azure Firewall, consulte Azure Firewall features.

Azure Firewall se puede implementar en cualquier red virtual. Sin embargo, normalmente se implementa en una red virtual central en un modelo hub-and-spoke, con otras redes virtuales emparejadas a ella. La ruta predeterminada de las redes virtuales emparejadas se establece para que apunte a esta red virtual de firewall central. Aunque se admite el emparejamiento de red virtual global, no se recomienda debido a posibles problemas de rendimiento y latencia entre regiones. Para obtener un rendimiento óptimo, implemente un firewall por región.

Este modelo permite un control centralizado sobre varias redes virtuales radiales en distintas suscripciones y ofrece ahorros de costos al evitar la necesidad de implementar un firewall en cada red virtual. Se deben evaluar los ahorros de costos con respecto a los costos de interconexión asociados según los patrones de tráfico.

Azure Firewall se pueden implementar mediante el portal de Azure, PowerShell, la API REST o las plantillas. Para obtener instrucciones paso a paso, consulte Tutorial: Implementación y configuración de Azure Firewall mediante el portal de Azure.

Azure Firewall usa reglas y colecciones de reglas. Una colección de reglas es un conjunto de reglas con el mismo orden y prioridad. Las colecciones de reglas se ejecutan en orden de prioridad. Las colecciones de reglas DNAT tienen mayor prioridad que las colecciones de reglas de red, que a su vez tienen mayor prioridad que las colecciones de reglas de aplicación. Todas las reglas terminarán.

Hay tres tipos de colecciones de reglas:

• Reglas de aplicación: configure nombres de dominio completos (FQDN) a los que se pueda acceder desde una red virtual.
• Reglas de red: configure reglas con direcciones de origen, protocolos, puertos de destino y direcciones de destino.
• Reglas NAT: Configure reglas DNAT para permitir conexiones entrantes de Internet o intranet (versión preliminar).

Para obtener más información, vea Configure Azure Firewall rules.

Azure Firewall se integra con Azure Monitor para ver y analizar registros. Los registros se pueden enviar a Log Analytics, Azure Storage o Event Hubs y analizarlos mediante herramientas como Log Analytics, Excel o Power BI. Para obtener más información, consulte Tutorial: Supervisión de registros de Azure Firewall.

Azure Firewall es un servicio de seguridad de red administrado basado en la nube que protege los recursos de red virtual. Se trata de un firewall como servicio con estado completo que incorpora alta disponibilidad y escalabilidad a la nube sin restricciones. Se integra previamente con proveedores de seguridad como servicio (SECaaS) de terceros para mejorar la seguridad de las conexiones de redes virtuales e Internet en sucursales. Para obtener más información, consulte Azure seguridad de red.

Application Gateway WAF proporciona protección centralizada entrante para aplicaciones web frente a exploits y vulnerabilidades comunes. Azure Firewall proporciona protección de entrada para protocolos que no son HTTP/S (por ejemplo, RDP, SSH, FTP), protección de nivel de red saliente para todos los puertos y protocolos, y protección de nivel de aplicación para HTTP/S de salida.

Azure Firewall complementa a los grupos de seguridad de red para proporcionar una mejor seguridad de red de "defensa en profundidad". NSGs (grupos de seguridad de red) ofrecen filtrado distribuido de tráfico en la capa de red para limitar el tráfico dentro de las redes virtuales de cada suscripción. Azure Firewall proporciona protección de red y de nivel de aplicación completamente centralizada y de estado completo en todas las suscripciones y redes virtuales.

Azure Firewall es un servicio administrado con varias capas de protección, incluida la protección de plataformas con NSG de nivel de NIC (no visible). Los NSG de nivel de subred no son necesarios en AzureFirewallSubnet y están deshabilitados para evitar interrupciones del servicio.

Los puntos de conexión privados son un componente de Private Link, una tecnología que permite interactuar con Azure servicios PaaS mediante direcciones IP privadas en lugar de las públicas. Azure Firewall se puede usar para evitar el acceso a direcciones IP públicas, lo que evita la filtración de datos hacia servicios de Azure que no aprovechan Private Link, así como para implementar directivas de confianza cero, definiendo quién de su organización necesita acceder a esos servicios PaaS de Azure, ya que Private Link, por defecto, abre el acceso de red para toda la red corporativa.

El diseño adecuado para inspeccionar el tráfico a puntos de conexión privados con Azure Firewall dependerá de la arquitectura de red, puede encontrar más detalles en el artículo Azure Firewall escenarios para inspeccionar el tráfico destinado a un punto de conexión privado.

Los puntos de conexión de servicio de la Red Virtual son una alternativa a Private Link para controlar el acceso de red a los servicios PaaS de Azure. Incluso si el cliente sigue usando direcciones IP públicas para acceder al servicio PaaS, la subred de origen se hace visible para que el servicio PaaS de destino pueda implementar reglas de filtro y restringir el acceso por subred. Puede encontrar una comparación detallada entre ambos mecanismos en Comparar puntos de conexión privados y puntos de conexión de servicio.

Azure Firewall puede usar reglas de aplicación para asegurar que no se produzca ninguna filtración de datos a servicios no autorizados y para implementar directivas de acceso con una granularidad mayor más allá del nivel de subred. Normalmente, los puntos de conexión de servicio de red virtual deben habilitarse en la subred del cliente que se conectará a un servicio de Azure. Sin embargo, al inspeccionar el tráfico a los puntos de conexión de servicio con Azure Firewall, debe habilitar el punto de conexión de servicio correspondiente en la subred Azure Firewall en su lugar y deshabilitarlo en la subred del cliente real (normalmente una red virtual radial). De este modo, puede usar reglas de aplicación en Azure Firewall para controlar a qué servicios Azure tendrán acceso las cargas de trabajo de Azure.

Para obtener más información sobre los precios, consulte Precios de Azure Firewall.

Para conocer los límites de servicio, consulte Azure límites de suscripción y servicios, cuotas y restricciones.

Azure Firewall no mueve ni almacena datos de cliente fuera de la región donde se implementa.

No, actualmente no se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar.

Sí, Azure Firewall admite el filtrado de tráfico entrante y saliente. El filtrado de entrada se usa normalmente para protocolos que no son HTTP, como RDP, SSH y FTP. Para el tráfico HTTP y HTTPS entrante, considere la posibilidad de usar un firewall de aplicaciones web como Azure Web Application Firewall (WAF) o las características de descarga y inspección profunda de paquetes TLS de Azure Firewall Premium.

Sí, Azure Firewall Basic admite la tunelización forzada.

Un ping tcp no se conecta realmente al FQDN de destino. Azure Firewall bloquea las conexiones a cualquier dirección IP de destino o FQDN a menos que una regla lo permita explícitamente.

En el caso de un ping tcp, si no hay ninguna regla que permita el tráfico, el firewall responde a la solicitud de ping TCP del cliente. Esta respuesta no alcanza la dirección IP de destino ni el FQDN y no se registra. Si una regla de red permite explícitamente el acceso a la dirección IP de destino o al FQDN, la solicitud ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

No, Azure Firewall no admite de forma nativa el emparejamiento BGP. Sin embargo, la característica de rutas SNAT de Autolearn usa indirectamente BGP a través de Azure Route Server.

Azure Firewall no admite de forma nativa ESP (carga de seguridad encapsulada), pero puede permitir el tráfico ESP configurando una regla de red de la siguiente manera:

configuración de Azure Firewall (regla de red):

• Protocolo: Cualquiera
• Puerto de origen: * (Cualquiera)
• Puerto de destino: * (Cualquiera)
• Origen o destino: especifique las direcciones IP según sea necesario.

Esta configuración permite que los paquetes ESP (número de protocolo IP 50) y otro tráfico que no sea TCP/UDP coincidan con la regla. Sin embargo, tenga en cuenta que Azure Firewall no inspecciona las cargas ESP.

Reference: si usa NSG (grupo de seguridad de red) en lugar de Azure Firewall: NSG no proporciona una opción directa para especificar ESP (número de protocolo IP 50), pero los paquetes ESP se pueden permitir mediante la siguiente configuración:

• Protocolo: Cualquiera
• Puerto: * (Cualquiera)
• Origen o destino: especifique las direcciones IP según sea necesario.

Recommendations:

• Para las configuraciones de VPN de IPsec, se recomienda usar Azure VPN Gateway.
• Considere la posibilidad de usar un patrón de NVA (aplicación virtual de red) en función de sus requisitos.

Puede usar Azure PowerShell para desasignar y asignar el Azure Firewall. El proceso varía en función de la configuración.

Para un firewall sin una NIC de administración:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Para un firewall con una NIC de administración:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Para un firewall en un centro virtual protegido:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Se recomienda configurar zonas de disponibilidad durante la implementación inicial. Sin embargo, puede volver a configurarlos después de la implementación si:

• El firewall se implementa en una red virtual (no se admite en centros virtuales protegidos).
• La región admite zonas de disponibilidad.
• Todas las direcciones IP públicas adjuntas se configuran con las mismas zonas.

Para volver a configurar zonas de disponibilidad:

1. Desasignar el firewall

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Actualice la configuración de zona y asigne el firewall:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Sí:

• El Azure Firewall y la red virtual deben estar en el mismo grupo de recursos.
• La dirección IP pública puede estar en un grupo de recursos diferente.
• Todos los recursos (Azure firewall, red virtual, IP pública) deben estar en la misma suscripción.

Un estado de aprovisionamiento con errores indica que se produjo un error en una actualización de configuración en una o varias instancias de back-end. El Azure Firewall permanece operativo, pero la configuración podría ser incoherente. Reintente la actualización hasta que el estado de aprovisionamiento cambie a Satisfactorio.

Azure Firewall usa una configuración activa-activa con varios nodos de back-end. Durante el mantenimiento planeado, el vaciamiento controlado de conexiones asegura actualizaciones ordenadas. En el caso de errores no planeados, un nuevo nodo reemplaza al conmutado por error y la conectividad se restaura normalmente en 10 segundos.

Sí, los nombres de firewall están limitados a 50 caracteres.

Una subred /26 garantiza suficientes direcciones IP para el escalado a medida que la Azure Firewall aprovisiona instancias de máquina virtual adicionales.

No, una subred /26 es suficiente para todos los escenarios de escalado.

Azure Firewall escala automáticamente en función del uso de CPU, el rendimiento y el recuento de conexiones. La capacidad de rendimiento oscila entre 2,5 y 3 Gbps inicialmente a 30 Gbps (SKU estándar) o 100 Gbps (SKU Premium).

Sí. Para obtener más información, consulte Azure límites de suscripción y servicio, cuotas y restricciones.

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. Azure Firewall El Tiempo de Espera de Inactividad de TCP es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con Azure soporte técnico para aumentar el tiempo de espera de inactividad de las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico este-oeste.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para obtener más información, consulte los ejemplos de .NET.

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma de Azure y no se puede usar para ningún otro propósito. La ruta de datos del inquilino se puede configurar sin una dirección IP pública, y el tráfico de Internet se puede redirigir forzosamente a otro firewall o bloquearse completamente.

Sí. Para obtener más información, consulte Backup Azure Firewall y Azure Firewall Policy with Logic Apps.

Para un acceso seguro a los servicios de PaaS, se recomiendan los puntos de conexión de servicio. Puede optar por habilitar los puntos de conexión de servicio en la subred del firewall de Azure y deshabilitarlos en las redes virtuales de rama conectadas. De este modo se beneficia de ambas características: la seguridad de los puntos de conexión y el registro central de todo el tráfico.

Sí, puede usar Azure Firewall en una red virtual de concentrador para enrutar y filtrar el tráfico entre varias redes virtuales de radio. Las subredes de cada una de las redes virtuales de spoke deben tener una UDR que apunte al Azure Firewall como puerta de enlace predeterminada para que este escenario funcione correctamente.

Sí. Sin embargo, la configuración de las UDR para redirigir el tráfico entre subredes de la misma red virtual requiere más atención. Aunque el uso del intervalo de direcciones de red virtual como prefijo de destino para la UDR es suficiente, también enruta todo el tráfico de una máquina a otra de la misma subred a través de la instancia de Azure Firewall. Para evitar esto, incluya una ruta para la subred en el UDR con un tipo de siguiente salto definido como red virtual. La administración de estas rutas podría ser problemática y estar sujeta a errores. El método recomendado para la segmentación de redes internas es usar grupos de seguridad de red, que no necesitan UDR.

Azure Firewall no realiza SNAT cuando la dirección IP de destino es un rango IP privado según IANA RFC 1918 o IANA RFC 6598 para redes privadas. Si su organización utiliza un rango de direcciones IP públicas para redes privadas, Azure Firewall hace SNAT del tráfico a una de las direcciones IP privadas del firewall dentro de la subred AzureFirewallSubnet. Puede configurar Azure Firewall para que no haga SNAT del intervalo de direcciones IP públicas. Para obtener más información, consulte intervalos de direcciones IP privadas de SNAT de Azure Firewall.

Además, al tráfico que procesan las reglas de aplicación siempre se le aplica SNAT. Si desea ver la dirección IP de origen en sus registros para el tráfico FQDN, puede usar reglas de red con el FQDN de destino.

Se admite la tunelización forzada al crear un nuevo firewall y también se admite para los firewalls existentes mediante la adición de una NIC de administración para la tunelización forzada. Para obtener más información sobre las nuevas implementaciones, consulte Azure Firewall tunelización forzada. Para los firewalls existentes, consulte Azure Firewall Management NIC.

Azure Firewall deben tener conectividad directa a Internet. Si AzureFirewallSubnet aprende una ruta predeterminada a la red local mediante BGP, debe reemplazarla por una UDR 0.0.0.0/0 con el valor NextHopType establecido como Internet para mantener la conectividad directa a Internet.

Si la configuración requiere tunelización forzada a una red local y puede determinar los prefijos de las direcciones IP de destino de los destinos de Internet, puede configurar estos intervalos con la red local como el próximo salto mediante una ruta definida por el usuario en AzureFirewallSubnet. O bien, puede usar BGP para definir estas rutas.

• Dirección URL: los asteriscos funcionan cuando se sitúan en el extremo derecho o en el extremo izquierdo. Si está a la izquierda, no puede formar parte del FQDN.
• FQDN: los asteriscos funcionan cuando se ponen en el extremo izquierdo.
• GENERAL: los asteriscos del lado izquierdo significan literalmente que cualquier cosa a la izquierda coincide, lo que significa que coinciden varios subdominios o variaciones de nombres de dominio potencialmente no deseados; vea los ejemplos siguientes.

Ejemplos:

No. Azure Firewall bloquea el acceso a Active Directory de forma predeterminada. Para permitir el acceso, configure la etiqueta de servicio AzureActiveDirectory. Para obtener más información, consulte etiquetas de servicio de Azure Firewall.

Sí, puede usar Azure PowerShell para hacerlo:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Un ping de TCP no se conecta realmente al FQDN de destino. Azure Firewall no permite una conexión a ninguna dirección IP o FQDN de destino a menos que haya una regla explícita que lo permita.

El ping TCP es un caso de uso único en el que, si no hay ninguna regla permitida, el propio firewall responde a la solicitud de ping TCP del cliente aunque el ping TCP no llegue a la dirección IP o FQDN de destino. En este caso, el evento no se registra. Si hay una regla de red que permite el acceso a la dirección IP o FQDN de destino, la solicitud de ping llega al servidor de destino y su respuesta se retransmite de nuevo al cliente. Este evento se registra en el registro de reglas de red.

Sí. Para obtener más información, consulte Azure límites de suscripción y servicio, cuotas y restricciones

No, actualmente no se permite mover un grupo de direcciones IP a otro grupo de recursos.

Un comportamiento estándar de un firewall de red es asegurarse de que las conexiones TCP se mantengan activas y cerrarlas de inmediato si no hay ninguna actividad. Azure Firewall El Tiempo de Espera de Inactividad de TCP es de cuatro minutos. Esta configuración no es configurable por el usuario, pero puede ponerse en contacto con Azure soporte técnico para aumentar el tiempo de espera de inactividad de las conexiones entrantes y salientes hasta 15 minutos. No se puede cambiar el tiempo de espera de inactividad para el tráfico este-oeste.

Si un período de inactividad es mayor que el valor de tiempo de espera, no hay ninguna garantía de que todavía exista la sesión TCP o HTTP. Una práctica común es usar TCP Keep-alive. Esta práctica mantiene la conexión activa durante un periodo más largo. Para obtener más información, consulte los ejemplos de .NET.

Sí, pero debe configurar el firewall en modo de tunelización forzada. Esta configuración crea una interfaz de administración con una dirección IP pública que usa Azure Firewall para sus operaciones. Esta IP pública es para el tráfico de administración. Se usa exclusivamente en la plataforma de Azure y no se puede usar para ningún otro propósito. La ruta de datos del inquilino se puede configurar sin una dirección IP pública, y el tráfico de Internet se puede redirigir forzosamente a otro firewall o bloquearse completamente.

Azure Firewall no mueve ni almacena los datos de los clientes fuera de la región en la que se implementa.

Sí. Para obtener más información, consulte Backup Azure Firewall y Azure Firewall Policy with Logic Apps.

No, actualmente no se admite Azure Firewall en centros virtuales protegidos (vWAN) en Qatar.

Azure Firewall utiliza máquinas virtuales de Azure que tienen un límite estricto de conexiones. El número total de conexiones activas por máquina virtual es de 250 000.

El límite total por firewall es el límite de conexión de la máquina virtual (250 000) x el número de máquinas virtuales del grupo de back-end del firewall. Azure Firewall comienza con dos máquinas virtuales y se escala horizontalmente en función del uso y el rendimiento de la CPU.

Azure Firewall actualmente usa puertos de origen TCP/UDP para el tráfico SNAT saliente, sin tiempo de espera inactivo. Cuando se cierra una conexión TCP/UDP, el puerto TCP utilizado se ve inmediatamente como disponible para próximas conexiones.

Como solución alternativa para determinadas arquitecturas, puede implementar y escalar con NAT Gateway con Azure Firewall para proporcionar un grupo más amplio de puertos SNAT para la variabilidad y la disponibilidad.

Los comportamientos de NAT específicos dependen de la configuración del firewall y del tipo de NAT configurado. Por ejemplo, el firewall tiene reglas DNAT para el tráfico entrante y reglas de red y reglas de aplicación para el tráfico saliente a través del firewall.

Para obtener más información, consulte Azure Firewall Comportamientos NAT.

Para cualquier mantenimiento planeado, la lógica de purga de conexiones actualiza los nodos de back-end correctamente. Azure Firewall espera 90 segundos para que se cierren las conexiones existentes. En los primeros 45 segundos, el nodo de back-end no acepta nuevas conexiones y, en el tiempo restante, responde con a todos los paquetes entrantes. Si es necesario, los clientes pueden volver a establecer la conectividad automáticamente con otro nodo de back-end.

Es posible que se produzca un apagado de instancia de máquina virtual Azure Firewall durante el escalado de conjuntos de escalado de máquinas virtuales (reducción vertical) o durante la actualización del software de flota. En estos casos, se equilibra la carga de las nuevas conexiones entrantes en las instancias de firewall restantes y no se reenvían a la instancia de firewall apagada. Después de 45 segundos, el firewall comienza a rechazar las conexiones establecidas mediante el envío de paquetes RST de TCP. Después de otros 45 segundos, la máquina virtual del firewall se apaga. Para obtener más información, consulte Restablecimiento de TCP y tiempo de espera de inactividad del balanceador de carga.

Azure Firewall escala gradualmente cuando el rendimiento medio o el consumo de CPU es de 60%, o el número de conexiones de uso es de 80%. Por ejemplo, comienza a escalar al alcanzar el 60 % de su rendimiento máximo. Los números de rendimiento máximo varían en función de la SKU de Azure Firewall y las características habilitadas. Para obtener más información, consulte rendimiento de Azure Firewall.

El escalado horizontal tarda entre cinco y siete minutos. Al realizar pruebas de rendimiento, asegúrese de probar al menos entre 10 y 15 minutos e inicie nuevas conexiones para aprovechar las ventajas de los nodos de Azure Firewall recién creados.

Cuando una conexión tiene un tiempo de espera de inactividad (cuatro minutos sin actividad), Azure Firewall finaliza correctamente la conexión enviando un paquete TCP RST.

Azure servicios se someten a actualizaciones de mantenimiento periódicas para mejorar la funcionalidad, la confiabilidad, el rendimiento y la seguridad. Con un período de mantenimiento configurado, el mantenimiento del sistema operativo invitado y el mantenimiento del servicio se realizan durante esa ventana. Sin embargo, el mantenimiento controlado por el cliente no incluye actualizaciones de host ni actualizaciones de seguridad críticas.

Las notificaciones avanzadas para Azure Firewall mantenimiento no están disponibles.

No, se requiere un período de mantenimiento mínimo de cinco horas.

No, las ventanas de mantenimiento se configuran actualmente para que se repitan diariamente.

El mantenimiento controlado por el cliente admite las actualizaciones del sistema operativo de invitado y del servicio, que constituyen la mayoría de los elementos de mantenimiento de interés para los clientes. Sin embargo, algunas actualizaciones, como las actualizaciones de host, están fuera del ámbito del mantenimiento controlado por el cliente. En raras ocasiones, podríamos anular su control sobre la ventana de mantenimiento para solucionar problemas de seguridad de alta gravedad.

Sí.

No. Actualmente, solo se puede asociar una configuración de mantenimiento a un Azure Firewall.

Todas las SKU de Azure Firewall: mantenimiento básico, estándar y premium controlado por el cliente.

La Azure Firewall puede tardar hasta 24 horas en seguir la programación de mantenimiento después de asociar la directiva de mantenimiento.

Las actividades de mantenimiento de la Azure Firewall no se pausan durante el período anterior a la ventana de mantenimiento programada. Durante días que no se incluyen en la programación de mantenimiento, las operaciones de mantenimiento normales continúan como de costumbre en el recurso.

Para obtener más información, consulte Configuración del mantenimiento controlado por el cliente.