Editar

Revisión del Marco de buena arquitectura de Azure de una puerta de enlace de Azure NAT

Azure Application Gateway
Azure Virtual Network
Azure Private Link

En este artículo se proporcionan los procedimientos recomendados para una puerta de enlace de Azure NAT. Dicha guía se basa en los cinco pilares de excelencia de la arquitectura: optimización de costos, excelencia operativa, eficiencia del rendimiento, confiabilidad y seguridad.

Se da por sentado que tiene un conocimiento práctico de Azure NAT Gateway y que está bien informado sobre las respectivas características. Como recordatorio, revise el conjunto completo de la documentación de Azure NAT Gateway.

NAT significa traducción de direcciones de red. Consulte Introducción a la traducción de direcciones de red.

Optimización de costos

El acceso a los servicios de PaaS debe realizarse a través de Azure Private Link o los puntos de conexión de servicio (incluido el almacenamiento) para evitar el uso de una puerta de enlace NAT. Los puntos finales de servicio y enlace privado no requieren atravesar la puerta de enlace de NAT para obtener acceso a los servicios de PaaS. Este enfoque reducirá el cargo por GB de los datos procesados, al comparar los costos de una puerta de enlace de NAT con Private Link o con los puntos de conexión de servicio. Asimismo, hay ventajas de seguridad adicionales al usar Private Link o los puntos de conexión de servicio.

Eficiencia del rendimiento

Cada recurso de puerta de enlace de NAT puede proporcionar hasta 50 Gbps de rendimiento. Puede dividir las implementaciones en varias subredes y asignar a cada subred o grupos de subredes una puerta de enlace NAT para realizar un escalado horizontal.

Cada dirección IP pública de puerta de enlace NAT proporciona 64 512 puertos SNAT. Asimismo, se pueden asignar hasta 16 direcciones IP a una puerta de enlace NAT. Las direcciones IP pueden ser direcciones IP públicas estándar individuales, el prefijo de IP pública o ambos elementos. Para las conexiones que van al mismo punto de conexión de destino, la puerta de enlace NAT puede admitir hasta 50 000 flujos simultáneos para TCP y UDP, respectivamente, por dirección IP de salida asignada. Revise la siguiente sección sobre la Traducción de direcciones de red de origen (SNAT) para obtener más detalles. TCP significa Protocolo de control de transmisión y UDP significa Protocolo de datagramas de usuario.

Agotamiento de la arquitectura de redes de sistemas

  • Los recursos de puerta de enlace NAT tienen un tiempo de espera de inactividad de TCP predeterminado de 4 minutos que se puede configurar hasta 120 minutos. Si esta configuración se cambia a un valor superior que el predeterminado, la puerta de enlace NAT retendrá los flujos durante más tiempo y puede causar una presión innecesaria en el inventario de puertos SNAT.
  • Las solicitudes atómicas (una solicitud por conexión) son una opción de diseño deficiente, ya que limita la escala, reduce el rendimiento y reduce la confiabilidad. En su lugar, reutilice las conexiones HTTP/S para reducir el número de conexiones y los puertos SNAT asociados. La reutilización de la conexión permitirá que la aplicación se escale mejor. El rendimiento de la aplicación mejorará, debido a la reducción de los protocolos de enlace, los costos generales y los costos de operaciones criptográficas cuando se utiliza TLS.
  • El Sistema de nombres de dominio (DNS) puede introducir muchos flujos individuales en el volumen cuando el cliente no almacena en caché el resultado de la resolución DNS. Use el almacenamiento en caché de DNS para reducir el volumen de flujos y reducir el número de puertos SNAT. DNS es el sistema de nombres que asigna nombres de dominio a direcciones IP para los recursos que están conectados a Internet o a una red privada.
  • Los flujos de UDP, como las búsquedas DNS, usan puertos SNAT durante el tiempo de espera de inactividad. El temporizador de tiempo de espera de inactividad de UDP está fijo en 4 minutos y no se puede cambiar.
  • Use los grupos de conexiones para dar forma al volumen de la conexión.
  • Nunca abandone de forma silenciosa un flujo TCP y confíe en temporizadores TCP para limpiar el flujo. Si no permite que TCP cierre explícitamente la conexión, la conexión TCP permanece abierta. Los sistemas intermedios y los puntos de conexión mantendrán esta conexión en uso, lo que a su vez hace que el puerto SNAT no esté disponible para otras conexiones. Este patrón puede desencadenar errores en la aplicación y el agotamiento de SNAT.
  • No cambie los valores del temporizador relacionado con el cierre de TCP de nivel de sistema operativo sin que un experto le indique el impacto que esto tendría. Aunque la pila de TCP se recuperará, el rendimiento de la aplicación puede verse afectado negativamente si los puntos de conexión de una conexión tienen expectativas no coincidentes. Cambiar los valores del temporizador suele ser un signo de un problema de diseño subyacente. Si la aplicación subyacente tiene otros antipatrones, el agotamiento de SNAT también se puede ampliar si se modifican los valores del temporizador.

Revise las instrucciones siguientes para mejorar la escalabilidad y la confiabilidad del servicio:

  • Explore el efecto de reducir el tiempo de espera de inactividad de TCP para reducir los valores. Un tiempo de espera de inactividad predeterminado de 4 minutos puede liberar el inventario de puertos SNAT antes.
  • Considere la posibilidad de usar patrones de sondeo asincrónicos para las operaciones de ejecución prolongada, con el fin de liberar recursos de conexión para otras operaciones.
  • Los flujos de larga duración, como las conexiones TCP reutilizadas, deben usar elementos TCP de KeepAlive o elementos de KeepAlive del nivel de aplicación, para evitar el tiempo de espera de los sistemas intermedios. Solo debe aumentar el tiempo de espera de inactividad como último recurso y, aún así, es posible que no resuelva la causa principal. Un tiempo de espera prolongado puede causar errores de baja tasa cuando expira el tiempo de espera y crear retrasos y errores innecesarios. Los elementos TCP de KeepAlive pueden habilitarse desde un lado de una conexión para mantener una conexión activa desde ambos lados.
  • En el caso de flujos de larga duración con tráfico UDP, puede habilitar elementos TCP de KeepAlive para mantener activas las conexiones. Tenga en cuenta que los elementos UDP de KeepAlive habilitados en un lado de la conexión solo mantienen activa la conexión desde un lado. Los elementos UDP de KeepAlive deben estar habilitados en ambos lados de una conexión para mantener activa una conexión.
  • Se deben usar patrones de reintento correctos para evitar reintentos o ráfagas agresivos durante un error transitorio o la recuperación de un error. La creación de una conexión TCP para cada operación HTTP (también conocidas como conexiones atómicas) es un antipatrón. Las conexiones atómicas evitarán que su aplicación se escale de forma correcta y malgastarán recursos. Canalice siempre varias operaciones a la misma conexión. Su aplicación aumentará la velocidad de las transacciones y reducirá los costos de los recursos. Cuando la aplicación usa un cifrado de la capa de transporte (por ejemplo, TLS), se produce un considerable costo asociado con el procesamiento de nuevas conexiones. Para conocer otros patrones de procedimientos recomendados, consulte Patrones de diseño en la nube de Azure.

Excelencia operativa

Aunque la puerta de enlace NAT se puede usar con Azure Kubernetes Service (AKS), no se administra como parte de AKS. Si asigna una puerta de enlace NAT a la subred de Container Networking Interface (CNI), habilitará los pods de AKS para la salida a través de la puerta de enlace NAT.

Al usar varias puertas de enlace NAT en zonas o regiones, mantenga el estado de IP saliente manejable mediante prefijos de IP pública de Azure o prefijos BYOIP. No se puede asignar un tamaño de prefijo IP mayor que 16 direcciones IP (tamaño de prefijo /28) a la puerta de enlace NAT.

Use las alertas de Azure Monitor para supervisar y alertar sobre el uso de los puertos SNAT, los paquetes procesados o eliminados y la cantidad de datos transmitidos. Use los registros de flujo del grupo de seguridad de red para supervisar el flujo de tráfico saliente desde instancias de máquina virtual en una subred configurada de puerta de enlace NAT.

Cuando una subred se configura con una puerta de enlace NAT, la puerta de enlace NAT reemplazará todas las demás conexiones salientes hacia la red pública de Internet de todas las VM de esa subred. La puerta de enlace NAT tendrá prioridad sobre un equilibrador de carga, con o sin reglas de salida, y sobre las direcciones IP públicas asignadas directamente a las VM. Azure realiza un seguimiento de la dirección de un flujo, por lo que no se producirá el enrutamiento asimétrico. El tráfico de entrada originado se traducirá correctamente, como una dirección IP de front-end del equilibrador de carga, y se traducirá por separado del tráfico de salida originado a través de una puerta de enlace NAT. Esta separación permite que los servicios entrantes y salientes coexistan sin problemas.

La puerta de enlace NAT se recomienda como valor predeterminado para habilitar la conectividad saliente para las redes virtuales. La puerta de enlace NAT es más eficaz y menos compleja operativamente que otras técnicas de conectividad saliente en Azure. Asimismo, las puertas de enlace NAT asignan puertos SNAT a petición y usan un algoritmo más eficaz para evitar conflictos de reutilización de puertos SNAT. No confíe en la conectividad saliente predeterminada (un antipatrón) para el estado. En su lugar, defina explícitamente con recursos de puerta de enlace NAT.

Confiabilidad

Los recursos de puerta de enlace NAT son de alta disponibilidad en una zona de disponibilidad y abarcan varios dominios de error. La puerta de enlace NAT se puede implementar en "ninguna zona" en la que Azure selecciona automáticamente una zona para colocar la puerta de enlace NAT. Un usuario también puede aislar la puerta de enlace NAT en una zona específica.

No se puede proporcionar el aislamiento de una zona de disponibilidad, a menos que cada subred solo tenga recursos dentro de una zona específica. En su lugar, implemente una subred para cada una de las zonas de disponibilidad donde se implementan las VM, alinee las VM zonales con las puertas de enlace NAT zonales correspondientes y cree pilas zonales independientes. Por ejemplo, una máquina virtual de la zona de disponibilidad 1 se encuentra en una subred con otros recursos que también están solo en la zona de disponibilidad 1. Así pues, una puerta de enlace NAT se configura en la zona de disponibilidad 1 para atender esa subred. Consulte el diagrama siguiente:

Diagrama que muestra el flujo direccional de una pila zonal.

Las redes virtuales y las subredes abarcan todas las zonas de disponibilidad de una región. No es necesario dividirlas por zonas de disponibilidad para dar cabida a los recursos de zona.

Seguridad

Con NAT, las máquinas virtuales individuales (u otros recursos de proceso) no necesitan direcciones IP públicas y pueden permanecer totalmente privadas. Estos recursos, a pesar de no tener una dirección IP pública, pueden llegar a orígenes externos fuera de la red virtual. También puede asociar un prefijo de IP pública para asegurarse de que se usará un conjunto contiguo de direcciones IP para la conectividad de salida. Las reglas de firewall de destino se pueden configurar en función de esta lista de direcciones IP predecibles.

Un enfoque común es diseñar un escenario de aplicación virtual de red (NVA) de solo salida con firewalls de terceros o con servidores proxy. Cuando se implementa una puerta de enlace NAT en una subred con un conjunto de escalado de máquinas virtuales de NVA, esas NVA usarán las direcciones de puerta de enlace NAT para la conectividad saliente, en lugar de la dirección IP de un equilibrador de carga o direcciones IP individuales. Para emplear este escenario con Azure Firewall, consulte Integración de Azure Firewall con Azure Standard Load Balancer.

Diagrama que muestra los firewalls con un

Microsoft Defender for Cloud puede supervisar cualquier conectividad saliente sospechosa a través de una puerta de enlace NAT. Esta es una característica de alerta de Microsoft Defender for Cloud.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes