Proxy / VPN

프록시의 기능은 크게 두가지. 1. 중계, 2. 캐싱.

HTTP proxy

X-Forwarded-For?Client IP 구하기 : X-Forwarded-For와 X-Real-IP

X-Forwarded-Host : Client가 요청한 원래 host. reverse proxy server가 원래 요청받은 서버가 어디인지 식별하기 위해 사용한다.

이 field들은 proxy server가 original host’s IP를 제대로 report해준다는 데 의존하기 때문에 신뢰성이 떨어진다.

위조되기도 쉽고, 표준이 아니라 “사실상의” 표준이기 때문에 지켜지지 않는 경우도 많다.

단, 마지막 IP는 항상 마지막 proxy server에 연결된 IP다. X-Forwarded-For:client, proxy1, proxy2...

클라이언트가 요청을 숨기기 위해 직접 프록시 서버를 사용하는 경우가 아니라도, 캐시 서버나 WAS, load balancer 등을 거쳐 가는 경우 또는 서버 측에서 자체적으로 리버스 프록시를 운영하는 경우 결과적으로 내부 서버가 받는 HTTP 패킷은 클라이언트의 IP가 아니므로 X-Forwarded-For를 사용해 클라이언트 IP를 식별하게 된다.

SOCKS proxy

SOCKS는 서버 클라이언트 간의 통신이 proxy를 거치도록 지원하는 Session layer 프로토콜이다. SOCKS server 측에서 사용하는 listening port는 1080이다. 버전 5(SOCKS5)부터 인증 기능을 지원하기 떄문에 인가된 유저만 접근할 수 있다. Session layer에서 동작하기 때문에 모든 어플리케이션이 SOCKS를 사용하도록 설정할 수 있다. 예를 들어 Tor의 경우 127.0.01:9150으로 걸면 된다.

VPN

Client send dst : VPN Server이고, Server recv src : VPN Server 이므로 위 처럼 Client와 Server에 Firewall 등 Logging 장비가 있다면 VPN Server를 직접 조사해보지 않아도 Logging 정보로 추적이 가능하다.

그러나 다음과 같은 제약이 있다.

• Client 측 Logging 장비를 조사하려면 Client로 의심되는 곳을 특정할 수 있어야한다.
• VPN을 두 번 타거나, VPN Server 측에서 받은 packet을 다른 인터페이스로 보낸다면 Client send dst IP != Server recv src IP 이므로 VPN Server를 조사하는 수 밖에 없다.

헌데 경우에 따라 VPN 뒤쪽에 있는 장비가 가려지지 않는 경우도 있는 듯?

회사A:서버1 - 회사A:VPN1 <> 회사B:VPN1 - 회사B:서버
회사A:서버2 - 회사A:VPN2 <> 회사B:VPN2
\* 전용선 연결

다음과 같이 연결되어 있는 상태에서 회사B:VPN2 - 회사B:서버 로 변경했는데 회사A 내부 방화벽 통신정책 변경 없이는 통신이 불가능했음…

회사A에서는 회사B:VPN 만 볼 수 있고 뒤에 있는건 무관한 줄 알았는데, 그게 아닌 경우도 존재하는 듯.