HAProxy TCP 모드에서 클라이언트의 Source IP를 내부 서버로 전달하는 방법을 알아봅니다. * 중간에 오타가 있어서 수정본을 다시 업로드 하고자 했으나... SlideShare 측의 답변으로는 "Re-Upload 기능을 제거했다."라고 합니다. 부디 오타 등 부자연스러운 부분에 대해 너그럽게 이해를 부탁 드립니다.

1. HAPROXY TCP 모드에서 내부 서버로
CLIENT IP 전달 방법
용영환 ( http://xenonix.com )
TABLE OF CONTENTS
HAProxy 의 장점............................................................................................................................................. 2
로드 밸런싱 할 때 Source IP 문제................................................................................................................... 2
HAProxy TCP 모드에서 내부 서버로 Source IP 전달 방법............................................................................... 3
HAProxy Proxy Protocol 지원 애플리케이션............................................................................................... 4
Apache HTTPD 에 Proxy Protocol 설정 방법................................................................................................ 4
HAProxy Proxy Protocol 설정 방법.............................................................................................................. 6
Source IP 확인............................................................................................................................................. 6
Proxy Protocol 적용할 때 주의사항................................................................................................................ 7
참고 문헌 ....................................................................................................................................................... 8

2. 웹서비스 아키텍처를 구성할 때 상대적으로 매우 저렴한 비용으로 트래픽 분산을 하는 방법은
여러가지가 있다. 대표적으로 Nginx 같은 고효율 웹서버에서 제공하는 로드 밸런싱 기능을 이용하는
것인데 설치와 설정이 다소 쉽고 성능도 매우 우수해서 대규모 트래픽을 소화해야 하는 웹서비스에 많이
적용하고 있다.
반면 HAProxy 를 로드밸런서로 사용하는 경우도 있다. 한편에서는 HAProxy 보다 Nginx 를 사용하는게 더
좋다고 말하는 경우도 있으나, 어떤 것이 좋고 나쁘다기 보다는 만들고자 하는 서비스가 무엇이냐에
따라 적절하게 선택하면 그게 가장 좋은 것 아닐까 생각한다. 그런 측면에서 HAProxy 를 선택하는 경우에
대해 먼저 이야기를 나눠보자.
HAPROXY 의 장점
HAProxy 의 큰 장점 중 하나는 상대적으로 저렴한 리눅스 서버에 L4, L7 을 한번에 쉽게 구축할 수 있다는
것이다.
앞서 언급한 Nginx 같은 웹서버의 로드 밸런서는 HTTP 프로토콜에 대한 분산처리만을 해준다. 물론 HTTP
또는 HTTPS 기반의 웹서비스만 제공하는 경우라면 웹서버 로드밸런서가 탁월한 성능을 보여주기
때문에 최선의 선택일 수도 있다.
하지만 웹서버 외에 SMTP, DBMS 등을 비롯하여 소켓통신을 하는 모든 경우에서도 로드 밸런싱을 하고자
한다면 HAProxy 가 합리적인 선택일 수 있다. 이를 위해서 HAProxy 는 HTTP 와 TCP 두 가지 모드를
제공한다.
로드 밸런싱 할 때 SOURCE IP 문제
모두 알고 계시는 바와 같이 HTTP 프로토콜은 Layer 4 인 TCP 위에 구현되어 있다. 그러므로 HTTP 모드를
사용하지 않고서도 TCP 모드에서도 HTTP 로드밸런싱이 가능하다. 왜 굳이 HTTP 모드를 놔두고 복잡하게
TCP 모드를 사용했는 지에 대해서는 이유가 있긴 하지만 이 문서에서 다루지는 않을 것이다.
자, 일단 TCP 모드를 사용하는 것을 전제로 이야기를 계속 진행해보자.
로드밸런서는 아래와 같이 외부에서 들어오는 트래픽을 내부 서버로 분산시켜 준다. 이때 한가지 알아야
하는 것이 패킷이 로드밸런서를 통해 들어오면서 내부 웹서버에서는 Source IP 대신 로드 밸런서 IP 를
원본 IP 로 인식한다.

3. 만약 웹서버에서 보안을 위해 특정 IP 만 접속할 수 있도록 제한을 걸거나, 어떤 IP 에서 접속하는지
로그를 남기고 싶을 때에도 로드 밸런서 IP 로만 보이기 때문에 사실상 불가능 하다.
이러한 현상은 HAProxy 뿐만 아니라 보통 로드 밸런서나 Proxy 서버에서 볼 수 있는 일반적인 것이다.
그럼에도 불구하고 하드웨어 L4 스위치 같은 걸 사용하면 이러한 현상이 나타나지 않는 이유는 그러한
고가의 L4 스위치는 Client IP 를 내부 서버로 전달해주는 기능이 탑재되어 있기 때문이다.
( 이러한 현상들을 직접 해결하기 귀찮다면 역시나 자본으로 해결하는게 가장 쉽고 편한 것 같다. )
HAPROXY TCP 모드에서 내부 서버로 SOURCE IP 전달 방법
우리가 원하는 것은 아래 그림과 같이 내부 웹서버에서 Source IP 를 제대로 인식하는 것이다.
HAProxy 는 Source IP 를 내부 서버로 전달하는 방법으로 Proxy Protocol 을 제공한다. HTTP 의 경우
프로토콜에 X-Forwareded-For 헤더를 붙여 전달할 수 있기 때문에 매우 간단하게 해결할 수 있지만 TCP 는
그러한 헤더가 없기 때문에 별도의 프로토콜을 사용해야 한다.
로드 밸런서
웹서버 1
웹서버 2
웹서버 3
192.168.0.10
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
클라이언트가
10.0.0.1 ???
로드 밸런서
웹서버 1
웹서버 2
웹서버 3
192.168.0.10
10.0.0.1
192.168.0.10
192.168.0.10
192.168.0.10
클라이언트 IP
192.168.0.10
OK

4. HAPROXY PROXY PROTOCOL 지원 애플리케이션
HAProxy 의 Proxy Protocol 을 지원하는 애플리케이션은 아래와 같다.
• Elastic Load Balancing
• Dovecot 2.2.19 이상
• exaproxy 1.0.0 이상
• exim 4.83 이상
• gunicorn 0.15.0 이상
• haproxy 1.5-dev3 이상
• hitch
• nginx 1.5.12 이상
• Percona DB Server 5.6.25-73.0 이상
• postfix 2.10 이상
• stud
• stunnel 4.45 이상
• Apache HTTPD 2.2 와 2.4
• varnish 4.1 이상
• MariaDB 10.3.1 이상
그리고 아쉽지만 아직 Proxy Protocol 을 지원하지 않는 애플리케이션은 아래와 같다.
• apache ATS
• squid
• MySQL
APACHE HTTPD 에 PROXY PROTOCOL 설정 방법
위 목록에 Apache HTTPD 가 포함되어 있지만 기본적인 상태에서는 Proxy Protocol 을 지원하지 못한다.
외부 모듈을 직접 컴파일 해서 설치해야만 한다. 복잡해 보일 수도 있지만 우리에겐 이 모듈이 꼭
필요하므로 시작해보자. 먼저 아래 Github 에 접속해서 소스 코드를 내부 웹서버에 내려 받아야 한다.
https://github.com/roadrunner2/mod-proxy-protocol

5. 위 화면과 같이 잘 내려받은 후에는 컴파일을 위해 apache-devel 을 설치해야 한다.
Ubuntu
apt-get install apache2-dev
CentOS
yum install httpd-dev
이제 내려 받은 mod_proxy_protocol.c 가 있는 디렉터리에서 아래와 같이 입력한다.
make
그러면 아래 화면과 같은 결과가 보일 것이다.
다시 ls -la 를 해보면 아래와 같이 .libs 디렉터리가 생성되어 있다.
.libs 디렉터리 안으로 들어가면 아래와 같은 파일 목록을 볼 수 있다.

6. 생성된 mod_proxy_protocol.so 파일을 Apache 모듈 디렉터리로 복사해 넣는다. 그리고 Apache 설정
파일에 아래를 추가한다.
LoadModule proxy_protocol_module {모듈 디렉터리}/mod_proxy_protocol.so
끝으로 아파치 웹서버의 전역 설정이나 VirtualHost 항목에 아래와 같이 ProxyProtocol On 을 지정한다.
아파치를 재시작해서 아래와 같이 정상적으로 동작하면 된다.
HAPROXY PROXY PROTOCOL 설정 방법
HAProxy 는 버전 1.5 이상부터 Proxy Protocol 을 지원하므로 되도록 최신 버전을 사용하는 걸 권장한다.
HAProxy 설정은 매우 쉽다. haproxy.cfg 파일을 열고 아래와 같이 내부 서버 IP 위데 send-proxy 를
추가해주기만 하면 된다.
SOURCE IP 확인
Proxy Protocol 적용 전에는 아래와 같이 REMOTE_ADDR 에 서버 IP 가 나타났으나
Proxy Protocol 을 정상적으로 적용하고 난 후에는 아래와 같이 REMOTE_ADDR 에 올바른 클라이언트 IP 가
보인다.

7. PROXY PROTOCOL 적용할 때 주의사항
Proxy Protocol 을 사용하면 TCP 패킷 맨 앞에 아래와 같이 PROXY TCPx 라는 헤더를 붙여 전송한다. 하지만
HTTP 프로토콜에서는 이러한 PROXY TCPx 헤더 정의가 없으므로 우리가 앞에서 살펴본 아파치용 Proxy
Protocol 모듈이 이러한 헤더를 인식하게 해준 것이다.
그러므로 Proxy Protocol 을 사용할 때에는 HAProxy 와 내부 서버, 양쪽 모두에서 Proxy Protocol 사용을
지정해야 한다. 그렇지 않으면 프로토콜이 맞지 않아 오류가 발생할 것이다.
예를 들어 HAProxy 쪽에서 Proxy Protocol 을 사용하기 위해 send-proxy 를 지정해주고, 내부 서버에서는
아직 Proxy Protocol 을 받을 준비가 안되어있다면 통신이 제대로 되지 않을 수 있다. 만약 HAProxy 에서
send-proxy 를 지정하고, Apache 쪽에서 ProxyProtocol On 을 지정하지 않으면 아래 화면과 같이 연결
오류가 발생한다.
반대의 경우도 마찬가지이다. 내부 서버에서 Proxy Protocol 을 켜고, HAProxy 쪽에서 send-proxy 지정을
해주지 않아도 위 화면과 같이 연결 오류가 발생한다.
물론 PROXY TCPx 헤더 여부를 자동으로 판단하여 상황에 맞게 동작하도록 되어있는 애플리케이션도
있겠으나 HAProxy 의 Proxy Protocol 을 실제 라이브 서버에 적용할 때에는 꼭 미리 확인하여 신중하게
작업을 해야 한다.

8. 참고 문헌
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
https://www.haproxy.com/blog/haproxy/proxy-protocol/
https://www.haproxy.com/blog/preserve-source-ip-address-despite-reverse-proxies/
https://roadrunner2.github.io/mod-proxy-protocol/mod_proxy_protocol.html
https://mariadb.com/kb/en/library/proxy-protocol-support/