요즘은 너무나도 당연히 대부분의 사용자 기기가 공유기 뒤에 숨어있듯이,
서버 또한 로드밸런서 뒤에 숨어있는 것이 너무나도 당연한 구조가 되었다.
이제 서버 개발자는 하나의 고민을 더 하게 된다.
예전에는 p2p 통신을 위해 홀펀칭을 고민하고 릴레이를 해주어야 했다면,
이제는 클라이언트 IP를 가져오기 위해 고민을 해야 할 차례가 되었다.
우리가 얻을 수 있는 클라이언트 IP는, 해당 클라이언트가 숨어있는 라우터 공유기의 공인 IP이다.
하지만 그 정보 또한, 프록시와 로드밸런서가 가득한 네트워크 세상에서 어떻게 가져와야 할지 고민해봤다.
사실 맨 처음에는 도커 서비스에서 client addr을 가져오니 도커 브릿지 ip가 찍히는 것이 문제였다.
그래서 docker network_mode를 host로 놓아 보았다. 그랬더니 이제는, 모든 클라이언트가 동일한 ip가 찍혔다.
AWS ALB의 ip주소였다.
AWS ALB와 NLB는 IP Preservation 기본 정책이 다르다.
Target Group 설정에 따라, ip preservation 옵션 기본값이 다르다.
- NLB에서 target group 이 instance일 경우 기본값 : enabled
- NLB에서 target group 이 ip일 경우 기본값 : disabled
- ALB에서는 X-Forwarded-For 사용
아래 문서를 참고해보자.
여기서 X-Forwarded-For 에 대해 조금 더 알아보자.
프록시를 거칠 때마다 해당 서버의 ip가 XFF 헤더 우측에 append된다.
예를 들어, 클라이언트가 123.123.123.123일 때,
프록시 서버가 10.11.12.13 이고, 서버 앞단의 로드밸런서가 100.100.100.101이라면,
XFF는 123.123.123.123, 10.11.12.13, 100.100.100.101
이 된다.
하지만, 우리는 XFF의 맨 좌측 값을 가져오자! 라고 단순하게 생각해서는 안 될 것이다.
클라이언트는 HTTP 요청을 보낼 때 자신의 헤더 값을 조작할 수 있으므로,
XFF에 다른 IP값을 잔뜩 넣어서 요청을 보내버릴 수도 있을 것이다.
따라서, 가장 오른쪽에 가까운 IP값을 사용하되,
알고 있는, 신뢰하는 프록시 IP를 제거해나가는 식으로 탐색해 가자.
'연구한 이야기 > 문제 해결 이야기' 카테고리의 다른 글
MySQL 통신 패킷 확인하기 (0) | 2024.06.23 |
---|---|
MySQL "Not Supported" 에러와 handshake (0) | 2024.05.30 |
서버 로그가 누락되고 있어요..! (0) | 2024.03.31 |
alpine리눅스와 stat (0) | 2024.03.24 |
mysql connect 시에 timezone 관련해서 에러가 나요! (2) | 2024.03.02 |