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

Esta publicación de blog describe cómo configurar NGINX Open Source y NGINX Plus como un proxy transparente para el tráfico a servidores ascendentes. Explica cómo se puede utilizar un proxy transparente para falsificar la dirección IP de origen de los paquetes para implementar la transparencia IP, y cómo se puede implementar un modo de equilibrio de carga llamado 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 . Por el bien de la brevedad, nos referiremos únicamente a NGINX Plus.

Editor: Esta es la quinta de una serie de publicaciones de blog que exploran en profundidad las nuevas características de NGINX Plus R10.

• Autenticación de clientes API con JWT y NGINX Plus
• NGINX Plus R10 aprovecha la potencia de IBM
• Autenticación de usuarios en aplicações existentes con OpenID Connect y NGINX Plus
• Uso del módulo JavaScript de NGINX para la transición progresiva de clientes a un nuevo servidor
• Transparencia de IP y retorno directo al servidor con NGINX y NGINX Plus como proxy transparente (esta publicación)

Asegúrese también de consultar el seminario web a pedido, ¿Qué hay de nuevo en NGINX Plus R10?

resumen

NGINX Plus funciona como un proxy inverso de capa 7. Esto permite que NGINX Plus aplique una serie de optimizaciones y mejoras a las solicitudes de red que administra.

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

Existen soluciones alternativas efectivas para el tráfico HTTP y HTTPS, utilizando el encabezado HTTP X-Forwarded-For o el protocolo PROXY . Este artículo describe dos métodos adicionales, que se aplican al tráfico TCP y UDP:

• La transparencia de IP garantiza que los servidores ascendentes observen que cada conexión se origina en el cliente remoto que la inició. Es aplicable a protocolos basados en TCP y UDP.
• El retorno directo del servidor (DSR) también organiza que las respuestas de los servidores ascendentes vayan directamente a los clientes remotos y eviten el equilibrador de carga intermedio. Es aplicable a protocolos basados en UDP y se puede implementar realizando NAT (traducción de dirección de red) en el servidor de origen o en un enrutador intermedio.

Es complejo implementar y solucionar problemas de Transparencia IP y DSR. Implemente estas configuraciones solo si el modo de operación de proxy inverso estándar no es suficiente para su aplicação o servicio.

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

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

1. Los clientes remotos realizan conexiones TCP o envían datagramas UDP directamente al proxy inverso NGINX Plus en su dirección IP y puerto publicados. NGINX Plus finaliza la conexión TCP o la sesión UDP y lee los datos solicitados en su interior.
2. Luego, NGINX Plus realiza una nueva conexión ( o reutiliza una conexión inactiva existente ) al servidor ascendente seleccionado (con equilibrio de carga).
3. Cuando NGINX Plus escribe 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, escribe datos en la dirección IP interna de NGINX Plus.
5. NGINX Plus recibe los datos de respuesta en la conexión del lado ascendente. Puede procesar o modificar la respuesta (por ejemplo, aplicar compresión a una respuesta HTTP).
6. Luego, NGINX Plus escribe los datos de respuesta en la conexión del lado del cliente.

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

Beneficios y limitaciones del modo proxy inverso de capa 7

El modo de operación de proxy inverso de capa 7 genera importantes mejoras de rendimiento y eficiencia para el tráfico HTTP y TCP (incluidas optimizaciones de TCP, almacenamiento en búfer y reutilización de keepalive de HTTP). Esto supone un desafío si el servidor ascendente necesita determinar la verdadera dirección IP de origen de la conexión o sesión para fines tales como autenticación y control de acceso, limitación de velocidad y registro.

Para algunos protocolos, NGINX Plus puede usar el encabezado HTTP X-Forwarded-For o el protocolo PROXY para proporcionar la dirección IP de origen a los servidores ascendentes. Esta publicación describe dos métodos adicionales, que son posibles gracias al parámetro transparente de la directiva proxy_bind , que se introdujo en NGINX Plus Release 10 (R10)<.htmla>.

Método 1: Transparencia de propiedad intelectual

La intención de Transparencia IP es ocultar la presencia del proxy inverso para que el servidor de origen observe que los paquetes IP se originan en la dirección IP del cliente. La transparencia IP se puede utilizar 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 equilibrio de carga de cuatro servidores web que responden con información de conexión simple.

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

   # en el contexto 'http'
   servidor {
   escuchar 80;
   
   ubicación / {
   contraseña_proxy http://http_upstreams;
   }
   }
   
   subida http_upstreams {
   servidor 172.16.0.11;
   servidor 172.16.0.12;
   servidor 172.16.0.13;
   servidor 172.16.0.14;
   }
   

2. Para confirmar que los servidores ascendentes observan que las conexiones se originan desde el balanceador de carga NGINX Plus, configure un servidor web NGINX Plus en cada uno de ellos cuatro (172.16.0.11 a 172.16.01.14) con un servidor virtual simple que devuelva información sobre la conexión, como:

   # en el contexto 'http'
   servidor {
   escuchar 80;
   
   ubicación / {
   devolver 200 "Hola desde $nombredehost. Se conectó desde $remote_addr:$remote_port a $server_addr:$server_port\n";
   }
   }
   

Cuando probamos esta configuración, los upstreams informan que las conexiones se originan desde la dirección IP local NGINX Plus (172.16.0.1):

$ for i in {1..4}; hacer curl http://192.168.99.10 ; hecho Hola desde dev1. Te conectaste desde 172.16.0.1:42723 a 172.16.0.11:80 Hola desde dev2. Te conectaste desde 172.16.0.1:39117 a 172.16.0.12:80 Hola desde dev3. Te conectaste desde 172.16.0.1:54545 a 172.16.0.13:80 Hola desde dev4. Te conectaste desde 172.16.0.1:57020 a 172.16.0.14:80

Configuración de NGINX Plus y sus upstreams para la transparencia de IP

NGINX Plus R10 y posteriores (y NGINX Open Source 1.11.0 y posteriores) pueden falsificar la dirección de origen del tráfico ascendente. Incluya el parámetro transparente en la directiva proxy_bind . Lo más común es configurar la dirección de origen como la del cliente remoto:

proxy_bind $dirección_remota transparente;

Sin embargo, este simple paso genera un desafío importante, ya que es necesario garantizar que el tráfico de respuesta (salida) 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. Luego, 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 raíz , de modo que puedan vincular sockets ascendentes a direcciones arbitrarias.

   En el contexto principal (de nivel superior) en /etc/nginx/nginx.conf , incluya la directiva de usuario para establecer el ID de los procesos de trabajo de NGINX Plus en root :

   # en el contexto 'principal'
   # 'user daemon' es el valor predeterminado; cámbielo a 'user root' con proxy_bind transparente
   user root;
   

2. En el balanceador de carga NGINX Plus , asegúrese de que cada conexión se origine desde la dirección del cliente remoto.

   Agregue la directiva proxy_bind con el parámetro transparente a la configuración del servidor virtual:

   # en el contexto 'http'
   servidor {
   escuchar 80;
   
   ubicación / {
   enlace_proxy $dirección_remota transparente;
   contraseña_proxy http://http_upstreams;
   }
   }
   

3. En el balanceador de carga NGINX Plus , configure iptables para capturar los paquetes de retorno de los servidores ascendentes y enviarlos a NGINX Plus.

   En este ejemplo, ejecutamos los comandos iptables e ip rule para capturar todo el tráfico TCP en el puerto 80 desde los servidores representados por el rango de IP 172.16.0.0/28:

   # regla ip agregar fwmark 1 búsqueda 100 # ruta ip agregar local 0.0.0.0/0 dev lo tabla 100 # iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff
   

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

   # iptables -t mangle -L Cadena PREROUTING (política ACCEPT) objetivo prot opt origen destino MARK tcp -- 172.16.0.0/28 cualquier lugar tcp spt:http MARK set 0x1 Cadena INPUT (política ACCEPT) objetivo prot opt origen destino Cadena FORWARD (política ACCEPT) objetivo prot opt origen destino Cadena OUTPUT (política ACCEPT) objetivo prot opt origen destino Cadena POSTROUTING (política ACCEPT) objetivo prot opt origen destino
   

4. 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 preexistente y configure la ruta predeterminada para que sea la dirección IP del proxy inverso/balanceador de carga NGINX Plus. Tenga en cuenta que esta dirección IP debe estar en la misma subred que una de las interfaces del servidor ascendente.

   # ruta del gw predeterminado 10.0.2.2 # ruta agregar gw predeterminado 172.16.0.1
   

   Compruebe que la tabla de enrutamiento tenga sentido:

   # route -n Tabla de enrutamiento IP del kernel Destino Puerta de enlace Máscara de gen Banderas Métrica Ref. Uso 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
   

   Si sus servidores ascendentes necesitan poder conectarse a servidores externos, también necesita configurar la nueva puerta de enlace NGINX Plus para reenviar y enmascarar el tráfico: consulte Cómo habilitar servidores ascendentes para llegar a servidores externos a continuación.

Prueba de la configuración de transparencia de IP

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

$ for i in {1..4}; hacer curl http://192.168.99.10 ; hecho Hola desde dev1. Te conectaste desde 192.168.99.1:60729 a 172.16.0.11:80 Hola desde dev2. Te conectaste desde 192.168.99.1:43070 a 172.16.0.12:80 Hola desde dev3. Te conectaste desde 192.168.99.1:45749 a 172.16.0.13:80 Hola desde dev4. Te conectaste desde 192.168.99.1:46609 a 172.16.0.14:80

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

Si la configuración no funciona, consulte Solución de problemas 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 equilibrio de carga y selecciona un servidor ascendente (por ejemplo, 172.16.0.11) al cual conectarse. Antes de que NGINX Plus se conecte, vincula su socket ascendente a la dirección del cliente remoto.
• El servidor ascendente recibe la conexión, que parece originarse directamente desde el cliente remoto.
• El servidor ascendente responde, dirigiendo los paquetes a la dirección del cliente remoto y enrutándolos a través de NGINX Plus (el enrutador predeterminado).
• La regla iptables en el balanceador de carga NGINX Plus marca estos paquetes y el enrutamiento los entrega localmente.
• NGINX Plus lee la respuesta.
• Luego, NGINX Plus envía la respuesta al cliente remoto.

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

Método 2: Devolución directa del servidor

El retorno directo del servidor (DSR) es una extensión del concepto de transparencia IP. En Transparencia IP, el servidor ascendente recibe paquetes que parecen originarse en el cliente remoto. Con DSR, además el servidor ascendente responde directamente al cliente remoto; los paquetes de retorno pasan por alto completamente el equilibrador de carga.

DSR puede ofrecer un pequeño beneficio en el rendimiento porque reduce la carga en el balanceador de carga, pero conlleva una serie de limitaciones:

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

DSR tiene un uso limitado 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 simples y no tienen la semántica de conexión de TCP. Puede configurar NGINX Plus para admitir DSR para protocolos UDP como DNS, lo que puede ofrecer beneficios en el rendimiento. Específicamente, DSR significa que NGINX Plus no necesita mantener abiertos los sockets UDP a la espera de un paquete de respuesta (lo que mejora la escalabilidad) y los paquetes de respuesta pueden omitir 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 IP?

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

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

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

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

Para demostrar DSR, primero cree un clúster con equilibrio de carga de cuatro servidores DNS que respondan con diferentes direcciones IP para las búsquedas del nombre www.example.com .

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

# en el contexto de 'stream'
servidor {
escuchar 53 udp;

respuestas_proxy 1;
tiempo_de_espera_proxy 1s;
contraseña_proxy dns_upstreams;
}

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

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

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

$TTL 604800
@ EN SOA ns1.ejemplo.com.admin.ejemplo.com. (
2 ; Número de serie
604800 ; Actualizar
86400 ; Reintentar
2419200 ; Caducidad
604800 ) ; Tiempo de vida de caché negativo

ejemplo.com.    EN NS ns1.ejemplo.com.

ns1 EN A 172.16.0.11
www EN A 172.16.0.11

Las pruebas dejan claro que NGINX Plus equilibra la carga de solicitudes entre los servidores DNS:

$ para i en {1..4} ; hacer dig +short @192.168.99.10 www.example.com ; hecho
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14

Configuración de NGINX Plus y sus flujos ascendentes UDP para DSR

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

proxy_bind $dirección_remota:$puerto_remoto transparente;

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

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

Son posibles dos métodos:

1. NAT de enrutador : reescribe los paquetes de salida en un enrutador intermedio (como el proxy NGINX Plus)
2. NAT de origen : reescribe los paquetes de salida a medida que salen de cada servidor DNS ascendente

Ambos métodos utilizan la capacidad NAT sin estado que se configura con el comando tc . Si los servidores ascendentes están conectados directamente a Internet (la topología significa que los paquetes de retorno no se envían a través de un enrutador intermedio que usted pueda controlar), entonces debe seleccionar el método NAT de origen .

Configuración de NGINX Plus para DSR

Los paquetes de respuesta no se envían a NGINX Plus, por lo que debe deshabilitar la verificació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 . Ahora NGINX Plus no espera respuestas y no concluye que el servidor ascendente ha fallado cuando no las recibe. Deshabilitar esta verificación también permite que NGINX Plus reutilice los recursos del socket inmediatamente.

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 de origen original como el puerto de origen en los datagramas enviados a los servidores ascendentes:

# en el contexto de 'transmisión'
servidor {
escuchar 53 udp;

enlace_proxy $dirección_remota:$puerto_remoto transparente;
respuestas_proxy 0;
#tiempo_de_espera_proxy 1 s;
}

NAT de enrutador: reescritura de los paquetes de salida en un enrutador intermedio

Puede reescribir paquetes de salida en un solo enrutador intermedio. Por ejemplo, si los servidores ascendentes están ubicados en una red privada detrás del balanceador de carga NGINX Plus, puede usar 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:

   # ruta agregar gw predeterminado nginx-ip-address
   

2. Configurar el servidor NGINX Plus para reenviar tráfico IP:

   # sysctl -w net.ipv4.ip_forward=1
   

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

   # tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 acción nat egress 172.16.0.11 192.168.99.10 # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 match ip src 172.16.0.12 match ip sport 53 acción nat egress 172.16.0.12 192.168.99.10 # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 match ip src 172.16.0.13 match ip sport 53 acción salida nat 172.16.0.13 192.168.99.10 # filtro tc agregar dev eth0 padre 10: protocolo ip prioridad 10 u32 coincidencia ip origen 172.16.0.14 coincidencia ip deporte 53 acción salida nat 172.16.0.14 192.168.99.10
   

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

Para obtener más información sobre NAT sin estado, consulte la página del manual tc nat . Dependiendo de su configuración, es posible que pueda reducir los comandos de filtro tc a un solo comando mediante el uso de máscaras CIDR para los parámetros antiguos src y egress .

Para mostrar la configuración actual del filtro tc , ejecute este comando:

# filtro tc mostrar 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 aplicarse a cada servidor ascendente.

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

# tc qdisc agregar dev eth0 identificador raíz 10: htb # tc filtro agregar dev eth0 padre 10: protocolo ip prioridad 10 u32 coincidencia ip origen 172.16.0.11 coincidencia ip deporte 53 acción nat salida 172.16.0.11 192.168.99.10

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

Prueba de la configuración de DSR

Para probar la configuración, envíe solicitudes DNS al balanceador de carga NGINX Plus y verifique que la carga esté equilibrada entre los servidores ascendentes.

La DSR no tiene efectos directamente visibles. Puede estar seguro de que funciona si ha utilizado proxy_responses0 directiva para configurar NGINX Plus para que no espere paquetes de respuesta, pero sus clientes DNS reciben respuestas con equilibrio de carga. Puede observar más a fondo el flujo de paquetes utilizando tcpdump , como se describe en Solución de problemas a continuación.

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 equilibrio de carga y selecciona un servidor ascendente (por ejemplo, 172.16.0.11) para escribir el contenido del datagrama. Antes de que NGINX Plus se conecte, vincula el lado 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 se origina directamente desde la dirección y el puerto del cliente remoto.
• El servidor ascendente responde enviando datagramas al cliente remoto. El servidor ascendente establece la dirección IP de origen y el puerto de los datagramas de respuesta en 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 NAT de origen ) o un enrutador intermedio (la configuración NAT del enrutador ).
• El cliente remoto recibe los datagramas, direccionados con la tupla de 4 correcta (direcciones IP y puertos de origen y destino).
• NGINX Plus no espera observar ningún datagrama de respuesta y cierra el socket ascendente inmediatamente.

El resultado neto es que los paquetes de respuesta pasan por alto el procesamiento de capa 7 en NGINX Plus y van directamente al cliente remoto.

Solución de problemas

Si la transparencia de IP o DSR no funcionan como se espera, utilice las siguientes sugerencias para investigar las posibles causas:

Ejecutar como root

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

setsockopt(IP_TRANSPARENT) falló (1: (Operación no permitida) durante la conexión al upstream, cliente: 192.168.99.1, servidor: , solicitud: "GET / HTTP/1.1", origen: "http://172.16.0.11:80/", host: "192.168.99.10"

Prueba con ping

Verifique que puede hacer ping a 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 reenviar paquetes.

Sin rangos de IP superpuestos

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

• La protección de “filtrado de ruta inversa” de Linux podría rechazar silenciosamente paquetes de NGINX Plus porque la dirección IP de origen está asociada con una subred en una interfaz diferente.
• Los paquetes de retorno no utilizan la ruta predeterminada y, en su lugar, se envían directamente al cliente remoto conectado localmente.

Utilice tcpdump en todas partes

A medida que crea la configuración y prueba cada paso intermedio, ejecute tcpdump continuamente en todos y cada uno de los servidores para verificar que los paquetes se envíen y reciban en los puntos finales correctos en cada etapa:

$ sudo tcpdump -i any -n tcp puerto 80

Investigue cualquier comportamiento inusual utilizando las comprobaciones que se enumeran a continuación.

Comprobar tablas de enrutamiento

Revise cuidadosamente las tablas de enrutamiento en cada servidor, prestando especial atención a los servidores ascendentes:

# route -n Tabla de enrutamiento IP del kernel Destino Puerta de enlace Máscara de gen Banderas Métrica Ref. Uso 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 rutas inesperadas? ¿Puede confirmar que todos los paquetes del flujo se enrutarán al destino correcto? Recuerde que en las configuraciones de iptables y Router NAT, todos los paquetes de salida deben enrutarse a través del proxy intermedio NGINX Plus.

Paquetes faltantes

Si los paquetes se descartan inesperadamente ( tcpdump muestra que son enviados por una máquina pero no recibidos por otra), el filtrado de ruta inversa es un potencial culpable silencioso. Para deshabilitar temporalmente el filtrado de ruta inversa, ejecute el siguiente comando:

# para f en /proc/sys/net/ipv4/conf/*/rp_filter; hacer echo 0 > $f ; hecho

Habilitar que los servidores ascendentes se comuniquen con servidores externos

Si sus servidores ascendentes residen en una red privada y usan NGINX Plus (u otro servidor) como su puerta de enlace predeterminada, es posible que desee configurar la puerta de enlace para permitir que los servidores ascendentes lleguen a hosts externos (de 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 generalmente está deshabilitado de manera predeterminada. Si los servidores no tienen direcciones IP enrutables (usan 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 MASCARADA

Verifique que puede hacer ping a un servidor externo desde su servidor ascendente interno:

root@dev1:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes de datos.
64 bytes desde 8.8.8.8: icmp_seq=1 ttl=61 tiempo=6,72 ms 64 bytes desde 8.8.8.8: icmp_seq=2 ttl=61 tiempo=5,49 ms ^C

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

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

Obtener asistencia de NGINX

La configuración para Transparencia IP o Retorno directo del servidor es compleja y otros dispositivos de red intermedios pueden afectar la implementación al descartar o reescribir paquetes. Si necesita ayuda, el equipo de Servicios Profesionales de NGINX está listo para ayudarlo.

Explore la transparencia de IP y DSR con NGINX Plus usted mismo: comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .