☰

NGINX 액세스 모듈 및 내부 DNS: 로컬 클라이언트만 허용하는 방법

tag-icon • tag-icon nginx reverse-proxy internal-dns
NGINX 액세스 모듈 및 내부 DNS: 로컬 클라이언트만 허용하는 방법

serverfault를 통해 검색했지만 이에 대한 답변을 찾을 수 없습니다. 어쩌면 제가 올바른 키워드를 모르고 있거나 개념적인 오해일 수도 있습니다. 어떤 도움이라도 주시면 감사하겠습니다!

그 상황:

  1. 내 로컬 서비스가 NGINX 역방향 프록시 뒤에서 실행되고 있습니다.
  2. 나는라우터의 LAN DNS(Draytek)*.example.com에 대한 로컬 요청을 내 로컬 서버(192.168.1.2)로 직접 해결합니다.

인터넷 연결이 없더라도 도메인은 로컬 서버로 확인되어 모든 서비스에 액세스할 수 있습니다. 그래서 LAN DNS를 사용합니다. 여태까지는 그런대로 잘됐다.

이제 로컬 클라이언트만 다음을 사용하여 특정 서비스에 액세스하도록 허용하고 싶습니다.NGINX 액세스 모듈와 함께:

allow 192.168.1.0/24;
deny all;

그러나 NGINX는 클라이언트의 IP(192.168.1.100) 대신 라우터의 공용 IP만 확인하므로 모든 요청이 거부됩니다.

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

내 질문은 다음과 같습니다

이 시나리오에서 NGINX에서 로컬 클라이언트와 원격 클라이언트를 어떻게 구별할 수 있습니까?

네트워크 다이어그램 링크

답변1

먼저 라우터가 다음을 추가하는지 확인하는 가정/조건입니다.X-전달-For헤더 또는 이와 유사한 것(실제 클라이언트 IP 추적 유지)

먼저 다음을 통해 클라이언트 IP를 확인해야 합니다.ngx_http_realip_module

여기에 제공된 예제 구성은 다음과 같습니다.

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;

이를 통해 접속 확인에 사용되는 IP는 올바른 IP(실제 클라이언트)여야 합니다.

한 가지 주의할 점은 이러한 구성을 사용하면 X-Forwarded-For 헤더에 라우터를 추가하려는 시도를 수행할 수 없다는 것입니다.자동으로추가된 IP가 이전 지시문에 의해 변경되었기 때문에 Proxy_add_x_forwarded_for를 사용합니다. 해당 특정 사례가 논의되었습니다.스택 오버플로 시

관련 정보