NGINX 및 NGINX Plus를 투명 프록시로 사용한 IP 투명성 및 직접 서버 리턴
이 블로그 게시물에서는 NGINX Open Source와 NGINX Plus를 업스트림 서버로의 트래픽에 대한 투명 프록시로 구성하는 방법을 설명합니다. 패킷의 소스 IP 주소를 스푸핑하여 IP 투명성을 구현하기 위해 투명 프록시를 사용하는 방법과 UDP 트래픽에 대한 Direct Server Return이라는 부하 분산 모드를 구현하는 방법을 설명합니다.
이 게시물의 정보는 NGINX Open Source 와 NGINX Plus 에 모두 적용됩니다. 간결하게 설명하기 위해 NGINX Plus만 언급하겠습니다.
편집자 - 이 글은 NGINX Plus R10의 새로운 기능을 심층적으로 살펴보는 일련의 블로그 게시물 중 다섯 번째입니다.
- JWT 및 NGINX Plus를 사용하여 API 클라이언트 인증
- NGINX Plus R10은 IBM POWER를 활용합니다.
- OpenID Connect 및 NGINX Plus를 사용하여 기존 애플리케이션에 사용자 인증
- NGINX JavaScript 모듈을 사용하여 클라이언트를 점진적으로 새 서버로 전환
- NGINX 및 NGINX Plus를 투명 프록시로 사용한 IP 투명성 및 직접 서버 리턴(이 게시물)
또한 NGINX Plus R10의 새로운 기능을 소개하는 주문형 웨비나도 꼭 확인해 보세요.
요약
NGINX Plus는 레이어 7 역방향 프록시로 작동합니다. 이를 통해 NGINX Plus는 관리하는 네트워크 요청에 다양한 최적화 및 향상을 적용할 수 있습니다.
결과적으로 업스트림(부하 분산) 서버는 모든 트래픽이 NGINX Plus 프록시의 IP 주소에서 발생한다는 것을 관찰합니다. 예를 들어, 인증이나 로깅 목적으로 업스트림 서버가 실제 원본 IP 주소(원격 클라이언트의 주소)를 확인해야 하는 경우 이는 문제가 될 수 있습니다.
HTTP 및 HTTPS 트래픽에는 X-Forwarded-For HTTP 헤더나 PROXY 프로토콜을 사용하는 효과적인 해결 방법이 있습니다. 이 문서에서는 TCP 및 UDP 트래픽에 적용되는 두 가지 추가 방법을 설명합니다.
- IP 투명성은 업스트림 서버에서 각 연결이 이를 시작한 원격 클라이언트에서 시작되었다는 것을 확인하도록 보장합니다. TCP 및 UDP 기반 프로토콜에 적용할 수 있습니다.
- DSR( Direct Server Return )은 업스트림 서버의 응답이 중간 로드 밸런서를 거치지 않고 원격 클라이언트로 직접 전송되도록 합니다. UDP 기반 프로토콜에 적용할 수 있으며 원본 서버나 중간 라우터에서 NAT(네트워크 주소 변환)를 수행하여 구현할 수 있습니다.
| 방법 1 – IP 투명성 | 방법 2a – DSR(라우터 NAT) | 방법 2b – DSR(원본 NAT) | |
|---|---|---|---|
| 지원되는 프로토콜 | TCP 기반 및 UDP 기반 | UDP 기반만 | UDP 기반만 |
| 업스트림 서버에 의한 트래픽 라우팅 | 모든 이탈 트래픽은 NGINX Plus 프록시로 라우팅되고 종료됩니다. | 모든 이탈 트래픽은 중간 NGINX Plus 서버를 통해 라우팅됩니다. | 모든 트래픽이 정상적으로 라우팅되었습니다. |
| 성능 | 표준: 이탈 트래픽은 NGINX Plus 프록시에서 종료됩니다. | 더 나은 점: 이탈 트래픽은 중간 NGINX Plus 서버에서 전달됩니다. | 최고: 이탈 트래픽은 NGINX Plus를 우회하여 원격 클라이언트로 직접 라우팅됩니다. |
| 건강 검진 | 기본적으로 수동, 지원은 활성 | 능동태가 필요하고 수동태는 불가능합니다. | 능동태가 필요하고 수동태는 불가능합니다. |
| 필수 구성 | |||
| NGINX Plus 프록시의 TCP 및 UDP | TCP: 기본적으로 작동합니다 UDP: 프록시 응답 1 |
TCP: 지원되지 않음 UDP: 프록시 응답 0 |
TCP: 지원되지 않음 UDP: 프록시 응답 0 |
| 패킷은 어떻게, 어디에서 처리되나요? | iptables는 NGINX Plus 프록시에서 종료됩니다. |
tc nat은 중간 NGINX Plus 서버에서 다시 작성됩니다. |
tc nat은 업스트림 서버에서 다시 작성됩니다. |
| NGINX Plus 프록시의 네트워킹 구성 | iptables를 사용하여 이탈 패킷 캡처 |
IP 전달 및 무상태 NAT | 없음 |
| 업스트림 서버의 네트워킹 구성 | NGINX Plus를 기본 경로로 지정 | NGINX Plus를 기본 경로로 지정 | 무상태 NAT |
IP 투명성과 DSR을 배포하고 문제를 해결하는 것은 복잡합니다. 표준 역방향 프록시 작동 모드가 애플리케이션이나 서비스에 적합하지 않은 경우에만 이러한 구성을 구현하세요.
소개: 표준 레이어 7 역방향 프록시의 패킷 흐름
패킷을 단순히 전달하는 스위치나 라우터와 달리 NGINX Plus는 레이어 7 역방향 프록시 로 작동합니다. 이 작동 모드에서 NGINX Plus는 원격 클라이언트와 선택된 업스트림 서버 간의 통신을 제어하기 위해 별도의 클라이언트 측과 업스트림 측 TCP 연결(HTTP 및 TCP 트래픽용) 또는 UDP 세션을 관리합니다.
- 원격 클라이언트는 TCP 연결을 만들거나 UDP 데이터그램을 게시된 IP 주소 및 포트에서 NGINX Plus 역방향 프록시로 직접 보냅니다. NGINX Plus는 TCP 연결이나 UDP 세션을 종료하고 그 안에 있는 요청 데이터를 읽습니다.
- NGINX Plus는 선택된 (부하 분산된) 업스트림 서버에 새로운 연결을 만들 거나 기존의 유휴 연결을 재사용합니다 .
- NGINX Plus가 업스트림 서버에 요청을 작성하면 연결은 NGINX Plus의 내부 IP 주소에서 시작됩니다.
- 상위 서버가 요청에 응답하면 NGINX Plus 내부 IP 주소에 데이터를 씁니다.
- NGINX Plus는 업스트림 측 연결에서 응답 데이터를 수신합니다. 응답을 처리하거나 수정할 수 있습니다(예: HTTP 응답에 압축을 적용).
- NGINX Plus는 클라이언트 측 연결에 응답 데이터를 작성합니다.
이 표준 역방향 프록시 작동 모드의 결과로 업스트림 서버는 TCP 및 UDP 트래픽이 로컬 NGINX Plus 프록시에서 시작된다는 것을 관찰합니다.
레이어 7 역방향 프록시 모드의 이점 및 제한 사항
레이어 7 역방향 프록시 모드 작동은 HTTP 및 TCP 트래픽에 상당한 성능 향상과 효율성을 제공합니다(TCP 최적화, 버퍼링, HTTP Keepalive 재사용 포함). 업스트림 서버가 인증 및 액세스 제어, 속도 제한, 로깅과 같은 목적으로 연결 또는 세션의 실제 원본 IP 주소를 확인해야 하는 경우 문제가 됩니다.
일부 프로토콜의 경우 NGINX Plus는 X-Forwarded-For HTTP 헤더나 PROXY 프로토콜을 사용하여 업스트림 서버에 원본 IP 주소를 제공할 수 있습니다. 이 게시물에서는 NGINX Plus 릴리스 10(R10)<.htmla> 에서 도입된 proxy_bind 지시문에 대한 transparent 매개변수를 통해 가능해진 두 가지 추가 방법을 설명합니다.
방법 1: IP 투명성
IP 투명성의 의도는 역방향 프록시의 존재를 숨겨서 원본 서버가 IP 패킷이 클라이언트의 IP 주소에서 시작되었음을 관찰할 수 있도록 하는 것입니다. IP 투명성은 TCP 기반 및 UDP 기반 프로토콜과 함께 사용할 수 있습니다.
NGINX Plus 로드 밸런서에서 HTTP 역방향 프록시 서비스 생성
IP 투명성을 보여주기 위해 먼저 간단한 연결 정보로 응답하는 4개의 웹 서버로 구성된 부하 분산 클러스터를 만듭니다.
업스트림 서버 그룹 전체에 걸쳐 트래픽 부하를 분산하는 간단한 HTTP 가상 서버를 구성합니다.
# 'http' 컨텍스트에서 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; }업스트림 서버에서 연결이 NGINX Plus 부하 분산 장치에서 시작되었음을 확인하려면 4개(172.16.0.11~172.16.01.14) 각각에 NGINX Plus 웹 서버를 구성합니다. 이 서버에는 다음과 같은 연결에 대한 정보를 반환하는 간단한 가상 서버가 포함됩니다.
# 'http' 컨텍스트에서 server { listen 80; location / { return 200 "Hello from $hostname. $remote_addr:$remote_port에서 $server_addr:$server_port로 연결했습니다\n"; } }
이 구성을 테스트하면 업스트림은 연결이 로컬 NGINX Plus IP 주소(172.16.0.1)에서 시작되었다고 보고합니다.
$ for i in {1..4}; do curl http://192.168.99.10 ; done 안녕하세요, dev1입니다. 172.16.0.1:42723에서 172.16.0.11:80에 접속했습니다. 안녕하세요, dev2입니다. 172.16.0.1:39117에서 172.16.0.12:80에 접속했습니다. 안녕하세요, dev3입니다. 172.16.0.1:54545에서 172.16.0.13:80에 접속했습니다. 안녕하세요, dev4입니다. 172.16.0.1:57020에서 172.16.0.14:80으로 연결되었습니다.
IP 투명성을 위한 NGINX Plus 및 업스트림 구성
NGINX Plus R10 이상(및 NGINX Open Source 1.11.0 이상)은 업스트림 트래픽의 소스 주소를 스푸핑할 수 있습니다. proxy_bind 지시문에 transparent 매개변수를 포함합니다. 가장 일반적으로는 소스 주소를 원격 클라이언트의 주소로 설정합니다.
proxy_bind $remote_addr 투명;
하지만 이 간단한 단계는 원격 클라이언트에 대한 응답(송신) 트래픽이 올바르게 처리되는지 확인해야 하기 때문에 상당한 어려움을 겪습니다. 응답 트래픽은 NGINX Plus로 라우팅되어야 하며, NGINX Plus는 업스트림 TCP 연결을 종료해야 합니다. NGINX Plus는 클라이언트 TCP 연결을 통해 원격 클라이언트로 응답 트래픽을 전송합니다.
NGINX Plus 로드 밸런서와 각 업스트림 서버 모두에 여러 가지 구성 변경을 해야 합니다.
NGINX Plus 로드 밸런서에서 작업자 프로세스가
루트로 실행되도록 구성하여 업스트림 소켓을 임의의 주소에 바인딩할 수 있도록 합니다./etc/nginx/nginx.conf 의 기본(최상위) 컨텍스트에서 NGINX Plus 작업자 프로세스의 ID를
root로 설정하는사용자지시문을 포함합니다.# 'main' 컨텍스트에서 # 'user daemon'이 기본값입니다. 투명한 proxy_bind를 사용하여 'user root'로 변경하세요 user root;NGINX Plus 로드 밸런서에서 각 연결이 원격 클라이언트 주소에서 시작되는지 확인하세요.
가상 서버 구성에
transparent매개변수가 포함된proxy_bind지시문을 추가합니다.# 'http' 컨텍스트에서 server { listen 80; location / { proxy_bind $remote_addr transparent; proxy_pass http://http_upstreams; } }NGINX Plus 로드 밸런서에서
iptables를구성하여 업스트림 서버에서 반환 패킷을 캡처하여 NGINX Plus로 전달합니다.이 예제에서는
iptables및iprule명령을 실행하여 IP 범위 172.16.0.0/28로 표현되는 서버에서 포트 80의 모든 TCP 트래픽을 캡처합니다.# ip 규칙에 fwmark 1 조회 100을 추가합니다. # ip 경로에 로컬 0.0.0.0/0 dev lo 테이블 100을 추가합니다. # iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff를 추가합니다.다음 명령을 실행하여
iptablesmangle 테이블에서 현재 구성을 나열(-L)합니다.# iptables -t mangle -L 체인 사전 라우팅(정책 수락) 대상 보호 옵션 소스 대상 MARK tcp -- 172.16.0.0/28 어디든 tcp spt:http MARK 설정 0x1 체인 입력(정책 수락) 대상 보호 옵션 소스 대상 체인 FORWARD(정책 수락) 대상 보호 옵션 소스 대상 체인 출력(정책 수락) 대상 보호 옵션 소스 대상 체인 POSTROUTING(정책 수락) 대상 보호 옵션 소스 대상업스트림 서버에서 모든 반환 트래픽이 NGINX Plus로 전달되도록 라우팅을 구성합니다.
각 업스트림 서버에서 기존 기본 경로를 제거하고 기본 경로를 NGINX Plus 부하 분산 장치/역방향 프록시의 IP 주소로 구성합니다. 이 IP 주소는 업스트림 서버의 인터페이스 중 하나와 동일한 서브넷에 있어야 합니다.
# route del default gw 10.0.2.2 # route add default gw 172.16.0.1라우팅 테이블이 합리적인지 확인하세요.
# route -n 커널 IP 라우팅 테이블 대상 게이트웨이 Genmask 플래그 메트릭 참조 사용 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업스트림 서버가 외부 서버에 연결해야 하는 경우 트래픽을 전달하고 위장하도록 새 NGINX Plus 게이트웨이도 구성해야 합니다. 아래 업스트림이 외부 서버에 도달하도록 활성화를 참조하세요.
IP 투명성 구성 테스트
이제 NGINX Plus에 요청을 보내 구성을 테스트할 수 있습니다. 업스트림 서버에서 직접 라우팅할 수 없는 원격 IP 주소에서 요청을 보내고 있는지 확인하세요.
$ for i in {1..4}; do curl http://192.168.99.10 ; done 안녕하세요, dev1입니다. 192.168.99.1:60729에서 172.16.0.11:80으로 접속했습니다. 안녕하세요, dev2입니다. 192.168.99.1:43070에서 172.16.0.12:80으로 접속했습니다. 안녕하세요, dev3입니다. 192.168.99.1:45749에서 172.16.0.13:80으로 접속했습니다. 안녕하세요, dev4입니다. 192.168.99.1:46609에서 172.16.0.14:80으로 연결되었습니다.
이제 연결이 NGINX Plus 부하 분산 장치의 로컬 주소가 아닌 원격 클라이언트의 IP 주소(192.168.99.1)에서 시작되는 것으로 보입니다.
구성이 작동하지 않는 경우, 아래의 문제 해결을 참조하세요.
요약: IP 투명성 구성은 어떻게 작동합니까?
- NGINX Plus는 원격 클라이언트(192.168.99.1)로부터 HTTP 요청을 수신합니다.
- NGINX Plus는 부하 분산 결정을 내리고 연결할 업스트림 서버(예: 172.16.0.11)를 선택합니다. NGINX Plus가 연결되기 전에 업스트림 소켓을 원격 클라이언트의 주소에 바인딩합니다.
- 업스트림 서버는 원격 클라이언트에서 직접 온 것처럼 보이는 연결을 수신합니다.
- 업스트림 서버는 응답하여 패킷을 원격 클라이언트 주소로 보내고 NGINX Plus(기본 라우터)를 통해 라우팅합니다.
- NGINX Plus 로드 밸런서의
iptables규칙은 이러한 패킷을 표시하고 라우팅을 통해 이를 로컬로 전달합니다. - NGINX Plus가 응답을 읽습니다.
- 그러면 NGINX Plus가 원격 클라이언트에 응답을 보냅니다.
결과적으로, 업스트림 서버의 관점에서 볼 때 연결은 원격 클라이언트에서 직접 시작된 것처럼 보입니다.
방법 2: 직접 서버 반환
DSR(Direct Server Return)은 IP 투명성 개념의 확장입니다. IP 투명성에서 업스트림 서버는 원격 클라이언트에서 시작된 것처럼 보이는 패킷을 수신합니다. DSR을 사용하면 업스트림 서버가 원격 클라이언트에 직접 응답하고, 반환 패킷은 로드 밸런서를 완전히 우회합니다.
DSR은 로드 밸런서의 부하를 줄여주기 때문에 약간의 성능상의 이점을 제공할 수 있지만 다음과 같은 몇 가지 제한이 있습니다.
- 부하 분산 장치는 반환 패킷을 볼 수 없으므로 업스트림 서버가 응답하는지 아니면 실패했는지 감지할 수 없습니다.
- 부하 분산 장치는 업스트림을 선택하기 전에 첫 번째 패킷을 넘어서는 요청을 검사할 수 없으므로 부하 분산 결정(콘텐츠 기반 라우팅)을 내리는 기능이 매우 제한적입니다.
- 로드 밸런서는 SSL/TLS와 같은 어떠한 형태의 협상이나 상태 처리에도 참여할 수 없습니다.
- 캐싱, HTTP 멀티플렉싱, 로깅과 같은 대부분의 다른 ADC(애플리케이션 전송 컨트롤러) 기능은 DSR에서는 사용할 수 없습니다.
DSR은 TCP 프로토콜에 대해 제한적으로 사용되며 어떤 경우에도 NGINX Plus의 역방향 프록시 아키텍처는 DSR/TCP에 적용될 수 없습니다.
UDP 프로토콜은 TCP의 연결 의미론이 전혀 없고 훨씬 간단합니다. DNS와 같은 UDP 프로토콜에 대해 DSR을 지원하도록 NGINX Plus를 구성할 수 있으며, 이를 통해 성능 이점을 얻을 수 있습니다. 구체적으로 DSR은 NGINX Plus가 응답 패킷을 기대하여 UDP 소켓을 열어 둘 필요가 없다는 것을 의미하며(확장성이 향상됨), 응답 패킷은 NGINX Plus의 레이어 7 처리를 완전히 우회할 수 있습니다(지연 시간이 감소함).
DSR 구성은 IP 투명성과 어떻게 다릅니까?
UDP 트래픽의 IP 투명성 구성과 DSR 구성 사이에는 세 가지 차이점이 있습니다.
- NGINX Plus는 업스트림 서버로 데이터그램을 보낼 때 원격 클라이언트의 IP 주소 와 포트를 모두 스푸핑해야 합니다(
proxy_bind포트 구성). - NGINX Plus는 업스트림 서버(
proxy_responses)에서 응답 데이터그램을 기대하도록 구성해서는 안 됩니다.0지령). - 반환 데이터그램의 소스 주소를 로드 밸런서의 공개 주소와 일치하도록 다시 작성하려면 추가 단계가 필요합니다.
또한, NGINX Plus는 업스트림 서버에 대해 활성 상태 검사를 수행하도록 구성되어야 합니다. NGINX Plus는 서버가 정상인지 확인하기 위해 일반적인 수동 검사에 의존할 수 없습니다. NGINX Plus는 서버에서 보낸 응답 패킷을 관찰하지 않기 때문입니다.
표준 UDP 역방향 프록시 서비스 생성
DSR을 시연하려면 먼저 www.example.com 이라는 이름을 조회할 때 서로 다른 IP 주소로 응답하는 4개의 DNS 서버로 구성된 부하 분산 클러스터를 만듭니다.
DNS 서버 간 부하 분산을 위한 간단한 역방향 프록시 구성을 구성합니다.
# 'stream' 컨텍스트에서
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;
}
proxy_responses 및 proxy_timeout 지시어는 기본적인 상태 검사를 구현합니다. 업스트림 서버가 1초 이내에 응답을 1개도 보내지 않으면 NGINX Plus는 서버에 오류가 발생한 것으로 간주하고 DNS 요청을 다시 시도합니다.
각 DNS 서버가 www.example.com 을 조회할 때 고유한 IP 주소로 응답하도록 구성합니다.
$TTL 604800
@ IN SOA ns1.example.com.admin.example.com. (
2 ; 일련번호
604800 ; 새로 고침
86400 ; 재시도
2419200 ; 만료
604800 ) ; 부정 캐시 TTL
example.com. IN NS ns1.example.com.
ns1 IN A 172.16.0.11
www IN A 172.16.0.11
테스트를 통해 NGINX Plus가 DNS 서버 간 요청의 부하를 분산하고 있음이 분명해졌습니다.
$ i in {1..4} ; dig +short @192.168.99.10 www.example.com ; 완료
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14
DSR을 위한 NGINX Plus 및 UDP 업스트림 구성
NGINX Plus R10 이상(및 NGINX Open Source 1.11.2 이상)은 업스트림 트래픽의 소스 주소와 포트를 모두 스푸핑할 수 있습니다. proxy_bind 지시문에 transparent 매개변수를 포함합니다.
프록시_바인딩 $원격_주소:$원격_포트 투명;
이를 통해 업스트림 서버는 전체 소스 IP 주소를 관찰하여 원격 클라이언트에 직접 전송되는 응답 데이터그램을 구성할 수 있습니다.
업스트림 서버는 올바른 IP 대상을 포함하여 응답("송신") 패킷을 생성하지만 로컬 IP 주소를 소스 주소로 사용합니다. 소스 주소는 클라이언트가 원래 연결했던 NGINX Plus 로드 밸런서의 IP 주소와 포트로 다시 작성해야 합니다.
두 가지 방법이 가능합니다.
- 라우터 NAT – 중간 라우터(예: NGINX Plus 프록시)에서 송신 패킷을 다시 작성합니다.
- 원점 NAT – 각 업스트림 DNS 서버를 떠날 때 이탈 패킷을 다시 작성합니다.
두 방법 모두 tc 명령으로 구성하는 상태 비저장 NAT 기능을 사용합니다. 업스트림 서버가 인터넷에 직접 연결되어 있는 경우(토폴로지는 반환 패킷이 제어할 수 있는 중간 라우터를 통해 전송되지 않음을 의미함), 원본 NAT 방식을 선택해야 합니다.
DSR을 위한 NGINX Plus 구성
응답 패킷은 NGINX Plus에 전달되지 않으므로 표준 UDP 역방향 프록시 서비스 생성 에서 구성한 상태 검사를 비활성화해야 합니다. proxy_responses 지시문을 수정하고 proxy_timeout 지시문을 비활성화합니다. 이제 NGINX Plus는 응답을 기다리지 않으며, 응답을 받지 못하더라도 업스트림 서버가 실패했다고 결론을 내리지 않습니다. 이 검사를 비활성화하면 NGINX Plus가 소켓 리소스를 즉시 재사용할 수 있습니다.
또한 proxy_bind 지시문의 첫 번째 매개변수에 $remote_addr 및 $remote_port 변수를 모두 포함하여 NGINX Plus가 업스트림 서버로 전송되는 데이터그램에서 원래 소스 주소와 소스 포트를 모두 보존하도록 합니다.
# '스트림' 컨텍스트에서
server {
listen 53 udp;
proxy_bind $remote_addr:$remote_port transparent;
proxy_responses 0;
#proxy_timeout 1s;
}
라우터 NAT - 중간 라우터에서 송신 패킷 다시 쓰기
단일 중간 라우터에서 송신 패킷을 다시 쓸 수 있습니다. 예를 들어, 업스트림 서버가 NGINX Plus 로드 밸런서 뒤의 개인 네트워크에 있는 경우 로드 밸런서를 기본 경로로 사용하고 패킷이 전달될 때 다시 쓸 수 있습니다.
모든 발신 트래픽을 NGINX Plus 서버를 통해 라우팅하도록 각 업스트림 서버를 구성합니다.
# 경로 추가 기본 gw nginx-ip-addressNGINX Plus 서버를 구성하여 IP 트래픽을 전달합니다.
# sysctl -w net.ipv4.ip_forward=1NGINX Plus 서버를 구성하여 상태 비저장 NAT 재작성을 수행합니다.
# tc qdisc dev eth0 루트 핸들 10을 추가합니다: htb # tc 필터 dev eth0 부모를 추가합니다: 프로토콜 ip prio 10 u32 일치 ip src 172.16.0.11 일치 ip sport 53 동작 nat egress 172.16.0.11 192.168.99.10 # tc 필터 dev eth0 부모를 추가합니다: 프로토콜 ip prio 10 u32 일치 ip src 172.16.0.12 일치 ip sport 53 동작 nat egress 172.16.0.12 192.168.99.10 # tc 필터 dev eth0 부모를 추가합니다: 프로토콜 ip prio 10 u32 일치 ip src 172.16.0.13 일치 ip sport 53 동작 nat egress 172.16.0.13 192.168.99.10 # tc 필터 추가 dev eth0 부모 10: 프로토콜 ip 우선 순위 10 u32 일치 ip src 172.16.0.14 일치 ip sport 53 작업 nat egress 172.16.0.14 192.168.99.10각 업스트림 서버의 적절한 송신 인터페이스와 적절한 IP 주소를 선택했는지 확인하세요.
Stateless NAT에 대한 자세한 내용은 tc nat 매뉴얼 페이지를 참조하세요. 구성에 따라 src 및 egress 기존 매개변수에 CIDR 마스크를 사용하여 tc 필터 명령을 단일 명령으로 줄일 수 있습니다.
현재 tc 필터 구성을 표시하려면 다음 명령을 실행하세요.
# tc 필터 show dev eth0
Origin NAT – 각 업스트림 서버에서 송신 패킷 다시 쓰기
업스트림 서버에서 네트워킹을 구성할 수 있는 경우, 특히 해당 서버가 인터넷에 직접 연결되어 있는 경우 다음 구성을 사용할 수 있습니다. 각 업스트림 서버에 적용해야 합니다.
각 업스트림 서버가 상태 비저장 NAT 재작성을 수행하도록 구성합니다.
# tc qdisc dev eth0 루트 핸들 10을 추가합니다: htb # tc 필터 dev eth0 부모 10을 추가합니다: 프로토콜 ip 우선 순위 10 u32 일치 ip src 172.16.0.11 일치 ip sport 53 동작 nat egress 172.16.0.11 192.168.99.10
각 업스트림에서 적절한 인터페이스와 IP 주소를 선택했는지 확인하세요.
DSR 구성 테스트
구성을 테스트하려면 DNS 요청을 NGINX Plus 부하 분산 장치로 보내고 업스트림 서버 전체에서 부하가 분산되었는지 확인합니다.
DSR에는 직접적으로 눈에 띄는 영향이 없습니다. proxy_responses를 사용했다면 작동한다는 확신을 가질 수 있습니다.0 NGINX Plus가 응답 패킷을 기대하지 않도록 구성하라는 지시어가 있지만, DNS 클라이언트는 부하 분산된 응답을 받습니다. 아래 문제 해결 에서 설명한 대로 tcpdump를 사용하여 패킷 흐름을 추가로 관찰할 수 있습니다.
요약: DSR 구성은 어떻게 작동하나요?
- NGINX Plus는 원격 클라이언트(192.168.99.1: 포트 )로부터 UDP 데이터그램을 수신합니다.
- NGINX Plus는 부하 분산 결정을 내리고 데이터그램 내용을 쓸 업스트림 서버(예: 172.16.0.11)를 선택합니다. NGINX Plus가 연결하기 전에 업스트림 소켓의 로컬 측을 원격 클라이언트의 IP 주소와 포트에 바인딩합니다.
- 업스트림 서버는 NGINX Plus에서 보낸 데이터그램을 수신합니다. 이 데이터그램은 원격 클라이언트 주소와 포트에서 직접 생성된 것으로 보입니다.
- 상위 서버가 응답하여 원격 클라이언트로 데이터그램을 다시 전송합니다. 업스트림 서버는 응답 데이터그램의 소스 IP 주소와 포트를 자체 로컬 IP 주소와 포트로 설정합니다.
- 소스 IP 주소(필요한 경우 포트 포함)는 업스트림 서버( 원본 NAT 구성) 또는 중간 라우터( 라우터 NAT 구성)에 의해 다시 작성됩니다.
- 원격 클라이언트는 올바른 4튜플(소스 및 대상 IP 주소와 포트)로 주소가 지정된 데이터그램을 수신합니다.
- NGINX Plus는 어떠한 응답 데이터그램도 관찰하지 않으며 업스트림 소켓을 즉시 닫습니다.
결과적으로 응답 패킷은 NGINX Plus의 Layer 7 처리를 우회하여 원격 클라이언트로 직접 전송됩니다.
문제 해결
IP 투명성 또는 DSR이 예상대로 작동하지 않으면 다음 제안 사항을 사용하여 가능한 원인을 조사하십시오.
루트 로 실행
NGINX Plus 작업자 프로세스가 root 로 실행되도록 구성되었는지 확인합니다. 그렇지 않은 경우 NGINX Plus가 소켓을 비로컬 주소에 바인딩하려고 할 때 다음과 유사한 오류 메시지가 오류 로그에 표시됩니다.
setsockopt(IP_TRANSPARENT) 실패(1: 업스트림에 연결하는 동안 작업이 허용되지 않습니다. 클라이언트: 192.168.99.1, 서버: , 요청: "GET / HTTP/1.1", 업스트림: "http://172.16.0.11:80/", 호스트: "192.168.99.10"
ping 으로 테스트
NGINX Plus 프록시에서 클라이언트와 서버에 ping을 보낼 수 있는지 확인하세요. 먼저 필요한 라우팅 구성을 만들고 NGINX Plus 중개자가 패킷을 전달하도록 구성하지 않는 한 업스트림 서버는 원격 클라이언트 IP 주소를 ping할 수 없습니다.
중복되는 IP 범위 없음
원격 클라이언트가 사용하는 IP 서브넷이 업스트림 서버에 직접 연결되지 않았는지 확인하세요. 그렇다면 두 가지 문제가 발생할 가능성이 있습니다.
- Linux의 "역경로 필터링" 보호 기능은 소스 IP 주소가 다른 인터페이스의 서브넷과 연결되어 있기 때문에 NGINX Plus에서 오는 패킷을 자동으로 거부할 수 있습니다.
- 반환 패킷은 기본 경로를 사용하지 않고 대신 로컬에 연결된 원격 클라이언트에 직접 전송됩니다.
tcpdump를 어디서나 사용하세요
구성을 구축하고 각 중간 단계를 테스트할 때 각 서버에서 tcpdump를 지속적으로 실행하여 각 단계에서 패킷이 올바른 엔드포인트로 전송되고 수신되는지 확인하세요.
$ sudo tcpdump -i any -n tcp 포트 80
아래 나열된 검사를 사용하여 비정상적인 행동을 조사하세요.
라우팅 테이블 확인
각 서버의 라우팅 테이블을 주의 깊게 확인하고 특히 업스트림 서버에 주의하세요.
# route -n 커널 IP 라우팅 테이블 대상 게이트웨이 Genmask 플래그 메트릭 참조 사용 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
예상치 못한 경로가 있나요? 흐름에 있는 모든 패킷이 올바른 대상으로 라우팅될 수 있는지 확인할 수 있나요? iptables 및 라우터 NAT 구성에서 모든 송신 패킷은 중간 NGINX Plus 프록시를 통해 라우팅되어야 합니다.
패킷 누락
패킷이 예기치 않게 삭제되는 경우( tcpdump 에서 한 시스템에서는 보냈지만 다른 시스템에서는 수신되지 않았다고 표시됨) 역방향 경로 필터링이 잠재적인 원인일 수 있습니다. 역방향 경로 필터링을 일시적으로 비활성화하려면 다음 명령을 실행하세요.
# f에 대해 /proc/sys/net/ipv4/conf/*/rp_filter; echo 0 > $f ; 완료
업스트림 서버가 외부 서버에 도달하도록 활성화
업스트림 서버가 개인 네트워크에 있고 NGINX Plus(또는 다른 서버)를 기본 게이트웨이로 사용하는 경우 업스트림 서버가 외부(인터넷) 호스트에 도달할 수 있도록 게이트웨이를 구성할 수 있습니다.
게이트웨이가 업스트림 서버에서 패킷을 전달할 수 있도록 IP 전달을 활성화해야 합니다. IP 전달은 일반적으로 기본적으로 비활성화되어 있습니다. 서버에 라우팅 가능한 IP 주소가 없는 경우(172.16.0.0/24와 같은 개인 주소 사용) 게이트웨이 서버의 외부 인터페이스에서 IP 마스커레이딩을 구성해야 합니다.
# sysctl -w net.ipv4.ip_forward=1 # iptables -t nat -A 포스트라우팅 -o eth0 -j 매스커레이드
내부 업스트림 서버에서 외부 서버에 ping을 보낼 수 있는지 확인하세요.
root@dev1:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84)바이트의 데이터.
8.8.8.8에서 64바이트: icmp_seq=1 ttl=61 시간=6.72ms 8.8.8.8에서 64바이트: icmp_seq=2 ttl=61 시간=5.49ms ^C
현재의 전달, 라우팅 및 iptables nat 구성을 표시하려면 다음 세 가지 명령을 실행하세요.
# sysctl net.ipv4.ip_forward # 경로 -n # iptables -t nat -L
NGINX에서 도움 받기
IP 투명성이나 직접 서버 반환에 대한 구성은 복잡하며, 다른 중간 네트워크 장치가 패킷을 삭제하거나 다시 작성하여 배포에 영향을 미칠 수 있습니다. 도움이 필요하면 NGINX 전문 서비스 팀이 도와드리겠습니다.
NGINX Plus를 통해 IP 투명성과 DSR을 직접 확인해 보세요. 오늘 무료 30일 체험판을 시작하거나, 사용 사례에 대해 논의하기 위해 저희에게 연락해 주세요 .
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."