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

  • Artículo
  • 8 minutos para leer

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 Virtual Network NAT y la puerta de enlace de Azure  NAT, y que está bien informado sobre las respectivas características. Como recordatorio, revise el conjunto completo de la documentación de Azure Virtual Network NAT.

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 puerta de enlace de NAT puede admitir 64 000 flujos para TCP y UDP respectivamente, por dirección IP de salida asignada. 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. 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 cuatro minutos. Si esta configuración cambia a un valor superior, NAT retendrá los flujos por 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.
  • 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 generalmente significa Sistema de nombres de dominio, ya que es el sistema de nombres 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. Cuanto mayor sea el tiempo de espera de inactividad, mayor será la presión sobre los puertos SNAT. Un tiempo de espera de inactividad más corto, como 4 minutos, reducirá el tiempo que los puertos SNAT estarán en uso.
  • 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.
  • 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 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. Si el prefijo IP es mayor que 16 direcciones IP, puede crear direcciones IP individuales a partir del prefijo IP y asignarlas a la puerta de enlace NAT.

Use alertas de Azure Monitor para supervisar y alertar sobre el uso de puertos SNAT.

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 y abarcan varios dominios de error. Esto es así incluso si una puerta de enlace NAT se implementa de forma regional, sin zonas de disponibilidad. Cuando se usan zonas de disponibilidad para el aislamiento de zonas, las puertas de enlace NAT también se pueden implementar de forma zonal.

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.

Seguridad

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 "sándwich" de equilibrador de carga y una puerta de enlace NAT.

Azure Security Center puede supervisar cualquier conectividad saliente sospechosa a través de una puerta de enlace NAT. Esta es una característica de alerta de Azure Security Center.

Pasos siguientes