VPN과 Proxy와 Tor - Proxy

David Im·2022년 8월 19일
0

VPN & Proxy & Tor

목록 보기
1/2
post-thumbnail

본 글은 야간모드에 최적화 되어있습니다. 우측 상단에서 해 혹은 달모양을 클릭시어 velog 설정을 야간모드로 해주시면 더욱 편안하게 읽으실 수 있습니다.

서론

오늘은 회사에서 정기배포가 있는날이라, 배포 CI/CD를 돌려놓고 남는 시간동안 잠깐 프론트 개발하시는분과 이야기를 했다.
프론트 개발자분께서 갑작스레 질문을 하나 던지셨는데 처음에는 문득 아무생각없이 대답했는데 그것에 이어져서 조금 더 정확하게 개념을 다시 머릿속에 세우고자 정리를 했다.

글로벌 서비스를 하고 있고, 앞으로 닥칠 문제에 대해서 해결방법을 어떻게 생각하냐는 의미인듯 했는데 질문은 아래와 같았다.

OO님, 저희 이제 GCP로 넘어가잖아요. 근데 Google은 중국에서는 정상적인 경로로 막혀있는데 어떻게 Google 서비스를 이용하게 할 수 있을지 생각나는 방법 있으세요?

처음에는 아무생각없이, 중국은 만리방화벽때문에 제대로 사용을 못하니까 전부 VPN 쓰도록 해야하지 않을까 싶다가, 우리쪽에 Proxy를 달면 되겠구나 싶어서 아래와 같이 대답했다.

유저가 VPN 사용하거나, 그게 아니라면 서버앞에 Proxy 붙여서 IP 우회하게 하면되지 않을까요? 어차피 VPN이나 Proxy나 둘 다 우회시켜서 접속가능하게 하는거잖아요.

여기서 말을 전달하다가 든 생각이 '어? VPN이랑 Proxy 둘 다 우회하는 역할이긴한데 뭔 차이였더라? 보안차이였던거같긴한데..' 하는 생각이 들었다.

전공이 정보통신이다보니, 전공시간에 배웠던 기억이 희미하게나마 나는데 네트워크통신 개론을 들은지가 어언 4~5년이 지나가다보니 차이점도 가물가물해졌기에 다시 찾아보고 공부했다.

첫번째로는 프록시(Proxy)에 대해서 학습한 내용을 작성했다.

1. Proxy


서버를 통해서 다른 네트워크 서비스에 간접적으로 접근할 수 있게 해주는 시스템 혹은 응용프로그램이다.

처음 생긴 목적은 인터넷 속도 향상이라고 하는데, 이를 통해 프록시 서버안에 캐시를 저장해놓게되면 빠른 통신이 가능해진다.

  • why?
    캐시 안에 있는 정보를 요구하는 요청에 대해서는 굳이 원격 서버에서 데이터를 가져올 필요가 없게 되기때문에 전송 시간 절약 및 불필요한 외부 연결을 하지 않아도 된다. 즉 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목 현상의 문제를 어느정도 보완할 수 있다.

주로 우리가 프록시를 사용하는것은 특정한 서버나 서비스로 라우팅시키거나 ip 우회접속을 시켜주기 위해서 사용한다.

이처럼 프록시 서버 자체는 우리가 접속중인 웹사이트와 사용하는 기기 사이에서 중개인 역할을 하고 트래픽 자체는 호스트 서버 연결에 사용되는 원격 시스템을 통해 전달한다.

프록시를 사용할 경우 실제 IP 주소를 숨길 수 있고, 웹 사이트에서는 원래 IP 주소가 아닌 프록시 서버의 IP주소를 인식해서 접근하게 된다.

하지만 응용프로그램 수준에서만 동작하는 것이라서 앱에서 발생하는 트래픽만 라우팅이 가능하고 트래픽에 대한 암호화를 처리할수는 없다

프록시 서버 유형

HTTP Proxy

단순하게 브라우저단에서 발생하는 트래픽을 설정된 경로에 맞게 라우팅해주는 프록시로 웹페이지에서의 사용에 가장 적합하다.
이녀석은 정말 라우팅에 적합한 녀석으로, 할 수 있는 일은 클라이언트 (사용자 브라우저)로부터 호스트 (사용자가 접근하고 싶은 웹 사이트를 호스팅하고 있는 서버)로 웹 트래픽 (HTTP와 HTTPS) 리다이렉트하는 것으로, 이로써 효과적으로 사용자의 IP를 웹 트래픽의 소스로 감출 수 있다.

단순한 라우터 역할만 수행하는 듯하다.

SOCKS Proxy

우선 SOCKS(Socket Secure)는 프록시 서버를 통해 클라이언트와 서버간에 네트워크 패킷을 교환하는 인터넷 프로토콜이다.

실제로 SOCKS 서버는 TCP 연결을 임의의 IP주소에 프록시하고 UDP 패킷을 전달하기 위한 수단을 제공한다.

웹페이지뿐 아니라 응용프로그램에서도 사용할 수 있는 프록시이고 하면서, 거의 모든 트래픽에 대한 처리를 진행할 수 있지만 HTTP 프록시보다 연결속도가 느리고 로딩시간이 길다.

SOCKS 프록시에는 여러 버전이 있지만 SOCKS5는 네트워크 트래픽 유형을 구별할 수 없기 때문에 가장 유연한 서버 프로토콜로 간주되는 확장이다. (토렌트 파일의 FTP, 웹 브라우징의 HTTP, 이메일의 SMTP 등)

장점으로는 IP 주소를 숨기고 뛰어난 성능을 제공하기때문에 토렌트나 P2P 서비스에 이상적인 모습을 보이고, 암호화가 없기때문에 VPN보다는 속도가 빠르다. 또한 TCP/UDP 프로토콜을 모두 사용할 수 있는 효율적인 연결성을 지니고 있다.

단점이라면 실제 IP를 변경하지만 트래픽 자체를 암호화하지는 않는다는 것.

Transperate Proxy

사용자가 프록시를 사용하고 있다는것을 눈치채지 못하도록 되어있는 말 그대로 "투명" 프록시이다.
위에 설명한 두개의 프록시가 사용자의 요청을 받아 프록시IP를 통해 대신 전달하지만, 해당 프록시는 클라이언트 측 구성을 필요로 하지 않고 프록시IP를 변환하지 않고 전달하며, 전체 네트워크에 설정되어있기때문에 개별적인 클라이언트에게는 보이지 않는다.그래서 프록시를 통해 라우팅 되고 있다는 사실을 인지하지 못한다는 것.

그럼 어디에 사용되는가?

  • 검열 혹은 모니터링
    회사같은 곳에서 보면 인트라넷 같이 액세스에 권한이 필요하거나 외부 유출을 막는 곳에서 주로 사용한다고한다. 바로바로 모니터링이 가능하고 특정 사이트에대한 화이트리스트, 블랙리스트를 작성하여 접근을 차단하는 것도 가능하다.

  • 대역폭 사용량 절약
    예를 들어 특정 소프트웨어 업데이트를 100대의 컴퓨터에 모두 다운로드할 경우, 투명프록시를 사용하는 회사라면 1대의 컴퓨터에 다운로드를 요청하기만 하면 된다.
    한 대의 컴퓨터에 다운로드 받은 요청 내용은 캐시되어 프록시 서버에 저장되고, 다른 컴퓨터가 동일한 소프트웨어를 요청하는 경우 인터넷 클라이언트에 요청하지 않아도 프록시 서버에서 곧바로 전송 가능하다.

  • 사용자 인증
    공용 WiFi를 제공하는 일부 회사에서도 투명 프록시를 사용하여 사용자를 인증한다고 한다. 우리가 카페같은 곳에서 와이파이를 사용하려고 할때 로그인페이지로 넘어가는 곳들이 있다. 그런곳에서 보통 투명 프록시를 사용한다. 물론 해당 과정을 거칠 경우 접속한 와이파이를 통하고 있는 사용자의 방문 웹사이트 등을 추적하는 것도 가능하다.

프록시 서버의 형태

포워드 프록시(Foward Proxy)

클라이언트가 특정 웹사이트에 접근할 때, 직접 접근을 시도하는게 아니라 포워드 프록시서버가 요청을 받아 해당 웹사이트로 연결하고 그 결과를 클라이언트에게 전달(포워딩)한다.

포워드 프록시가 클라이언트와 서버간의 통신 중계 역할을 하기 때문에 캐싱을 사용해서 데이터를 저장하는 경우도 있으며, 서버는 포워드프록시로부터 클라이언트의 요청을 받기 때문에 클라이언트의 정보를 알 수 없다.

리버스 프록시(Reverse Proxy)

포워드 프록시와 반대로 클라이언트 사이드에서 프록시가 처리하는 것이 아니라, 클라이언트가 요청을 넘기면 요청을 받는 서버앞에 존재하는 리버스 프록시가 그 요청을 대신받아 적절한 서버로 분배한다.
이 경우 클라이언트는 서버측의 정보를 알필요 없이 리버스 프록시에게 요청만 하면 된다.

포워드 프록시방식은 클라이언트가 프록시 서버를 타고 요청하는 서버에 직접요청을 날리기때문에 DB접근까지 가능해질 수 있다는 위험성이 있어 구현적으로는 리버스프록시를 많이 사용한다.

리버스 프록시가 요청을 받아 서버단에 전달하기 때문에 내부 서버의 로드밸런싱이나 서버 확장에 유리하고, 클라이언트가 요청하는 엔드포인트는 리버스프록시 서버이기때문에 클라이언트는 내부에 존재하는 실제 서버의 정보는 알 수 없다.

참고

  • 리버스 프록시로 서비스를 제공하게되면 WAS에서 REMOTE_ADDR을 가져오게 되면 리버스 프록시 서버의 IP를 가져오기때문에 클라이언트의 IP를 제대로 얻을 수 없으므로, 이전 포스트 Django에서 Request Header로 IP얻기에서 설명했던 XFF(X-Forwarded-For)를 사용하면 얻어올 수 있다.

DMZ(Demilitarize Zone)

이 개념은 이번에 프록시에 대해서 제대로 찾아보다가 발견하게 되었는데, 인프라적이나 아키텍쳐적으로 알아두면 좋은 내용일 듯하여 포함하였다.

일반적으로 기업들의 네트워크 환경은 외부망(External Network)와 내부망(Internal Network)로 구성되고 그 사이에 DMZ(Demilitarize Zone)이라는 것이 존재한다고 한다.
외부망, DMZ, 내부망 사이에는 방화벽을 구축하여 기본적인 액세스에 대한 보안규칙을 설정한다.

DMZ에는 메일서버, 웹서버, DNS 서버등을 배치하고, 내부망에는 WAS를 위치시키고 DBMS와 연결되는 구조로 구성한다.

이때 만약 DMZ가 존재하지 않고 WAS를 최전방에 배치하게 될 경우 어떻게 될까?

만약 해커가 해킹을 시도하는 경우 WAS가 최전방에 배치되어있기때문에 바로 DBMS로 접근이 가능해져 DB의 데이터까지 털려버리는 보안상으로 엄청난 리스크가 생길수 있다.

그걸 방지하고자 DMZ를 배치하여 그곳에 웹서버를 두고서 리버스 프록시를 설정한다. 그리고 WAS를 내부망에 배치하여 리버스 프록시로 동작하는 웹서버만 내부 WAS와 연결한다. 이렇게 구성할 경우 웹 서버가 해킹당하더라도 해커는 다시 내부망에 접속하기 위해 2차 방화벽을 돌파해야 하기 때문에 보안적으로 강해질 수 있다.

포워드 프록시와 리버스 프록시의 차이점

1. 엔드포인트(End-Point)의 차이

  • 포워드 프록시는 "실제 서버" 가 엔드포인트이다.
  • 리버스 프록시는 "리버스 프록시 서버" 가 엔드포인트이다.

2. 어떠한 것을 감추는가의 차이

  • 포워드 프록시는 클라이언트 요청 앞단에 프록시를 배치하므로, 클라이언트를 감춘다.
  • 리버스 프록시는 서버 앞단에 프록시를 배치하므로, 서버를 감춘다.

프록시 서버를 사용 하면 얻을 수 있는 장점

  • 아키텍쳐와 같은 구성이나 성능적인 측면에서 강점을 가져간다.
    이처럼 서버의 로드밸런싱역할도 수행할 수 있기때문에, 리버스 프록시 서버 앞단에 캐시서버를 붙이거나 SSL 하드웨어 가속기등을 연동하면, 아키텍쳐 측면에서 성능향상에도 도움이된다고 한다.

    리버스 프록시를 사용해서 동작하는 예로는 cloudflareakamai같은 CDN 서비스들이 리버스 프록시로 동작하는 캐시 서버라고 한다. 즉, CDN을 연동한다면 DDOS 공격등에 효과적으로 방어가 가능하면서도 안정적이고 빠른 서비스를 제공할 수 있다는 장점이 있다.
  • 클라이언트나 서버를 감추기 때문에 보안적인 측면에서 우수하다.
    포워드 프록시는 클라이언트를 감춰주기때문에 개인 보안적으로 우수한 측면을 가져갈 수있고, 리버스 프록시의 경우에는 위에 설명한 DMZ와 리버스 프록시 기본 개념처럼 요청에 대한 엔드포인트를 리버스 프록시가 받아서 처리하기때문에 실제 동작하는 WAS나 DBMS로의 직접적인 액세스를 차단할 수 있고, 클라이언트는 리버스프록시 서버를 실제 엔드포인트로 알기 때문에 보안적인 측면에서 강점으로 가져 갈 수 있다.

  • 트래픽 분산 효과
    일부 프록시 서버는 로드 밸런싱도 제공하여 여러 대의 분산된 서버가 있다면 서버의 트랙픽을 분산시켜 준다.
    그리고 앤드 포인트마다 호출하는 서버를 설정할 수 있기때문에 역할에 따라 서버의 트래픽을 분산시킬 수 도 있다.

    리버스 프록시를 Cluster로 구성할 경우, 가용성을 높일 수 있고, 사용자가 증가하는 상황에 맞게 웹 서버나 WAS를 유연하게 관리할 수 있다는 장점이 있다고한다.
    리버스 프록시 앞단에 L4 Switch 혹은 로드밸런서를 붙이게 되면 RR, Least Connection등 상황에 맞는 분배알고리즘을 적용해 서비스 신뢰성을 높이는 것도 가능하다고 한다.

마무리

간만에 컴퓨터공학 관련자료, 그중에서도 내 전공분야였던 네트워크 관련된 자료를 찾아보니 흥미가 굉장히 올라왔다. 특히 리버스 프록시가 굉장한 내용들이 많아서 찾아보다 보니 강점들을 많이 가지고 있고, 사실상 거의 모든 기업에서 적용하고 있다고 봐도 무방한 수준의 내용들이었다. 알아두면 반드시 좋은 개념이라고 생각하고 아키텍쳐 구성등이 필요한 경우에는 필수적인 개념이라는 생각이 들었다.

공부하면서 찾아본 참고자료들에도 자세한 내용들이 있으니 참고해도 좋을 듯 하다.
(사실 찾아본 참고자료들 공부하면서 요약하고 정리한 내용인건 안비밀...)

막상 시작하긴 어렵지만 역시 파고들면 파고들수록 재밌어지는게 컴퓨터분야이고 코딩분야인듯하다

참고자료

profile
코더보다 개발자로, 결과와 과정의 시너지를 만들어 가고 싶은 주니어 개발자

0개의 댓글