STUN-TURN과 NAT의 관계

STUN과 TURN은 주로 VoIP나 WebRTC를 다룰 때 나오는 주제인데, 그 근본적인 원인은 NAT에게 있다고 할 수 있다.

VoIP를 예로 들면, App. Layer 프로토콜인 SIP와 SDP로 세션을 수립할 때 자신의 IP, Port를 담아서 보내는데 일반적인 NAT는 이를 커버해주지 않으므로 STUN과 TURN이 필요한 것이다.

그렇다면 일반적이지 않은 NAT를 사용하면 되는게 아닌가? 싶겠지만 그 기능(ALG)에는 여러 문제가 있다. 궁금하다면 다음의 링크를 참고하시라. SIP ALG and why it should be disabled on most routers | VoiceHost

아무튼, STUN과 TURN에 대해 알아보자면...

 

VoIP 네트워크를 위와 같이 구성했다고 치자. 그러면 시그널링은 어찌저찌 가능한데, 문제는 P2P 통신이다. SDP에 포함된 IP 주소가 Private인 채로 시그널링되기 때문에 이후 라우팅이 불가능하다.

이를 해결하려면 처음부터 자신의 Public 주소를 삽입해야 한다. 하지만 호스트 스스로는 자신의 주소를 알아낼 방법이 없으니, 이 때 사용되는 것이 STUN이다.

 

STUN 서버를 통해 호스트는 자신의 Public IP 및 Port 번호를 알아내고 전송할 수 있다. 일종의 Query같은 느낌이다.

굳이 이렇게 하는 이유가 뭔지 궁금할 수도 있는데, NAT가 겹으로 적용되어 있을 경우에도 효과적으로 대응할 수 있기 때문이라 보면 된다. 흔한 경우로 CGNAT가 있다. 다만 호스트와 STUN 서버가 같은 네트워크에 존재하면 정상 작동하지 않는다.

NAT의 종류에 따라서도 문제가 발생할 수 있다. Symmetric NAT 환경이라면 STUN을 통해 얻은 정보는 STUN 세션에서만 유효하므로 이후 RTP 통신에서 사용될 수 없다. 이를 해결하려면 중계 서버인 TURN 서버를 활용해야 한다.

 

TURN 서버가 STUN의 역할을 하면서 패킷을 중계해준다면 이론상 문제가 없다. 시그널링 중에도 TURN 서버와의 세션을 유지할 수 있으니 말이다.

 

*모든 토폴로지는 가상으로 실제 통신과 다를 수 있습니다