Métodos para Recuperar la IP de Origen del Cliente

En ciertas situaciones, nuestros servicios requieren utilizar la IP del cliente por razones específicas de negocio o seguridad. Sin embargo, el escenario habitual implica que el tráfico pase a través de múltiples redes, balanceadores de carga o servicios de proxy antes de llegar al servicio real. En cada capa de este proceso, la IP original del cliente puede perderse, dejando a nuestro servicio solo con la IP de la red precedente. Este resultado no es ideal para nosotros.

Debido a la naturaleza intrincada de nuestra pila tecnológica, obtener la IP del cliente implica emplear varios métodos, a veces en combinación.

Gestión de la IP del cliente mediante NAT

En ciertas infraestructuras de IDC establecidas o alquiladas por usuarios, nuestros servicios pueden residir en una red LAN separada detrás de una puerta de enlace. Cuando los clientes intentan conectarse a nuestros servicios desde una red externa, el tráfico se enruta a través de la puerta de enlace.

Un escenario similar puede surgir al utilizar servicios en la nube. La red VPC proporcionada por plataformas de nube pública funciona como una red LAN independiente, aislada de otras VPC e internet. Como resultado, se requiere una puerta de enlace para facilitar el acceso a internet externo y conectarse a servicios externos.

Esta puerta de enlace, que podría ser un enrutador o un dispositivo de firewall, generalmente ofrece servicios de traducción de direcciones DNAT (Destination NAT) para servicios internos. Esto implica que la puerta de enlace tiene una o más direcciones IP públicas y reenvía el tráfico desde puertos específicos en la IP pública a puertos específicos en una IP interna. La puerta de enlace gestiona el reenvío de tráfico y el mapeo de puertos. Sin embargo, debido a la modificación de la dirección de origen en la cabecera del paquete IP original por parte de la puerta de enlace, nuestros servicios dentro de la red interna solo pueden identificar la dirección IP de la puerta de enlace, no la dirección real del cliente.

Históricamente, las capacidades DNAT proporcionadas por dispositivos de red o software eran relativamente básicas. Operaban principalmente en la capa 3 y carecían de capacidades de conciencia y manipulación para cargas útiles de capas más profundas. Su propósito principal era la exposición de servicios, y no podían pasar la IP del cliente aguas abajo. Además, debido a las limitaciones de rendimiento de estos dispositivos o software, había restricciones en el número de conexiones activas y el número máximo de nuevas conexiones que podían manejar. Escalar sin actualizaciones de hardware a menudo era un desafío, lo que los hacía menos adaptables al entorno dinámico de hoy.

Para abordar estas limitaciones, recurrimos al balanceo de carga, que posee capacidades más avanzadas de manipulación de tráfico.

IP del cliente en el balanceo de carga

En general, el balanceo de carga se clasifica principalmente en dos tipos según su capa de trabajo: capa 4 y capa 7, correspondientes a flujos de datos TCP y tráfico de aplicación (representado por HTTP), respectivamente.

A diferencia de las puertas de enlace IP, el balanceo de carga evita modificar la cabecera del paquete IP. A nivel de paquete IP, solo realiza reenvío transparente. En consecuencia, en contraste con el DNAT discutido anteriormente, el balanceo de carga asegura el paso correcto de la IP de origen contenida en el paquete IP a los componentes detrás del balanceador de carga.

Para el balanceo de carga de capa 4, después de lograr el reenvío fundamental de tráfico, los servicios posteriores pueden recuperar con precisión la IP del cliente sin necesidad de ningún procesamiento especial. En escenarios excepcionales, puede aprovechar el Proxy Protocol. Esto implica agregar una nueva sección antes de la carga útil original del tráfico, que abarca la IP del cliente. Otros servidores proxy inversos o el servicio mismo detrás del balanceador de carga pueden entonces interpretar los datos del Proxy Protocol para obtener la IP del cliente.

Para el balanceo de carga de capa 7, posee capacidades más profundas de procesamiento de tráfico. Puede transmitir directamente la IP de origen a nivel del protocolo HTTP. Un enfoque prevalente es la utilización del encabezado HTTP X-Forwarded-For. El componente de balanceo de carga extrae la IP de origen del paquete IP del tráfico, posteriormente analiza y reescribe la solicitud HTTP. Inserta un nuevo campo XFF en su cabecera de solicitud, incorporando el valor de la IP del cliente.

HTTPS presenta un desafío particular debido a su carga útil cifrada, lo que hace que el componente de balanceo de carga no pueda manipular directamente sus encabezados HTTP. En tales situaciones, se pueden considerar los siguientes enfoques:

• Sin requisitos específicos, tratar el tráfico HTTPS como tráfico TLS estándar y reenviarlo directamente en la capa 4 es una opción. En este escenario, la IP del cliente aún puede transmitirse al servicio detrás del balanceador de carga a través de la cabecera del paquete IP.

• Cuando se necesita funcionalidad de capa 7, alojar el certificado TLS en el componente de balanceo de carga permite la terminación TLS. Este proceso implica eliminar el cifrado TLS en la capa de balanceo de carga, utilizando HTTP plano en la LAN detrás del balanceador de carga, o establecer una nueva conexión HTTPS al servicio en lugar de reenvío directo. Esto permite que el componente de balanceo de carga maneje nuevamente el tráfico HTTP original y continúe pasando la IP utilizando el método XFF.

A través de un manejo matizado del tráfico, el balanceo de carga ofrece varios métodos para transmitir la IP del cliente al servicio backend. Implementaciones representativas de componentes de balanceo de carga incluyen servicios ELB basados en la nube, F5 BIG-IP basado en hardware, Linux Virtual Server (LVS) basado en el kernel de Linux, y NGINX basado en software de usuario.

Transmisión de la IP del cliente en servicios CDN

Ocasionalmente, aprovechamos los servicios CDN proporcionados por plataformas de nube pública para mejorar la velocidad de acceso de los usuarios a nuestros servicios. Su funcionamiento es similar a un servidor proxy inverso de capa 7, pero en un contexto más amplio, los CDN pueden considerarse parte del dominio del balanceo de carga.

Los servicios CDN generalmente proporcionan capacidades de terminación TLS y pueden incorporar la IP del cliente en las solicitudes HTTP enviadas al servicio. Por ejemplo, el servicio CDN AWS CloudFront admite pasar la IP del cliente utilizando el método XFF, similar al enfoque utilizado en el balanceo de carga de capa 7.

Utilización de la puerta de enlace API

Si bien los componentes de balanceo de carga generalmente ofrecen capacidades básicas de control de tráfico, las API proporcionadas por balanceadores de carga basados en la nube o hardware pueden ser difíciles de alinear con nuestras necesidades específicas de negocio. En tales escenarios, recurrimos a componentes más adaptables para aplicar estrategias personalizadas a nuestros servicios. Aquí es donde entra en juego una puerta de enlace API, como Apache APISIX o API7 Enterprise.

APISIX y API7 Enterprise admiten el Proxy Protocol, lo que permite la recuperación de la IP del cliente desde el balanceador de carga.

Además, cuentan con un plugin llamado "real-ip", similar al módulo ngx_http_realip_module de NGINX. Este plugin obtiene la IP del cliente desde una fuente y la utiliza para la transmisión aguas abajo y el registro. El plugin real-ip en APISIX y API7 Enterprise mejora la funcionalidad encontrada en NGINX. Permite la activación o desactivación dinámica de la función de IP real y amplía las fuentes de IP del cliente más allá de las limitaciones de ngx_http_realip_module, que se limita a encabezados HTTP y Proxy Protocol. Puede aprovechar cualquier variable extendida de NGINX o APISIX, como parámetros de consulta o campos de formulario POST.

Resumen

Al aprovechar una combinación de tecnologías en diferentes capas, podemos transmitir efectivamente la IP del cliente a través de cada componente del servicio, satisfaciendo tanto las necesidades de negocio como de seguridad.

Para obtener más información sobre soluciones de gestión de API, contacta a API7.ai.