• 4 min read

Disponibilidad general de la tunelización forzada y del filtrado por FQDN de SQL en Azure Firewall

Dos nuevas características clave de Azure Firewall, la tunelización forzada y el filtrado por FQDN de SQL, ya están disponibles con carácter general. Además, hemos aumentado el límite de varias direcciones IP públicas de 100 a 250, tanto para la traducción de direcciones de red de destino (DNAT) como para la traducción de direcciones de red de origen (SNAT).

Dos nuevas características clave de Azure Firewall, la tunelización forzada y el filtrado por FQDN de SQL, ya están disponibles con carácter general. Además, hemos aumentado el límite de varias direcciones IP públicas de 100 a 250, tanto para la traducción de direcciones de red de destino (DNAT) como para la traducción de direcciones de red de origen (SNAT).

Azure Firewall es una oferta de firewall como servicio (FWaaS) nativo de nube que permite controlar y registrar de forma centralizada todos los flujos de tráfico usando un enfoque de DevOps. El servicio admite reglas de filtro tanto a nivel de aplicación como a nivel de red y está integrado con la fuente de inteligencia sobre amenazas de Microsoft para filtrar direcciones IP y dominios malintencionados conocidos. Azure Firewall ofrece alta disponibilidad gracias a la escalabilidad automática integrada.

La funcionalidad de tunelización forzada ya está disponible con carácter general

La tunelización forzada permite redirigir todo el tráfico enlazado a Internet de Azure Firewall hacia el firewall de su entorno local, o bien encadenarlo a un dispositivo de red virtual (NVA) cercano para llevar a cabo una inspección adicional. Puede habilitar un firewall para la tunelización forzada cuando crea un nuevo firewall. Desde hoy, no se puede migrar una implementación de firewall actual a un modo de tunelización forzada.

Para admitir la tunelización forzada, el tráfico de administración de servicios se separa del tráfico del cliente. Es necesaria una subred dedicada adicional denominada AzureFirewallManagementSubnet con su propia dirección IP pública asociada. La única ruta permitida en esta subred es una ruta predeterminada a Internet y la propagación de rutas BGP (Protocolo de puerta de enlace de borde) debe estar deshabilitada.

Con esta configuración, AzureFirewallSubnet ya puede incluir rutas a cualquier firewall del entorno local o NVA para procesar el tráfico antes de pasarlo a Internet. También puede publicar estas rutas mediante el protocolo BGP en AzureFirewallSubnet si la propagación de rutas BGP está habilitada en esta subred.

VNnetFirewall en modo de tunelización forzada.

Figura 1. Azure Firewall en modo de tunelización forzada.

Cómo evitar SNAT con la tunelización forzada

Azure Firewall proporciona SNAT automática para todo el tráfico saliente hacia direcciones IP públicas. Azure Firewall no lleva a cabo la traducción SNAT cuando la dirección IP de destino es un intervalo de direcciones IP privadas, conforme a IANA RFC 1918. Esta lógica funciona perfectamente cuando se sale directamente a Internet. Sin embargo, con la tunelización forzada habilitada, el tráfico enlazado a Internet se somete a SNAT y se traduce a una dirección IP privada del firewall en AzureFirewallSubnet, lo que impide que el firewall del entorno local pueda ver el origen. Puede configurar Azure Firewall para que no use SNAT independientemente de la dirección IP de destino agregando “0.0.0.0/0” como intervalo de direcciones IP privadas. Tenga en cuenta que, con esta configuración, Azure Firewall nunca puede salir directamente a Internet. Para obtener más información, consulte Intervalos de direcciones IP privadas SNAT de Azure Firewall.

Azure Firewall configurado para no usar SNAT independientemente de la dirección IP de destino agregando 0.0.0.0/0 como intervalo de direcciones IP privadas.

Figura 2. Configuración de Azure Firewall para no usar SNAT en prefijos de direcciones IP privadas.

Enrutamiento a PaaS públicas y Office 365

Aunque la tunelización forzada de Azure Firewall permite dirigir todo el tráfico enlazado a Internet al firewall del entorno local o a un NVA cercano, esto no siempre es recomendable. Por ejemplo, puede que sea preferible salir a una plataforma como servicio (PaaS) pública o a Office 365 directamente. Esto se puede hacer agregando rutas definidas por el usuario (UDR) a AzureFirewallSubnet con “Internet” como el próximo salto para destinos específicos. Dado que esta definición es más específica que la ruta predeterminada, tendrá prioridad. Consulte lntervalos IP y etiquetas de servicio de Azure y El servicio web de URL y dirección IP de Office 365 para obtener más información.

Como método alternativo para la salida directa a una PaaS pública, puede habilitar puntos de conexión de servicio de Virtual Network (VNet) en AzureFirewallSubnet. Estos puntos de conexión amplían la identidad y el espacio de direcciones privadas de la red virtual a los servicios de PaaS de Azure a través de una conexión directa. Cuando están habilitados, se crean automáticamente rutas específicas a los servicios de PaaS correspondientes. Los puntos de conexión de servicio permiten proteger los recursos de servicios de Azure críticos en su red virtual. El tráfico desde la red virtual al servicio de Azure siempre permanece en la red troncal de Microsoft Azure.

Es importante tener en cuenta que, con esta configuración, no podrá agregar “0.0.0.0/0” como prefijo de dirección IP privada como se ha indicado antes, pero sí puede agregar intervalos personalizados en los que no se aplicará SNAT.

Por último, también se puede usar un punto de conexión privado de Azure para conectarse de forma privada y segura a servicios de PaaS pública mediante Azure Private Link. Sin embargo, estas conexiones omitirán la ruta predeterminada a Azure Firewall, como se explica en esta documentación. Si necesita que todo el tráfico pase a través del firewall, puede mitigarlo agregando una ruta definida por el usuario (UDR) en todas las subredes de cliente con la dirección IP del punto de conexión privado y el sufijo /32 como destino, y Azure Firewall como el próximo salto. Tenga en cuenta que, para que esta configuración funcione y el tráfico devuelto desde el punto de conexión privado pase también a través del firewall, tendrá que usar siempre SNAT. Para ello, debe agregar 255.255.255.255/32 como intervalo de direcciones IP privadas.

UDR agregada a un punto de conexión privado de almacenamiento que apunta al firewall como el próximo salto para que todo el tráfico pase a través del firewall.

Figura 3. Ruta definida por el usuario (UDR) a un punto de conexión privado de almacenamiento que apunta al firewall como el próximo salto.

Disponibilidad general del filtrado por FQDN de SQL

Ahora puede configurar FQDN de SQL en las reglas de aplicación de Azure Firewall. Esto le permite limitar el acceso desde su red virtual a las instancias de SQL Server que especifique. Puede filtrar el tráfico de las redes virtuales que va a Azure SQL Database, Azure SQL Data Warehouse, Instancia administrada de Azure SQL o instancias IaaS de SQL implementadas en sus redes virtuales.

Actualmente, el filtrado por FQDN de SQL se admite únicamente en modo proxy (puerto 1433). Si usa puertos no predeterminados para el tráfico de la infraestructura como servicio (IaaS) de SQL, puede configurar esos puertos en las reglas de aplicación del firewall.

Si utiliza SQL en el modo de redireccionamiento predeterminado, puede filtrar el acceso usando la etiqueta de servicio de SQL como parte de las reglas de red. La incorporación de la compatibilidad con el modo de redireccionamiento a las reglas de aplicación está en nuestra hoja de ruta.

Reglas de aplicación de Azure Firewall para el filtrado por FQDN de SQL.

Figura 4. Filtrado por FQDN de SQL en las reglas de aplicación de Azure Firewall.

Aumento del límite de direcciones IP públicas

Ahora puede usar hasta 250 direcciones IP públicas con Azure Firewall para DNAT y SNAT.

  • DNAT: puede traducir varias instancias de puerto estándar para los servidores backend. Por ejemplo, si tiene dos direcciones IP públicas, puede traducir el puerto TCP 3389 (RDP) para ambas direcciones IP.
  • SNAT: hay disponibles puertos adicionales para las conexiones SNAT salientes, lo que reduce la posibilidad de que se agoten los puertos SNAT. Actualmente, Azure Firewall selecciona aleatoriamente la dirección IP pública de origen que se usará para una conexión. Si dispone de algún filtro descendente en la red, deberá permitir todas las direcciones IP públicas asociadas al firewall. Considere la posibilidad de usar un prefijo de dirección IP pública para simplificar esta configuración.

Si desea obtener más información, consulte Implementación de una instancia de Azure Firewall con varias direcciones IP públicas mediante Azure PowerShell.

Pasos siguientes

Para obtener más información sobre todo lo que se trata aquí, consulte los siguientes recursos: