☰

Módulo de acceso NGINX y DNS interno: Cómo permitir solo clientes locales

tag-icon • tag-icon nginx reverse-proxy internal-dns
Módulo de acceso NGINX y DNS interno: Cómo permitir solo clientes locales

Busqué en serverfault pero no pude encontrar una respuesta a esto. Tal vez simplemente no sé la palabra clave correcta o se trata de un malentendido conceptual. ¡Cualquier ayuda sería apreciada!

La situación:

  1. Mis servicios locales se ejecutan detrás de un proxy inverso NGINX
  2. Uso unLAN DNS en el enrutador (Draytek)para resolver solicitudes locales a *.example.com directamente a mi servidor local (192.168.1.2).

Incluso si no hay conexión a Internet, los dominios se resolverán en el servidor local y todos los servicios serán accesibles. Por eso uso el DNS de LAN. Hasta ahora, todo bien.

Ahora quiero permitir que solo los clientes locales accedan a ciertos servicios usando elMódulo de acceso NGINXcon:

allow 192.168.1.0/24;
deny all;

Pero NGINX solo ve la IP pública del enrutador en lugar de la IP del cliente (192.168.1.100) y, por lo tanto, se rechaza cada solicitud:

[...] access forbidden by rule, client: 123.123.123.123, server: service.example.de, request: [...]"

Mi pregunta es:

¿Cómo puedo distinguir entre clientes locales y remotos en NGINX en este escenario?

Enlace al diagrama de red

Respuesta1

Primero una suposición/condición, que es verificar si su enrutador agrega elX-reenviado-paraencabezado o algo similar (mantiene un seguimiento de la IP real del cliente)

Primero debe resolver la IP del cliente, a través dengx_http_realip_module

La configuración de ejemplo proporcionada allí:

set_real_ip_from  192.168.1.0/24;
set_real_ip_from  192.168.2.1;
set_real_ip_from  2001:0db8::/32;
real_ip_header    X-Forwarded-For;
real_ip_recursive on;

Con esto, la IP utilizada para las comprobaciones de acceso debe ser la correcta (cliente real).

Una advertencia es que con dicha configuración, no se pueden realizar intentos de agregar el enrutador al encabezado X-Fordered-For.automáticamentecon proxy_add_x_forwarded_for, ya que la IP agregada habrá sido alterada por la directiva anterior. Ese caso específico ha sido discutidoen el desbordamiento de la pila

información relacionada