SNAT APP SERVICES

¿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.

¿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.

Azure tiene 160 puertos disponibles en la VIP del load balancer. Un stamp cuenta con 5 direcciones de IP para realizar el SNAT en el load balancer. Estos puertos son compartidos entre todas las instancias que se encuentran dentro del stamp.  Por lo que Azure realiza la formula que se presenta a continuación, permitiendo a cada instancia utilizar aproximadamente 160 puertos.

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.

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).

Una de las ultimas recomendaciones es tener en consideración utilizar Regional VNET integración. (Esta recomendacion aplica si nuestra aplicacion esta en un ambiente multitenat. Si mi aplicativo esta en un ASE esta recomendación no aplica).

• Regional VNet Integration
• Troubleshooting intermittent outbound connection errors in Azure App Service

Integración de VNET regional con Service endpoints

Si su destino es un servicio de Azure que admite Service endpoints, puede evitar problemas de agotamiento del puerto SNAT mediante el uso de la integración de VNet regional con services endpoints or endpoints privados/

Cuando usa la integración de VNet regional y coloca los Service endpoints en la subred de integración, el tráfico saliente de su aplicación a esos servicios no tendrá restricciones de puerto SNAT saliente. Del mismo modo, si usa la integración de VNet regional y los puntos de conexión privados, no tendrá problemas con el puerto SNAT de salida a ese destino.

Pros:

• La aplicación ya no estará restringida por limitaciones de SNAT.

• No es necesario realizar cambios de código ni volver a implementar la aplicación.

• Configuración de bajo costo y bajo mantenimiento que puede proporcionar una mitigación rápida mientras evalúa los cambios de código.

Contras:

• Todos los puntos finales a los que se conecta la aplicación deben estar alojados en Azure.

• Se requiere configuración adicional en los servicios dependientes para habilitar los puntos finales del servicio.

Nota:

Por lo tanto, puede usar la integración de VNET con otros recursos azules como el almacenamiento, SQL, etc. y no ejecutar SNAT. Sin embargo, si abandona la red de Azure y necesita salir a Internet, es posible que aún se apliquen los límites de SNAT.

Integración de VNET con NAT gateway

Si su servicio de destino esta almacenado fuera de Azure, se podría evitar problemas de agotamiento del puerto SNAT usando la integración de VNT y redireccionando el trafico a través del NAT Gateway, ya que el trafico esta siendo redirecciona por medio de la VNET no esta restringido por los limites de SNAT.

Ya que las solicitudes de salida al internet se hará desde el NAT Gateway y es por esto que usaría los 64k puertos que preasignados por el NAT Gateway.

Todas las aplicaciones que forman parte de esta VNET y enrutan el tráfico a través del NAT Gateway compartirán estos puertos de 64K. Esto le brinda mucho más que los 128 puertos SNAT preasignados predeterminados cuando se ejecuta en servicios de aplicaciones sin esta configuración.

Si su sitio ya está en una red virtual, no es necesario que cambie su configuración de red virtual. Continúe con el siguiente paso para instalar y configurar el NAT Gateway y enrutar el tráfico a través de ella.

• Regional VNet Integration
• Tutorial: Create a NAT gateway using the Azure portal
• NAT Gateway and app integration
• Troubleshooting intermittent outbound connection errors in Azure App Service

Nota: Si el punto final de destino se resuelve en una dirección IP pública, es posible que deba configurar la aplicación WEBSITE_VNET_ROUTE_ALL = 1 en su sitio para forzar todo el tráfico a través de VNET y, por lo tanto, a través del NAT Gateway

Pros:

• Los puertos SNAT disponibles son mucho más que los 128 predeterminados.

• No se requieren cambios de código ni redistribución de la aplicación.

• Este enfoque funciona incluso si la aplicación se conecta a puntos finales alojados fuera de Azure.

Contras:

• Costo adicional para el NAT gateway y la VNET. Considere esto como una mitigación provisional mientras evalúa los cambios de código para una solución a más largo plazo.

• Se requiere configuración adicional fuera de Azure App Services.