Escenarios de Azure Firewall para inspeccionar el tráfico destinado a un punto de conexión privado
Nota:
Si desea proteger el tráfico a puntos de conexión privados en Azure Virtual WAN mediante el centro virtual protegido, consulte Protección del tráfico destinado a puntos de conexión privados en Azure Virtual WAN.
Un punto de conexión privado de Azure es el bloque de creación fundamental para Azure Private Link. Los puntos de conexión privados permiten que los recursos de Azure implementados en una red virtual se comuniquen de forma privada con recursos de Private Link.
Los puntos de conexión privados permiten a los recursos el acceso al servicio Private Link implementado en una red virtual. El acceso al punto de conexión privado a través del emparejamiento de red virtual y las conexiones de red locales amplía la conectividad.
Es posible que tenga que inspeccionar o bloquear el tráfico de los clientes a los servicios expuestos a través de puntos de conexión privados. Complete esta inspección mediante Azure Firewall o una aplicación virtual de red de terceros.
Se aplican las siguientes limitaciones:
El tráfico de los grupos de seguridad de red (NSG) se omite de los puntos de conexión privados debido a que las directivas de red se deshabilitan para una subred de una red virtual de forma predeterminada. Para usar directivas de red como el soporte de rutas definidas por el usuario y grupos de seguridad de red, el soporte de directivas de red debe estar habilitado para la subred. Esta configuración solo se aplica a los puntos de conexión privados dentro de la subred. Esta configuración se aplica a todos los puntos de conexión privados dentro de la subred. Para otros recursos de la subred, el acceso se controla en función de las reglas de seguridad del grupos de seguridad de red.
Los puntos de conexión privados ignoran el tráfico de rutas definidas por el usuario (UDR). Las rutas definidas por el usuario se pueden usar para invalidar el tráfico destinado al punto de conexión privado.
Se puede asociar una sola tabla de rutas a una subred
Una tabla de rutas admite hasta 400 rutas
Azure Firewall filtra el tráfico mediante:
FQDN en las reglas de red para los protocolos TCP y UDP
FQDN en las reglas de aplicación para HTTP, HTTPS y MSSQL.
Importante
Se recomienda el uso de reglas de aplicación en lugar de reglas de red al inspeccionar el tráfico destinado a puntos de conexión privados para mantener la simetría de flujo. Se prefieren las reglas de aplicación frente a las reglas de red para inspeccionar el tráfico destinado a los puntos de conexión privados, ya que Azure Firewall siempre aplica SNAT al tráfico con reglas de aplicación. Si se usan reglas de red, o se utiliza NVA en lugar de Azure Firewall, se debe configurar SNAT para el tráfico destinado a puntos de conexión privados para conservar la simetría de los flujos.
Nota
El filtrado por nombre de dominio completo de SQL se admite solo en modo de proxy (puerto 1433). El modo de proxy puede traducirse en una mayor latencia en comparación con el modo de redirección. Si quiere seguir usando el modo de redirección, que es el valor predeterminado para los clientes que se conectan desde dentro de Azure, puede filtrar el acceso mediante FQDN en reglas de red del firewall.
Escenario 1: Arquitectura en estrella tipo hub-and-spoke: red virtual dedicada para puntos de conexión privados
Este escenario es la arquitectura más expansible para conectarse de forma privada a varios servicios de Azure mediante puntos de conexión privados. Se crea una ruta que apunta al espacio de direcciones de red donde se implementan los puntos de conexión privados. Esta configuración reduce la sobrecarga administrativa y evita que se ejecute en el límite de 400 rutas.
Las conexiones de una red virtual de cliente a Azure Firewall en una red virtual de centro de conectividad generan cargos si las redes virtuales están emparejadas. No se cobran las conexiones de Azure Firewall en una red virtual de centro de conectividad a puntos de conexión privados en una red virtual emparejada.
Para obtener más información sobre los cargos relacionados con las conexiones con redes virtuales emparejadas, consulte la sección de preguntas más frecuentes de la página de precios.
Escenario 2: Arquitectura en estrella tipo hub-and-spoke: red virtual compartida para máquinas virtuales y puntos de conexión privados
Este escenario se implementa cuando:
No es posible tener una red virtual dedicada para los puntos de conexión privados
Cuando solo algunos servicios se exponen en la red virtual con puntos de conexión privados
Las máquinas virtuales tienen rutas de sistema /32 que apuntan a cada punto de conexión privado. Una ruta por punto de conexión privado está configurada para enrutar el tráfico a través de Azure Firewall.
La sobrecarga administrativa del mantenimiento de la tabla de rutas aumenta a medida que los servicios se exponen en la red virtual. También aumenta la posibilidad de alcanzar el límite de ruta.
Según la arquitectura global, es posible ejecutar en el límite de 400 rutas. Se recomienda usar el escenario 1 siempre que sea posible.
Las conexiones de una red virtual de cliente a Azure Firewall en una red virtual de centro de conectividad generan cargos si las redes virtuales están emparejadas. No se cobran las conexiones de Azure Firewall en una red virtual de centro de conectividad a puntos de conexión privados en una red virtual emparejada.
Para obtener más información sobre los cargos relacionados con las conexiones con redes virtuales emparejadas, consulte la sección de preguntas más frecuentes de la página de precios.
Escenario 3: Red virtual única
Use este patrón cuando no sea posible realizar una migración a una arquitectura de centro y radio. Se aplican las mismas consideraciones que en el escenario 2. En este escenario, no se aplican cargos de emparejamiento de red virtual.
Escenario 4: Tráfico local en puntos de conexión privados
Esta arquitectura se puede implementar si ha configurado la conectividad con la red local mediante:
Si los requisitos de seguridad requieren el enrutamiento del tráfico de cliente a los servicios expuestos a través de puntos de conexión privados a través de un dispositivo de seguridad, implemente este escenario.
Se aplican las mismas consideraciones que en el escenario 2. En este escenario, no hay cargos de emparejamiento de red virtual. Para obtener más información sobre cómo configurar los servidores DNS para permitir que las cargas de trabajo locales tengan acceso a puntos de conexión privados, consulte Cargas de trabajo locales que usan un desviador DNS.
Pasos siguientes
En este artículo, ha explorado los diferentes escenarios que puede usar para restringir el tráfico entre una máquina virtual y un punto de conexión privado mediante Azure Firewall.
Para ver un tutorial sobre cómo configurar Azure Firewall para inspeccionar el tráfico destinado a un punto de conexión privado, consulte Tutorial: Inspección del tráfico de punto de conexión privado con Azure Firewall
Para más información sobre el punto de conexión privado, consulte ¿Qué es un punto de conexión privado de Azure?