Protocolo PROXY

El Protocolo PROXY permite que un proxy o balanceador de carga comunique la información de conexión original del cliente, incluyendo su dirección IP real y puerto, al servidor backend, anteponiendo una pequeña cabecera estandarizada al inicio de la conexión TCP.

¿Por qué el Protocolo PROXY? El problema que resuelve

Los proxies TCP estándar operan estableciendo una nueva conexión con el servidor backend en nombre del cliente. Desde la perspectiva del servidor backend, la conexión se origina desde la dirección IP del proxy, no desde la del cliente original. Este comportamiento oculta la verdadera identidad del cliente, creando varios desafíos:

• Registro: Los registros de acceso del servidor graban la IP del proxy, lo que imposibilita rastrear las solicitudes hasta clientes individuales.
• Seguridad: Los Firewalls de Aplicaciones Web (WAFs), los limitadores de velocidad y las listas de control de acceso (ACLs) en los servidores backend no pueden identificar y bloquear con precisión a clientes maliciosos basándose en sus direcciones IP reales.
• Análisis: Los sistemas de geolocalización, entrega de contenido personalizado y detección de abuso pierden datos críticos de ubicación y comportamiento del cliente.
• Depuración: La resolución de problemas de red o comportamientos específicos del cliente se vuelve significativamente más compleja sin visibilidad de la fuente original del cliente.

El Protocolo PROXY aborda esto proporcionando un mecanismo para que el proxy transmita los detalles de conexión del cliente (IP de origen, puerto de origen, IP de destino, puerto de destino) a través de la capa de proxy, permitiendo que el servidor backend identifique correctamente al cliente original.

Cómo funciona el Protocolo PROXY

El Protocolo PROXY opera en la capa de transporte (Capa 4) del modelo OSI. Cuando un proxy o balanceador de carga que soporta el Protocolo PROXY recibe una conexión de un cliente, establece una nueva conexión con el servidor backend. Antes de enviar cualquier dato de la capa de aplicación (por ejemplo, solicitudes HTTP, consultas de bases de datos), el proxy primero envía una cabecera del Protocolo PROXY. Esta cabecera contiene la información de conexión del cliente.

Para que el Protocolo PROXY funcione correctamente, deben cumplirse dos condiciones:
1. El proxy o balanceador de carga debe estar configurado para enviar la cabecera del Protocolo PROXY.
2. El servidor backend debe estar configurado para recibir y analizar la cabecera del Protocolo PROXY antes de procesar cualquier dato de la capa de aplicación. Si el servidor backend no entiende la cabecera, la interpretará como datos de aplicación malformados, lo que provocará errores de conexión.

Versiones del Protocolo PROXY

Existen dos versiones principales del Protocolo PROXY: v1 y v2.

Versión 1 (v1)

El Protocolo PROXY v1 es un formato legible por humanos, basado en ASCII. Soporta IPv4 e IPv6 sobre TCP.

Formato:
PROXY <INET_PROTOCOL> <CLIENT_IP> <PROXY_IP> <CLIENT_PORT> <PROXY_PORT>\r\n

• <INET_PROTOCOL>: TCP4 para IPv4 o TCP6 para IPv6.
• <CLIENT_IP>: La dirección IP del cliente original.
• <PROXY_IP>: La dirección IP del proxy (la IP que el backend ve como origen de la conexión).
• <CLIENT_PORT>: El puerto de origen del cliente original.
• <PROXY_PORT>: El puerto de destino en el proxy al que se conectó el cliente.

Ejemplo (IPv4):

PROXY TCP4 192.168.1.1 10.0.0.1 52345 80\r\n

Esta cabecera indica una conexión TCPv4 desde el cliente 192.168.1.1:52345 al proxy, que luego se conectó al backend en 10.0.0.1:80.

Limitaciones de v1:
* Limitado a conexiones TCP.
* La sobrecarga ASCII puede ser ligeramente menos eficiente.
* No soporta metadatos adicionales.

Versión 2 (v2)

El Protocolo PROXY v2 es un formato binario diseñado para la eficiencia y la extensibilidad. Soporta sockets IPv4, IPv6 y UNIX sobre TCP y UDP, e incluye un mecanismo de campos Tipo-Longitud-Valor (TLV) para transmitir metadatos de conexión adicionales.

Ventajas de v2:
* Eficiencia: El formato binario reduce el tamaño de la cabecera.
* Mayor soporte de protocolos: Soporta sockets TCP, UDP y UNIX.
* Soporte IPv6: Integra completamente IPv6.
* Extensibilidad (TLV): Permite pasar metadatos arbitrarios, como información de conexión SSL, IDs de conexión únicos u otros datos específicos de la aplicación.

Visión general de la estructura (simplificada):
La cabecera v2 comienza con una firma de 13 bytes, seguida de un campo de versión/comando de 1 byte, un campo de protocolo de 1 byte, un campo de longitud de dirección de 2 bytes, y luego la información de dirección de longitud variable y los campos TLV opcionales.

Aunque el formato binario sin procesar es complejo, la clave es su capacidad para transmitir más información de manera eficiente y a través de una gama más amplia de protocolos.

Protocolo PROXY vs. X-Forwarded-For (XFF)

Tanto el Protocolo PROXY como la cabecera HTTP X-Forwarded-For (XFF) tienen como objetivo pasar la información de la IP del cliente a través de un proxy. Sin embargo, operan en diferentes capas y tienen características distintas.

El Protocolo PROXY ofrece una solución más robusta y universal para pasar la información de la IP del cliente, especialmente para servicios no HTTP o escenarios donde se requieren fuertes garantías contra la suplantación de IP del cliente a nivel de red.

Implementación del Protocolo PROXY

La implementación del Protocolo PROXY requiere configuración tanto en el proxy/balanceador de carga emisor como en el servidor backend receptor.

Configuración del Proxy/Balanceador de Carga (Envío del Protocolo PROXY)

HAProxy:
HAProxy es una opción común para el balanceo de carga y soporta completamente el Protocolo PROXY.

frontend http_in
    bind *:80
    mode tcp
    default_backend web_servers

backend web_servers
    mode tcp
    server s1 192.168.1.10:80 send-proxy-v2 # Envía Protocolo PROXY v2
    server s2 192.168.1.11:80 send-proxy    # Envía Protocolo PROXY v1

AWS Network Load Balancer (NLB):
Al configurar un Grupo de Destino para un NLB, puede habilitar el soporte para el Protocolo PROXY v2. Esta configuración se aplica a todo el grupo de destino. Todos los destinos en ese grupo deben estar configurados para aceptar el Protocolo PROXY.

Cloudflare Spectrum:
Para servicios proxy a través de Cloudflare Spectrum, puede habilitar el soporte del Protocolo PROXY. Cloudflare enviará cabeceras del Protocolo PROXY v2 a sus servidores de origen.

Nginx (Módulo Stream - como proxy):
El ngx_stream_proxy_module de Nginx puede configurarse para enviar el Protocolo PROXY, principalmente en su versión comercial o compilaciones específicas.

stream {
    upstream backend_servers {
        server 192.168.1.10:80;
        server 192.168.1.11:80;
    }
    server {
        listen 12345;
        proxy_pass backend_servers;
        proxy_protocol on; # Nginx envía Protocolo PROXY v1
    }
}

Configuración del Servidor Backend (Recepción y Análisis del Protocolo PROXY)

Nginx (como servidor web backend):
Nginx puede configurarse para escuchar y analizar las cabeceras del Protocolo PROXY.

http {
    server {
        listen 80   proxy_protocol; # Escucha el Protocolo PROXY v1/v2 en el puerto 80
        listen 443  ssl proxy_protocol;

        set_real_ip_from 10.0.0.0/8; # Confía en las IPs de tu red de proxy
        real_ip_header proxy_protocol; # Usa la IP de la cabecera del Protocolo PROXY

        location / {
            root /var/www/html;
            index index.html;
            # La IP real del cliente ahora estará disponible en $remote_addr
            # y $proxy_protocol_addr puede usarse para el registro o lógica específica
            log_format custom_log '$proxy_protocol_addr - $remote_user [$time_local] '
                                  '"$request" $status $body_bytes_sent '
                                  '"$http_referer" "$http_user_agent"';
            access_log /var/log/nginx/access.log custom_log;
        }
    }
}

En Nginx, $remote_addr se establecerá en la IP del proxy, pero las variables $proxy_protocol_addr y $proxy_protocol_port contendrán la IP y el puerto reales del cliente. Las directivas set_real_ip_from y real_ip_header proxy_protocol permiten a Nginx poblar correctamente $remote_addr con la IP real del cliente.

Servidor HTTP Apache:
Apache puede utilizar el módulo mod_remoteip para analizar las cabeceras del Protocolo PROXY.

<IfModule mod_remoteip.c>
    # Habilitar el análisis del Protocolo PROXY
    RemoteIPProxyProtocol On

    # Definir proxies de confianza
    RemoteIPTrustedProxy 10.0.0.0/8
    RemoteIPTrustedProxy 192.168.0.0/16

    # Configurar el formato de registro para usar la IP real del cliente
    LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
</IfModule>

Con RemoteIPProxyProtocol On, Apache esperará la cabecera del Protocolo PROXY. La variable %a en LogFormat reflejará entonces correctamente la IP real del cliente.

Aplicaciones Personalizadas:
Para aplicaciones personalizadas escritas en lenguajes como Python, Node.js, Go o Java, la propia aplicación necesita leer el flujo TCP entrante, buscar la cabecera del Protocolo PROXY, analizarla y luego proceder con el protocolo específico de la aplicación.

• Detección: La aplicación debe leer primero unos pocos bytes (por ejemplo, 100-200 bytes) del socket para verificar si coinciden con la firma del Protocolo PROXY v1 (PROXY) o la firma v2.
• Análisis: Si se detecta una cabecera del Protocolo PROXY, la aplicación la analiza para extraer la IP del cliente, el puerto, etc.
• Continuación: Después del análisis, la aplicación procesa los datos restantes en el socket como su protocolo nativo.
• Sin Cabecera: Si no se encuentra ninguna cabecera del Protocolo PROXY, la aplicación asume que la conexión es directamente de un cliente o de un proxy que no usa el Protocolo PROXY y procesa los datos directamente.

Muchas bibliotecas y frameworks de red ofrecen middleware o soporte integrado para el análisis del Protocolo PROXY.

Beneficios de usar el Protocolo PROXY

• Registro de IP Preciso: Asegura que los registros de acceso del servidor, firewalls y sistemas de monitoreo registren la verdadera dirección IP del cliente.
• Seguridad Mejorada: Permite que las herramientas de seguridad (WAFs, mitigación de DDoS, limitadores de velocidad) en los servidores backend apliquen políticas basadas en la identidad real del cliente.
• Análisis Mejorado: Proporciona datos geográficos y demográficos precisos para análisis, pruebas A/B y personalización.
• Arquitectura de Red Simplificada: Consolida el manejo de la IP del cliente en la capa de transporte, reduciendo la necesidad de cabeceras específicas de la aplicación como XFF.
• Amplia Compatibilidad: Funciona con cualquier aplicación basada en TCP/UDP, no solo HTTP.

Consideraciones y Mejores Prácticas

• Límites de Confianza: Habilite el Protocolo PROXY solo desde proxies o balanceadores de carga de confianza que usted controle. Si una entidad no confiable envía una cabecera del Protocolo PROXY falsificada, su servidor backend podría ser engañado sobre el origen del cliente.
• Compatibilidad de Extremo a Extremo: Asegúrese de que tanto el proxy como el servidor backend estén configurados correctamente para enviar y recibir la versión específica del Protocolo PROXY (v1 o v2). Las incompatibilidades provocarán fallos en la conexión.
• Rendimiento: La sobrecarga introducida por la cabecera del Protocolo PROXY es mínima, especialmente con el formato binario de v2. Sin embargo, el análisis en cada conexión añade un costo de procesamiento pequeño y despreciable.
• Monitoreo: Monitoree los registros de su servidor backend y el tráfico de red para verificar que las IPs de los clientes se identifiquen correctamente y que no ocurran errores inesperados del Protocolo PROXY.