En este artículo se describen los procedimientos recomendados para una Azure NAT Gateway. Dicha guía se basa en los cinco pilares de excelencia de la arquitectura: optimización de costes, excelencia operativa, eficiencia del rendimiento, confiabilidad y seguridad.
Como requisito previo para esta guía, debe tener conocimientos prácticos de Azure NAT Gateway y comprender sus características respectivas. Para obtener más información, consulte la Documentación de Azure NAT Gateway.
Optimización de costos
Configure el acceso a soluciones de plataforma como servicio (PaaS) mediante Azure Private Link o puntos de conexión de servicio, incluido el almacenamiento, para que no tenga que usar una NAT Gateway. Private Link y los puntos de conexión de servicio no requieren atravesar NAT Gateway para obtener acceso a los servicios de PaaS. Este enfoque reduce el coste por gigabyte (GB) de datos procesados, en comparación con el coste de usar una NAT Gateway. Private Link y los puntos de conexión de servicio también proporcionan ventajas de seguridad.
Eficiencia del rendimiento
Cada recurso de NAT Gateway proporciona hasta 50 gigabits por segundo (Gbps) de rendimiento. Puede dividir las implementaciones en varias subredes y asignar a cada subred o grupos de subredes una NAT Gateway para realizar un escalado horizontal.
Cada dirección IP pública de NAT Gateway proporciona 64.512 puertos de traducción de direcciones de red de origen (SNAT). Puede asignar hasta 16 direcciones IP a una NAT Gateway, incluidas direcciones IP públicas estándar individuales, el prefijo de dirección IP pública o ambos. Para cada dirección IP de salida asignada que va al mismo punto de conexión de destino, la NAT Gateway puede admitir hasta 50 000 flujos simultáneos para el protocolo de control de transmisión (TCP) y el protocolo de datagramas de usuario (UDP), respectivamente.
Agotamiento de SNAT
Tenga en cuenta las instrucciones siguientes para ayudar a evitar el agotamiento de SNAT:
Los recursos de NAT Gateway tienen un tiempo de espera de inactividad de TCP predeterminado de cuatro minutos. Puede configurar el tiempo de espera hasta 120 minutos. Si cambia esta configuración a un valor superior que el predeterminado, NAT Gateway retiene los flujos durante más tiempo, lo que puede crear una presión innecesaria en el inventario de puertos SNAT.
Las solicitudes atómicas (una solicitud por conexión) limitan la escala, reducen el rendimiento y reducen la confiabilidad. En lugar de solicitudes atómicas, puede reutilizar las conexiones HTTP o HTTPS para reducir el número de conexiones y los puertos SNAT asociados. Al reutilizar las conexiones, la aplicación puede escalar mejor. El rendimiento de la aplicación mejora, debido a la reducción de los protocolos de enlace, los costes generales y los costes de operaciones criptográficas cuando se utiliza la seguridad de la capa de transporte (TLS).
Si no almacena en caché los resultados de la resolución DNS, las búsquedas del sistema de nombres de dominio (DNS) pueden introducir muchos flujos individuales en el volumen. 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 UDP se fija en cuatro minutos.
Use los grupos de conexiones para dar forma al volumen de la conexión.
Para limpiar los flujos, nunca abandone de forma silenciosa flujos TCP ni confíe en temporizadores TCP. Si no permite que TCP cierre explícitamente una conexión, la conexión TCP permanece abierta. Los sistemas intermedios y los puntos de conexión mantienen esta conexión en uso, lo que hace que el puerto SNAT no esté disponible para otras conexiones. Este antipatrón puede desencadenar errores en la aplicación y el agotamiento de SNAT.
No cambie los valores del temporizador relacionado con el cierre TCP en el nivel de sistema operativo a menos que conozca las implicaciones. Si los puntos de conexión de una conexión tienen expectativas no coincidentes, la pila de TCP se puede recuperar, pero puede afectar negativamente al rendimiento de la aplicación. Normalmente tiene un problema de diseño subyacente si necesita cambiar los valores del temporizador. Y si la aplicación subyacente tiene otros antipatrones y modifica los valores del temporizador, también puede acelerar el agotamiento de SNAT.
Revise las instrucciones siguientes para mejorar la escalabilidad y la confiabilidad del servicio:
Considere los efectos de reducir el tiempo de espera de inactividad de TCP a un valor inferior. Un tiempo de espera de inactividad predeterminado de cuatro minutos puede liberar de forma preventiva el inventario de puertos SNAT.
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.
Considere usar elementos TCP de KeepAlive o elementos de KeepAlive del nivel de aplicación para flujos de TCP de larga duración, como las conexiones TCP reutilizadas, 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 provocar errores de baja velocidad cuando expira el tiempo de espera. También puede introducir un retraso y errores innecesarios. Puede habilitar elementos TCP de KeepAlive desde un lado de una conexión para mantener una conexión activa desde ambos lados.
Considere la posibilidad de usar elementos de KeepAlive de UDP para flujos de UDP de larga duración para evitar que los sistemas intermedios agoten el tiempo de espera. Al habilitar elementos de KeepAlive de UDP en un lado de la conexión, solo un lado de la conexión permanece activo. Debe habilitar elementos de KeepAlive de UDP en ambos lados de una conexión para mantener activa una conexión.
Considere usar patrones de reintento correctos para evitar reintentos y ráfagas agresivos durante un error transitorio o la recuperación de un error. Para las conexiones atómicas puede crear una conexión TCP nueva para cada operación HTTP. Las conexiones atómicas malgastan recursos y evitan que la aplicación se escale de forma correcta.
Para aumentar la velocidad de la transacción y reducir los costes de recursos de la aplicación, canalice siempre varias operaciones en la misma conexión. Cuando la aplicación utiliza el cifrado de la capa de transporte, por ejemplo, TLS, el nuevo procesamiento de conexiones aumenta el coste. Para conocer otros patrones de procedimientos recomendados, consulte Patrones de diseño en la nube de Azure.
Excelencia operativa
Puede usar una NAT Gateway con Azure Kubernetes Service (AKS), pero la administración de NAT Gateway no se incluye en AKS. Si asigna una NAT Gateway a la subred de Container Networking Interface (CNI), habilitará los pods de AKS para la salida a través de la NAT Gateway.
Al usar varias NAT Gateway en zonas o regiones, mantenga el estado de IP saliente manejable mediante prefijos de IP pública de Azure o prefijos propios (BYOIP). No se puede asignar un tamaño de prefijo IP mayor que 16 direcciones IP (tamaño de prefijo /28) a una NAT Gateway.
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 (NSG) para supervisar el flujo de tráfico saliente desde instancias de máquina virtual en una subred configurada de NAT Gateway.
Al configurar una subred con una NAT Gateway, la NAT Gateway reemplaza todas las demás conexiones salientes hacia la red pública de Internet de todas las VM de esa subred. La NAT Gateway tiene prioridad sobre un equilibrador de carga, independientemente de las reglas de salida. La puerta de enlace también tiene prioridad sobre las direcciones IP públicas que se asignan directamente a las máquinas virtuales. Azure realiza un seguimiento de la dirección de un flujo e impide el enrutamiento asimétrico. El tráfico de entrada originado, como una dirección IP de front-end del equilibrador de carga, se traduce correctamente y se traduce por separado del tráfico de salida originado a través de una NAT Gateway. Esta separación permite que los servicios entrantes y salientes coexistan sin problemas.
Se recomienda una NAT Gateway como valor predeterminado para habilitar la conectividad saliente para las redes virtuales. Una NAT Gateway proporciona eficacia y simplicidad operativa en comparación con otras técnicas de conectividad de salida en Azure. Asimismo, las NAT Gateway 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 el antipatrón de conectividad saliente predeterminada para el estado. En su lugar, defina explícitamente la configuración con recursos de NAT Gateway.
Confiabilidad
Los recursos de puerta de enlace NAT son de alta disponibilidad en una zona de disponibilidad y abarcan varios dominios de error. Puede implementar una NAT Gateway en una región sin zona en la que Azure selecciona automáticamente una zona para colocar la NAT Gateway o aísla la NAT Gateway a una zona de disponibilidad específica.
Para proporcionar el aislamiento de una zona de disponibilidad, cada subred debe tener solo recursos dentro de una zona específica. Para implementar este enfoque, puede realizar lo siguiente:
- Implemente una subred para cada una de las zonas de disponibilidad en las que se implementan las máquinas virtuales.
- Alinee las máquinas virtuales zonales con NAT Gateway zonales coincidentes.
- Cree pilas zonales independientes.
En el diagrama siguiente, 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.
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 una NAT Gateway, las máquinas virtuales individuales u otros recursos de proceso, no necesitan direcciones IP públicas y pueden permanecer 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. Puede configurar reglas de firewall de destino 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 no de Microsoft o con servidores proxy. Al implementar una NAT Gateway en una subred con un conjunto de escalado de máquinas virtuales de NVA, esas NVA usan una o varias direcciones de NAT Gateway para la conectividad saliente, en lugar de la dirección IP del 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.
Puede usar la característica de alertas de Microsoft Defender for Cloud para supervisar cualquier conectividad saliente sospechosa en una NAT Gateway.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Ethan Haslett | Arquitecto sénior de soluciones en la nube
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Marco de buena arquitectura de Microsoft
- Tutorial: Creación de una puerta de enlace de NAT mediante Azure Portal
- Recomendaciones para el uso de zonas de disponibilidad y regiones