[Newtork] 네트워크의 3가지 구조: Inline, Out of path, Proxy

🔊 해당 포스팅은 인프런 강의 널널한개발자님의 외워서 끝내는 네트워크 핵심이론 - 응용 내용을 공부하면서 배운 내용을 저만의 방식으로 재정리하고자 하는 목적 하에 작성되는 포스팅입니다. 아래 포스팅에서 사용되는 모든 자료는 제가 직접 재구성했음을 알립니다.

 

우리의 노트북으로 구글 웹서버에 접속할 수 있는 것은 네트워크 덕분이다

---

이번 포스팅에서는 네트워크의 대표적인 3가지 구조인 Inline, Out of path, Proxy 각각에 대해 알아보도록 하자. 만약 네트워크를 공부하다가 못 보던 네트워크 장치(스위치)에 대해 알게 되었다고 한다면 가장 먼저 앞으로 소개할 3가지 네트워크 구조 중 어떤 것에 속하는지 판단부터 해보자.

(참고로 앞으로 소개할 네트워크 구조 중 하나에만 반드시 속해야 하는 것은 아니고 한번에 2개의 구조에 같이 속할 수도 있다)

 

앞으로 소개할 네트워크 구조는 크게 2가지 특성 관점에서 설명하려고 한다. 첫 번째는 해당 네트워크 구조가 다루는 데이터 단위, 두 번째는 해당 네트워크 구조의 기능이다.

1. 패킷을 필터링하는 네트워크 : Inline 구조

가장 먼저 배울 구조는 Inline(이하 인라인) 구조이다. 인라인 구조를 갖는 네트워크 장치 중에서 우리 주변에서 가장 쉽게 볼 수 있는 것이 있다. 바로 라우터 장치, 공유기 장치, 방화벽, IPS(침입 방지 시스템)이다. 인라인 구조에서 다루는 데이터 단위는 OSI 레이어의 L3 계층인 IP 계층에서의 단위인 패킷(Packet)이다. 그리고 인라인 구조는 패킷을 필터링 하는 기능이 존재한다.

 

여기서 필터링을 할 수 있는 이유는 인라인 구조에서는 패킷을 차단(drop)하거나 차단하지 않고 전송(bypass) 중 선택을 할 수 있다는 기능 때문이다. 또한 다른 부분에서 필터링을 또 할수도 있는데, 만약 패킷을 차단하지 않고 전송(bypass)하는 선택을 했다고 했을 때 해당 패킷을 어떤 네트워크 인터페이스(ex. 다른 라우터 장치 또는 L2 Distribution/Access 스위치 등..)를 목적지로 해서 전송할지를 선택 즉, 필터링 하는 기능을 한다.

2. 패킷을 감지하는 네트워크 : Out of path 구조

다음으로 알아볼 구조는 Out of path 구조이다. Out of path 구조도 마찬가지로 다루는 데이터 단위가 패킷이다. 하지만 인라인 구조와는 달리 필터링 기능이 없으며 오로지 패킷을 읽기만 가능한 Read Only 기능만 존재한다. 이렇게 읽기만 가능하기 때문에 자연스레 Out of path 구조의 네트워크는 주로 네트워크 보안을 감지하거나 네트워크 장애를 감지하는 센서 기능, 더 나아가 감지한 네트워크 패킷을 분석하는 기능을 주로 수행한다. 

 

네트워크 장애나 보안을 감지 즉, 센서 기능을 수행하기 위해서는 네트워크에서 흐르는 패킷 데이터를 따로 수집해야 하고, 이에 따라 수집하는 물리적인 장치가 필요하다. 이 때, 패킷 데이터를 따로 수집하기 위해 수행하는 것을 L2 Port Mirroring 이라고 한다. 이 용어에 대해 잠시 알아보도록 하자.

 

우선 패킷 데이터를 수집하기 위해서는 L2 스위치 종류(L2 Distribution/Access 스위치 등) 중 한 장치의 포트 즉, 인터페이스 단자에 Sensor 용 기기를 연결해서 L2 스위치로 흐르는 프레임(L2 스위치이기 때문에 패킷보다는 프레임이라는 용어를 사용)을 Sensor 용 기기로 복사 붙여넣기 즉, 미러링하는 것이다.

 

L2 Port Mirroring 이란?

 

참고로, 위에서 말한 L2 스위치의 '포트'라는 용어는 어플리케이션 계층에서 프로세스의 식별자인 포트번호를 의미하지 않는다. 계층에 따라 포트라는 용어가 의미하는 바가 약간 상이함을 알아두자.

 

L2 스위치에서의 포트는 위 그림에서 선을 꼽는 구멍인 인터페이스 단자를 의미한다

 

그런데 이 미러링은 사실 부하가 매우 큰 작업이기 때문에 성능이 좋은 하드웨어 장치가 요구된다. 그래서 이러한 센서를 위한 용도의 하드웨어 장치가 따로 존재하는데, 이를 Tab 이라고도 부른다.

3. 소켓 스트림을 필터링하는 네트워크 : Proxy 구조

마지막으로 알아볼 구조는 Proxy(이하 프록시) 구조이다. 프록시 구조는 이전 구조들과 다르게 다루는 데이터 단위가 소켓 스트림이다. 소켓 스트림이라는 것은 곧 유저 모드의 애플리케이션에서 다루는 데이터를 의미한다. 그래서 인라인, Out of path 구조에서는 다루는 데이터 단위가 패킷이기 때문에 사람의 눈으로 확인하기 위해서는 이 패킷들을 조립하는 복잡한 구조를 거쳐야 했지만, 프록시 구조에는 이미 조립된 상태인 소켓 스트림이기 때문에 프록시 구조에서는 네트워크를 통과하는 데이터를 파일 단위로 볼 수 있게 되어 사람의 눈으로 식별하고 분석하기 매우 용이한 상태가 된다. 그리고 프록시 구조에서는 필터링 기능이 있다. 필터링이라 함은 소켓 스트림이 프록시를 통과하도록 두느냐 마냐를 의미한다.

 

프록시라는 이름인 영어 단어 Proxy의 의미인 '대리'에서도 알 수 있듯이 프록시는 소켓 스트림 데이터를 다룸으로써 유저 모드 애플리케이션에서 스트림 전체를 모니터링할 수 있게 된다. 그래서 아래에서 소개하겠지만 프록시 구조의 네트워크는 주로 통신을 우회하는 데 사용된다.

 

그런데 프록시는 그 프록시가 어떤 목적인지와 어떤 관점인지에 따라 약간 구조가 달라질 수 있다. 이에 대해 하나씩 알아보도록 하자.

3-1. 우회하기 위한 Proxy

프록시 서버는 네트워크 우회 통신을 하기 위해 주로 사용된다. 그리고 아래의 구조는 클라이언트 관점이다. 먼저 아래와 같은 통신 구조가 있다고 해보자.

 

PC1이 구글 웹서버와 통신한다고 해보자

 

예를 들어서 PC1은 한국에 있는 컴퓨터라고 가정해보자. 그리고 통신하려는 목적지인 구글 웹서버는 미국에 있다고 해보자. 이 때, 프록시를 사용하지 않고 일반적으로 네트워크 통신하는 과정은 위 그림의 회색 실선과 같다. 그런데 이러한 구조에서는 특징이 하나 있다. 구글 웹서버의 관점에서, 자기 자신에게 통신 요청을 보낸 서버 즉, PC1에 대한 정보를 구글 웹서버는 다 볼 수 있다. 위 그림에서는 구글 웹서버는 네트워크에 있는 데이터를 보고 이 요청을 보낸 서버의 이름이 PC1 이고 IP 주소가 무엇이고 등 여러가지 정보를 알 수 있다. 다시 말해 출발지 서버에 대한 정보를 모두 알 수 있다.

 

그런데 PC1이 구글 웹서버에 자신의 정보를 노출하고 싶지 않을 수 있다. 이렇게 클라이언트 자신의 IP 주소와 같은 정보를 숨기기 위해서도 프록시를 사용하기도 한다. 이런 경우에 프록시 서버 덕분에 구글 웹서버에서 볼 수 있는 출발지 IP 주소는 PC1의 주소가 아닌 프록시 서버의 IP 주소가 된다.

 

물론 또 다른 경우에, 아래 그림처럼 인터넷 즉, 정확히 말하면 인터넷을 제공하는 업체인 ISP(Internet Service Provider)가 PC1이 접속하려는 구글 웹서버를 (그럴리야 없겠지만..) 차단했을 수도 있다.

 

인터넷 제공하는 업체인 ISP가 PC1이 접속하려는 웹서버를 차단시켰다

 

PC1은 어떻게 해서든 구글 웹서버에 접속하고 싶다. 이럴 때 PC1은 프록시 서버를 통해서 구글 웹서버에 우회하여 접속할 수 있게 된다. 물론 이렇게 프록시 서버를 통해 통신하는 방법은 직접 통신할 때보다 당연히 속도가 느려질 수 밖에 없다.

 

이번엔 프록시 서버 구조를 컴퓨터의 3계층 그림으로 이해해보도록 하자.

 

컴퓨터 3계층에서의 프록시 서버 구조

 

가장 먼저 프록시 서버는 소켓을 하나 생성해서 PC1에서 보낼 요청에 대한 대기(Listen) 상태에 있기 시작한다. 그리고 PC1은 프록시 서버로 요청을 보내고, 이 순간 프록시 서버는 프록시 서버 자신이 도착지인 구글 웹서버로 요청을 보내기 위한 소켓을 또 하나 생성한다. 그리고 이를 통해 구글 웹서버로 PC1의 요청을 그대로 보내준다. 위 그림에서 1번~4번 순서를 잘 따라가며 읽어보도록 하자.

3-2. 보호와 감시를 위한 Proxy

두 번째로 알아볼 프록시 구조는 역시 클라이언트 관점이되 보호와 감시를 위한 구조이다. 먼저 클라이언트(PC1)를 감시하는 용도일 때를 살펴보자. 아래는 위에서 살펴본 그림과 비슷한 그림이다.

 

감시를 위한 프록시 구조

 

이전과 다른 점은 프록시 서버가 (PC1 기준의) 내부 네트워크 안으로 이동했다는 점이다. 위처럼 PC1이 구글 웹서버와 통신할 때 해당 프록시 서버를 이용해서 통신하면 프록시 서버 입장에서는 PC1이 구글 웹서버로 어떤 통신을 보내는지 모두 살펴볼 수 있다. 즉, 감시의 기능을 하게 되는 것이다. 위에서 배운것처럼 프록시에서 다루는 데이터 단위는 소켓 스트림이기 때문에 프록시 서버에서는 네트워크에서 흐르는 데아터를 파일단위로 볼 수 있기 때문에 사람의 눈으로 식별이 매우 쉬워진다. 이러한 구조일 때, 프록시 서버는 감시의 역할을 한다.

 

또 한가지 목적으로, 프록시는 클라이언트를 보호하는 역할도 한다. 만약 PC1이 구글 웹서버에서 특정 csv 파일을 다운로드 받는다고 가정해보자.

 

만약 프록시 서버를 사용할 때 구글 웹서버에서 csv 파일을 다운로드 받는다면?

 

먼저 구글 웹서버는 PC1이 요청한 csv 파일 다운로드 요청을 수행하기 위해 csv 파일을 전송할 것이다. 이 때, 프록시 서버를 사용하고 있기 때문에 먼저 프록시 서버로 csv 파일을 전송한다. 이 때, 프록시 서버에도 해당 csv 파일이 저장이 된다. 이 때, 프록시 서버는 구글 웹서버가 전송한 csv 파일이 악성 파일인지 아닌지 등 검사를 함으로써 PC1이 위험에 빠지지 않도록 보호해주는 역할을 하게 된다.

 

그런데 여기서 궁금한 점이 생겼다. 위처럼 다운로드 받은 파일이 프록시 서버를 거친다고 했는데, 만약 다운로드 받는 파일이 프록시 서버의 파일 시스템 용량보다 초과되는 경우는 어떻게 될지 궁금해서 질문을 남겼다.

 

일단 프록시 서버에서는 항상 파일 전체를 다운로드 받는 것은 아니라고 한다. 스트리밍 하듯이 중계를 하기도 한다고 한다. 그래서 어떻게 프록시 서버를 구현할지에 따라 달라질 수 있다. 만약 대용량 파일들 다운로드 받는 경우가 많다면 방금 위에서 설명한 용량 초과 문제를 대비하기 위해 프록시 기능을 그에 맞게 구현하면 된다. 그리고 프록시 서버에 다운르드된 데이터들을 무한정 쌓아두지 않고 참조 주기를 따져 일정 기간이 넘어가면 삭제하도록 구성하는 것이 보통이라고 한다.

3-3. 서버를 보호하자 : Reverse Proxy

다음으로는 서버 관점에서 서버를 보호하기 위한 용도로 사용되는 리버스 프록시에 대해 알아보도록 하자. 예를 들어서, 아래처럼 PC1이 구글 웹서버로 통신하는 상황이라고 가정해보자.

 

WAF는 Web Application Firewall의 약자로, 보안 장치 서버이다

 

이 때, PC1이 해커라고 해보자. 해커는 구글 웹서버를 해킹하기 위해 구글 웹서버에 대한 정보를 알아내려고 통신하려고 한다. 이러한 상황에서 구글 웹서버의 정보를 PC1에 노출시키지 않도록 하기 위해 프록시가 활용되는데, 이러한 프록시를 리버스 프록시라고 부른다.

 

좀 더 구체적인 동작을 이해하기 위해 예를 들어보자. 해커이자 클라이언트에 속하는 PC1은 브라우저에 www.google.com  이라는 구글 웹서버의 도메인을 입력하고 요청을 보낸다. 그 순간 (저번 포스팅에서 배운것처럼) DNS에 해당 도메인에 매핑된 IP 주소를 반환받고, 이 IP 주소로부터 응답을 받는다. 해커는 이 때 응답 값 자체보다는 IP 주소에 더 관심이 있을 것이다. 만약 프록시를 사용하지 않는다면 해커가 받게 되는 IP 주소는 고스란히 실제 구글 웹서버의 IP 주소일 것이다. 하지만 프록시를 사용하게 되면 해커가 받게 되는 IP 주소는 구글 웹서버의 IP 주소가 아닌 프록시 서버의 IP 주소가 된다. 결국, 프록시 서버가 구글 웹 서버를 보호하는 역할을 하게 되는 것이다.

3-4. PC에 설치하는 Proxy

마지막으로, PC에 설치할 수 있는 프록시 서버가 있다. 우선 이 PC에 설치하는 프록시가 왜 필요한지부터 이해할 필요가 있다. 똑같은 예시로, 내 PC에서 구글 웹서버에 접속하려고 한다고 해보자. 그러면 내 PC에서 구글 웹서버로 요청할 때 보내는 네트워크 데이터가 존재할 것이고, 이 데이터들을 분석하고 싶을 수 있다. 하지만 요즘엔 보통 HTTPS로 통신하기 때문에 데이터가 모두 암호화된 상태이다.

 

이렇게 암호화된 데이터를 복호화해서 사람의 눈으로 식별하고 분석하기 위해서 내 PC에 설치할 수 있는 프록시 서버가 존재한다. 대표적으로 Fiddler 라는 프로그램이다. 필자도 시험삼아 본인의 노트북에 해당 프로그램을 깔아보았는데, 10일까지만 무료이고, 그 이후로는 유료구독해야만 이용가능한 프로그램인 것 같다.

 

이렇게 PC에 설치하는 프록시 서버 구조에 대해서 컴퓨터 3계층 관점에서 이해해보도록 하자.

 

컴퓨터 3계층에서의 PC에 설치하는 프록시 서버 구조

 

크롬 브라우저에서 www.google.com  도메인으로 접속한다고 해보자. 그러면 크롬이라는 프로그램이 실행중인 프로세스가 실행될 것이다. 이 때, PC에 설치된 프록시 서버(ex. Fiddler 같은 프로그램)는 소켓을 하나 생성해 크롬 프로세스의 요청을 대기(Listen)하는 포트를 하나 개방할 것이다. 그리고 크롬 브라우저에 입력한 도메인으로 접속할 때 보낸 데이터들이 HTTPS로 프록시 서버로 들어온다. 이 때, 프록시 서버에서는 HTTPS로 암호화된 데이터를 복호화 할 수 있고, 이 때 네트워크 데이터 분석이 가능해진다. 그리고 난 뒤, 프록시 서버가 클라이언트 용(구글 웹서버로 요청 보내기 위함) 소켓을 하나 생성하고 구글 웹서버로 HTTPS 통신을 수행한다.

---

지금까지 네트워크의 구조인 Inline, Out of path, Proxy 구조에 대해 알아보았다. 각 구조마다 특성을 마지막으로 Wrap-up 해보고, 포스팅을 마무리하도록 하자.

 

• Inline 구조 : 패킷 데이터를 다루며, 필터링 기능이 존재. 우리 주변에서 흔히 보는 라우터, 공유기, 방화벽 등이 대표적인 Inline 구조를 갖는다.
• Out of path 구조 : 패킷 데이터를 다루며, 오로지 데이터를 읽는 기능(Read Only)만 갖고 있다. 그래서 네트워크 보안이나 장애를 감지하는 센서 구조로 주로 활용된다.
• Proxy 구조 : 'Proxy'의 한국어 뜻은 '대리'이며 말 그대로, 네트워크 통신을 대리하는 역할을 하며 주로 네트워크 우회가 주요 목적이다. 소켓 스트림 데이터를 다루기 때문에 유저 어플리케이션에서 네트워크 데이터를 쉽게 살펴볼 수 있다. Proxy 구조는 세부적으로 아래와 같이 나뉜다.
  • 우회하기 위한 Proxy : 클라이언트 관점에서 자신의 IP 주소를 도착지 서버에 노출하지 않기 위함 또는 ISP가 도착지 서버를 차단했을 경우, 도착지 서버로 어떻게든 접속하기 위해 네트워크를 우회하기 위한 용도이다.
  • 보호화 감시를 위한 Proxy : 클라이언트 관점에서 클라이언트가 보내는 네트워크 요청을 감시하거나 클라이언트가 서버로부터 특정 파일을 다운로드 받거나 했을 때 해당 파일이 클라이언트를 위험에 처하지 않도록 보호하는 역할을 한다.
  • 서버를 보호하기 위한 Proxy : 서버 관점에서 서버의 정보를 클라이언트(주로 해커)에게 노출시키지 않고 서버를 보호하기 위한 용도이다. 주로 Reverse Proxy 라고 부른다.
  • PC에 설치하는 Proxy : 내 PC에서 특정 서버로 네트워크 통신을 할 때 보내는 데이터를 분석하기 위한 용도의 프록시 서버이다. 대표적인 프로그램으로 Fiddler가 있다.

---

다음 포스팅에서는 우리 주변에서 매우 흔히 볼 수 있는 장치인 인터넷 공유기의 작동 원리에 대해 배워보도록 하자.