네트워크 패킷 제어 기술
개요
네이버 클라우드 기술블로그에 있는 네트워크 패킷 제어 기술을 보고 재작성하였습니다.
이번에도 역시 모르는 사람이 보아도 이해할 수 있을 정도로 단순하게 작성해보도록 하겠습니다.
네트워크 패킷?
네트워크 패킷은 우리가 인터넷을 사용하여 통신할 때 주고받는 우편과 비슷하다고 생각하시면 됩니다.
우리가 네이버 웹사이트에 접속한다고 생각해봅시다. 웹브라우저는 웹페이지를 요청하는 패킷을 네이버에 전달합니다. http request 패킷을 만들어 네이버 서버에 보내게 되면, 네이버 서버에서는 이를 확인 후 웹페이지의 내용을 보내주게 됩니다.
이를 우편에 비유하면 다음과 같습니다.
- 웹브라우저는 웹페이지 정보를 요청하는 편지를 적습니다.
- 웹브라우저는 보내는 사람은 자신의 IP 주소를 적고, 받는 사람에는 네이버 IP 주소를 적어서 우편을 보냅니다.
- 네이버 서버는 이를 받은 후 요청한 웹페이지의 내용을 작성합니다.
- 서버에서 받은 우편을 기반으로 보내는 사람은 네이버의 IP를 적고, 받는 사람에는 요청한 사람의 IP를 적어 우편을 보냅니다. (답장을 보냄)
- 네이버로부터 우편을 받은 웹브라우저는 이 우편의 내용을 해석하여 웹페이지를 화면에 나타냅니다.
이렇게 표현하면 조금 이해가 쉬우실것으로 생각됩니다. 웹페이지에 접속할때, 카카오톡으로 문자를 보낼때, 유튜브로 영상을 시청할때 모두 위와같은 방법으로 서버와 우편을… 아니 패킷을 주고 받는다고 이해하시면 됩니다.
네트워크 패킷 제어 기술
본 포스팅에서는 Mirroring, Inliine, Proxy 에 대해서 작성해보려 합니다.
위와 같은 네트워크 패킷 제어 기술은 주로 네트워크 모니터링 솔루션, 접근통제 솔루션, 네트워크를 통한 컨텐츠 보호 솔루션, DB 보안, 방화벽, IDS(침입탐지), IPS(침입방지) 등의 네트워크를 제어하는 솔루션에서 많이 사용하는 기술입니다.
Mirroring 방식
미러링은 말 그대로 네트워크 패킷을 미러링하는 방법입니다.
지나가는 패킷을 복제한 뒤 패킷을 흘려보내어 모니터링하는데 사용할 수 있습니다.
위에서 설명한 예로 들어보면, 우체국에서 사람들이 보낸 편지를 복사한 뒤 보내는것으로 생각할 수 있습니다. 그러면 우체국에서는 우편을 확인할 수 있겟죠.
그러면 이렇게 복제된 패킷은 어떻게 사용하야할까요?
패킷을 미러링하여 가져왔다면, 이를 세션을 관리해야 합니다. 세션이 뭐냐…..면, 하나의 클라이언트가 하나의 서버와 주고 받는 패킷을 하나의 세션이라고 합니다. 만약 유튜브를 시정하면서 게임을 하고있다고 하면 두개의 세션으로 통신을 하고 있는 것입니다.
미러링 된 패킷을 세션으로 분리한 뒤 모니터링한 후 유해한 트래픽이 보이면 알람을 발생시킬 수 있습니다. 또는 해당 세션을 차단하여 트래픽을 정지시킬수도 있는데, 목적지에 RST 또는 FIN 패킷을 보내 서버와의 연결을 끊을 수 있습니다. 쉽게 표현하자면, 우체국에서 서버에 데이터를 그만 보내달라고 우편을 보내는데, 이때 보내는 사람을 우체국 주소가 아닌 사용자 주소로 보내는 것입니다. 그렇게 되면 서버는 해당 사용자가 세션을 종료했다고 생각하여 데이터를 그만 보낼 수 있겠습니다.
Inline 방식
Inline 방식은 특정 장비로 네트워크 패킷을 거쳐 가도록 하는 방식입니다. 미러링이 패킷을 복사한 뒤 보낸다면, A에서 B로 패킷을 보낼때 C에서 확인 후 가게 하는 방법입니다.
위의 예로 들자면 우체국에서 편지 내용을 확인한 후 보내는 방법이라고 할 수 있겠습니다.
inline 방식은 주로 세션을 차단하기 위해 많이 사용합니다. 방화벽, 침입방지시스템(IPS)와 같은 장비의 차단 방식도 inline 방식으로 네트워크 패킷 제어를 합니다. 차단 동작은 패킷을 버리거나 RST 또는 FIN 파킷을 만들어 원래의 패킷 대신 전달하는 방법을 사용합니다. 미러링과의 차이점이라면 패킷을 흘려보내기 전에 차단시킬 수 있다는 점이 있습니다. (미러링은 이미 지난 후에 알림)
차단 방식을 다시 위의 편지로 예를 들자면,
우체국에서 편지를 읽어보고 스팸편지(영국에서 보낸 행운의편지?)라면 해당 편지를 버리거나, 원래 목적지에 스팸편지가 와서 차단했습니다. 라는 내용의 편지를 보내는 것입니다.
이러한 inline 방식을 사용할땐 주로 FOD(Failover device) 장비를 사용합니다.
FOD는 네트워크 패킷이 inline이 되도록 해주며, 비상시에는 bypass로 전환하여 네트워크의 안정성을 유지시켜주는 장비입니다.
만약 inline 을 통해 패킷을 확인하는 장비가 장애가 발생한다면 해당 네트워크는 단절이 됩니다. FOD 는 장비와 health check를 통해 주기적으로 상태를 확인하고, 장비에 장애가 발생한다면 bypass로 전환하여 네트워크 장애를 막아줍니다.
편지를 배송하는 중 우체국이 문을 닫고있다면 바로 목적지로 전달하는 방식이라고 이해하면 되겠습니다. (이건 예시가 좀 억지인 듯 한데….. 아무튼!)
Inline 방식의 단점은 미러링 방식에 비해 처리할 수 있는 양이 작다는 점입니다. 미러링은 필요한 패킷만 복사하여 처리할 수 있기 때문에 부하가 적습니다. 하지만 inline 방식은 모든 패킷을 받아야하기 때문에 미러링방식보다는 부하가 많이 발생합니다.
Proxy 방식
Proxy 방식은 네트워크 장비 없이 순수 SW 만으로 구동되는 방식입니다. Proxy 는 종종 들어보았을법 한데 뭔지는 모르는 분들도 꽤 되실것 같습니다.
A에서 B로 패킷을 보낼때 중간에 Proxy 서버를 거쳐 가게하는 방식입니다. A는 B로 패킷을 보낼때 직접보내지 않고 Proxy 서버로 보냅니다. 프록시 서버는 A 패킷의 요청을 대신 B에게 전달해줍니다.
Proxy 방식은 왜 사용하는 것일까요?
Proxy 우회 라는 말을 들어보셨을껍니다. 해외 사이트에 접속하고 싶은데, 접속이 막혀있는경우 Proxy 서버로 우회할 수 있습니다. Proxy 서버로 요청을 보내면 Proxy 서버가 대신 응답을 받아 전달해줍니다.
앞서 본것과 같이 쉬운예를 들자면, 해외 물건 구매대행을 생각해볼 수 있습니다. 직접 구매하기가 어려우니 구매대행자에게 대신 요청하면 구매대행자가 직접 물건을 사서 전달해주게됩니다. 이 구매대행자가 Proxy 서버라고 생각하시면 됩니다.
그 외에도 ssl 복호화를 위해 Proxy 서버를 사용하는 경우도 있습니다. A와 B 간의 통신이 SSL 암호화가 되어있다면 미러링이나 인라인방식으로는 패킷의 정보를 확인할 수 없습니다. 그렇게되면 네트워크 장비가 탐지를 할 수 없게됩니다.
하지만 중간에 Proxy 서버를 두고 A <-> Proxy 서버간에 SSL 통신을 하고, Proxy 서버에서 패킷 복호화 후 B에게 전달하게 되면 네트워크 장비가 패킷의 정보를 확인하고 올바른 제어를 할 수 있게 됩니다.
참고
- https://blog.naver.com/n_cloudplatform/221653186482
Leave a comment