클라이언트 소스 IP를 검색하는 방법

특정 상황에서, 우리의 서비스는 특정 비즈니스 또는 보안 이유로 클라이언트 IP를 사용해야 합니다. 그러나 일반적인 시나리오에서는 트래픽이 실제 서비스에 도달하기 전에 여러 네트워크, 로드 밸런서 또는 프록시 서비스를 통과합니다. 이 과정의 각 계층에서 원래의 클라이언트 IP가 손실될 수 있으며, 이로 인해 우리 서비스는 이전 네트워크의 IP만을 가지게 됩니다. 이러한 결과는 우리에게 이상적이지 않습니다.

우리의 기술 스택이 복잡하기 때문에, 클라이언트 IP를 얻기 위해서는 다양한 방법을 사용해야 하며, 때로는 이들을 조합해야 합니다.

NAT를 통한 클라이언트 IP 관리

사용자가 구축하거나 임대한 특정 IDC 인프라에서, 우리의 서비스는 게이트웨이 뒤의 별도 LAN 네트워크에 위치할 수 있습니다. 클라이언트가 외부 네트워크에서 우리 서비스에 연결하려고 할 때, 트래픽은 게이트웨이를 통해 라우팅됩니다.

클라우드 서비스를 사용할 때도 유사한 상황이 발생할 수 있습니다. 공용 클라우드 플랫폼에서 제공하는 VPC 네트워크는 독립적인 LAN 네트워크로 기능하며, 다른 VPC 및 인터넷과 격리됩니다. 결과적으로, 외부 인터넷 접근 및 외부 서비스 연결을 위해 게이트웨이가 필요합니다.

이 게이트웨이는 라우터 또는 방화벽 장치일 수 있으며, 일반적으로 내부 서비스를 위한 DNAT(Destination NAT) 주소 변환 서비스를 제공합니다. 이는 게이트웨이가 하나 이상의 공용 IP 주소를 보유하고, 공용 IP의 특정 포트에서 내부 IP의 특정 포트로 트래픽을 전달하는 것을 포함합니다. 게이트웨이는 트래픽 전달 및 포트 매핑을 관리합니다. 그러나 게이트웨이가 원본 IP 패킷 헤더의 소스 주소를 수정하기 때문에, 내부 네트워크에 있는 우리 서비스는 실제 클라이언트 주소가 아닌 게이트웨이의 IP 주소만을 식별할 수 있습니다.

역사적으로, 네트워크 장치 또는 소프트웨어가 제공하는 DNAT 기능은 상대적으로 기본적이었습니다. 이들은 주로 3계층에서 작동하며, 더 깊은 계층의 페이로드에 대한 인식 및 조작 능력이 부족했습니다. 이들의 주요 목적은 서비스 노출이었으며, 클라이언트 IP를 하위로 전달할 수 없었습니다. 또한, 이러한 장치 또는 소프트웨어의 성능 제한으로 인해 활성 연결 수 및 최대 새 연결 수에 제약이 있었습니다. 하드웨어 업그레이드 없이 확장하는 것이 종종 어려웠기 때문에, 오늘날의 동적 환경에 적응하기 어려웠습니다.

이러한 한계를 해결하기 위해, 우리는 더 발전된 트래픽 조작 능력을 가진 로드 밸런싱을 사용합니다.

로드 밸런싱에서의 클라이언트 IP

일반적으로, 로드 밸런싱은 작동 계층에 따라 주로 두 가지 유형으로 분류됩니다: 4계층과 7계층, 각각 TCP 데이터 스트림과 애플리케이션 트래픽(HTTP로 대표됨)에 해당합니다.

IP 게이트웨이와 달리, 로드 밸런싱은 IP 패킷 헤더를 수정하지 않습니다. IP 패킷 수준에서는 투명 전달만 수행합니다. 결과적으로, 앞서 논의한 DNAT와 달리, 로드 밸런싱은 IP 패킷에 포함된 소스 IP가 로드 밸런서 뒤의 구성 요소로 정확히 전달되도록 합니다.

4계층 로드 밸런싱의 경우, 기본적인 트래� 전달을 완료한 후, 후속 서비스는 특별한 처리 없이도 클라이언트 IP를 정확히 검색할 수 있습니다. 특별한 경우에는 Proxy Protocol을 활용할 수 있습니다. 이는 원래 트래� 페이로드 앞에 새로운 섹션을 추가하여 클라이언트 IP를 포함시키는 것을 의미합니다. 로드 밸런서 뒤의 다른 리버스 프록시 서버 또는 서비스 자체가 Proxy Protocol 데이터를 해석하여 클라이언트 IP를 얻을 수 있습니다.

7계층 로드 밸런싱의 경우, 더 깊은 트래픽 처리 능력을 가지고 있습니다. HTTP 프로토콜 수준에서 소스 IP를 직접 전달할 수 있습니다. 일반적인 방법은 X-Forwarded-For HTTP 헤더를 사용하는 것입니다. 로드 밸런싱 구성 요소는 트래픽의 IP 패킷에서 소스 IP를 추출한 후, HTTP 요청을 파싱하고 재작성합니다. 요청 헤더에 새로운 XFF 필드를 삽입하여 클라이언트 IP 값을 포함시킵니다.

HTTPS는 암호화된 페이로드로 인해 특별한 도전을 제기합니다. 이로 인해 로드 밸런싱 구성 요소가 HTTP 헤더를 직접 조작할 수 없습니다. 이러한 상황에서는 다음 접근 방식을 고려할 수 있습니다:

• 특별한 요구 사항이 없는 경우, HTTPS 트래픽을 표준 TLS 트래픽으로 취급하고 4계층에서 직접 전달하는 것이 옵션입니다. 이 시나리오에서는 클라이언트 IP가 여전히 IP 패킷 헤더를 통해 로드 밸런서 뒤의 서비스로 전달될 수 있습니다.

• 7계층 기능이 필요한 경우, 로드 밸런싱 구성 요소에서 TLS 인증서를 호스팅하여 TLS 종료를 수행할 수 있습니다. 이 과정은 로드 밸런싱 계층에서 TLS 암호화를 제거하고, 로드 밸런서 뒤의 LAN에서 일반 HTTP를 사용하거나, 직접 전달 대신 서비스에 대한 새로운 HTTPS 연결을 설정하는 것을 포함합니다. 이를 통해 로드 밸런싱 구성 요소는 원래의 HTTP 트래픽을 다시 처리하고 XFF 방법을 사용하여 IP를 계속 전달할 수 있습니다.

미묘한 트래픽 처리를 통해, 로드 밸런싱은 클라이언트 IP를 백엔드 서비스로 전달하는 다양한 방법을 제공합니다. 로드 밸런싱 구성 요소의 대표적인 구현에는 클라우드 기반 ELB 서비스, 하드웨어 기반 F5 BIG-IP, Linux 커널 기반의 Linux Virtual Server(LVS), 사용자 소프트웨어 기반의 NGINX가 있습니다.

CDN 서비스에서의 클라이언트 IP 전달

때때로, 우리는 사용자가 우리 서비스에 접근하는 속도를 높이기 위해 공용 클라우드 플랫폼에서 제공하는 CDN 서비스를 활용합니다. 이들의 기능은 7계층 리버스 프록시 서버와 유사하지만, 더 넓은 맥락에서 CDN은 로드 밸런싱 영역의 일부로 간주될 수 있습니다.

CDN 서비스는 일반적으로 TLS 종료 기능을 제공하며, 서비스로 전송되는 HTTP 요청에 클라이언트 IP를 포함할 수 있습니다. 예를 들어, AWS CloudFront CDN 서비스는 XFF 방법을 사용하여 클라이언트 IP를 전달하는 것을 지원하며, 이는 7계층 로드 밸런싱에서 사용되는 접근 방식과 유사합니다.

API 게이트웨이 활용

로드 밸런싱 구성 요소는 일반적으로 트래픽에 대한 기본적인 제어 기능을 제공하지만, 클라우드 기반 또는 하드웨어 로드 밸런서가 제공하는 API는 우리의 특정 비즈니스 요구와 일치시키기 어려울 수 있습니다. 이러한 시나리오에서는 더 유연한 구성 요소를 사용하여 우리 서비스에 맞춤화된 전략을 적용합니다. 이때 Apache APISIX 또는 API7 Enterprise와 같은 API 게이트웨이가 등장합니다.

APISIX와 API7 Enterprise는 Proxy Protocol을 지원하여 로드 밸런서에서 클라이언트 IP를 검색할 수 있습니다.

또한, 이들은 NGINX의 ngx_http_realip_module과 유사한 "real-ip" 플러그인을 가지고 있습니다. 이 플러그인은 소스에서 클라이언트의 IP를 가져와 하위 전달 및 로깅에 사용합니다. APISIX와 API7 Enterprise의 real-ip 플러그인은 NGINX에서 찾을 수 있는 기능을 향상시킵니다. 이는 실제 소스 IP 기능을 동적으로 활성화 또는 비활성화할 수 있으며, 클라이언트 IP의 소스를 HTTP 헤더 및 Proxy Protocol에 제한된 ngx_http_realip_module의 제약을 넘어 확장합니다. 이는 쿼리 매개변수 또는 POST 양식 필드와 같은 NGINX 또는 APISIX 확장 변수를 활용할 수 있습니다.

요약

다양한 계층의 기술을 조합하여, 우리는 서비스의 각 구성 요소를 통해 클라이언트 IP를 효과적으로 전달할 수 있으며, 이는 비즈니스 및 보안 요구를 충족시킵니다.

API 관리 솔루션에 대해 더 알아보려면 API7.ai에 문의하십시오.