Acceso saliente a Internet: controlar la salida desde Azure

En este artículo se explica cómo controlar el acceso saliente a Internet desde Azure redes virtuales. Compara los patrones de salida combinados, Azure Firewall y puerta de enlace NAT para ayudarle a elegir un método predecible y seguro para las cargas de trabajo.

Lo que trata este artículo

El control de salida determina cómo las cargas de trabajo de Azure llegan a la red pública de Internet. Una estrategia de salida bien diseñada proporciona direcciones IP públicas predecibles, evita el agotamiento de puertos SNAT y, opcionalmente, filtra las conexiones salientes por destino.

Note

Este artículo cubre conceptos específicos relacionados con la salida. Para obtener una cobertura completa del firewall, consulte Azure Firewall y inspección del tráfico.

Quién necesita este artículo

Lea este artículo si se aplican una o varias de estas condiciones:

  • Las cargas de trabajo necesitan acceso saliente controlado a Internet para actualizaciones, API o servicios externos.
  • Necesita direcciones IP públicas predecibles para las conexiones salientes.
  • Necesita evitar el agotamiento de puertos SNAT o ampliar la conectividad saliente para cargas de trabajo con un gran número de conexiones.
  • Debe elegir entre NAT Gateway, Azure Firewall o un patrón combinado para el control de salida y la inspección.

Sugerencia

¿Sigue la ruta del escenario? Seleccione el escenario en la parte superior de la página para obtener instrucciones adaptadas. La guía básica siguiente se aplica a todos los lectores.

Enfoque lift-and-shift: Sus máquinas virtuales migradas necesitan un acceso a Internet saliente controlado. Centralice todo el tráfico saliente a través del firewall del concentrador para aplicar una directiva de seguridad coherente en las cargas de trabajo migradas.

Lea este artículo si:

  • Implemente cargas de trabajo que necesiten acceder a Internet para actualizaciones, llamadas API o servicios de terceros.
  • Desea centralizar el control de salida a través de Azure Firewall en la VNet central.
  • Debe desactivar el acceso de salida predeterminado en las cargas de trabajo migradas y reemplazarlo por un método de salida explícito.
  • Requerir una dirección IP pública fija y predecible para las conexiones salientes.

Enfoque de modernización: Todas las VNet secundarias enrutan el tráfico saliente a través del firewall central mediante rutas definidas por el usuario (UDR). Este modelo de salida centralizado es integral para la arquitectura de seguridad, ya que impide que los equipos de aplicaciones pasen los controles de seguridad administrados por TI.

Lea este artículo si:

  • Es necesario garantizar que todas las cargas de trabajo de los spokes (AKS, App Service, máquinas virtuales) dirijan el tráfico saliente a través del firewall del hub.
  • Se desea un enrutamiento basado en UDR desde cada spoke hacia el Azure Firewall del hub para garantizar una directiva de salida coherente.
  • Requerir que el firewall del concentrador actúe como SNAT para todas las conexiones salientes.
  • Es necesario evitar el agotamiento de puertos SNAT para cargas de trabajo de alto recuento de conexiones.

Enfoque multinube: Incluya egreso centralizado si su diseño objetivo requiere una política controlada de salida a Internet. De lo contrario, el tráfico entre nubes pasa por la ruta de tránsito (Azure Firewall en un centro virtual seguro) y no necesita una configuración de salida independiente.

Lea este artículo si:

  • ¿Necesita una directiva centralizada de salida a Internet en su zona de aterrizaje de Azure?
  • ¿Quiere compartir el mismo Azure Firewall tanto para la inspección del tránsito entre nubes como para la salida a Internet?
  • Sustituya el acceso de salida predeterminado antes de que se retire gradualmente.

servicios y características de Azure

En la tabla siguiente se describen los servicios y características disponibles para el acceso saliente a Internet en Azure redes virtuales.

Servicio o característica Qué proporciona Cuándo usarlo
Acceso saliente predeterminado (retirado) Azure asigna automáticamente una dirección IP pública temporal para las conexiones salientes. La dirección IP asignada no es predecible y puede cambiar sin previo aviso. No use para nuevas implementaciones. Reemplace por NAT Gateway o Azure Firewall. Consulte Consideraciones de seguridad.
Azure NAT Gateway Servicio SNAT administrado con direcciones IP públicas fijas y predecibles. Proporciona 64 512 puertos SNAT por ip pública, hasta 16 direcciones IP públicas (más de 1 millón de puertos totales). Sin filtrado de contenido. Cargas de trabajo exclusivamente de salida que necesitan una IP de salida fija, aplicaciones con un elevado número de conexiones y escenarios en los que existe el riesgo de agotamiento de puertos SNAT.
Azure Firewall Inspección completa de nivel 3 a 7 para el tráfico saliente. Filtrado de FQDN, filtrado de direcciones URL, categorías web e IDPS (SKU Premium). Administración centralizada de directivas. Cuando necesites controlar a qué destinos se conectan tus recursos, y no solo que tengan acceso de salida.
NAT Gateway + Azure Firewall Nat Gateway controla el escalado de SNAT en la subred del firewall. Azure Firewall controla la inspección y el filtrado. No se produce ninguna NAT doble. Entornos de producción que necesitan filtrado escalable de salida y reconocimiento de contenido. Arquitectura recomendada para cargas de trabajo empresariales.
VM con IP pública (salida) La máquina virtual usa su propia dirección IP pública para el tráfico saliente. No hay control ni filtrado centralizados. No usar en producción. No hay administración centralizada, imprevisible a escala y no se beneficia de los recursos SNAT compartidos.

Cómo elegir

Diagrama en el que se muestran tres rutas de salida de una red virtual de carga de trabajo a través de NAT Gateway, Azure Firewall o ambas.

Cómo controlar el acceso saliente

Use la tabla siguiente para seleccionar un método de salida en función de sus requisitos.

Sus necesidades Enfoque recomendado Por qué
Se ha corregido solo la dirección IP saliente, sin necesidad de filtrado. Puerta NAT Proporciona direcciones IP públicas predecibles con asignación automática de puertos SNAT. Sin sobrecarga de inspección ni costo de filtrado. La opción más sencilla lista para producción.
Filtrado de FQDN, filtrado de direcciones URL o inspección del tráfico Azure Firewall Filtra las conexiones salientes por FQDN o dirección URL de destino. La SKU Premium agrega la inspección de IDPS y TLS para la detección avanzada de amenazas.
Se ha corregido el filtrado de contenido y ip de salida. NAT Gateway + Azure Firewall Nat Gateway en AzureFirewallSubnet proporciona SNAT escalable. Firewall inspecciona el tráfico antes de la salida. Lo mejor de ambas funcionalidades.
No usar para nuevas implementaciones Acceso saliente predeterminado o dirección IP pública de máquina virtual Se ha retirado el acceso saliente predeterminado. Las direcciones IP públicas de la máquina virtual no proporcionan ningún control centralizado. Ambos no son adecuados para las cargas de trabajo de producción.

NAT Gateway frente a Azure Firewall para el tráfico saliente

Use la siguiente comparación para comprender los inconvenientes entre NAT Gateway y Azure Firewall cuando se usan de forma independiente.

Capacidad Puerta NAT Azure Firewall
Puertos SNAT 64.512 por IP pública (hasta 16 direcciones IP, más de 1 millón en total) 2.496 por IP pública por instancia de back-end (máx. 250 IP)
Filtrado de tráfico Ninguno: permite todo el tráfico de salida Reglas de FQDN, filtrado de direcciones URL, categorías web, reglas de red
Inspección de IDPS y TLS No disponible Solo para SKU Premium
Throughput Velocidad de línea para la subred (sin límite publicado para SNAT) Hasta 100 Gbps (Premium), 30 Gbps (Estándar), 250 Mbps (Básico)
Modelo de costo Recurso por hora + por GB de datos procesados Recurso por hora + datos por GB procesados (mayor costo base)
Complejidad del enrutamiento Se asocia directamente a una subred; no se requiere ninguna UDR. Requiere UDR (0.0.0.0/0 → IP privada del firewall) en subredes de carga de trabajo
Caso de uso Conexiones salientes de gran volumen que necesitan direcciones IP fijas Entornos regulados que necesitan filtrado y registro de salida

Prioridad de enrutamiento para el tráfico saliente

Azure evalúa los métodos de salida en el orden de prioridad siguiente. Los métodos de mayor prioridad invalidan los de prioridad inferior en la misma subred:

  1. UDR a una aplicación virtual o puerta de enlace de red virtual: invalida todos los demás métodos de salida, incluida la puerta de enlace NAT.
  2. Puerta de enlace NAT: tiene prioridad sobre las direcciones IP públicas a nivel de instancia y las reglas de salida del equilibrador de carga.
  3. Dirección IP pública de nivel de instancia en la máquina virtual.
  4. Reglas de salida del equilibrador de carga.
  5. La ruta predeterminada del sistema a Internet (Microsoft retiró esta opción para las nuevas implementaciones).

Importante

Una ruta definida por el usuario (UDR) con el destino 0.0.0.0/0 que apunta a una aplicación virtual (como Azure Firewall) invalida la puerta de enlace NAT. Este comportamiento está previsto en la arquitectura combinada NAT Gateway + Firewall. La UDR en las subredes de carga de trabajo obliga al tráfico a pasar por el firewall, mientras que NAT Gateway en la AzureFirewallSubnet proporciona las direcciones IP de salida definitivas.

Arquitectura combinada: PUERTA de enlace NAT + Azure Firewall

El patrón de producción recomendado para la salida empresarial combina ambos servicios:

  1. Las subredes de carga de trabajo tienen una UDR que envía el tráfico 0.0.0.0/0 al Azure Firewall dirección IP privada.
  2. Azure Firewall inspecciona y filtra el tráfico saliente mediante reglas de red, reglas de aplicación o ambas.
  3. NAT Gateway se asocia a AzureFirewallSubnet y proporciona SNAT escalable para las conexiones salientes del firewall.
  4. No se produce doble NAT. El firewall envía tráfico a NAT Gateway mediante su dirección IP privada y nat Gateway aplica SNAT una vez mediante sus direcciones IP públicas.

Esta arquitectura proporciona una inspección centralizada con SNAT escalable. AzureFirewallSubnet no necesita UDR adicionales porque NAT Gateway enruta automáticamente el tráfico saliente de Internet cuando está asociado.

Note

La puerta de enlace NAT estándar es un recurso zonal y no admite implementaciones con redundancia de zona. Si implementas un Azure Firewall con redundancia de zona, utiliza NAT Gateway V2 (SKU EstándarV2) para SNAT con redundancia de zona. La puerta de enlace NAT estándar se convierte en un único punto de error durante una interrupción zonal cuando se empareja con un firewall con redundancia de zona. Para más información, consulte SKU de NAT Gateway.

Tutorial de flujo de datos

En la secuencia siguiente se muestra cómo fluye una única solicitud de salida a través de la arquitectura combinada:

  1. Una máquina virtual de una subred de carga de trabajo inicia una conexión TCP a una API externa (por ejemplo, api.contoso.com:443).
  2. La UDR de la subred coincide con 0.0.0.0/0 y envía el paquete a la dirección IP privada del Azure Firewall.
  3. Azure Firewall evalúa la conexión con las reglas de aplicación y las reglas de red. Si una regla de aplicación con un FQDN permite coincidencias de entrada, el firewall permite la conexión.
  4. El firewall envía el paquete permitido desde su propia interfaz en AzureFirewallSubnet.
  5. NAT Gateway, asociada a AzureFirewallSubnet, realiza SNAT. Traduce la dirección IP de origen privada del firewall a una de sus direcciones IP públicas y asigna un puerto SNAT desde el grupo.
  6. La respuesta de la API externa regresa a la dirección IP pública de la puerta de enlace NAT. Nat Gateway realiza la traducción inversa y devuelve el paquete al firewall.
  7. El firewall envía la respuesta a la máquina virtual de origen a través del estado de conexión existente.

En este flujo de extremo a extremo, el firewall inspecciona el tráfico exactamente una vez y NAT Gateway aplica SNAT exactamente una vez, sin doble NAT.

Supervisión y diagnóstico

Supervise la infraestructura de salida para detectar problemas de capacidad antes de que afecten a las cargas de trabajo:

  • Métricas de puerta de enlace NAT: Supervise el número total de conexiones SNAT, el recuento de conexiones SNAT (por estado) y la disponibilidad de la ruta de acceso de datos en Azure Monitor. Establezca alertas cuando el uso del puerto SNAT supere los 80% de capacidad asignada.
  • Registros de Azure Firewall: Habilite la configuración de diagnósticos para enviar registros a Log Analytics. Use las categorías de registro AzureFirewallApplicationRule y AzureFirewallNetworkRule para auditar las conexiones salientes permitidas y denegadas.
  • Monitor de conexión: Use Network Watcher Connection Monitor para probar la conectividad de extremo a extremo desde las máquinas virtuales de cargas de trabajo hasta extremos externos. Connection Monitor detecta aumentos de latencia y errores de conectividad que podrían indicar el agotamiento de SNAT o la configuración incorrecta del firewall.
  • Métricas de firewall: Realice un seguimiento del rendimiento, el recuento de aciertos de reglas y el uso de puertos SNAT para ajustar el tamaño correcto de la SKU del firewall e identificar las reglas activas.

Consideraciones de diseño

Use Azure Firewall para toda la comunicación saliente de cargas de trabajo migradas. Este enfoque proporciona filtrado, registro y detección de amenazas centralizados de FQDN desde el primer día:

  • Desactive el acceso de salida predeterminado: En el caso de las nuevas implementaciones, las subredes tienen como valor predeterminado privado (sin salida automática). Para las VNet existentes, sustituye explícitamente la salida predeterminada por la salida de Azure Firewall para evitar depender de direcciones IP públicas impredecibles y sin control.
  • UDR en las subredes de carga de trabajo: Cree una ruta definida por el usuario (0.0.0.0/0 → la IP privada de Azure Firewall) en cada subred de carga de trabajo de la red spoke. Esta configuración obliga a que todo el tráfico con destino a Internet pase por el firewall del concentrador.
  • Puerta de enlace NAT en AzureFirewallSubnet: Asocie la puerta de enlace NAT a la subred del firewall para un SNAT escalable. Esta combinación proporciona direcciones IP de salida predecibles y evita el agotamiento de puertos SNAT.
  • Comience con reglas de permiso generales, apriete con el tiempo: Durante la migración, permita la salida a destinos que necesitan las aplicaciones (Windows Update, repositorios de paquetes, API de terceros). Una vez estabilizada la migración, audite los registros de firewall y restrinja a los FQDN conocidos.

El enrutamiento basado en UDR desde cada red secundaria (spoke) al firewall central (hub) es la base de su modelo de seguridad de salida. Los equipos de aplicaciones no pueden omitir los controles de salida administrados por TI:

  • UDR en cada VNet spoke: Cada subred de carga de trabajo spoke tiene una tabla de rutas con 0.0.0.0/0 → IP privada del Azure Firewall hub. Esta configuración garantiza que los nodos de AKS, las subredes con integración de red virtual de App Service y las máquinas virtuales dirijan todo el tráfico saliente a través del firewall.
  • Firewall hub como SNAT: Azure Firewall realiza NAT de origen para todas las conexiones salientes. Todas las cargas de trabajo spoke comparten las direcciones IP de salida del firewall, lo que simplifica la inclusión en la lista de permitidos de los firewalls de los socios.
  • Puerta de enlace NAT para el escalado de SNAT: Asocie la puerta de enlace NAT a la subred AzureFirewallSubnet. Con 16 direcciones IP públicas (más de 1 millón de puertos SNAT), se administran cargas de trabajo de alto recuento de conexiones, como clústeres de AKS con muchos pods que realizan llamadas API externas.
  • Reglas de aplicación para el control de FQDN: Use las reglas de aplicación de Azure Firewall para restringir el tráfico saliente por FQDN. Los equipos de aplicaciones solicitan entradas de permiso de FQDN a través de un proceso de administración de cambios. Deny-by-default impide la filtración de datos.

Azure Firewall en el centro virtual seguro inspecciona tanto el tráfico de tránsito entre nubes como el tráfico de salida a Internet. El uso compartido de un único firewall para ambas rutas simplifica la arquitectura:

  • Protección del firewall del centro virtual para la salida: Si implementa Virtual WAN con un centro seguro, Azure Firewall en el centro controla la salida de Internet para todas las redes virtuales conectadas. Configure la directiva de enrutamiento de tráfico de Internet del centro seguro para enviar 0.0.0.0/0 a través del firewall.
  • El tráfico de salida y el tránsito entre nubes utilizan el mismo firewall: El tráfico destinado a Internet y el tráfico destinado a AWS/Google Cloud a través de túneles IPSec pasan por Azure Firewall para su inspección. Este diseño implica que mantienes un único conjunto de reglas para todas las rutas salientes.
  • Centralice solo si es necesario: Si el diseño entre nubes no exige la salida centralizada de Internet (por ejemplo, las cargas de trabajo solo se comunican entre nubes), puede omitir esta configuración y confiar solo en la inspección del firewall de tránsito entre nubes.

Prerequisites

Antes de implementar controles de salida salientes, confirme los siguientes elementos:

  • Se implementa una red virtual con subredes dimensionadas para sus cargas de trabajo. Consulte Redes virtuales y subredes para obtener instrucciones de diseño de subred.
  • Comprende las rutas definidas por el usuario (UDR) y cómo invalidan el enrutamiento predeterminado Azure. Consulte Redes virtuales y subredes para obtener detalles de configuración de UDR.
  • La subred del firewall tiene el tamaño correcto si usa Azure Firewall. AzureFirewallSubnet requiere un mínimo de /26 (64 direcciones).
  • Conoce los requisitos de escalado de SNAT. Calcule las conexiones salientes simultáneas máximas para determinar cuántas direcciones IP públicas de puerta de enlace NAT necesita (64 512 puertos por IP).

Consideraciones de seguridad

Reemplazar el acceso de salida predeterminado

Se ha retirado el acceso saliente predeterminado. En el caso de las versiones de API publicadas después del 31 de marzo de 2026, las nuevas redes virtuales tienen como valor predeterminado subredes privadas (sin salida automática). Las redes virtuales existentes no se ven afectadas, pero debe migrar a un método de salida explícito. Para obtener más información, consulte la documentación de acceso saliente predeterminada.

Note

Las redes virtuales y las máquinas virtuales existentes que usan actualmente el acceso saliente predeterminado siguen funcionando. Sin embargo, la dirección IP pública asignada no es predecible, no proporciona ningún filtrado y desencadena Azure Advisor alertas. Planifique la migración a NAT Gateway o Azure Firewall independientemente del calendario de retirada.

Enrutamiento UDR para inspección centralizada de cortafuegos

Al usar Azure Firewall para el control de salida, cree una UDR en cada subred de carga de trabajo con:

  • Destino: 0.0.0.0/0
  • Tipo de próximo salto: Aplicación virtual
  • Dirección del siguiente salto: dirección IP privada de Azure Firewall (por ejemplo, 10.0.1.4)

Esta configuración garantiza que todo el tráfico enlazado a Internet desde subredes de carga de trabajo pase a través del firewall para su inspección. Sin esta UDR, el tráfico omite el firewall y usa cualquier método saliente configurado directamente en la subred.

Evitar el agotamiento de puertos SNAT

El agotamiento de puertos SNAT se produce cuando una carga de trabajo abre más conexiones salientes simultáneas que admite el inventario de puertos disponible. Los síntomas incluyen tiempos de espera de conexión intermitentes, paquetes TCP RST en conexiones salientes y solicitudes HTTP fallidas por errores de socket. Los registros de aplicación muestran errores de "dirección ya en uso" o "no se puede asignar la dirección solicitada". El agotamiento normalmente se manifiesta bajo carga cuando muchas conexiones de corta duración se abren rápidamente a la misma dirección IP y puerto de destino.

Para evitar el agotamiento:

  • Use NAT Gateway para cargas de trabajo con recuentos de conexiones salientes elevados. Cada dirección IP pública proporciona 64 512 puertos SNAT con asignación dinámica en todos los recursos de la subred.
  • Agregue direcciones IP públicas a la puerta de enlace NAT si la supervisión muestra el uso del puerto superior a 80%. Agregue hasta 16 direcciones IP públicas.
  • Use la agrupación de conexiones en el código de aplicación para reutilizar las conexiones existentes en lugar de abrir nuevas para cada solicitud.
  • Diversifique los puntos de conexión de destino siempre que sea posible. La asignación de puertos SNAT se realiza por cada tupla de IP/puerto de destino, por lo que distribuir el tráfico entre varias direcciones IP de destino reduce la presión sobre los puertos.
  • Reduzca los tiempos de espera de inactividad para recuperar puertos más rápido. El tiempo de espera de inactividad predeterminado de NAT Gateway es de 4 minutos. Reduzca este valor para las cargas de trabajo que crean muchas conexiones de corta duración.

Los grupos de seguridad de red complementan el control de salida

Los grupos de seguridad de red (NSG) y los métodos de salida sirven para diferentes propósitos y funcionan juntos. Los grupos de seguridad de red filtran el tráfico por dirección IP y puerto a nivel de subred o de NIC. NAT Gateway y Azure Firewall controlan cómo el tráfico llega a Internet. Utilice ambas capas para la defensa en profundidad. Consulte Grupos de seguridad de red y grupos de seguridad de aplicaciones para obtener instrucciones de diseño de grupos de seguridad de red.

Consideraciones de tunelización forzada

El tráfico saliente mediante túnel forzado a través de la infraestructura local puede introducir latencia y añade una dependencia del firewall local. Considere Azure Firewall para la inspección de salida si es importante una latencia baja. Si el cumplimiento exige la inspección local, pruebe la latencia de un extremo a otro de las subredes de carga de trabajo y asegúrese de que la ruta de acceso local puede controlar los requisitos de rendimiento sin convertirse en un cuello de botella.

Impedir la filtración de datos

El filtrado de FQDN de Azure Firewall evita la exfiltración de datos al restringir las conexiones salientes únicamente a nombres de dominio aprobados. Defina reglas de aplicación que permitan el tráfico a FQDN específicos (por ejemplo, *.blob.core.windows.net o api.partner.com) y deniegue todas las demás conexiones salientes. Este enfoque garantiza que las cargas de trabajo en peligro no puedan enviar datos a puntos de conexión controlados por atacantes.

Aprende más

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

A continuación, en el itinerario de lift-and-shift:

Configure el firewall del centro de conectividad: configure Azure Firewall para la inspección centralizada del este-oeste y el control de tráfico saliente.

A continuación en su proceso de modernización:

Configuración del firewall del centro: configure Azure Firewall como SNAT/DNAT en el centro para limpiar todo el tráfico antes de que llegue al nivel de aplicación.

A continuación, en el itinerario entre nubes:

Configure la supervisión multinube: los entornos multinube son más difíciles de diagnosticar y resolver. Establezca la monitorización antes de poner en producción.

  • Last updated on