NAT Traversal이란 주제가 담긴 글이 이미 라인하트님의 3부작 연재로 2008년 4월에 심도있게 다루어졌습니다. 또한 NAT에 대한 주제로 민형애비님이 2008년 1월에 글이 있었습니다.
******위 글을 보고 싶으시면 아래 링크를 참조 하세요********
http://www.nexpert.net/75
http://www.nexpert.net/category/Voice%20%26%20Security
*********************************************************
그런데 제가 또다시 NAT와 NAT Traversal에 대한 얘기를 다시 시작하려고 합니다.
NAT Traversal은 UC를 다루다 보면 자주 이 문제를 만나게 되고, 위 글들을 열심히 읽어보지 않으면, 이해는 가지만 스스로 개념을 확고하게 잡지 못합니다.
특히나 저처럼 난독증이 있거나…. 이해력이 부족한 사람들은 특히나 그렇죠
그래서 라인하트님의 글을 SIP버전으로 제가 이해한 방식대로 글을 써보려고 합니다. 하지만 ^^ 쉽게 써 질지 모르겠네요
1. NAT란?
NAT는 IP Address를 변환하는 Router의 기능입니다.
Network Address Translatoin의 약자 이구요, 우리가 가정에서 사용하는 공유기의 역할이 이 NAT를 하는 역할을 합니다. 좀더 정확하게는 공유기는 PAT(Port Address Translation)을 하게 됩니다.
NAT라는 기능이 사용되는 이유는 두가지입니다.
가정집에서 사용하는 이유처럼 ‘공인 IP Address’가 모자라기 때문인 경우와, 기업내부의 네트웍을 숨기려는 보안의 이유가 있습니다. 방화벽의 기본기능이기도 하죠.
<그림1-1> 처럼 PC의 IP는 192.168.0.1(사설IP)이지만, Router를 거치면서 1.2.3.4(공인IP)로 변환이 되어서 인터넷으로 나가게 되는 기능을 NAT라고 부릅니다.
<그림1-1>
2. SIP의 기본 Call Flow
SIP의 Call Flow는 <그림2-2> 과 같이 Phone A가 IP PBX로 Phone B와 통화하기 위해 Invite를 보내고 SIP 200 OK를 받으므로써 시그널이 완료 되고 음성 통화로가 열리게 됩니다.
Phone A와 Phone B가 서로 보낼 RTP의 Path는 invite와 200 OK 내 SDP를 확인 하여 서로 알게 됩니다.
이때 각각의 전화기가 SDP에서 참조하는 부분은 <그림2-1>의 SDP 내용 중 C(Connection Information)와 M(media description and transport address)을 이용해 PhoneA,B 서로가 어디로 RTP를 보낼지를 확인하고 Phone A,B간 RTP를 전송하게 됩니다.
<그림2-1>
(SDP에 대한 이해가 필요하시다면 http://www.nexpert.net/141 를 참조하세요)
<그림2-2>
3. SIP와 NAT 무엇이 문제인가?
NAT+SIP 환경에서 SIP Signaling 자체는 문제가 되지 않습니다. 하지만, RTP 즉 음성이 지나가는 Path가 문제입니다.
SIP Invite안의 SDP를 통해 RTP의 IP Address와 Port를 상대방에게 알려줍니다.
하지만 Phone들이 NAT 안에 있다면, RTP IP와 port를 NAT로 변경되기 전의 것, 즉 IP Phone의 RTP Port 와 사설 IP를 상대방에게 알려주게 됩니다.
이 과정에서는 NAT가 된다 하더라도 SIP의 Call flow에는 전혀 문제없이 진행이 됩니다.
<그림3-1>을 참조하시면,Phone A는 Invite w/ SDP를 Phone B에게 보내기 위해 IP PBX를 통해 Invite를 보내고 Invite를 받은 Phone B는 200OK with SDP를 보내게 됩니다. 이 과정에서는 NAT가 된다 하더라도 L3와 L4의 IP address와 Port를 그대로 이용하기 때문에 문제없지 진행이 되는 거죠
<그림3-1>
하지만, Phone A와 PhoneB가 서로 RTP를 보내려고 할때는 어떻게 될까요?
<그림3-1>에 나타나 있는 것과 같이 Invite with SDP와 200OK with SDP에 들어있는 RTP의 주소와 Port는 NAT가 되기 전 IP와 Port 즉 전화기에 세팅되어 있는 것으로 IP Phone간에 정보교환을 했기 때문에, <그림3-2>처럼 두 폰이 RTP를 사설 IP로 보내려고 시도를 하게 됩니다. 하지만, Router는 다른 네트웍에 있는 사설 IP를 당연히 알수가 없겠죠? 그래서 Routing이 되지 않습니다. RTP를 보낼 수 없게 되는거죠.
<그림3-2>
만약 Phone B가 NAT가 되지않는 IP를 가지고 있다면 어떻게 될까요? 위의 그림과는 틀린 예이지만 같은 맥락이므로 잠시 짚고 넘어가겠습니다.
결론부터 얘길하자면, <그림3-3>처럼 Phone A는 RTP를 보낼수 있게 됩니다. 하지만, 반대로 Phone B는 여전히 RTP를 전달 할수 없게 됩니다. 결국 1-way증상이 일어나게 됩니다. (만약, 행여 Routing이 된다 하더라고 Port 때문에 역시나 문제가 됩니다.) 왜냐하면, Phone A가 보낸 Invite는 역시나 NAT문제가 있지만 Phone B가 보낸 200OK w/ SDP내의 IP와 Port 모두 정상적이기 때문입니다.
<그림3-3>
4. 어떻게 해결해야 하나?
1)인터넷 전화 사업자
우리는 이미 NAT(PAT)가 되는 환경에서 IP Phone을 잘 쓰고 있습니다. 각 가정에는 인터넷 전화기가 있고 이미 공유기를 연결하여 PC와 전화기를 같이 사설IP를 이용하여 쓰고 있습니다. Service Provider는 이러한 문제를 SBC(Session Border Controller)와 전화기의 특정 기능을 조합하여 해결하는데 사용합니다.
- Session Border Controller
위에서 언급했듯이 가정집 내 인터넷 전화들은 대부분 공유기에 연결이 되어 있습니다. 이런 상황에서 NAT+SIP 문제를 해결하기 위해서 인터넷 전화 사업자들은 SBC라는 장비를 이용합니다.
SBC는 NAT Traversal과 Topology Hiding을 수행하는데 사업자의 내부 PBX(Centrix)의 네트웍을 외부로 부터 숨기고 NAT 환경을 해결합니다.
- Dummy RTP Packet을 이용
사업자는 SBC를 망의 앞단에 놓아서 NAT Traversal과 Topology Hide를 합니다. 그럼 가정집 내의 전화는 어떻게 해결 해야 할까요? 가정집 마다 SBC를 놓을 수는 없기 때문에 간단한 아이디어로 이 문제를 해결합니다. 비밀은 전화기에 있죠.
인터넷 전화 사업자는 자사의 전화기에(사실은 대부분의 SIP폰에 있는 기능입니다.) NAT Pin Hole을 뚫는 방식인 Dummy RTP 기능을 구현해 놓습니다.
전화기는 약 30초 주기로(일반적인 NAT테이블 갱신 주기보다 짧게) 2byte RTP를 SBC로 보내어 Phone의 UDP port와 공유기의 Port를 매핑하여 유지하며, SBC에게 자신이 사용할 NAT된 IP 와 UDP Port를 알려줍니다.
이렇게 되면 전화기가 사용될 RTP의 IP와 Port를 임의로 유지할 수 있어 가정집 내 SBC가 없어도 통화가 가능해 집니다.
2) Skype
Skype의 경우는 조금 독특한 방법을 씁니다. 전세계 수 많은 무료 사용자를 수용하기 위한 모델이기 때문입니다. Skype는 방화벽을 뚫는다라는 광고(?)문구를 퍼트리고 있는데 이 방법은 ^^ 일반적인 회사에서 IPT모델로 가지고 가기에는 약간 문제가 되는 모델이기도 합니다.
간단히 설명 드리면 공인 IP를 가지고 있는 Skype유저가 SBC 역할을 자신도 모르게 하게 되고 통화가 되는 호의 미디어 까지도 처리를 하게 되는 거죠 ^^
위 두가지의 경우와 함께 STUN과 ICE를 그림과 함께 쓰려고 했으나 다음에 기회가 된다면 사업자모델, Skype모델과 함께 자세하게 올리는 기회를 갖도록 하겠습니다.
너무나 오랜기간 동안 블로깅을 쉬었습니다. 다행히도 라인하트님께서 아픈 몸을 이끌고 계속해서 글을 올려 주셔서 블로그가 쉼없이 달려온듯 보입니다. 다시한번 라인하트님께 감사드리고 백그라운드에서 열심히 일해주고 계시는 솔민아빠님도 고맙습니다. 올 한해 NExpert가 좀더 진일보 하는 한해가 되도록 노력하겠습니다.
====================
허클베리 핀(CCIEV #18695)
yj@nexpert.net (허클베리 핀의 이메일)
http://www.twitter.com/yohur (허클베리 핀의트위터 )
http://www.youtube.com/yohur (허클베리핀의 유튜브 채널)
http://www.twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스)
http://cafe.nexpert.net/ (체계적인 UC 정보의 전달을 위한 카페, 아직 아무것도 없다는......)
나는 원래 디지털 네이티브 ^____________^
