Cómo identificar las conexiones de los usuarios finales en un Load Balancer en Nginx

Descubre cómo identificar las conexiones de los usuarios finales en un Load Balancer en Nginx.

Como ya sabemos por otros artículos y tutoriales de este mismo site, como por ejemplo el que trata Apache, dentro de las suscripciones de Servidores existe la posibilidad de desplegar load balancer (balanceadores de carga), para de esta manera mejorar la estabilidad y evitar posibles interrupciones de servicio por sobrecarga o posibles fallos en un servidor.

El problema de tener una arquitectura con balanceadores de carga es que introduce cierto nivel de complejidad que puede hacer que sea un poco más difícil identificar las conexiones de los usuarios finales.

Esto se debe a que en los servidores web se muestran conexiones cuyo origen es el propio load balancer (balanceador de carga), no las IP con las que se conectan los usuarios.

Esto es algo relativamente sencillo de solventar, ya que puede configurarse a nivel de la aplicación web de destino. En este caso, vamos a ver cómo resolverlo para Nginx, un servidor web de los más ampliamente usados.

A través de este sencillo tutorial descubrirás cómo hacerlo en simples pasos de manera totalmente guiada.

Este tutorial está relacionado con:

 

¿Cómo identificar las conexiones de los usuarios finales en un Load Balancer en Nginx?

 

Pre-requisitos o pre-configuración

Para completar de forma satisfactoria este tutorial y poder identificar las conexiones de los usuarios finales en un Load Balancer en Nginx, se necesitará:

  • Por un lado, estar dado de alta en la Plataforma Jotelulu con una organización y estar registrado en la misma tras hacer Log-in.
  • Contar con un usuario con permiso de administración sobre toda la organización y sobre los usuarios de esta.
  • Tener al menos, 2 servidores desplegados en una misma suscripción.
  • Tener instalado Nginx.

 

Paso 1. Configuramos el identificador de las conexiones de los usuarios finales en un Load Balancer en Nginx

En el caso de Nginx, lo primero que se debe hacer es acceder al servidor con la cuenta de “root” o con otra cuenta con acceso privilegiado, o sea, una cuenta dada de alta en “sudoers”.

Lo siguiente será crear una plantilla “log_format” en la que se deberá agregar la variable “$http_x_forwarded_for” para que se añada el valor de la cabecera en el log.

Para ello se deberá acceder al archivo de configuración de Nginx que está ubicado en la siguiente ruta:

/etc/nginx/nginx.conf

Para la edición, se puede usar cualquier editor como “vi” o “nano”.

# vi /etc/nginx/nginx.conf

O

# nano /etc/nginx/nginx.conf

Debemos bajar en el archivo hasta encontrar el texto “access_log”, en la sección “Logging Settings”:

Una vez editado el fichero, se deben buscar la sección de “Logging Settings” y localizar el texto “Access_log”. Es en esta sección donde se configura cómo se va a comportar el log de Nginx, y por tanto se determina cómo se van a escribir los datos en los archivos de registro (log).

Cuando se haya localizado, antes de “Access_log” se debe definir una nueva plantilla “log_format” en el que se describa el “$http_x_forwarded_for”.

Una forma de hacerlo es como se describe a continuación:

log_format customjote ‘[$time_local] $http_x_forwarded_for – $remote_addr $request $status $body_bytes_sent $http_referer $http_user_agent’;

Con estas líneas se está definiendo un nuevo “log_format” llamado “customjote” en el que se añade al log la fecha y hora local, y los datos de desde donde se hace el renvío en base a la variable “$http_x_forwarded_for” además de añadir otros datos.

NOTA: El orden de los modificadores puede variar según las necesidades del lector, igual que la posibilidad de quitar alguna de las variables.

Para que esta opción se active se debe añadir una línea de “Access_log” antes del “;” con el siguiente contenido:

access_log /var/log/nginx/access.log customjote; 

Finalmente, el archivo quedará similar al siguiente ejemplo:

##
# Logging Settings
##
log_format
customjote ‘[$time_local] $http_x_forwarded_for – $remote_addr $request $status $body_bytes_sent $http_referer $http_user_agent’;
Access_log
/var/log/nginx/access.log

Paso 1. Fichero de configuración de Nginx una vez editado
Paso 1. Fichero de configuración de Nginx una vez editado

 

Para que los cambios tomen efecto habrá que reiniciar Nginx por lo que se deberá lanzar el siguiente comando:

# sudo systemctl restart nginx

Llegados a este punto, ya deberíamos poder ver las redirecciones por lo que es recomendable que lo revisemos con una consulta del fichero de log en tiempo real, usando para ello un comando como “tail”.

# tail -f /var/log/nginx/access.log

 

Paso 1. Comprobamos el log de Nginx para ver si se ha configurado correctamente
Paso 1. Comprobamos el log de Nginx para ver si se ha configurado correctamente

En este momento, ya se puede ver que, en la primera columna, la primera dirección IP que se muestra es básicamente el valor del equipo desde el que se reenvía, o sea el valor de la cabecera “X-Forwarded-For” que se ha configurado en este tutorial.

 

Conclusión

Tal como has visto en este tutorial cómo identificar las conexiones de los usuarios finales en un Load Balancer en Nginx, trabajar con balanceadores de carga (Load Balancers) permite repartir la carga de los clientes y servicios entre los distintos servidores para minimizar las caídas de sistemas y optimizar las colas de trabajo, pero a su vez hace que no se pueda identificar el origen de una conexión. Como has podido ver, con este tutorial se soluciona esta situación para trabajos con Nginx Webserver, al igual que el resto de los productos y servicios de esta plataforma, es muy sencillo de configurar y más siguiendo este simple tutorial.

Esperamos que con este tutorial la configuración del balanceador de carga haya quedado clara. Pero en caso de que te surja cualquier pregunta, no dudes en consultarnos.

¡Gracias por confiar en nosotros!

Categorías:Servidores

Rellena el formulario y nuestro equipo de Sales contactará contigo lo antes posible.

growth@jotelulu.com  |  +34 911 333 712  |  jotelulu.com 

Puedes darte de baja de estas comunicaciones en cualquier momento.  Consulta nuestra Política de privacidad.

Precios competitivos para la pyme y mucho más margen para el partner

Disaster Recovery ha sido diseñado, implementado y puesto en producción teniendo en cuenta dos premisas: Debe tener un precio atractivo para la pyme a la vez que deja un buen margen de beneficio a la empresa de IT que lo comercializa y gestiona.

DR_buen_precio_y_mas_margen

De esta manera, Disaster Recovery pretende ser un producto diferencial que permita incrementar la seguridad de todo tipo de empresas de manera asequible e implicando, además, rentabilidad para el distribuidor que lo comercializa.

Protege la infraestructura de tus clientes

Disaster Recovery permite replicar cualquier suscripción de infraestructura (Escritorio Remoto y Servidores) en otra zona de disponibilidad creando un entorno de alta disponibilidad y blindando así el servicio.

Replica en pocos pasos no sólo los discos sino todos los elementos que forman parte de cada suscripción:

  • Servidores: Instancias, discos, reglas de firewall, redes, IPs…
  • Escritorio Remoto: Usuarios, Aplicaciones, Licencias, Personalización…
DR_blinda_la_infraestructura

Tratamos de hacer fácil lo difícil

Las herramientas de Disaster Recovery existentes necesitan de conocimientos avanzados para poder ser gestionadas, implicando, muchas veces, un expertise difícil de alcanzar.

 

Disaster Recovery de Jotelulu busca hacer fácil lo difícil y plantea un despliegue muy sencillo basado en una configuración de tres pasos:

Origin (Primary Site)
Determina la ubicación de origen de la suscripción sobre la que se va a establecer el servicio de Disaster Recovery.

Destino (Recovery Site)
Establece la ubicación de destino (zona de disponibilidad) en la que quieres que se despliegue el Recovery Site.

Características de la réplica
Establece los datos asociados al número de copias que se quieren guardar y la frecuencia con la que se va a llevar a cabo la réplica.