Mi firewall funciona bien: la conexión de Internet se reenvía a un servidor NGINX, que luego se distribuye en consecuencia y el servidor de aplicaciones funciona correctamente excepto los LOG internos.
El problema al que me enfrento es con respecto a la IP que recibe nuestro servidor de aplicaciones: no son la "IP del cliente", sino que actualmente son la IP de NGINX.
Considere esta red: IP 1 del cliente, IP 2 del firewall, IP 3 de NGINX, IP 4 del servidor web.
En el firewall vemos que los paquetes se reenvían al NGINX, pero en el NGINX tcpdump
vemos conexiones entrantes desde el propio NGINX IP 3 en lugar de la fuente original IP 1.
El punto es que en los LOG del servidor web vemos nuestras conexiones de entrada como IP 3, lo esperado es IP 1.
¿Es una mala configuración con el firewall o NGINX? ¿Alguna idea sobre cómo solucionar esto?
Configuración actual ( /etc/nginx/sites-enabled/app.domain.com
):
...
location ^~ / {
proxy_pass http://10.0.0.11;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
...
Respuesta1
Ésta es una operación normal. Cuando nginx es un proxy inverso, abre una conexión al destino final y realiza un proxy desde el cliente al servidor de aplicaciones. La IP de origen no puede ser otra cosa que la dirección IP de nginx; de lo contrario, la conexión TCP no funcionaría.
Debe configurar el servidor de aplicaciones para utilizar la dirección IP especificada en X-Real-IP
el encabezado en lugar de la dirección IP de la conexión TCP.
Respuesta2
La solución para este caso fue cambiar el código C# como se muestra a continuación. No se realizaron cambios en el firewall o nginx.
var userIP = Request.ServerVariables["HTTP_X_FORWARDED_FOR"];
Intentos fallidos anteriores:
var userIP = Request.ServerVariables["X_FORWARDED_FOR"];
var userIP = Request.ServerVariables["X-REAL-IP"];
var userIP = Request.ServerVariables["REMOTE_ADDR"];
var userIP = Request.UserHostAddress;
Gracias a todos los contribuyentes que ayudaron a aclarar que el problema no estaba en el firewall ni en la configuración de nginx.