Uncategorized

SNAT App Service ASE

¿Qué es el SNAT?

Source NAT y normalmente se usa cuando un host interno / privado necesita iniciar una conexión a un host externo / público. El dispositivo que realiza NAT cambia la dirección IP privada del host de origen a una dirección IP pública.

Existe una tupla para realizar una conexión:

  • TCP
  • La IP de origen
  • El puerto de origen
  • La IP de destino
  • El puerto de destino

¿Qué sucedería si desde 2 máquinas distintas queremos realizar una conexión externa al mismo destino y usando el mismo puerto?

No podría cambiar la IP y puerto del destino ya que no podria llegar mi solicitud a donde necesito. Por lo que la opción que tengo es cambiar la información de mi recurso de origen.

Esta traducción del destino es muy común. Es más, sucede cuando deseamos conectarnos desde nuestro dispositivo móvil al wifi de nuestro hogar. El router será el encargado de realizar esa traducción.

SNAT with App Service

Por lo general, una aplicación web de App Service necesita conectarse a algún otro recurso, ya sea dentro o fuera de Azure. Como por ejemplo una base de datos SQL, caché de Redis u otro servicio web Restful.

Sin embargo, una aplicación web de App Service no puede establecer conexiones de red a los recursos finales por medio de Internet directamente.

Esto se debe a que una aplicación web de App Service está alojada en una o algunas instancias de worker de App Service. Las instancias de “worker” están delimitadas dentro de la unidad de escala (stamp) del sitio. 

Las instancias no tienen direcciones IP de Internet asignadas y necesitan aprovechar el equilibrador de carga (load balancer) para realizar la traducción de direcciones de red de origen, también conocida como SNAT, para conectarse a direcciones IP externas.

Esta imagen tiene un atributo alt vacío
¿Como funciona el SNAT? 
  1. Una aplicación de App Service envía un paquete TCP a una dirección IP de Internet. La dirección IP de origen y el número de puerto del paquete son internos.
  2. El paquete TCP se enruta desde una instancia del worker al load balancer. El load balancer es el encargado de realizar el SNAT cambiando la IP de origen y el puerto del paquete TCP por sus propios y lo envía a Internet.
  3. El servidor de Internet recibe el paquete TCP. Más tarde, cuando devuelve cualquier paquete, utiliza la dirección IP y el puerto del equilibrador de carga como destino del paquete.
  • Cuando el load balancer recibe un paquete enrutado desde el servidor de Internet, cambia la dirección IP y el puerto de destino a los de la instancia del worker, utilizando el registro de mapeo anterior.

El SNAT port exhaustion ocurre generalmente cuando en la aplicación no se están reutilizando las conexiones o se está creando una conexión de salida para cada solicitud.

Azure usa un algoritmo para determinar la cantidad de puertos SNAT preasignados disponibles. El algoritmo basa la cantidad de puertos en el tamaño del grupo de backend. Puede encontrar más detalles al respecto en el siguiente artículo:

https://docs.microsoft.com/es-mx/azure/load-balancer/load-balancer-outbound-connections

Esto no son buenas prácticas y pueden llevarnos a agotar las conexiones.  La recomendación de nuestro lado es mantener las conexiones simultaneas por debajo de los 100, para evitar cualquier problema que nos pueda generar.

¿Como puedo verificar si mis puertos de SNAT se están agotando?

Cuando se agotan los puertos SNAT de una instancia, se pueden observar los siguientes síntomas desde la aplicación:

  • Las solicitudes que llegan a mi aplicativo tienen problemas de lentitud.
  •  Las solicitudes que llegan a mi aplicativo están pendientes a conectarse al recurso final.
  • Excepciones de socket cuando se agota el tiempo de espera de las conexiones en la aplicación web.
  • Fallos intermitentes al conectarme a otro recurso.
Solucionar problemas de SNAT

La recomendación es realizar algunos cambios en el código y seguir las mejores prácticas para evitar SNAT. Para resolver el problema de SNAT, necesitamos:

• Modificar la aplicación para reutilizar conexiones

• Modificar la aplicación para usar la agrupación de conexiones

• Modificar la aplicación para utilizar una lógica de reintento menos agresiva

• Utilice keepalives para restablecer el tiempo de espera inactivo de salida

• Asegúrese de que los servicios de backend puedan devolver una respuesta rápidamente.

• Escale el plan de App Service a más instancias(esto es una manera de mitigación).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *