@ NAT 와 VoIP 시그널과 RTP 전송 영향에 대한 알아보자.
1. VoIP 환경에서 NAT 를 사용하는 이유?
: 공인 IP 부족, 공인 IP 사용 시 서비스사를 바꿀 때마다 컴퓨터의 IP 주소를 변경해야 하는 번거로움 덜기.
: 보안의 이유(내부 정보 감추기)
2. VoIP 환경에서 NAT, Firewall 사용 시 문제?
: End-to-End 모델에서 큰 문제가 있다, one-way, 호 시도 fail 등,
3. VoIP 환경에서 NAT, Firewall 사용 시 대응 방법
- SIP Proxy 가 ALG(Application Level Gateway)로 NAT와 방화벽 제어
- SIP 시그널링 수정
- SIP 처리 할 수 있게 NAT와 Firewall 수정
- P2P 기반 NAT 및 방화벽 통화 기법 : ICE, STUN, TURN
[NAT]
1:1 NAT 의 경우 Layer3 IP 정보만 변환해주며 NAPT(Network Address and Port Translation, PAT) 경우
IP와 Port(Layer4) 까지 변환해준다. 아래 처럼 NAT에 의해 수정될 수 있는 field 이다.
!- 아래 처럼 NAT 환경에서 문제점. NAT는 L3,L4만 조절 가능, SIP 본문은 control 불가능
* NAT 종류
|
Symmetric NAT : 목적지에 따라 다른 공유기의 외부 IP:Port를 가지는 것(ex. NAT-PAT)
|
Cone NAT : 내부망의 IP:Port 에 대해 목적지에 관계없이 공유기의 외부IP:Port가 변하지 않는다는 것
(종류 - Full Cone, Restricted Cone, Port Restricted Cone) , (ex. 1:1 NAT)
|
#최근 IETF 지침#
프로토콜을 새로 만들 때 그 프로토콜이 NAT 환경에 영향을 받지 않도록 하는 지침 발표.
SIP 프로토콜은 그 이전에 만들어졌기 때문에 이러한 지침에서 벗어나는 부분이 있다.
지침의 핵심은 애플리케이션 계층에서 IP 주소나 포트 번호를 직접 다루지 말라는 것이다.(SIP는 다룬다 --;)
!- 위 그림은 NAT 환경에서 만들어진 SIP 메시지 이다. 문제점
a. Via 헤더의 주소가 사설IP 주소이기 때문에 위 메시지에 대한 응답 메시지들은 발신자에게 제대로 전달 불가
b. Contact 헤더의 주소 역시 사설IP 주소이기 때문에 향후 이 발신자에 대한 세션 설정 시도가 발신자에게 전달 불가
c. 아래쪽 SDP의 미디어 부문에 포함되어 있는 c= 헤더의 주소가 사설 IP주소이기 때문에
사용자 B가 보낸 RTP 패킷은 제대로 라우팅 되지 않는다.
위 3가지 문제중에서 SIP 자체로 해결 가능한 것은 첫번째(a)이다.
=> 위와 같은 메시지를 받은 SIP Proxy 서버나 수신측 UA가 메시지 내의 Via 헤더에 들어있는 IP주소와 패킷이 실제로
어디에서 온 것인지를 비교하여 두 주소가 서로 다르다면(즉, 사설 IP 주소를 사용하는 것이라면), 메시지에
received= 헤더를 추가하여 패킷의 출발지인 공인 IP 주소를 기록하도록 하는 것이다. 따라서 이후 이에 대한
응답메시지는 received= 헤더의 IP 주소를 따라 패킷의 발신지였던 NAT 장비로 전달되고, NAT 장비는 원래 가지고
있는 정보에 따라 사설 IP를 사용하고 있는 사용자 A에게 응답 메시지를 배달할 수 있다.
NAT 장비는 TCP 연결을 설정하면서 내부의 사설IP주소와 포트 번호를 자신의 공인 IP 주소와 포트 번호로 연관 시키는
바인딩을 만들어 유지하기 때문에 위의 방식은 NAT와 SIP 모두에게 별도의 부담이 없다. 그러나 b,c는 간단하지 않다.
!- 아래 처럼 NAT 장비를 지나 갈 때 Via:10.0.0.1;received=172.34.5.1;rport=34123 을 추가한다.
=> 두번째 문제는 영구적 TCP를 사용한다면 해소될 수 있다. 즉, 일단 한번 세션이 시작되면 이에 대한 TCP 연결을
계속 유지함으로써 상대방이 자신의 Contact 헤더의 주소를 사용할 필요(ex INVITE, BYE)자체를 없애는 것이다.
=> 세번째 문제는 RTP 흐름을 상호 대등하게 만들면 부분적으로 해소될 수 있다. 이 경우 NAT 사설망 안에서
RTP 패킷을 제대로 주고받을 수 있는 단말은 단 하나로 제한된다. 상대방은 이 쪽에서 보낸 SDP에 들어있는
IP주소, 즉 사설 IP 정보는 무시하고, RTP 스트림을 받을 때 그 패킷을 보낸 NAT 장비의 IP주소와 포트 번호로
RTP 패킷을 보낸다.
NAT의 용도가 내부의 망 정보들을 노출시키지 않기 위해서라면 이러한 세 가지 SIP와 RTP에 대한 문제점 이외도
내부 사설 IP 정보의 누출도 문제가 될 수 있다. 시그널링이나 미디어 전송 관점에서는 별로 중요하지 않지만
보안 관점에서는 Call-ID 헤더 또한 망 정보를 누출시키는 요인이 될 수 있다.
[방화벽]
* 내부망의 UA가 UDP로 세션을 처리하는 경우
INVITE 메시지를 받은 외부 Proxy서버는 UDP로 응답하게 되는데 이 UDP 패킷은 내부망의 UA와 미리 설정 연결이
없기 때문에 방화벽에 의해 차단된다.
* 내부방의 UA가 TCP로 세션을 처리하는 경우
내부망 UA가 외부로 메시지를 보낼때 미리 TCP 연결을 설정하기 때문에 외부 Proxy 서버의 응답 메시지는 차단하기
않고 UA로 전달된다. 하지만 미디어 패킷인 RTP는 앞의 TCP 연결과 무관하기 때문에 외부에서 들어오는 RTP 패킷은
모두 방화벽에 의해 차단된다. 결과적으로 통화는 내부에서 외부로 가는 소리만 들리게 된다.
역시 외부 UA가 방화벽 안쪽에 있는 UA에게 INVITE 호 시도를 할 경우 역시 방화벽에 의해 차단된다.
* 외부에서 내부로 호 시도를 방화벽을 통과 하기 위한 방안
=> 방화벽에 SIP 관련 패킷을 통과하도록 허용. 하지만 허용 범위를 넓히는 것 자체가 방화벽 본래의 목적에
반하기 때문에 보안 담당자들이 SIP 패킷의 차단을 일부러 해제하지는 않을 것이다.
[STUN,TURN,ICE]
NAT 를 통과하기 위한 ITEF의 표준은 3가지 이다.
STUN (Simple Traversal of UDP through NAT)
TURN (Traversal Using Relay NAT)
ICE (Interactive Connectivity Establishment)
!- STUN Signal/RTP flow
!-TURN Signal/RTP flow
아래 media 그림이 잘못 된 것 같다. 모든 media가 TURN Server를 경유해서 가야지 않을까?
!- ICE Signal/RTP flow
* STUN(RFC 3489, updated RFC 5389)
STUN 서버, STUN 클라이언트로 구성된다.
UA스스로가 NAT 내부, 즉 사설망에 있는지 여부와 그렇다면 어떤 종류의 NAT이고 NAT 장치의 공인 IP주소가
무엇인지를 찾아내도록 도와주는 프로토콜이다. UA가 외부 공중망에 있는 STUN 서버에게 STUN 패킷을 보내면
STUN 서버는 패킷을 보낸 장치의 IP 주소와 포트 번호를 담아 응답합니다. UA는 자신의 IP주소와 STUN 서버가
보내온 IP 주소를 빅하여 두 주소가 같으면 NAT가 없음을 알게 되고, 반면에 두 주소가 다르면 NAT 내부에 있는
것이므로 UA는 이후 SIP과 SDP에 포함될 IP 주소를 STUN 서버가 보내준 공인 IP 주소로 수정하여 호를 시도한다.
결과적으로 UA 스스로가 NAT문제를 해결할 수 있게 된다. 그러나 STUN 방식은 두 UA가 모두 NAT 내부에
있을 때에는 제대로 동작하지 않는다. 또한 Symmetric NAT에서는 지원하지 않는다(?). 이 해결책은 TURN이다.
a. STUN UA -> STUN Server 에 보내는 메시지
: 해당 패킷은 STUN UA에서 만 캡쳐 한 내용.
b. STUN Server -> STUN UA 에게 응답 메시지
: 응답 내용의 XOR-MAPPED-ADDRESS 에 자신이 사설IP를 쓰고 있으며 공인IP는 무엇인지를 파악
c. SIP INVITE는 STUN Server 에게 보낸다.
: SIP INVITE를 D-IP는 STUN Server 이며 SIP 메시지에 Contact는 자신의 공인IP/Port 주소이다.
* 윈도우 기반 STUN/SIP 서버
* TURN
UA로 하여금 외부 공중망에 있는 TURN 서버를 경유하여 호를 설정하도록 하는 방식이다.
즉 두 UA가 서로 직접 메시지를 주고받는 것이 아니라 공중망에 위치한 TURN 서버와 세션을 설정하도록 하여
TRUN 서버가 이를 중계하는 방식이다. 두 UA가 경로가 다소 우회된다.
하지만 Symmetric NAT나 방화벽이 있을 경우에도 호를 설정할 수 있는 유일한 방법은 TURN이다.
* ICE
STUN이나 TURN을 사용할 때 P2P 방식을 통해 최적의 라우팅을 제공하려는 기법이다.
세션 설정 과정에서 자신이 알 수 있는 모든 주소들을 동원하여 시그널링을 시도한다.
* UA가 사용 할 수 있는 주소 들
|
UA 자신의 사설 IP 주소
STUN 서버가 알려준 NAT 장치의 공인 IP 주소
패킷을 중개할 TURN 서버의 IP 주소
|
주소들의 우선순위는 직접 통신 가능한 주소가 우선이고, TURN 서버 주소와 같은 간접 통신을 위한 주소는
뒤에 배치된다. 세션 설정 후 망 상황이 바뀌거나 세션이 변경되면 ICE에 의한 주소 교환을 처음부터
다시 수행한다. ICE 방식은 일반 P2P 파일 공유 애플리케이션에서 NAT나 방화벽을 통과할 때 사용되는 기법과 흡사.
!- a. Caller 가 가능한 모든 주소를 수집한다.
!- b. 이후 다양한 방법으로 호를 시도한다.
만약 내부망(사설)의 경우로 호 성공 시 최적 라우팅 경로로 호 완성된다.
* STUN/TURN/ICE 서버
|
http://www.myvoipapp.com - 윈도우 기반, 20일 무료 사용 가능, STUN/SIP 서버 가능
http://www.pjsip.org/pjnath/docs/html/index.htm - STUN/TURN/ICE linux 기반 library
http://numb.viagenie.ca/ - 무료 STUN/TURN 서버 서비스 제공
http://sourceforge.net/projects/turnservernet/ - open TURN 서버
http://www.eyeball.com/nat-traversal.htm - 유료 STUN/TURN/ICE 기반 서버
|
[애플리케이션 계층 게이트웨이(ALG)/SBC]
STUN/TURN/ICE 는 모두 UA의 관여를 필요한다. 즉 UA에 STUN/TURN/ICE 처리 가능해야 된다.
즉 전화기에 해당 기능 구현이 가능해야 되는 단점이 있다. UA의 관여 없이 해결책으로는 ALG/SBC가 있다.
(통상 VoIP SIP ALG를 'SBC'라고 부르기고 하겠음)
SBC는 방화벽이 인정하고 신뢰하는 서버로써 SIP/RTP 의 Proxy 역활을 한다.
방화벽은 SBC에서 만들어 지거나 SBC로 보내어지는 SIP/RTP만 통화를 허용하고 그 외는 차단한다.
SBC는 NAT에서도 적용 가능하다. SBC는 Proxy된 모든 SIP 메시지를 조사하여 본문의 사설 IP 정보들을
모두 해당 공인 IP 주소로 변경한다.
위 그림에서 왼쪽의 SIP Proxy 에 Firewall 이 있다고 해도 왼쪽의 UA가 중간에 SBC로 향하는 signal/RTP는
허용 되며 또한 SBC가 오른쪽에 전달하는 signal/RTP 역시 허용되게 된다.
위 처럼 방화벽은 SIP SBC에 대한 최소한의 허용만으로 signal/RTP 패킷 통과를 보장하게 된다.
또한 SBC 중간에 NAT/Firewall 이 있는 경우 cache table 을 계속 지속해서 pin hole 을 뚫는 방법등이
필요하게 된다. UA의 register 을 cache table 의 만료 시간보다 짥게 하거나 아니면 cache table 만료 시간을
길게 하거나 또는 dummy RTP를 사용해서 외부 UA가 내부로 먼저 들어오게 되는 RTP 세션을 잘 통과하기도 한다.
또 다른 방법주에서 SIP 방화벽 Proxy 를 사용하는 방법. SIP 방화벽 Proxy는 UA에 대한 인증,확인등을 대신하고
INVITE나 200ok 메시지를 보고 UA들의 IP주소와 포트번호를 알아내어 방화벽에게 이들 IP주소와 포트 번호에 대해
잠시 차단을 해제 할 것을 요청한다. 또한 NAT의 경우 방화벽 Proxy는 UA의 사설IP 주소와 공인 IP 주소의 바인딩
관리를 통해 메시지의 SDP에 들어있는 사설IP 주소를 공인IP 주소로 변경해 줌으로써 UA간의 직접적인 RTP 패킷
교환이 가능하게 한다. BYE 메시지에 의해 세션이 종료 될 경우 방화벽 Proxy는 다시 원래대로 차단하게 하고
NAT 장비역시 바인딩 정보를 삭제도록 한다.
하지만 아직 방화벽이나 NAT 장비가 SIP Proxy와 직접 처리하기 위한 프로토콜은 없다.
위 SBC 모델은 단점은 SBC 자체가 SIP의 구성 요소가 아니기 때문에 SIP의 단대단 특징을 무시한다.
그 결과 SIP 의 TLS와 같은 보안 메카니즘을 지원하지 않을 수 있다. 또한 S/MIME으로 메시지 본문을 보안 처리 할 때
SBC가 S/MIME 기능 처리를 못하거나 메시지 내용을 손상 할 수 있다.
이런 이유로 SBC보다는 STUN/TURN/ICE 사용이 권장된다. 또한 SBC 경유 시 추가 지연이 발생한다.
<= 하지만 사업자 모델에서는 중앙 제어가 가능한 SBC가 권장된다.
* SBC 제품
http://www.acmepacket.com/ - acme packet(SBC)
http://www.cwti.kr/ - 크로스위브 사이페리아 VoIP FW(SBC)
http://www.nablecomm.com - nXer SBC 네이블커뮤니케이션즈(SBC)
[개인정보유출]
기존 PSTN에서는 발신자 신상을 숨기는 일이 어렵지 않다. 공중전화를 사용하는 것이 하나의 방법이다.
하지만 SIP 세션에서는 상당히 많은 정보들이 교환되어 정보 유출을 피할 길이 없다.
SIP에서 익명을 제공하는 길은 B2BUA를 사용하는 방법이다.
신원 확인이 필요한 경우 P-Asserted-Identity 헤더를 사용할 수 있다.
* 참고 사이트
http://www.nexpert.net/75 - NAT 에 대한 이해
http://msdn.microsoft.com/en-us/library/bb330896.aspx - MS VoIP NAT
