05. 프록시

커넥션에서 한번 언급했던 프록시입니다. 이번시간에는 프록시에 대해 알아봅시다!

 

프록시?

트랜잭션을 처리하는데에는 여러 컴퓨터들이 연결되어 있다고 했습니다.

'클라이언트'와 '원 서버' 사이에 위치해서 여러가지 편의기능을 제공하는 컴퓨터를 프록시라고 했는데요.

정확한 용어로는 중개 서버라고 합니다. 말 그대로 클라이언트에게는 서버역할을, 다른 서버에게는 클라이언트 역할을 하는 것이죠.

그림 1 중개서버 역할을 하는 프록시

※ 프록시와 게이트웨이의 차이

게이트웨이는 뒤에 다루겠지만 차이점을 간단하게 집고 넘어가겠습니다.

프록시와 게이트웨이 모두 같은 기능을 하나, 프로토콜에 차이가 있는데요

같은 프로토콜인 경우 (HTTP/HTTP, TCP/TCP) 프록시를, 다른 프로토콜인 경우 (HTTP/TCP)에 게이트 웨이를 사용합니다.

 

 

프록시.. 뭐가 그래 좋은데?

1) 접근 제어

프록시의 핵심 기능 중 하나입니다. 바로 사용자의 권한에 따라 데이터 접근을 제어할 수 있게 하는 것입니다.

그 뿐 아니라, 트래픽을 감시 및 추적도 가능합니다!

덕분에 많은 조직에서 프록시의 접근 제어 기능을 사용하고 있습니다.

그림 2 프록시의 접근 제어

 

2) 보안 기능

접근 제어의 연장선입니다. 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제를 하여 보안성을 강화하는 방법입니다. 접근 제어와 같이 트래픽을 감시할 수 있는 후크를 제공합니다.

그림 3  모든 데이터 흐름을 보안 프록시를 거치도록 설정

3) 캐시 기능

서버 하나가 모든 트래픽을 감당하기는 매우 힘듬니다.  그렇기 때문에 사용자들이 자주 요청하는 문서들을 알아내서 프록시에 사본을 보내 관리를 시켜, 사용자들의 접근성을 높인 기술입니다. 정말 핵심기능입니다! 

중요한 만큼 파트 자체를 분리시켜 다음 장에 다루도록 합시다.

 

4) 대리 프록시(리버스 프록시, Surrogate)

서버를 대신한다는 의미로 '대리 프록시'라고 합니다. 재밋는점은 프록시가 서버의 정보(IP, 호스트명)을 위임받기 때문에 요청하는 측은 서버와 커넥션을 생성했다 착각하고 있다는 것입니다.

여러 이유로 인해 대리 프록시를 사용하는데,

첫번째로는 웹 서버의 성능 개선 입니다. 웹 서버가 느린 경우 프록시를 이용해 속도를 개선해주기 때문에, '서버 가속기'라고도 합니다.

두번째로는 보안 기능 강화입니다. 대리프록시와 원 서버간의 방화벽을 설정해 사용자들이 원 서버에 직접 접속하지 못하게 막을 수 있습니다. 프록시와 서버 간에는 정규 매핑으로 통신을 할 수 있습니다.

그림 4 대리 프록시

보안기능에 대한 정보는 여기를 참고합시다.

https://docs.oracle.com/cd/E19438-01/820-0862/adypp/index.html

https://docs.oracle.com/cd/E19438-01/820-0862/adypp/index.html

5) 컨텐츠 라우터

인터넷 트래픽 조건과 컨텐츠 종류에 따라 요청을 특정 웹 서버로 유도의 역할도 가능합니다.

주로 유료 고객들에게 맞춤형 서비스를 제공하는데 쓰입니다.

 

 

6) 트랜스코더

서버 컨텐츠를 클라이언트에게 전달하기 전 데이터 표현방식을 변환하는 트랜스코더^[각주:1] 역할을 수행합니다.

 

(1) 이미지의 크기를 줄여 전송 비용을 낮춘다. ex: GIF 이미지를 JPG 이미지로 변환할 수 있다.

 

(2) 외국어 문서 등을 변역하는 것에도 활용을 할 수 있다

 

(3) 디스플레이의 크기별로 화면의 배치를 조정하는 반응형 웹 설정을 할 수 있다.

 

7) 익명 프록시

HTTP 메시지에는 사용자의 신원을 특정할 수 있는 정보가 담겨져 있습니다. (IP주소, From 헤더, Referer 헤더, 쿠키)

이러한 정보들을 제거해주어 사용자의 익명성을 보장해주는 프록시를 익명프록시라고 합니다.

 

---

프록시 배치

프록시의 종류를 알았으니 이제는 적절하게 배치를 할 차례입니다. 어디든 배치가 가능하나 프록시의 종류나 목적에 따라 위치가 달라집니다!

 

1) 출구 프록시

로컬 네트워크와 인터넷 사이를 오가는 트래픽을 제어하기 위해서 로컬 네트워크의 출구에 프록시를 배치하는 방법입니다. 이로써 프록시는 방화벅 역할을 할 수 있고, 또한 인터넷 트래픽의 성능을 개선할 수 있습니다. 마지막으로 특정 컨텐

츠를 열람할 수 없도록 하는 접근 제한의 기능도 수행할 수 있습니다.

그림5 출구 프록시

2) 입구 프록시

사용자들의 모든 요청을 종합해서 처리하기 위해서 ISP 접근지점에 배치하는 방법입니다. 캐시 프록시가 이에 속합니다.

 

3) 대리 프록시

원 서버를 대신하여 웹 서버로 향하는 모든 요청을 해결하는 프록시이기 때문에 최대한 서버와 가까이 붙어 있어야 빠른 처리가 가능합니다. 추가적으로 보안과 성능을 향상시키면 원서버의 단점을 보완할 수 있습니다. 그림 4를 참고합시다!

 

4) 네트워크 교환 프록시

네트워크가 교환되는 지점 (교차점)의 혼잡을 완화하고 트래픽 흐름을 감시하기 위해 배치되는 프록시 입니다.

하지만 사용자들의 프라이버시를 침해하기 때문에 배치를 신중하게 결정해야 합니다!

 

그림6 네트워크 교환 프록시

 

 

프록시로 트래픽 유도

클라이언트는 보통 웹 서버와 상호작용을 하려 합니다. 그렇다면 어떻게 프록시가 이 트래픽을 가져올 수 있을까요?

이번에는 그에대해 알아봅시다.

1. 클라이언트를 수정

클라이언트가 웹 서버와 상호작용을 하려 한다는 성질을 이용하면, 프록시와 상호작용을 하도록 클라이언트를 수정 하면 됩니다! 주로 브라우저가 이런 방법을 사용합니다.

그림 7 프록시를 사용하도록 클라이언트 설정

2. 네트워크의 경로를 수정

만약 수정하고 싶은 클라이언트를 알지 못하고, 또 안다고 하더라도 수정할 방법이 없으면 어떻게 해야 할까요?

이런경우에는 트래픽을 가로채 경로를 프록시로 향하게 수정하는 방법이 있습니다! 이를 위해서는 스위칭 장치와 라우터가 필요합니다! 추가로 이러한 기능을 하는 프록시를 인터셉트 프록시라고 합니다.

그림 8 라우터를 이용한 네트워크 경로 수정

3. 대리 프록시 사용

웹 서버를 대신하는 대리 프록시입니다! 말로만 대신하는 것이 아닌, 웹 서버의 이름과 IP주소 모두 자신이 가져와 사용합니다! 그렇게 되면 클라이언트는 서버와 트랜잭션중이라 생각하지만 사실은 대리 프록시와 트랜잭션중인 것이죠!

웹 서버의 IP주소와 이름은 적절히 다른 것으로 변경 됩니다! 그림 4를 참고합시다!

 

4. 웹 서버가 경로를 수정

웹서버에는 리다이렉트(응답코드 : 305)라는 명령이 있습니다. 이는 서버가 제시한 다른 경로로 향하라는 명령인데 이를 이용해서 클라이언트의 요청이 서버로 온다면 프록시로 향하게 만들  수 있습니다. 이 명령을 받은 클라이언트는 바로 우회된 경로의 프록시와 트랜잭션을 실시 합니다.

 

그림 9 웹서버가 리다이렉트를 통해 경로를 수정함

 

프록시에 대한 주의점

1. 서버와 프록시에 넘겨주는 URI는 다르다.

서버의 경우 자기자신의 대한 정보를 이미 알고 있기 때문에 호스트명, 스킴, 포트번호가 필요가 없습니다.

하지만 프록시의 경우에는 원서버와 결국 연결해야되기 때문에, 원서버의 호스트명, 스킴, 포트번호가 존재하는 완전한 URI를 제공받아야 합니다!

이 경우에는 클라이언트나 타 서버가 프록시와 연결되는 것을 인지하고 있어야 합니다!!!

 

2. 대리 프록시와 인터셉트 프록시는 부분 URI를 지원해야 한다.

대리 프록시는 서버를 대신하는 역할을 가진다. 그렇기 때문에 원서버와 커넥션을 맺는 것으로 착각한 클라이언트는 대리 프록시로 완전하지 않은 부분 URI를 전송합니다.

인터셉트 프록시 역시 원서버로 향하는 트래픽을 몰래 가져오는 것이기 때문에, 부분 URI를 가져올 것입니다.

그렇기 때문에 일반 프록시와 다르게 이 두 프록시는 반드시 부분 URI를 지원하는 기능을 가져야 합니다!

 

부분 URI로 서버의 정보를 찾는 방법

• Host 헤더가 있다면 이를 이용해 원 서버의 이름과 포트번호를 추출한다.
• Host 헤더가 없다면?
  • 대리 프록시의 경우에는 그 프록시가 원 서버의 정보 (주소, 포트)를 가지고 있다.
  • 인터셉트 프록시라면 기존에 향하던 트래픽에 원 서버의 정보가 있다.
• 모두 실패했다면? 반드시 에러메세지를 반환해야 한다!

 

※ 프록시를 이용한 URI 분석

 

그림 10 프록시를 이용한 URI 분석

1. IP로 변환하기 위해 호스트명 입력

2. DNS 서버가 IP로 변환 시도 ---- 성공시 4, 실패시 2

3. 자동확장기능 실시 (www, .com 등등 붙이기)

4. 변환 성공 후 IP 반환

5. 서버로 연결

• 프록시를 사용하는 경우 여러가지 방법으로 트래픽을 프록시로 우회
• 이 IP주소가 유효한지 검사 (혹시 죽은 IP 주소는 아닌가?)

6. 유효한 IP라면 커넥션 생성, 만약 아니라면 역방향 DNS 룩업이나, 다른 IP 주소 검색

 

3. 프록시를 지날 때 메시지에는 'Via 헤더'를 남겨야 한다.

예상치 못한 상황에 대비하기 위해서 메시지가 어느 프록시를 지났는지에 대한 증거를 남겨야 합니다.

이를 위해서 'Via 헤더'를 생성해 지나온 프록시에 대한 정보를 저장해둡니다!

 

구성은 다음과 같습니다.

Via: {프로토콜 이름/버전} {노드 이름} {코멘트}

ex) Via: Http/1.0 proxy.abc.net 진단 정보...

이러한 Via 헤더가 쭉 프록시를 거칠 때 마다 이어지며, 응답 메시지에서의 Via 헤더는 요청의 역순 입니다.

그림 11 Via 헤더 순서

 

4. 각 프록시들의 상호운용성을 확인 해야 한다.

동일한 컴퓨터가 아니기 때문에 메시지를 전송할 때 해당 포멧이 지원이 되는지, 메시지의 변형이 있을 때 (홉별 헤더 삭제, 등) 오류를 발생하지는 않는지에 대해 체크를 해야 합니다.

 

1) TRACE 메서드 사용

TRACE 메서드는 프록시를 추적하면서 어떤 프록시를 지나는지, 또 요청 메시지를 어떻게 수정했는지에 대해 체크를 할 수 있습니다. 프록시들을 거쳐가며 정보를 수집 한 후 서버에게 메시지가 도달하면, TRACE 정보를 클라이언트에게 첨부해서 전송합니다.

추가적으로 OPTION 메서드를 이용하면 각 프록시에서 지원하는 메서드 정보 역시 알 수 있습니다.

HTTP/1.1에서는 Allow 헤더를 사용합니다

1. 본문 포맷을 수정해 데이터 표현 방식을 변환 [본문으로]