Compartir por

Solución de problemas de conectividad de Azure NAT Gateway

  • Artigo

Este artículo proporciona una guía sobre cómo solucionar problemas comunes de conectividad saliente con su recurso de puerta de enlace NAT. En este artículo también se indican los procedimientos recomendados sobre cómo diseñar aplicaciones para usar conexiones salientes de forma eficaz.

Caída en la disponibilidad de la ruta de acceso a datos en la puerta de enlace NAT con errores de conexión

Escenario

Observará una caída en la disponibilidad de la ruta de acceso a datos de la puerta de enlace NAT, que coincide con los errores de conexión.

Causas posibles:

  • Agotamiento del puerto de traducción de direcciones de red de origen (SNAT)

  • Límites de conexión SNAT simultáneos.

  • Tiempos de espera de conexión.

Pasos de solución de problemas

Posibles soluciones para el agotamiento de los puertos SNAT o cuando se alcanzan los límites de conexión simultáneas

  • Agregue direcciones IP públicas a la puerta de enlace NAT hasta un total de 16 para escalar la conectividad saliente. Cada dirección IP pública proporciona 64 512 puertos SNAT y admite hasta 50 000 conexiones simultáneas por punto de conexión de destino único para la puerta de enlace NAT.

  • Distribuya el entorno de aplicaciones entre varias subredes y proporcione un recurso de puerta de enlace de NAT para cada subred.

  • Libere el inventario de puertos SNAT reduciendo el temporizador de tiempo de espera de inactividad de TCP a un valor inferior. El temporizador de tiempo de espera de inactividad de TCP no se puede establecer en menos de 4 minutos.

  • Considere los patrones de sondeo asincrónicos para liberar los recursos de conexión para otras operaciones.

  • Realice conexiones a los servicios PaaS de Azure a través de la red troncal de Azure mediante Private Link. Un vínculo privado libera puertos SNAT para las conexiones salientes a Internet.

  • Si la investigación no es concluyente, abra un caso de soporte técnico para solucionar el problema.

Nota:

Es importante saber por qué se produce el agotamiento de los puertos SNAT. Asegúrese de que usa los patrones correctos para lograr escenarios escalables y confiables. La incorporación de más puertos SNAT a un escenario sin conocer la causa de la demanda sería el último recurso. Si desconoce los motivos por los que su escenario está ejerciendo presión sobre el inventario de puertos SNAT, agregar más puertos SNAT mediante la adición de más direcciones IP solo retrasará el error de agotamiento cuando la aplicación se escale. Es posible que esté ocultando otras ineficacias y antipatrones. Para obtener más información, consulte Procedimientos recomendados para un uso eficaz de las conexiones salientes.

Posibles soluciones para tiempos de espera de conexión de TCP

Use conexiones persistentes de TCP o conexiones persistentes de capa de aplicación para actualizar los flujos inactivos y restablecer el temporizador de tiempo de espera de inactividad. Para obtener ejemplos, consulte Ejemplos de .NET.

Los paquetes keepalive de TCP solo deben habilitarse desde un lado de una conexión para mantener una conexión activa desde ambos lados. Cuando se envía una conexión persistente de TCP desde un lado de una conexión, el otro lado envía automáticamente un paquete acknowledge (ACK). A continuación, se restablece el temporizador de tiempo de espera de inactividad en ambos lados de la conexión.

Nota:

Aumentar el tiempo de espera de inactividad de TCP es un último recurso y es posible que no resuelva la causa principal del problema. Un tiempo de espera prolongado puede introducir retrasos y provocar errores innecesarios de baja velocidad cuando expira el tiempo de espera.

Posibles soluciones para los tiempos de espera de conexión del Protocolo de datagramas de usuario (UDP)

Los temporizadores de tiempo de espera de inactividad de UDP se establecen en 4 minutos y no se pueden configurar. Habilite conexiones persistentes de UDP para ambas direcciones en un flujo de conexión para mantener conexiones largas. Cuando se habilita una conexión persistente de UDP, solo está activa para una dirección en una conexión. La conexión puede seguir inactiva y agotar el tiempo de espera en el otro lado de una conexión. Para evitar que una conexión UDP entre en inactividad y se agote su tiempo de espera, los paquetes keepalive UDP deben estar habilitados para ambas direcciones en un flujo de conexión.

Los paquetes keepalive de la capa de la aplicación también se pueden usar para actualizar los flujos inactivos y restablecer el tiempo de espera de inactividad. Compruebe el lado del servidor para ver qué opciones existen para conexiones persistentes específicas de la aplicación.

Caída en la disponibilidad de la ruta de acceso a datos en la puerta de enlace NAT sin errores de conexión

Escenario

La disponibilidad de la ruta de acceso a datos de la puerta de enlace NAT cae, pero no se observan conexiones con errores.

Causa posible

Caída transitoria en la disponibilidad de la ruta de acceso a datos causada por el ruido en la ruta de acceso a datos.

Pasos para solucionar problemas

Si observa una caída en la disponibilidad de la ruta de acceso a datos sin ningún efecto en la conectividad saliente, podría deberse a que la puerta de enlace NAT recoge ruido transitorio en la ruta de acceso a datos.

Configure una alerta para caídas de la disponibilidad de la ruta de acceso a datos o use Azure Resource Health para recibir alertas sobre los eventos de mantenimiento de NAT Gateway.

No hay conectividad de salida a Internet.

Escenario

No observará ninguna conectividad saliente en la puerta de enlace NAT.

Causas posibles:

  • Configuración incorrecta de la puerta de enlace NAT.

  • El tráfico de Internet se redirige lejos de la puerta de enlace NAT y se fuerza una tunelización a una aplicación virtual o a un destino local con una VPN o ExpressRoute.

  • Las reglas del grupo de seguridad de red (NSG) están configuradas para bloquear el tráfico de Internet.

  • La disponibilidad de la ruta de acceso a datos de la puerta de enlace NAT está degradada.

  • Configuración incorrecta del sistema de nombres de dominio (DNS).

Pasos para solucionar problemas

  • Compruebe que la puerta de enlace NAT esté configurada con al menos una dirección IP pública o prefijo y que esté asociada a una subred. La puerta de enlace NAT no está operativa hasta que se asocian una dirección IP pública y una subred. Para obtener más información, consulte Aspectos básicos de la configuración de la puerta de enlace NAT.

  • Compruebe la tabla de enrutamiento de la subred conectada a la puerta de enlace NAT. Cualquier tráfico 0.0.0.0/0 donde se aplica la tunelización forzada a una aplicación virtual de red (NVA), ExpressRoute o VPN Gateway tendrá prioridad sobre la puerta de enlace NAT. Para obtener más información, consulte cómo Azure selecciona una ruta.

  • Compruebe si hay reglas de NSG configuradas para la interfaz de red en la máquina virtual que bloquea el acceso a Internet.

  • Compruebe si la disponibilidad de la ruta de acceso a datos de la puerta de enlace NAT está en un estado degradado. Consulte la guía de solución de problemas de errores de conexión si la puerta de enlace NAT está en un estado degradado.

  • Compruebe la configuración de DNS si DNS no se está resolviendo correctamente.

Posibles soluciones para la pérdida de conectividad saliente

  • Adjunte una dirección IP pública o un prefijo a la puerta de enlace NAT. Asegúrese también de que la puerta de enlace NAT esté asociada a subredes de la misma red virtual. Compruebe que la puerta de enlace NAT pueda realizar una conexión saliente.

  • Tenga en cuenta cuidadosamente los requisitos de enrutamiento del tráfico antes de realizar cambios en las rutas de tráfico de la red virtual. Las rutas definidas por el usuario (UDR) que envían tráfico 0.0.0.0/0 a una aplicación virtual o puerta de enlace de red virtual invalidan la puerta de enlace NAT. Consulte rutas personalizadas para obtener más información sobre cómo afectan las rutas personalizadas al enrutamiento del tráfico de red.

    Para explorar las opciones para actualizar las rutas de tráfico en la tabla de enrutamiento de subredes, consulte:

  • Actualice las reglas de seguridad del NSG que bloquean el acceso a Internet para cualquiera de las máquinas virtuales. Para obtener más información, consulte administración de los grupos de seguridad de red.

  • Que el DNS no se resuelva correctamente puede producirse por muchas razones. Consulte la guía de solución de problemas de DNS para ayudar a investigar por qué se produce un error en la resolución de DNS.

La dirección IP pública de la puerta de enlace NAT no se usa para realizar una conexión saliente

Escenario

La puerta de enlace NAT se implementa en la red virtual de Azure, pero se usan direcciones IP inesperadas para las conexiones salientes.

Causas posibles:

  • Configuración incorrecta de la puerta de enlace NAT.

  • Conexión activa con otro método de conectividad saliente de Azure, como Azure Load Balancer o direcciones IP públicas de nivel de instancia en máquinas virtuales. Los flujos de conexión activos siguen usando la dirección IP pública anterior que se asignó cuando se estableció la conexión. Cuando se implementa la puerta de enlace NAT, las nuevas conexiones comienzan a usar la puerta de enlace NAT inmediatamente.

  • Las direcciones IP privadas se usan para conectarse a los servicios de Azure mediante puntos de conexión de servicio o Private Link.

  • Las conexiones a las cuentas de almacenamiento proceden de la misma región que la máquina virtual desde la que realiza una conexión.

  • El tráfico de Internet se redirige lejos de la puerta de enlace NAT y se aplica una tunelización forzada a una aplicación virtual de red o un firewall.

Procedimientos para solucionar problemas

  • Compruebe que la puerta de enlace NAT tenga al menos una dirección IP pública o un prefijo asociado y al menos una subred.

  • Compruebe si algún método de conectividad saliente anterior, como un equilibrador de carga público, sigue activo después de implementar la puerta de enlace NAT.

  • Compruebe si las conexiones realizadas a otros servicios de Azure proceden de una dirección IP privada en la red virtual de Azure.

  • Compruebe si tiene Private Link o puntos de conexión de servicio habilitados para conectarse a otros servicios de Azure.

  • Asegúrese de que la máquina virtual se encuentra en la misma región que el almacenamiento de Azure al realizar una conexión de almacenamiento.

  • Compruebe si la dirección IP pública que se usa para las conexiones se origina desde otro servicio de Azure dentro de la red virtual de Azure, como una aplicación virtual de red (NVA).

Posibles soluciones para la dirección IP pública de la puerta de enlace NAT que no se usa para la conexión saliente

  • Adjunte una dirección IP pública o un prefijo a la puerta de enlace NAT. Asegúrese de que la puerta de enlace NAT está conectada a subredes de la misma red virtual. Compruebe que la puerta de enlace NAT pueda realizar una conexión saliente.

  • Pruebe y resuelva los problemas con las máquinas virtuales que se mantienen en direcciones IP de SNAT antiguas desde otro método de conectividad saliente de la siguiente manera:

    • Asegúrese de que ha establecido una nueva conexión y de que las conexiones existentes no se reutilizan en el sistema operativo o que el explorador almacena en caché las conexiones. Por ejemplo, al usar curl en PowerShell, asegúrese de especificar el parámetro -DisableKeepalive para forzar una conexión nueva. Si usa un explorador, es posible que las conexiones estén agrupadas.

    • No es necesario reiniciar una máquina virtual de una subred configurada para la puerta de enlace NAT. Sin embargo, si se reinicia una máquina virtual, el estado de la conexión se vacía. Cuando el estado de la conexión se vacía, todas las conexiones empiezan a usar las direcciones IP del recurso de puerta de enlace NAT. Este comportamiento es un efecto secundario de la máquina virtual que se reinicia, no un indicador de que se requiere un reinicio.

    • Si sigue teniendo problemas, abra un caso de soporte técnico para solucionar el problema.

  • Las rutas personalizadas que dirigen el tráfico 0.0.0.0/0 a una aplicación virtual de red tendrán prioridad sobre la puerta de enlace NAT para enrutar el tráfico a Internet. Para que la puerta de enlace NAT enrute el tráfico a Internet en lugar de la aplicación virtual de red, quite la ruta personalizada para el tráfico 0.0.0.0/0 que va a la aplicación virtual. El tráfico 0.0.0.0/0 se reanuda mediante la ruta predeterminada a Internet y se usa la puerta de enlace NAT en su lugar.

Importante

Antes de realizar cambios en cómo se enruta el tráfico, tenga en cuenta cuidadosamente los requisitos de enrutamiento de la arquitectura en la nube.

  • Los servicios implementados en la misma región que una cuenta de almacenamiento de Azure usan direcciones IP privadas de Azure para la comunicación. No puede restringir el acceso a servicios específicos de Azure en función de su intervalo de direcciones IP salientes públicas. Para obtener más información, consulte Restricciones para las reglas de red IP.
  • Private Link y los puntos de conexión de servicio usan las direcciones IP privadas de las instancias de máquina virtual de la red virtual para conectarse a los servicios de la plataforma Azure en lugar de a la dirección IP pública de la puerta de enlace NAT. Use Private Link para conectarse a otros servicios de Azure a través de la red troncal de Azure en lugar de a través de Internet con la puerta de enlace NAT.

Nota:

Private Link es la opción recomendada sobre los puntos de conexión de servicio para el acceso privado a los servicios hospedados de Azure.

Errores de conexión en el destino público de Internet

Escenario

Se produce un error en las conexiones de la puerta de enlace NAT a destinos de Internet o se agota el tiempo de espera.

Causas posibles:

  • Firewall u otros componentes de gestión del tráfico en el destino.

  • Limitación de la velocidad de API impuesta por el lado de destino.

  • Formas de tráfico de la capa de transporte o mitigaciones de DDoS volumétricas.

  • El punto de conexión de destino responde con paquetes fragmentados.

Procedimientos para solucionar problemas

  • Valide la conectividad a un punto de conexión en la misma región o en otra parte para la comparación.

  • Lleve a cabo la captura de paquetes desde los lados de origen y destino.

  • Examine el recuento de paquetes en el origen y el destino (si está disponible) para determinar cuántos intentos de conexión se realizaron.

  • Examine los paquetes descartados para ver cuántos paquetes descartó la puerta de enlace NAT.

  • Analice los paquetes. Los paquetes TCP con paquetes de protocolo IP fragmentados indican la fragmentación de IP. La puerta de enlace NAT no admite la fragmentación de IP y, por tanto, se produce un error en las conexiones con paquetes fragmentados.

  • Asegúrese de que la dirección IP pública de la puerta de enlace NAT aparece como permitida en los destinos de asociados con firewalls u otros componentes de administración de tráfico.

Posibles soluciones para errores de conexión en el destino de Internet

  • Compruebe que la dirección IP pública de la puerta de enlace NAT aparece como permitida en el destino.

  • Si va a crear pruebas de gran volumen o de tasa de transacciones, explore si la reducción de la velocidad reduce la aparición de errores.

  • Si la reducción de la velocidad de las conexiones reduce la aparición de errores, compruebe si el destino alcanzó sus límites de velocidad de API u otras restricciones.

Errores de conexión en el servidor FTP para el modo activo o pasivo

Escenario

Verá errores de conexión en un servidor FTP al usar la puerta de enlace NAT con el modo FTP activo o pasivo.

Causas posibles:

  • El modo FTP activo está habilitado.

  • El modo FTP pasivo está habilitado y la puerta de enlace NAT usa más de una dirección IP pública.

Posible solución para el modo FTP activo

FTP usa dos canales independientes entre un cliente y un servidor, el comando y los canales de datos. Cada canal se comunica en conexiones TCP independientes, una para enviar los comandos y el otra para transferir datos.

En el modo FTP activo, el cliente establece el canal de comandos y el servidor establece el canal de datos.

La puerta de enlace NAT no es compatible con el modo FTP activo. FTP activo usa un comando PORT del cliente FTP que indica al servidor FTP qué dirección IP y puerto para el servidor usar en el canal de datos para volver a conectarse al cliente. Este comando PORT usa la dirección privada del cliente, que no se puede cambiar. La puerta de enlace NAT para la comunicación basada en Internet aplicará SNAT al tráfico del lado cliente, por lo que el servidor FTP considera que el comando PORT no es válido.

En su lugar, una solución alternativa al modo FTP activo es usar el modo FTP pasivo. Sin embargo, para usar la puerta de enlace NAT en modo FTP pasivo, se deben tener en cuenta algunas consideraciones.

Posible solución para el modo FTP pasivo

En el modo FTP pasivo, el cliente establece conexiones en los canales de comandos y datos. El cliente solicita que el servidor responda en un puerto en lugar de intentar establecer una conexión de nuevo con el cliente.

El FTP pasivo saliente no funciona en una puerta de enlace NAT con varias direcciones IP públicas, en función de la configuración del servidor FTP. Cuando una puerta de enlace NAT con varias direcciones IP públicas envía tráfico saliente, selecciona de manera aleatoria una de sus direcciones IP públicas como dirección IP de origen. FTP produce un error cuando los canales de control y de datos usan direcciones IP de origen diferentes, en función de la configuración del servidor FTP.

Para evitar posibles errores de conexión FTP pasiva, realice los siguientes pasos:

  1. Compruebe que la puerta de enlace NAT esté asociada a una única dirección IP pública en lugar de a varias direcciones IP o un prefijo.

  2. Asegúrese de que el intervalo de puertos pasivos de la puerta de enlace NAT pueda pasar los firewalls en el punto de conexión de destino.

Nota:

Al reducir la cantidad de direcciones IP públicas en la puerta de enlace NAT, se reduce el inventario de puertos SNAT disponible para establecer conexiones salientes y puede aumentar el riesgo de agotamiento de puertos SNAT. Tenga en cuenta las necesidades de conectividad de SNAT antes de quitar las direcciones IP públicas de la puerta de enlace NAT. No se recomienda cambiar la configuración del servidor FTP para aceptar tráfico del plano de datos y el control de diferentes direcciones IP de origen.

Las conexiones salientes en el puerto 25 están bloqueadas

Escenario

No se puede realizar una conexión saliente con la puerta de enlace NAT en el puerto 25 para el tráfico del Protocolo simple de transferencia de correo (SMTP).

Causa

La plataforma Azure bloquea las conexiones SMTP salientes en el puerto TCP 25 para las VM implementadas. Este bloqueo es para garantizar una mejor seguridad para los asociados y clientes de Microsoft, proteger la plataforma Azure de Microsoft y cumplir con los estándares del sector.

Utilice un servicio de retransmisión SMTP autenticado para enviar correo electrónico desde máquinas virtuales de Azure o desde Azure App Service. Para obtener más información, consulte Solución de problemas de conectividad SMTP saliente.

Consulte la guía de solución de problemas.

Capturas de red adicionales

Si la investigación no es concluyente, abre un caso de soporte técnico para solucionar problemas adicionales y recopila la siguiente información para una resolución más rápida. Elige una sola máquina virtual en la subred configurada de la puerta de enlace NAT y realice las siguientes pruebas:

  • Para probar la respuesta del puerto de sondeo, use ps ping de una de las máquinas virtuales de back-end de la red virtual y registre los resultados (ejemplo: ps ping 10.0.0.4:3389).

  • Si no se recibe respuesta con estas pruebas de ping, ejecute un seguimiento netsh simultáneo en la máquina virtual de back-end y la máquina virtual de prueba de la red virtual mientras ejecuta PsPing y detenga el seguimiento netsh.

Procedimientos recomendados de conectividad saliente

Azure supervisa y opera su infraestructura con gran cuidado. Sin embargo, todavía pueden producirse fallos transitorios desde las aplicaciones implementadas y no hay garantía de que las transmisiones sean sin pérdidas. La puerta de enlace NAT es la opción preferida para establecer una conectividad saliente altamente confiable y resistente desde implementaciones de Azure. Para optimizar la eficacia de la conexión de la aplicación, consulte las instrucciones que se indican más adelante en el artículo.

Use agrupar conexiones

Cuando agrupas las conexiones, evita abrir conexiones de red nuevas para las llamadas a la misma dirección y puerto. Puedes implementar un esquema de agrupación de conexiones en la aplicación, en el que las solicitudes se distribuyen internamente entre un conjunto fijo de conexiones y se reutilizan siempre que sea posible. Esta configuración limita el número de puertos SNAT en uso y crea un entorno predecible. La agrupación de conexiones ayuda a reducir la latencia y el uso de recursos y, en última instancia, a mejorar el rendimiento de las aplicaciones.

Para más información acerca de agrupar las conexiones HTTP, consulta Agrupación de conexiones HTTP con HttpClientFactory.

Reutilizar las conexiones

En lugar de generar conexiones TCP atómicas individuales para cada solicitud, configura la aplicación para reutilizar las conexiones. La reutilización de las conexiones da lugar a transacciones TCP de mayor rendimiento y es especialmente adecuada para protocolos como HTTP/1.1, donde la reutilización de la conexión es el valor predeterminado. Esta reutilización se aplica a otros protocolos que usan HTTP como su transporte, como REST.

Usar una lógica de reintento menos agresiva

Cuando se agotan los puertos SNAT o se producen errores de aplicación, los reintentos agresivos o por fuerza bruta sin lógica de retroceso y decadencia provocan el agotamiento o su persistencia. Puede reducir la demanda de puertos SNAT mediante el uso de una lógica de reintento menos agresiva.

Según el tiempo de espera de inactividad configurado, si los reintentos son demasiado agresivos, las conexiones no tienen tiempo suficiente para cerrar y liberar los puertos SNAT para su reutilización.

Más mayor orientación y ejemplos, consulta Patrón para reintentos.

Uso de conexiones persistentes para restablecer el tiempo de expiración de inactividad saliente

Para obtener más información sobre las conexiones persistentes, consulte Tiempo de espera de inactividad de TCP.

Cuando sea posible, Private Link se debe usar para conectarse directamente desde las redes virtuales a los servicios de la plataforma Azure con el fin de reducir la demanda en los puertos SNAT. Reducir la demanda en los puertos SNAT puede ayudar a reducir el riesgo de agotamiento de puertos SNAT.

Para crear una instancia de Private Link, consulte las siguientes guías de inicio rápido para empezar:

Pasos siguientes

Siempre nos esforzamos por mejorar la experiencia de nuestros clientes. Si encuentra problemas de puerta de enlace NAT que no se han solucionado o resuelto en este artículo, proporcione comentarios a través de GitHub en la parte inferior de esta página.

Para obtener más información sobre NAT Gateway, consulte: