[기사]클라우드 시대에 개발자가 알아야 하는 인프라 지식 ‘NAT(Network Address Translation)’@마소

URL : http://news.imaso.co.kr/25351

이번 시간에 다루려고 하는 NAT(Network Address Translation)를 고려하지 않고 네트워크 프로그램을 작성해도 프로그램이 동작하는 데는 큰 이상이 없는 것 같아 보인다. 하지만 이로 인해 여러 가지 문제들이 발생하고 성능에도 많은 영향을 끼칠 수 있다.

한국에서는 3G, LTE와 같은 모바일 망에서 CGN(Carrier Grade NAT)이라는 기술을 사용한다. SKT, KT, LG U+와 같은 큰 네트워크 망사업자가 공유기에서 사용하는 NAT 기술을 이용해 망을 운영하는 기술인데, 한마디로 표현하면 모바일 망 자체가 거대한 공유기로 운영된다고 생각하면 쉽게 상상이 될 것이다. 현재의 IPv4 주소로는 엄청나게 많은 모바일 단말을 수용할 수 없어서 어쩔 수 없이 이런 기술을 운용해야 하지만, 이로 인한 문제점도 적잖이 발생하고 있다.

RTT
한국은 인터넷 강국이다. 우리들이 일반적으로 네트워크 성능과 관련해 이야기하는 Bandwidth 부분에서도 세계 최강을 자랑하지만, 네트워크 상의 응답시간에 직접적인 영향을 끼치는 RTT(round trip time) 또한 매우 좋다. 그러다 보니 일반적으로 한국 개발자들은 네트워크 응답시간이 끼치는 시간에 대해 크게 고려하지 않는 경우가 많다. 업무와 관련해 필자가 진행했던 테스트에서도 한국에서 제작한 앱들은 정말 단순하게 동작하는 경우가 많았고, 해외에서 제작하거나 해외 사용자를 겨냥한 앱들에서는 대체적으로 굉장히 효율적으로 동작하도록 노력하는 모습들이 많이 보였다.

.....

<표 1> 네트워크 애플리케이션 서비스 시 위치에 따른 응답시간

.....

최대한 간단하게 비교하기 위해 로그온, 인증과 같은 컨트롤 과정을 제외하고 1개의 메시지를 통신하는데 3개의 turn이 발생한다고 가정해 본다(3way handshake + request + response + ack and close). 또한 2명의 사용자가 메시지를 서로 주고받는다면 대략 6개의 turn이 발생한다고 가정하자.

<표 2> 네트워크 애플리케이션별 구현에 따른 네트워크 RTT 값

만일 네트워크 프로그래밍을 뛰어나게 잘하는 개발자라면 클라이언트-서버 방식이 아닌 P2P 방식으로 네트워크 애플리케이션을 구현할 것이다. <표 2>의 네트워크 응답시간에 따른 성능뿐만 아니라 또 다른 요소가 개발 방식을 바꾸는 주요 요소인데, P2P 방식의 경우에는 기본적으로 주요 프로세싱을 클라이언트 단말로 넘기기 때문에 초기에 큰 서버가 필요 없다. 거기에 STUN 기반으로 동작해서 중재 서버를 거치지 않고 사용자들끼리 직접적으로 데이터를 주고받게 된다면 서버의 네트워크 대역폭도 많이 사용하지 않게 된다.

네트워크를 고려하고 네트워크 상황에 최적화한 프로그래밍을 하게 될 경우 서버 운영비용도 많이 아낄 수 있고, 호스팅이나 클라우드 사용 시 네트워크 사용료도 많이 줄일 수 있다. 여기에 더해 사용자들이 느끼는 체감 성능은 엄청나게 올라가고 향후 해외 서비스까지도 원활하게 제공할 수 있을 것이다.

이처럼 굉장히 좋은 인프라라도 개발할 때 네트워크를 고려해야 하는 이유는 명확하다.

P2P 기반의 프로그램
처음 P2P 기반의 프로그램이 나왔을 때 많은 이들이 놀라워했던 기억이 떠오른다. 이름이 넵스터였던 걸로 기억하는데 mp3를 사용자끼리 공유하는 앱이었다.

.....

잡한 것은 직접적으로 두 P2P 사용자가 통신할 수 있도록 네트워크 상황을 체크하는 과정이다. 최적의 연결 방법을 찾아서 통신해야 하기 때문에 앱 개발 때 고려해야 할 부분이 많아진다. 특히 문제가 되는 부분은 두 PC 간에 직접적인 통신을 방해하는 NAT  장비나 방화벽 장비인데, 이 부분에 대해 보다 자세히 알아보자.


NAT는 왜 필요한가?

.....

<그림 2> 인터넷의 시초인 ARPANET

초창기에는 클래스별 할당이라는 방식으로 IP를 배분했었다. IP를 신청하면 1600만 개 단위로 IP를 할당한 것이다. 그 뒤로 IP가 부족해서 6만5000여개 단위로 변경되기는 했지만 막상 직원이 1만 명도 안 되는 회사에서 1600만 개(정확하게는 1677만7216개)나 6만5000개를 받게 되면, 나머지 사용하지 않는 주소들은 전 세계 어디에서도 사용할 수 없게 된다. 그러다 보니 주소가 너무 빨리 소진되게 됐고 처음 생각했던 인터넷 구조가 변경돼야 한다는 생각에 이르게 됐다.

IP 부족 현상을 해결하기 위한 대안은 3 단계로 분류됐다.

① 단기 해결책 : 서브네팅
② 중기 해결책 : 주소 변환 – NAT
③ 장기 해결책 : IPng – IPv6

우선 IP 주소 할당의 불합리함을 극복하고 IP 대역을 잘게 쪼개서 효율적으로 사용할 수 있도록 하는 단기 해결책이 나오게 된다. 이로 인해서 인터넷이 좀더 복잡해지긴 했지만 주소 고갈 현상을 해결할 수 있는 아주 훌륭한 방법으로 평가된다. 이와 관련해 상세한 내용은 위키피디아(http://en.wikipedia.org/ wiki/IPv4_subnetting_reference)를 참고하기 바란다.

중기 해결책으로 나온 방법이 NAT이며, 근본적인 해결을 위한 장기 해결책이 IP Next Generation으로 불리우는 IPv6이다.

사실 단기, 중기 해결책이 너무 훌륭해서 장기 해결책인 IPv6가 도입 되는데는 상당히 오랜 시간이 걸렸다. 하지만 단기와 중기 해결책에는 단점도 있어서 서브네팅이나 NAT로 인한 네트워크 복잡성의 증가로 문제가 생길 경우 해결이 어려웠고, 네트워크 엔지니어뿐만 아니라 애플리케이션 프로토콜 개발자까지도 NAT 환경을 고려해서 개발해야 하는 어려움이 따랐다.

그래서 장기 해결책으로 IPv6를 표준화하고 개발하는 측에서는 NAT를 필요악으로 규정하고, IPv6 전환의 목표 중 하나를 간섭 없는 엔드투엔드 통신으로 규정할 정도로 NAT 기법을 없애도록 노력하고 있다.


IP 주소 고갈의 중기 해결책인 NAT
알면 알수록 NAT를 사용할 경우 고려해야 할 사항은 많아진다.

.....

하지만 NAT가 당장 없어질 기술도 아니고, NAT를 알고 네트워크 프로그래밍을 하는 것과 그렇지 않은 것은 아주 큰 차이가 있기 때문에 이에 대해 상세히 알아보자.


.....

NAT에서 공식적으로 사용할 수 있는 주소 체계를 정의한 것과 같다. 사설 주소(Private IP Address)라고 부르는 주소들이 이에 속한다(RFC 1918 참조 : http:// www.rfc-editor.org/rfc/rfc1918.txt).

사설 주소는 인터넷 상의 어디에도 존재하지 않는다. 만일 이 주소를 사용할 때 인터넷과 연결하려면 NAT 기법을 이용해 IP 주소를 공인 IP 주소(Public IP Address)로 변환해서 내보내야 한다.

.....

<리스트 1> 사설 IP 주소
10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

.....

공인 주소와 사설 주소를 어떤 방식으로 매핑하느냐에 따라서 1:1, 1:N, M:N과 같은 형식으로 분류한다. 공인 IP와 사설 IP를 하나씩 매핑할 경우를 ‘1:1’, 공인 IP 하나로 하나 이상의 네트워크(여러 개의 IP)를 매핑할 경우 ‘1:N’, 여러 개의 공인 IP를 여러 개의 사설 IP로 변환할 경우 ‘M:N’이라고 부른다.

1:1 매핑 방식은 IP 주소를 절약하기 위한 기법이 아니라 관리와 보안상 사용하는 기법이기 때문에 이번 시간에는 주로 1:N NAT에 대해서 다루려 한다. 1:N 매핑은 NAT 방식 중 PAT (Port Address Translation) 방식이라고 불린다. 포트를 매핑하기 때문에 1개의 IP로 여러 명이 통신할 수 있다.

PAT 방식은 트랜스포트 레이어의 포트 번호를 변경한다. 1:1 매핑 방식이 아니기 때문에 PAT 기능을 제공하는 장비에서는 항상 NAT 테이블이라는 세션을 저장하는 세션 저장소를 가지고 있어야 하고 이로 인해 방향성이 생기게 된다.

.....


NAT의 역사
NAT가 처음 만들어 지고, 사용되기 시작했을 때는 M:N NAT 기법이 주로 활용됐다.

혼자 모뎀을 이용해서 인터넷에 연결하면 간단하지만 회사에서 여러 명이 인터넷에 연결해야 할 경우 여러 가지 비용 문제가 발생한다.

① 각 PC에 모뎀이 장착될 경우의 비용
② 각 PC에서 각자 모뎀으로 인터넷을 연결할 경우 통제가 불가능
③ PPP 연결에 필요한 ID 유지비용

이런 문제들로 인해서 중앙 집중화된 인터넷 연결 장치가 필요하게 됐고, 인터넷 게이트웨이에 여러 개의 모뎀이 장착돼 사용됐다.

.....

<그림 5> 모뎀 집중식 인터넷 게이트웨이를 사용할 경우 모뎀 회선이 꽉 차면 새로운 사람은 인터넷을 사용할 수 없다.

.....

이때의 인터넷 연결 시스템도 전화처럼 인터넷 연결을 시도하면 모뎀과 외부 회선 하나를 점유해야 했고, 5개의 모뎀이 있는 시스템이라면 전체 회사에서 동시에 5명만이 인터넷을 할 수 있었다.


전화 네트워크와 인터넷 네트워크
전화는 써킷(Circuit) 네트워크라 불린다. 한 명이 전화를 걸 경우 말을 하든 안하든 간에 회선 전체를 점유하게 되기 때문이다. 반면 현재 사용되는 인터넷 기술들은 모두 패킷 기반의 네트워크다. 회선을 한 명이 점유하는 것이 아니라 도로 위의 자동차들처럼 패킷이라는 단위로 데이터가 잘게 쪼개져서 여러 명이 회선을 공유해 사용할 수 있다.

이 기술이 인터넷 연결 시스템에 적용되면서 하나의 모뎀으로 여러 명이 동시에 인터넷을 연결할 수 있게 됐는데, 이때 적용된 기술이 1:N NAT이다.

.....

1:N NAT 즉, PAT 기술을 통해서 공인 IP를 많이 아낄 수 있게 됐는데 이 기술에는 큰 단점이 있다. 우선 가장 큰 단점은 앞서 언급했던 것처럼 통신에 방향성이 생긴다는 점이다. 전용번호가 없는 회사에 전화를 걸 때를 생각해 보자. 직통번호가 없는 회사는 외부로 전화를 거는 것은 가능하나 전화가 올 때는 특정 사람만 받을 수 있다.

NAT가 애플리케이션과 프로토콜에 끼치는 영향?
이제 본격적으로 NAT(PAT)가 네트워크 프로그래밍에 끼치는 영향에 대해 알아보자.

초기에 PAT 기술이 나오고 난 후, 그리고 뒤이어 PAT 기술을 방화벽에 적용한 SPI(Stateful  Packet Inspection) 엔진 기반의 방화벽이 나오고 난 후 몇 가지 통신 문제가 발생하게 된다.

.....

<그림 6> PAT 환경에서 발생한 비동기 애플리케이션 구동 문제

첫 번째 문제는 비동기 애플리케이션의 경우에 생기는 문제다. 예를 들면 비동기 애플리케이션을 작성했는데, 각자 보내고 받는 프로세스가 분리돼 있고 세션을 맺는 방향이 A에서 B, B에서 A 형태로 2개이면 PAT에서는 한 방향만 정상적인 통신이 가능하다.

.....

<그림 7> PAT 환경에서 컨트롤 프로세스와 데이터 프로세스가 달라서 생기는 문제
두 번째 문제는 컨트롤 프로토콜과 데이터 프로토콜을 나눠서 다른 프로세스로 동작시키는 경우다. 패킷이 PAT를 거치면서 주소를 변환하게 되는데, 이때 PAT 장비(공유기나 방화벽)는 컨트롤 프로토콜과 데이터 프로토콜이 하나의 애플리케이션이라는 것을 인지하지 못한다.

컨트롤 및 데이터 관련 프로세스가 달라서 다른 포트를 사용할 때, 방향성은 같더라도 주기적으로 패킷이 발생하지 않으면(컨트롤 프로세스만 주기적으로 패킷을 발생시키거나 그 반대 일 경우) 중간에 있는 PAT 장비에서 세션을 종료(expire)시킬 수 있다.

<그림 8> PAT 환경에서 애플리케이션 헤더에 IP를 포함시키는 경우
세 번째 문제는 애플리케이션 프로토콜 내부에 IP 주소를 넣어서 사용하는 경우다. 클라이언트와 서버가 통신할 때 클라이언트 IP를 이용해서 무언가 동작해야 하는 상황이 발생한다면, PAT 장비가 IP 주소를 변환하고 난 후에 정상적으로 동작하지 않을 수 있다. 왜냐하면 IP 주소는 PAT에 의해 변경됐더라도 애플리케이션 헤더 안에 있는 IP 주소는 그대로이기 때문이다.

최근 P2P 관련 애플리케이션들은 대부분 이런 이슈들을 가지고 있다. 그렇기 때문에 대부분의 잘 짜여진 P2P 애플리케이션들은 NAT를 식별하고 어떻게 동작하는지의 여부까지도 인지할 수 있도록 개발되고 있다.

.....

NAT의 문제점 해결
첫 번째 방법은 프로토콜을 개발할 때, NAT 환경을 고려하는 것이다. 보통 NAT Traversal이라고 불리는 기능을 프로토콜을 개발할 때 추가적으로 넣는다. 한마디로 표현하면 프로토콜 자체에서 NAT 환경을 고려해 NAT 장비를 잘 통과하도록 변경하는 기능이다. SIP라던지 IPSEC이라는 프로토콜들은 이런 기능을 가지고 있다.

두 번째 방법은 중간에 있는 PAT나 방화벽 장비에서 이런 프로토콜들을 이해하고 자신이 애플리케이션 내용까지 확인해서 변경하는 방법이다. 보통 이런 기능을 ALG(Application Layer Gateway)라고 부르고 시중에 나오는 방화벽들은 이런 ALG 기능을 몇 개 수준에서 수십 개 수준까지 지원한다. 하지만 이런 기능에도 제약은 따른다.

① 우선 잘 알려진 프로토콜이어야 한다. 방화벽이나 PAT 장비에서 이해할 수 있을 만큼 많이 사용하고 표준화된 프로토콜이어야 한다.
② 반대로 새로 개발된 최신 프로토콜의 경우 구현이 어렵다. 그리고 사용자가 직접 개발한 프로토콜은 지원이 되지 않는다고 보면 된다.
③ 방화벽과 PAT 장비 성능에 무리가 따른다. ALG 기능 구현을 위해서 애플리케이션 레이어 프로토콜을 일일이 확인하고 변경해 줘야하기 때문에 이 기능을 사용할 경우 원래 계획된 성능보다 장비 성능이 많이 떨어질 수 있다.

이런 제약 사항들 때문에 최근 CGN(Carrier Grade NAT : SKT, KT, LG U+ 같은 대형 사업자에서 사용하는 NAT 기술)에서는 가능하면 ALG 기능을 사용하지 않도록 권고하고 있다.

사실 대안도 없이 ALG 기능을 사용하지 못한다면 PAT를 사용할 때 오래된 프로토콜이나 P2P 프로그램들을 정상적으로 사용할 수 없을 것이다. 그래서 CGN 기술에서 사용하는 NAT는 다른 대안을 가지고 있다. 이 부분에 대한 이해와 표준, 그리고 테스트 방법과 같은 내용은 다음 시간에 상세하게 다룰 예정이다.