Transparencia de IP y retorno directo del servidor con NGINX y NGINX Plus como proxy transparente

Owen GarrettDirector sénior de Gestión de Producto

Esta entrada de blog describe cómo configurar NGINX Open Source y NGINX Plus como proxy transparente para el tráfico dirigido a servidores ascendentes. Explica cómo utilizar un proxy transparente para suplantar la dirección IP de origen de los paquetes e implementar la transparencia de IP, así como un modo de equilibrio de carga denominado retorno directo del servidor para el tráfico UDP.

La información de esta publicación se aplica tanto a NGINX Open Source como a NGINX Plus. Para abreviar, nos referiremos únicamente a NGINX Plus.

Nota del editor: Esta es la quinta entrega de una serie de artículos del blog que analizan en profundidad las nuevas funciones de NGINX Plus R10.

• Autenticación de clientes de API con JWT y NGINX Plus
• NGINX Plus R10 aprovecha la potencia de IBM POWER
• Autenticación de usuarios en aplicaciones existentes con OpenID Connect y NGINX Plus
• Uso del módulo JavaScript de NGINX para migrar progresivamente los clientes a un nuevo servidor
• Transparencia de IP y retorno directo del servidor con NGINX y NGINX Plus como proxy transparente (esta publicación)

No te pierdas tampoco el seminario web bajo demanda, «¿Qué novedades incluye NGINX Plus R10?»

Resumen

NGINX Plus funciona como un proxy inverso de capa 7. Esto permite a NGINX Plus aplicar diversas optimizaciones y mejoras a las solicitudes de red que gestiona.

Como consecuencia, los servidores ascendentes (con equilibrio de carga) observan que todo el tráfico procede de una dirección IP del proxy NGINX Plus. Esto supone un problema si el servidor ascendente necesita determinar la verdadera dirección IP de origen (la del cliente remoto), por ejemplo, con fines de autenticación o registro.

Existen soluciones alternativas eficaces para el tráfico HTTP y HTTPS, que utilizan bien la cabecera HTTP X-Forwarded-For o bien el protocolo PROXY. Este artículo describe otros dos métodos aplicables al tráfico TCP y UDP:

• Transparencia de IP garantiza que los servidores ascendentes detecten que cada conexión procede del cliente remoto que la inició. Se aplica a protocolos basados en TCP y UDP.
• Retorno directo del servidor (DSR) permite además que las respuestas de los servidores ascendentes se envíen directamente a los clientes remotos, sin pasar por el balanceador de carga intermedio. Se aplica a protocolos basados en UDP y puede implementarse mediante NAT (traducción de direcciones de red) en el servidor de origen o en un router intermedio.

Método 1 – Transparencia de IP Método 2a – DSR (NAT en el router) Método 2b – DSR (NAT en el servidor de origen)Protocolos compatibles Basados en TCP y UDP Solo basados en UDP Solo basados en UDPEstrategia de enrutamiento del tráfico de los servidores ascendentes Todo el tráfico saliente se enruta al proxy NGINX Plus, donde finaliza Todo el tráfico saliente se enruta a través del servidor NGINX Plus intermedio Todo el tráfico se enruta con normalidadRendimiento Estándar: el tráfico saliente finaliza en el proxy NGINX Plus Mejor: el servidor NGINX Plus intermedio reenvía el tráfico saliente Óptimo: el tráfico saliente se enruta directamente al cliente remoto, sin pasar por NGINX PlusComprobaciones de estado Pasivas de forma predeterminada; se admiten activas Se requieren activas; no se permiten pasivas Se requieren activas; no se permiten pasivasConfiguración necesariaTCP y UDP en el proxy NGINX Plus TCP: funciona de forma predeterminada
UDP: proxy_responses 1 TCP: no compatible
UDP: proxy_responses 0 TCP: no compatible
UDP: proxy_responses 0¿Cómo y dónde se procesan los paquetes? iptables finaliza el tráfico en el proxy NGINX Plus tc nat reescribe los paquetes en el servidor NGINX Plus intermedio tc nat reescribe los paquetes en los servidores ascendentesConfiguración de red en el proxy NGINX Plus iptables para capturar los paquetes salientes Reenvío de IP y NAT sin estado NingunaConfiguración de red en el servidor ascendente Designar NGINX Plus como ruta predeterminada Designar NGINX Plus como ruta predeterminada NAT sin estado

La implementación y la resolución de problemas de la transparencia de IP y DSR son complejas. Implemente estas configuraciones únicamente si el modo de funcionamiento estándar de proxy inverso no es suficiente para su aplicación o servicio.

Introducción: flujo de paquetes en un proxy inverso estándar de capa 7

A diferencia de un conmutador o un router que simplemente reenvía paquetes, NGINX Plus funciona como un proxy inverso de capa 7. En este modo de funcionamiento, NGINX Plus gestiona conexiones TCP independientes del lado del cliente y del lado del servidor ascendente (para el tráfico HTTP y TCP), o sesiones UDP, con el fin de controlar la comunicación entre el cliente remoto y el servidor ascendente seleccionado.

1. Los clientes remotos establecen conexiones TCP o envían datagramas UDP directamente al proxy inverso NGINX Plus en la dirección IP y el puerto publicados. NGINX Plus finaliza la conexión TCP o la sesión UDP y lee los datos de la solicitud que contiene.
2. A continuación, NGINX Plus establece una nueva conexión (o reutiliza una conexión existente que esté inactiva) con el servidor ascendente seleccionado (mediante balanceo de carga).
3. Cuando NGINX Plus envía la solicitud al servidor ascendente, la conexión se origina desde la dirección IP interna de NGINX Plus.
4. Cuando el servidor ascendente responde a la solicitud, envía los datos a la dirección IP interna de NGINX Plus.
5. NGINX Plus recibe los datos de respuesta en la conexión con el servidor ascendente. Puede procesar o modificar la respuesta (por ejemplo, aplicar compresión a una respuesta HTTP).
6. A continuación, NGINX Plus escribe los datos de respuesta en la conexión del lado del cliente.

Una consecuencia de este modo de funcionamiento estándar del proxy inverso es que el servidor ascendente observa que el tráfico TCP y UDP procede del proxy NGINX Plus local.

Ventajas y limitaciones del modo de proxy inverso de capa 7

El modo de funcionamiento de proxy inverso de capa 7 ofrece mejoras significativas de rendimiento y eficiencia para el tráfico HTTP y TCP (incluidas las optimizaciones de TCP, el almacenamiento en búfer y la reutilización de conexiones persistentes HTTP). Sin embargo, plantea un problema si el servidor ascendente necesita determinar la verdadera dirección IP de origen de la conexión o sesión para fines como la autenticación y el control de acceso, la limitación de velocidad y el registro.

Para algunos protocolos, NGINX Plus puede utilizar la cabecera HTTP X-Forwarded-For o el protocolo PROXY para proporcionar la dirección IP de origen a los servidores ascendentes. Este artículo describe otros dos métodos, posibles gracias al parámetro transparent de la directiva proxy_bind, que se introdujo en NGINX Plus Release 10 (R10)<.htmla>.

Método 1: transparencia de IP

El objetivo de la transparencia de IP es ocultar la presencia del proxy inverso para que el servidor de origen detecte que los paquetes IP proceden de la dirección IP del cliente. La transparencia de IP puede utilizarse con protocolos basados en TCP y UDP.

Creación de un servicio de proxy inverso HTTP en el balanceador de carga NGINX Plus

Para demostrar la transparencia de IP, primero creamos un clúster con balanceo de carga formado por cuatro servidores web que responden con información básica sobre la conexión.

1. Configure un servidor virtual HTTP sencillo que distribuya la carga del tráfico entre un grupo de servidores ascendentes:

# in the 'http' context
server {
    listen 80;

    location / {
        proxy_pass http://http_upstreams;
    }
}

upstream http_upstreams {
    server 172.16.0.11;
    server 172.16.0.12;
    server 172.16.0.13;
    server 172.16.0.14;
}

1. Para confirmar que los servidores ascendentes detectan que las conexiones se originan en el equilibrador de carga NGINX Plus, configure un servidor web NGINX Plus en cada uno de los cuatro servidores (del 172.16.0.11 al 172.16.01.14) con un servidor virtual sencillo que devuelva información sobre la conexión, como la siguiente:

# in the 'http' context
server {
    listen 80;

    location / {
        return 200 "Hello from $hostname. You connected from $remote_addr:$remote_port to $server_addr:$server_portn";
    }
}

Cuando probamos esta configuración, los servidores ascendentes indican que las conexiones se originan en la dirección IP local de NGINX Plus (172.16.0.1):

$ for i in {1..4}; do curl http://192.168.99.10 ; done
Hello from dev1. You connected from 172.16.0.1:42723 to 172.16.0.11:80
Hello from dev2. You connected from 172.16.0.1:39117 to 172.16.0.12:80
Hello from dev3. You connected from 172.16.0.1:54545 to 172.16.0.13:80
Hello from dev4. You connected from 172.16.0.1:57020 to 172.16.0.14:80

Configuración de NGINX Plus y los servidores upstream para la transparencia de IP

NGINX Plus R10 y versiones posteriores (y NGINX Open Source 1.11.0 y versiones posteriores) pueden suplantar la dirección de origen del tráfico ascendente. Incluya el parámetro «transparent» en la directiva «proxy_bind». Lo más habitual es establecer como dirección de origen la del cliente remoto:

proxy_bind $remote_addr transparent;

Sin embargo, este sencillo paso plantea un reto importante, ya que debe asegurarse de que el tráfico de respuesta (saliente) dirigido al cliente remoto se gestione correctamente. El tráfico de respuesta debe enrutarse a NGINX Plus, y NGINX Plus debe finalizar la conexión TCP ascendente. A continuación, NGINX Plus envía el tráfico de respuesta al cliente remoto a través de la conexión TCP del cliente.

Debe realizar varios cambios de configuración, tanto en el balanceador de carga NGINX Plus como en cada servidor ascendente:

1. En el balanceador de carga NGINX Plus, configure los procesos de trabajo para que se ejecuten como root, de modo que puedan vincular los sockets de los servidores ascendentes a direcciones arbitrarias. En el contexto principal (de nivel superior) de /etc/nginx/nginx.conf, incluya la directiva user para establecer el ID de los procesos de trabajo de NGINX Plus en root:

# in the 'main' context
# 'user daemon' is the default; change to 'user root' with transparent proxy_bind
user root;

1. En el balanceador de carga NGINX Plus, asegúrese de que cada conexión se origine en la dirección del cliente remoto. Añada la directiva proxy_bind con el parámetro transparent a la configuración del servidor virtual:

# in the 'http' context
server {
    listen 80;

    location / {
        proxy_bind $remote_addr transparent;
        proxy_pass http://http_upstreams;
    }
}

1. En el balanceador de carga NGINX Plus, configure iptables para capturar los paquetes de retorno de los servidores ascendentes y entregarlos a NGINX Plus. En este ejemplo, ejecutamos los comandos iptables e ip rule para capturar todo el tráfico TCP del puerto 80 procedente de los servidores representados por el intervalo de direcciones IP 172.16.0.0/28:

# ip rule add fwmark 1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100
# iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff

1. Ejecute el siguiente comando para mostrar (-L) la configuración actual de la tabla mangle de iptables:

# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       tcp  --  172.16.0.0/28        anywhere             tcp spt:http MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

1. En los servidores ascendentes, configure el enrutamiento para que todo el tráfico de retorno se reenvíe a NGINX Plus. En cada servidor ascendente, elimine cualquier ruta predeterminada existente y configure como ruta predeterminada la dirección IP del equilibrador de carga/proxy inverso NGINX Plus. Tenga en cuenta que esta dirección IP debe estar en la misma subred que una de las interfaces del servidor ascendente.

# route del default gw 10.0.2.2
# route add default gw 172.16.0.1

1. Comprueba que la tabla de enrutamiento tenga sentido:

# route -n
Kernel IP routing table
Destination   Gateway     Genmask        Flags Metric Ref Use Iface
0.0.0.0       172.16.0.1  0.0.0.0        UG    0      0     0 eth2
10.0.2.0      0.0.0.0     255.255.255.0  U     0      0     0 eth0
172.16.0.0    0.0.0.0     255.255.255.0  U     0      0     0 eth2
192.168.56.0  0.0.0.0     255.255.255.0  U     0      0     0 eth1

1. Si sus servidores ascendentes necesitan poder conectarse a servidores externos, también debe configurar la nueva puerta de enlace de NGINX Plus para que reenvíe y enmascare el tráfico. Consulte «Permitir que los servidores ascendentes accedan a servidores externos» más adelante.

Prueba de la configuración de transparencia de IP

Ahora puede probar la configuración enviando solicitudes a NGINX Plus. Asegúrese de enviar las solicitudes desde una dirección IP remota a la que no se pueda enrutar directamente desde los servidores ascendentes:

$ for i in {1..4}; do curl http://192.168.99.10 ; done
Hello from dev1. You connected from 192.168.99.1:60729 to 172.16.0.11:80
Hello from dev2. You connected from 192.168.99.1:43070 to 172.16.0.12:80
Hello from dev3. You connected from 192.168.99.1:45749 to 172.16.0.13:80
Hello from dev4. You connected from 192.168.99.1:46609 to 172.16.0.14:80

Observe que ahora las conexiones parecen proceder de la dirección IP del cliente remoto (192.168.99.1), en lugar de una dirección local del balanceador de carga NGINX Plus.

Si la configuración no funciona, consulte la sección «Solución de problemas» que aparece a continuación.

Resumen: ¿Cómo funciona la configuración de transparencia de IP?

• NGINX Plus recibe una solicitud HTTP de un cliente remoto (192.168.99.1).
• NGINX Plus toma una decisión de balanceo de carga y selecciona un servidor ascendente (por ejemplo, 172.16.0.11) al que conectarse. Antes de establecer la conexión, NGINX Plus vincula su socket ascendente a la dirección del cliente remoto.
• El servidor ascendente recibe la conexión, que parece proceder directamente del cliente remoto.
• El servidor ascendente responde, dirige los paquetes a la dirección del cliente remoto y los enruta a través de NGINX Plus (el router predeterminado).
• La regla de iptables del balanceador de carga NGINX Plus marca estos paquetes y el enrutamiento los entrega localmente.
• NGINX Plus lee la respuesta.
• A continuación, NGINX Plus envía la respuesta al cliente remoto.

El resultado final es que, desde la perspectiva de los servidores ascendentes, las conexiones parecen proceder directamente de los clientes remotos.

Método 2: retorno directo del servidor

Direct Server Return (DSR) es una extensión del concepto de transparencia de IP. En la transparencia de IP, el servidor ascendente recibe paquetes que parecen proceder del cliente remoto. Además, con DSR, el servidor ascendente responde directamente al cliente remoto; los paquetes de respuesta omiten por completo el balanceador de carga.

DSR puede ofrecer una pequeña mejora del rendimiento porque reduce la carga del balanceador de carga, pero presenta varias limitaciones:

• El equilibrador de carga nunca ve los paquetes de respuesta, por lo que no puede detectar si el servidor ascendente está respondiendo o ha fallado.
• El equilibrador de carga no puede inspeccionar una solicitud más allá del primer paquete antes de seleccionar un servidor ascendente, por lo que su capacidad para tomar decisiones de equilibrio de carga (enrutamiento basado en contenido) es muy limitada.
• El equilibrador de carga no puede participar en ningún tipo de negociación ni de procesamiento con estado, como SSL/TLS.
• La mayoría de las demás funciones de los controladores de entrega de aplicaciones (ADC), como el almacenamiento en caché, la multiplexación HTTP y el registro, no son posibles con DSR.

DSR tiene una utilidad limitada para los protocolos TCP y, en cualquier caso, la arquitectura de proxy inverso de NGINX Plus no se puede aplicar a DSR/TCP.

Los protocolos UDP son mucho más sencillos, ya que no presentan ninguna de las características de conexión propias de TCP. Puede configurar NGINX Plus para que admita DSR en protocolos UDP como DNS, lo que puede mejorar el rendimiento. En concreto, DSR permite que NGINX Plus no tenga que mantener abiertos los sockets UDP a la espera de un paquete de respuesta (lo que mejora la escalabilidad) y que los paquetes de respuesta omitan por completo el procesamiento de capa 7 de NGINX Plus (lo que reduce la latencia).

¿En qué se diferencia una configuración DSR de la transparencia de IP?

Existen tres diferencias entre una configuración de transparencia de IP y una configuración DSR para el tráfico UDP:

• NGINX Plus debe suplantar tanto la dirección IP del cliente remoto como el puerto al enviar datagramas a los servidores ascendentes (configuración del puerto proxy_bind).
• NGINX Plus no debe configurarse para esperar datagramas de respuesta de los servidores ascendentes (la directiva proxy_responses 0).
• Es necesario realizar un paso adicional para reescribir la dirección de origen de los datagramas de retorno de modo que coincida con la dirección pública del equilibrador de carga.

Además, NGINX Plus debe configurarse para realizar comprobaciones de estado activas de los servidores ascendentes. NGINX Plus no puede basarse en sus comprobaciones pasivas habituales para verificar si un servidor está en buen estado, ya que no observa los paquetes de respuesta enviados por el servidor.

Creación de un servicio de proxy inverso UDP estándar

Para demostrar el funcionamiento de DSR, cree primero un clúster con balanceo de carga formado por cuatro servidores DNS que respondan con distintas direcciones IP a las consultas del nombre «www.example.com».

Configure una configuración sencilla de proxy inverso que distribuya la carga entre los servidores DNS:

# in the 'stream' context
server {
    listen 53 udp;

    proxy_responses 1;
    proxy_timeout 1s;
    proxy_pass dns_upstreams;
}

upstream dns_upstreams {
    server 172.16.0.11:53;
    server 172.16.0.12:53;
    server 172.16.0.13:53;
    server 172.16.0.14:53;
}

Las directivas proxy_responses y proxy_timeout implementan una comprobación de estado básica. Si un servidor ascendente no envía 1 respuesta en el plazo de 1 segundo, NGINX Plus considera que el servidor ha fallado y vuelve a intentar la solicitud DNS.

Configure cada servidor DNS para que responda con su propia dirección IP a las consultas de www.example.com:

$TTL   	604800
@           IN          SOA         ns1.example.com. admin.example.com. (
                              2           ; Serial
                         604800           ; Refresh
                          86400           ; Retry
                        2419200           ; Expire
                         604800 )         ; Negative Cache TTL

example.com.    IN      NS      ns1.example.com.

ns1             IN      A       172.16.0.11
www             IN      A       172.16.0.11

Las pruebas dejan claro que NGINX Plus distribuye las solicitudes entre los servidores DNS:

$ for i in {1..4} ; do dig +short @192.168.99.10 www.example.com ; done
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14

Configuración de NGINX Plus y de los servidores UDP ascendentes para DSR

NGINX Plus R10 y versiones posteriores (y NGINX Open Source 1.11.2 y versiones posteriores) pueden suplantar tanto la dirección de origen como el puerto del tráfico ascendente. Incluya el parámetro «transparent» en la directiva «proxy_bind»:

proxy_bind $remote_addr:$remote_port transparent;

Esto permite que el servidor ascendente vea la dirección IP de origen completa, de modo que pueda crear datagramas de respuesta que se envíen directamente al cliente remoto.

El servidor ascendente genera paquetes de respuesta («salientes») con el destino IP correcto, pero utiliza su dirección IP local como dirección de origen. La dirección de origen debe reescribirse con la dirección IP y el puerto del balanceador de carga NGINX Plus al que se conectó originalmente el cliente.

Hay dos métodos posibles:

1. NAT del router – Reescriba los paquetes salientes en un router intermedio (como el proxy NGINX Plus)
2. NAT de origen – Reescribe los paquetes salientes cuando abandonan cada servidor DNS ascendente

Ambos métodos utilizan la funcionalidad de NAT sin estado que se configura con el comando tc. Si los servidores ascendentes están conectados directamente a Internet (es decir, si la topología implica que los paquetes de retorno no pasan por un router intermedio que pueda controlar), debe seleccionar el método NAT de origen.

Configuración de NGINX Plus para DSR

Los paquetes de respuesta no se entregan a NGINX Plus, por lo que debe deshabilitar la comprobación de estado que configuró en Creación de un servicio de proxy inverso UDP estándar: modifique la directiva proxy_responses y deshabilite la directiva proxy_timeout. De este modo, NGINX Plus no espera respuestas ni determina que el servidor ascendente ha fallado cuando no las recibe. Al deshabilitar esta comprobación, NGINX Plus también puede reutilizar inmediatamente los recursos de socket.

Incluya también las variables $remote_addr y $remote_port en el primer parámetro de la directiva proxy_bind para que NGINX Plus conserve tanto la dirección como el puerto de origen originales en los datagramas enviados a los servidores ascendentes:

# in the 'stream' context
server {
    listen 53 udp;

    proxy_bind $remote_addr:$remote_port transparent;
    proxy_responses 0;
    #proxy_timeout 1s;
}

NAT del router: reescritura de los paquetes salientes en un router intermedio

Puede reescribir los paquetes salientes en un único router intermedio. Por ejemplo, si los servidores ascendentes se encuentran en una red privada detrás del balanceador de carga NGINX Plus, puede utilizar el balanceador de carga como ruta predeterminada y reescribir los paquetes a medida que se reenvían.

1. Configure cada servidor ascendente para enrutar todo el tráfico saliente a través del servidor NGINX Plus:

# route add default gw nginx-ip-address

1. Configure el servidor NGINX Plus para reenviar el tráfico IP:

# sysctl -w net.ipv4.ip_forward=1

1. Configure el servidor NGINX Plus para realizar una reescritura NAT sin estado:

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.12 match ip sport 53 action nat egress 172.16.0.12 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.13 match ip sport 53 action nat egress 172.16.0.13 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.14 match ip sport 53 action nat egress 172.16.0.14 192.168.99.10

1. Asegúrese de seleccionar la interfaz de salida adecuada y las direcciones IP correspondientes de cada servidor ascendente.

Para obtener más información sobre NAT sin estado, consulte la página del manual de tc nat man page. En función de su configuración, es posible que pueda reducir los comandos tc filter a uno solo mediante el uso de máscaras CIDR para los parámetros src y egress old.

Para mostrar la configuración actual de tc filter, ejecute este comando:

# tc filter show dev eth0

NAT de origen – Reescritura de los paquetes de salida en cada servidor ascendente

Si puede configurar la red en los servidores ascendentes, especialmente si están conectados directamente a Internet, puede utilizar la siguiente configuración. Debe aplicarla a cada servidor ascendente.

Configure cada servidor ascendente para realizar una reescritura NAT sin estado:

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10

Asegúrese de seleccionar la interfaz y las direcciones IP adecuadas en cada servidor ascendente.

Prueba de la configuración de DSR

Para probar la configuración, envíe solicitudes DNS al balanceador de carga NGINX Plus y compruebe que se distribuyan entre los servidores ascendentes.

DSR no tiene efectos visibles de forma directa. Puede estar seguro de que funciona si ha utilizado la directiva proxy_responses 0 para configurar NGINX Plus de modo que no espere paquetes de respuesta y, aun así, sus clientes DNS reciben respuestas con equilibrio de carga. También puede observar el flujo de paquetes mediante tcpdump, tal como se describe más adelante en Solución de problemas.

Resumen: ¿Cómo funciona la configuración de DSR?

• NGINX Plus recibe un datagrama UDP de un cliente remoto (192.168.99.1:puerto).
• NGINX Plus toma una decisión de balanceo de carga y selecciona un servidor ascendente (por ejemplo, 172.16.0.11) en el que escribir el contenido del datagrama. Antes de conectarse, NGINX Plus vincula el extremo local del socket ascendente a la dirección IP y al puerto del cliente remoto.
• El servidor ascendente recibe el datagrama enviado por NGINX Plus, que aparentemente procede directamente de la dirección y el puerto del cliente remoto.
• El servidor ascendente responde enviando datagramas al cliente remoto. El servidor ascendente establece como dirección IP y puerto de origen de los datagramas de respuesta su propia dirección IP y puerto locales.
• La dirección IP de origen (y el puerto, si es necesario) se reescribe mediante el servidor ascendente (la configuración de NAT de origen) o un router intermedio (la configuración de NAT de router).
• El cliente remoto recibe los datagramas, dirigidos a la 4-tupla correcta (direcciones IP y puertos de origen y destino).
• NGINX Plus no espera recibir ningún datagrama de respuesta y cierra inmediatamente el socket ascendente.

El resultado final es que los paquetes de respuesta omiten el procesamiento de la capa 7 en NGINX Plus y se envían directamente al cliente remoto.

Solución de problemas

Si la transparencia de IP o DSR no funcionan según lo previsto, siga estas recomendaciones para investigar las posibles causas:

Ejecutar como root

Compruebe que los procesos de trabajo de NGINX Plus estén configurados para ejecutarse como root. De lo contrario, cuando NGINX Plus intente vincular el socket a una dirección no local, verá en el registro de errores un mensaje similar al siguiente:

setsockopt(IP_TRANSPARENT) failed (1: Operation not permitted) while connecting to upstream, client: 192.168.99.1, server: , request: "GET / HTTP/1.1", upstream: "http://172.16.0.11:80/", host: "192.168.99.10"

Prueba con ping

Compruebe que puede hacer ping a los clientes y servidores desde el proxy NGINX Plus. Los servidores ascendentes no pueden hacer ping a las direcciones IP de clientes remotos a menos que primero cree la configuración de enrutamiento necesaria y configure el intermediario NGINX Plus para que reenvíe los paquetes.

Sin rangos de direcciones IP superpuestos

Asegúrese de que las subredes IP utilizadas por los clientes remotos no estén conectadas directamente a los servidores ascendentes. Si lo están, es probable que surjan dos problemas:

• La protección de «filtrado de ruta inversa» de Linux podría rechazar silenciosamente los paquetes de NGINX Plus porque la dirección IP de origen está asociada a una subred de una interfaz diferente.
• Los paquetes de retorno no utilizan la ruta predeterminada, sino que se envían directamente al cliente remoto conectado localmente.

Usa tcpdump en todas partes

A medida que vaya completando la configuración y probando cada paso intermedio, ejecute tcpdump continuamente en todos y cada uno de los servidores para comprobar que, en cada etapa, los paquetes se envían a los puntos de conexión correctos y se reciben desde ellos:

$ sudo tcpdump -i any -n tcp port 80

Investigue cualquier comportamiento inusual mediante las comprobaciones que se indican a continuación.

Comprobar las tablas de enrutamiento

Compruebe detenidamente las tablas de enrutamiento de cada servidor, prestando especial atención a los servidores ascendentes:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth2
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

¿Hay alguna ruta inesperada? ¿Puede confirmar que todos los paquetes del flujo se enrutarán al destino correcto? Recuerde que, en las configuraciones de iptables y NAT del router, todos los paquetes salientes deben enrutarse a través del proxy intermedio NGINX Plus.

Paquetes perdidos

Si los paquetes se descartan inesperadamente (tcpdump muestra que un equipo los envía, pero otro no los recibe), el filtrado de ruta inversa podría ser el causante silencioso. Para desactivar temporalmente el filtrado de ruta inversa, ejecute el siguiente comando:

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f ; done

Permitir que los servidores ascendentes accedan a servidores externos

Si sus servidores ascendentes se encuentran en una red privada y utilizan NGINX Plus (u otro servidor) como puerta de enlace predeterminada, puede que desee configurar la puerta de enlace para permitir que los servidores ascendentes accedan a hosts externos (Internet).

Debe habilitar el reenvío de IP para que la puerta de enlace pueda reenviar paquetes desde los servidores ascendentes; el reenvío de IP suele estar deshabilitado de forma predeterminada. Si los servidores no tienen direcciones IP enrutables (utilizan direcciones privadas como 172.16.0.0/24), también debe configurar el enmascaramiento de IP en las interfaces externas del servidor de puerta de enlace:

# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Compruebe que puede hacer ping a un servidor externo desde su servidor de origen interno:

root@dev1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=6.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=5.49 ms
^C

Para mostrar la configuración actual de reenvío, enrutamiento y iptables nat, ejecute los tres comandos siguientes:

# sysctl net.ipv4.ip_forward
# route -n
# iptables -t nat -L

Obtener asistencia de NGINX

La configuración de la transparencia de IP o del retorno directo del servidor es compleja, y otros dispositivos de red intermedios podrían afectar a la implementación al descartar o modificar los paquetes. Si necesita ayuda, el equipo de Servicios profesionales de NGINX está a su disposición.

Descubra por sí mismo la transparencia de IP y DSR con NGINX Plus: comience hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Owen GarrettDirector sénior de Gestión de Producto

Más artículos de Owen Garrett