¿Cuál es la red de ruta de acceso privada para Azure Local?

Se aplica a: Implementaciones hiperconvergidas de Azure Local

En este artículo se ofrece una visión general de la arquitectura de red de ruta privada de Azure Local que usa la puerta de enlace de Azure Arc y el proxy explícito de Azure Firewall.

Acerca de la red de rutas de acceso privadas para Azure Local

La arquitectura de red de ruta de acceso privada para Azure Local permite una conectividad de salida segura a Azure sin exponer el entorno local a la red pública de Internet. Esta arquitectura usa Azure Arc puerta de enlace y Azure Firewall proxy explícito para enrutar el tráfico a través de conexiones privadas, como ExpressRoute o una red privada virtual (VPN) de sitio a sitio.

Al centralizar la conectividad saliente a través de servicios administrados Azure, las redes de rutas de acceso privadas ayudan a reducir la superficie expuesta a ataques, simplificar la configuración de red y alinear Azure Local implementaciones con los requisitos de seguridad y cumplimiento empresariales.

Este artículo incluye:

• Componentes de arquitectura: Comprender los componentes principales necesarios, incluidas las máquinas de Azure Local, la puerta de enlace de Arc, Azure Firewall proxy explícito y la infraestructura de red de Azure.
• Categorización del tráfico: Distinguir claramente entre diferentes tipos de tráfico de red (interno, HTTP, HTTPS, terceros) y sus rutas de enrutamiento adecuadas.

Ventajas principales

Estas son las principales ventajas de usar Azure Local arquitectura de red de ruta de acceso privada:

• Mejor seguridad: Mantenga el tráfico de Azure Local dentro de su red local y de Azure mediante ExpressRoute o VPN de sitio a sitio.
• Configuración más sencilla: Use su infraestructura de red y seguridad existente mientras la puerta de enlace de Arc gestiona la conectividad con Azure.
• Administración más sencilla: Menos puntos de conexión para administrar significa un seguimiento y solución de problemas más fáciles.

Información general sobre la arquitectura

Las redes de rutas de acceso privadas para Azure Local combinan los siguientes componentes:

• máquinas de Azure Local que generan tráfico saliente.
• Instancia local de Azure Local.
• Proxy Arc que se ejecuta en hosts de Azure Local y reenvía el tráfico HTTPS a la puerta de enlace de Arc.
• puerta de enlace de Azure Arc, que solo permite tráfico HTTPS saliente a puntos de conexión administrados por Microsoft.
• Firewall empresarial que es la infraestructura de seguridad existente de su organización que controla el tráfico saliente.
• red virtual de Azure asociada a la instancia.
• Proxy explícito de Azure Firewall, que administra el tráfico HTTP y el tráfico HTTPS no permitido por la puerta de enlace de Arc.
• Circuito ExpressRoute como ruta de comunicación entre las redes locales y Azure redes virtuales.
• Puntos de conexión públicos de Azure. El entorno local requiere acceso a servicios Azure, como Azure Resource Manager, Key Vault y Microsoft Graph.

Cada tipo de tráfico sigue una ruta de enrutamiento específica basada en el protocolo y el destino.

Para configurar estos componentes, consulte los requisitos previos en Registro de Azure Local con Azure Arc puerta de enlace y ruta de acceso privada.

Restricciones y limitaciones

Al implementar Azure Local arquitectura de red de ruta de acceso privada, tenga en cuenta las siguientes restricciones y limitaciones:

• Esta solución utiliza el proxy explícito de Azure Firewall como un proxy de reenvío. Azure Local no admite la inspección de seguridad de la capa de transporte (TLS) en los puntos de conexión necesarios.
• No se pueden aplicar certificados TLS al proxy explícito Azure Firewall.

Importante

Microsoft no valida ni admite ninguna variación de la arquitectura de ruta de acceso privada Azure Local diferente de lo que describe este artículo.

Categorías de tráfico

En una implementación de ruta de acceso privada, Azure Local clasifica el tráfico saliente en función del protocolo y el destino. La identificación correcta de cada categoría es fundamental para garantizar una conectividad segura y confiable.

En la tabla siguiente se resumen cada categoría de tráfico, su decisión de enrutamiento y el escenario de flujo de tráfico que muestra la ruta de acceso en detalle:

Categoría de tráfico	Protocol	Decisión de enrutamiento	Escenario de flujo de tráfico
Tráfico interno, de máquina a máquina y de Private Link	HTTP y HTTPS	Omite el proxy y se conecta directamente a los puntos de conexión internos.	Tráfico del sistema operativo de la máquina que omite el proxy explícito de Azure Firewall
Tráfico HTTP del sistema operativo a Azure	HTTP	Rutas a través del proxy explícito de Azure Firewall	Tráfico HTTP del sistema operativo de la máquina a través del proxy explícito de Azure Firewall
Tráfico HTTPS del sistema operativo a puntos de conexión administrados por Microsoft	HTTPS	Rutas a través del proxy de Arc y el túnel de la puerta de enlace de Arc	Tráfico HTTPS del sistema operativo del equipo a través del proxy de Arc
Tráfico HTTPS de sistema operativo de terceros	HTTPS	El proxy de Arc redirige al proxy explícito de Azure Firewall	Tráfico HTTPS del sistema operativo del equipo a través del proxy de Arc
Puente de recursos de Arc y tráfico de clúster de Azure Kubernetes Service (AKS)	HTTPS	Rutas a través del proxy de IP del clúster y el túnel de la puerta de enlace de Arc	Tráfico HTTPS de la máquina virtual del dispositivo Azure Resource Bridge y tráfico HTTPS del clúster de AKS

En las secciones siguientes se describe cada categoría de tráfico con más detalle.

Tráfico del sistema operativo que omite el proxy

Algunas conexiones HTTP y HTTPS deben omitir Azure Firewall proxy explícito y conectarse directamente a sus destinos internos previstos. Normalmente, los motivos técnicos o de rendimiento requieren estas excepciones.

Configure estas conexiones para omitir el proxy para que puedan llegar directamente a sus puntos de conexión internos. Agregue puntos de conexión de Private Link, como Azure Key Vault o cuentas de almacenamiento de Azure Storage, a la lista de omisión del proxy si su organización requiere su uso.

Tráfico HTTP del sistema operativo a través del proxy explícito de Azure Firewall

Parte del tráfico HTTP a nivel de sistema operativo no puede usar el proxy de Arc y debe enrutarse a través del proxy explícito de Azure Firewall en su lugar. Enrute este tráfico a través de Azure Firewall proxy explícito para asegurarse de que alcanza Azure al tiempo que cumple los requisitos internos de red y seguridad.

Tráfico HTTPS del sistema operativo a través del proxy de Arc

El tráfico HTTPS de nivel de sistema operativo siempre debe enrutarse a través del proxy de Arc.

El enrutamiento de este tráfico a través del proxy de Arc garantiza una conectividad segura, controlada y coherente con los puntos de conexión de Azure mediante las funcionalidades integradas de seguridad y administración de la puerta de enlace de Arc.

Asegúrate de permitir todos los puntos de conexión de la puerta de enlace de Arc necesarios para Azure Local. Para más información, consulte Puntos de conexión necesarios de la puerta de enlace de Arc de Azure Local.

Tráfico HTTPS de sistema operativo de terceros

Todo el tráfico HTTPS de nivel de sistema operativo se enruta inicialmente al proxy de Arc. Sin embargo, la puerta de enlace de Arc solo permite conexiones a puntos de conexión administrados por Microsoft.

Como resultado, el tráfico HTTPS destinado a servicios de terceros, como puntos de conexión del fabricante de equipos originales (OEM), servicios de actualización de proveedores de hardware u otros agentes de terceros instalados en los servidores, no puede pasar a través de la puerta de enlace de Arc. Este tráfico se enruta a través del proxy explícito de Azure Firewall.

Configure las reglas de aplicación del proxy explícito de Azure Firewall para permitir de forma explícita el acceso a los puntos de conexión necesarios de terceros. Defina estas reglas en función de los requisitos de seguridad y conectividad de su organización para asegurarse de que los servicios de terceros funcionan correctamente.

Tráfico del puente de recursos de Arc y del clúster de AKS

El puente de recursos de Azure Arc es una solución de administración basada en Kubernetes que se implementa como un dispositivo virtual (también denominado dispositivo Arc) en su infraestructura local. Su propósito principal es permitir que los recursos locales aparezcan y se administren como Azure recursos a través de Azure Resource Manager.

Para ello, el puente de recursos de Arc requiere conectividad saliente a puntos de conexión de Azure específicos. En un entorno local de Azure, este tráfico saliente se enruta a través de la IP del clúster como proxy, que a su vez reenvía de forma segura el tráfico a través del túnel de la puerta de enlace de Arc establecido por tus máquinas locales de Azure. Este enfoque simplifica la configuración de red, mejora la seguridad y garantiza el cumplimiento de las directivas de red de su organización.

Además, al implementar el clúster de AKS en Azure Local, de forma predeterminada, la máquina virtual del plano de control y los pods también usan la dirección IP del clúster como proxy para enviar el tráfico saliente a través de la puerta de enlace de Arc. Sin embargo, para algunos servicios que se ejecutan dentro de los clústeres de AKS, también es posible que tenga que permitir puntos de conexión adicionales que van directamente al firewall.

Escenarios de flujo de tráfico

En las secciones siguientes se muestra la ruta de enrutamiento de cada categoría de tráfico descrita en Categorías de tráfico. Cada escenario incluye un diagrama de cómo se mueve el tráfico a través de la implementación de la ruta de acceso privada.

Note

En los diagramas siguientes, las etiquetas como Node1 y Node2 representan Azure Local máquinas.

Tráfico del sistema operativo de la máquina que omite el proxy explícito de Azure Firewall

En el diagrama siguiente se muestra el tráfico de las máquinas de Azure Local que eluden por completo el proxy de Arc.

Entre los escenarios típicos se incluyen:

• Comunicaciones internas dentro de la intranet local.
• Comunicaciones de máquina a máquina dentro del sistema Azure Local.
• Tráfico destinado a sistemas internos de administración o supervisión.
• Tráfico destinado a puntos de conexión de Private Link, como Azure Key Vault o cuentas de Azure Storage.

Este tráfico se dirige directamente a estos extremos sin pasar por la puerta de enlace de Arc ni por el proxy explícito de Azure Firewall. Este enfoque garantiza una baja latencia y una comunicación interna eficaz.

Cuando defina la cadena de omisión de proxy en el script de inicialización de Arc o use la aplicación Configurator, asegúrese de incluir lo siguiente:

• Incluya al menos la dirección IP de cada máquina local de Azure.
• Incluya al menos la dirección IP del sistema Azure Local.
• Incluya al menos las direcciones IP que definió para la red de infraestructura. El puente de recursos de Arc, AKS y los servicios de infraestructura futuros que usan estas direcciones IP requieren conectividad saliente.
• O bien, puede omitir toda la subred de infraestructura.
• Incluya el nombre NetBIOS de cada máquina.
• Incluya el nombre NetBIOS del sistema Azure Local.
• Incluya un nombre de dominio o un nombre de dominio con un asterisco (*) como comodín al principio para incluir cualquier host o subdominio. Por ejemplo, 192.168.1.* para subredes o *.contoso.com para nombres de dominio.
• Los parámetros deben estar separados con una coma ,.
• No se admite la notación de enrutamiento de Inter-Domain sin clases (CIDR) para omitir subredes.
• El uso de cadenas <locales> no se admite en la lista de omisión del proxy.

Tráfico HTTP del sistema operativo de la máquina a través de Azure Firewall como proxy explícito

En este diagrama se muestra cómo se administra el tráfico HTTP estándar (no HTTPS) desde máquinas Azure Local:

• Enrutar el tráfico HTTP a través del proxy explícito de Azure Firewall. No use un .local dominio como nombre del servidor proxy. Por ejemplo, no se puede usar proxy.local:8080 como servidor proxy. Use la dirección IP del servidor proxy en su lugar si el proxy pertenece a un .local dominio.
• Asegúrese de que el firewall empresarial y Azure Firewall proxy explícito permiten los puntos de conexión necesarios para Azure Local. Las directivas de seguridad de la organización determinan si el tráfico está permitido o bloqueado.

Esta configuración garantiza que el tráfico HTTP estándar se alinee con la infraestructura de seguridad existente.

Tráfico HTTPS del sistema operativo del equipo a través del proxy de Arc

En este diagrama se explica cómo se enruta el tráfico HTTPS desde máquinas Azure Local de forma segura:

• El proxy de Arc que se ejecuta en cada máquina enruta el tráfico HTTPS destinado a los puntos de conexión de Azure permitidos. Asegúrate de haber permitido la URL de tu puerta de enlace de Arc en tu proxy o firewall.
• El proxy de Arc establece un túnel HTTPS seguro hacia el punto de conexión público del gateway de Arc hospedado en Azure.
• El proxy de Arc redirige el tráfico que no permite (puntos de conexión no aprobados) al proxy explícito de Azure Firewall para su posterior inspección o bloqueo. Asegúrese de permitir los puntos de conexión HTTPS de terceros necesarios para Azure Local, como los puntos de conexión de OEM Solution Builder Extension (SBE), en el proxy explícito de Azure Firewall mediante las reglas de aplicación correspondientes.

Esta configuración garantiza la conectividad HTTPS de salida segura, controlada y compatible.

Tráfico HTTPS de la máquina virtual del dispositivo Azure Resource Bridge a través del proxy de IP del clúster

En este diagrama se muestra el control del tráfico HTTPS para la máquina virtual del dispositivo de puente de recursos de Azure.

• La máquina virtual del dispositivo envía tráfico HTTPS a través de un proxy IP de clúster.
• El proxy de IP del clúster enruta de forma segura el tráfico permitido a través del túnel HTTPS de la puerta de enlace de Arc hacia Azure.
• El tráfico no permitido se redirige al firewall o al proxy para la aplicación de seguridad.

Este proceso garantiza que el tráfico de máquina virtual del dispositivo se administre de forma segura y sea compatible con las directivas de su organización.

Tráfico HTTPS del clúster de AKS a través del proxy de IP del clúster

En este diagrama se muestra el control del tráfico HTTPS para clústeres de AKS en Azure Local:

• La máquina virtual del plano de control del clúster de AKS enruta el tráfico HTTPS a través del proxy IP del clúster en el puerto 40343.
• La máquina virtual del nodo de trabajo de AKS enruta el tráfico HTTPS a través del proxy IP del clúster en el puerto 40343.
• El proxy de IP de clúster reenvía de forma segura el tráfico permitido a través del túnel HTTPS de la puerta de enlace de Arc hasta los puntos de conexión de Azure.
• Los pods de AKS crean la conexión a la puerta de enlace de Arc para enrutar el tráfico HTTPS a través del túnel de conexión HTTP de la puerta de enlace de Arc.
• El tráfico que la puerta de enlace de Arc no permite se envía al firewall o proxy para realizar comprobaciones de seguridad adicionales.

Este proceso garantiza que los clústeres de AKS mantengan una conectividad de salida segura y compatible.

Clústeres de AKS en subred independiente de la subred de infraestructura

En este diagrama se muestran los requisitos de firewall y control del tráfico HTTPS para el clúster de AKS cuando se ejecuta en una subred independiente de la subred de infraestructura de Azure Local. En este ejemplo se representa cómo se enruta cada tipo de tráfico TCP y HTTPS desde la subred de AKS para ayudar a los equipos de seguridad a comprender qué puertos o puntos de conexión de nombre de dominio completos (FQDN) deben abrir en su firewall o proxy que filtra el tráfico de la subred de AKS a la subred de infraestructura e Internet.

En la tabla siguiente se enumeran los requisitos de firewall para el tráfico entre la subred de AKS y la subred de infraestructura de Azure Local. El color de la flecha del diagrama muestra la trayectoria correspondiente en el diagrama anterior.

Traffic	Puerto	Direction	Regla de firewall	Flecha del diagrama
Subred de AKS a la IP del clúster de Azure Local	40343	Outbound	Permitir tanto en L4 como en L7 para HTTPS y HTTP Connect	Azul claro
Subred de AKS a la IP del clúster de Azure Local	55000	Outbound	Permitir TCP	Azul claro
Subred de AKS a la IP del clúster de Azure Local	65000	Outbound	Permitir TCP	Azul claro
Subred de AKS hacia y desde la subred de la infraestructura de Azure Local	22	Bidireccional	Permitir TCP	Amarillo claro
Subred de AKS hacia y desde la subred de la infraestructura de Azure Local	6443	Bidireccional	Permitir TCP	Amarillo claro

Para obtener más información sobre el firewall requerido, consulte Puertos requeridos de la subred de AKS al usar Arc Gateway.

Note

Requisitos del firewall en la subred de AKS para el tráfico HTTPS no compatible con la puerta de enlace de Arc (tráfico de la flecha rosa)

Al ejecutar Azure Arc puerta de enlace en los hosts de Azure Local, AKS reduce el número de puntos de conexión HTTPS que debe abrir en la subred de AKS, pero todavía necesita permitir el acceso a esos puntos de conexión que no son compatibles con Azure Arc puerta de enlace.

Para obtener una lista de los puntos de conexión de FQDN necesarios para AKS en una subred independiente al usar la puerta de enlace de Arc, consulte Puntos de conexión de FQDN necesarios de la subred de AKS al usar la puerta de enlace de Arc.

Tráfico HTTPS de las máquinas virtuales de Azure Local a través del proxy dedicado de Arc

En este diagrama se explica el control del tráfico HTTPS para las máquinas virtuales de Azure Local:

• Cada máquina virtual Azure Local usa su propio proxy de Arc dedicado para enrutar el tráfico HTTPS.
• El tráfico HTTPS permitido se tuneliza de forma segura a través de la puerta de enlace de Arc hasta los puntos de conexión públicos de Azure.
• El tráfico no permitido se redirige al proxy explícito de Azure Firewall para aplicar las directivas de seguridad.
• El tráfico de máquina virtual mediante Key Vault Private Link tiene el FQDN de Key Vault configurado en DNS para usar Private Link.

Esta configuración garantiza que las máquinas virtuales de Azure Local tengan conectividad saliente segura, controlada y compatible.

Paso siguiente

• Implementar una ruta privada con la puerta de enlace de Azure Arc en Azure Local