NAT 주위의 릴레이를 사용한 통과
Traversal Using Relays around NAT |
TUNT(Traversal Using Relays using NAT)는 멀티미디어 애플리케이션을 위한 NAT(네트워크 주소 변환기) 또는 방화벽의 통과를 지원하는 프로토콜이다.TCP(Transmission Control Protocol) 및 UDP(User Datagram Protocol)와 함께 사용할 수 있다.대칭 NAT 장치로 가장한 네트워크의 고객에게 가장 유용하다.Turn은 NAT을 통해 프라이빗 네트워크의 잘 알려진 포트에서 서버를 실행하는 데 도움이 되지 않으며, 예를 들어 전화와 같이 NAT 뒤에 있는 사용자가 단일 피어에만 연결할 수 있도록 지원한다.
Turn 지정자: RFC8656.Turn URI 체계는 RFC7065에 문서화되어 있다.
소개
이점을 제공하는 동시에 NAT에도 단점이 있다.그러한 단점들 중 가장 골치 아픈 것은 그것이 많은 기존 IP 애플리케이션을 깨뜨리고, 새로운 IP 애플리케이션을 배치하는 것을 어렵게 만든다는 점이다."NAT 친화적" 프로토콜을 구축하는 방법을 설명하는 지침이 개발되었지만, 많은 프로토콜은 이러한 지침에 따라 구성될 수 없다.그러한 프로토콜의 예로는 멀티미디어 애플리케이션과 파일 공유가 있다.
Session Traversal Utilities for NAT(STUN)은 애플리케이션이 NAT을 통과할 수 있는 한 가지 방법을 제공한다.STUN은 클라이언트가 피어로부터 패킷을 수신하는 데 유용할 수 있는 전송 주소(IP 주소와 포트)를 얻을 수 있도록 한다.단, STON이 획득한 주소는 모든 피어가 사용할 수 있는 것은 아닐 수 있다.그러한 어드레스는 네트워크의 위상학적 조건에 따라 작동한다.따라서 스턴 자체로는 NAT Traversal을 위한 완벽한 솔루션을 제공할 수 없다.
완전한 해결책은 클라이언트가 패킷을 공공 인터넷으로 전송할 수 있는 모든 피어로부터 미디어를 수신할 수 있는 전송 주소를 얻을 수 있는 수단을 필요로 한다.이것은 오직 공공 인터넷에 상주하는 서버를 통해 데이터를 중계해야만 이루어질 수 있다.TUN(Traversal Using Relay NAT)은 클라이언트가 이러한 릴레이로부터 IP 주소와 포트를 얻을 수 있도록 하는 프로토콜이다.
Turn은 거의 항상 클라이언트와의 연결을 제공하지만, Turn 서버의 제공자에게는 자원이 집약적이다.따라서 가능한 한 다른 메커니즘(예: 스턴 또는 직접 연결)을 선호하면서 Turn을 마지막 수단으로만 사용하는 것이 바람직하다.이를 위해 ICE(Interactive Connectivity Setup) 방법론을 사용하여 최적의 연결 수단을 찾을 수 있다.
프로토콜
이 프로세스는 클라이언트 컴퓨터가 데이터 트랜잭션을 위해 피어 컴퓨터에 연락하기를 원할 때 시작되지만 클라이언트와 피어가 각 NAT에 뒤처져 있기 때문에 그렇게 할 수 없다.NAT 중 하나가 대칭 NAT(STUN과 호환되지 않는 것으로 알려진 NAT의 한 유형)이기 때문에 STOUN이 옵션이 아닌 경우 Turn을 사용해야 한다.
먼저, 클라이언트는 "Allocate" 요청으로 Turn 서버에 접속한다.할당 요청은 클라이언트가 피어에 연결할 수 있도록 Turn 서버에 리소스를 할당하도록 요청한다.할당이 가능하다면, 서버는 클라이언트가 릴레이로 사용할 주소를 할당하고, TETURN 서버에 위치한 "할당된 릴레이 전송 주소"를 포함하는 "할당 성공" 응답을 클라이언트에게 전송한다.
둘째, 클라이언트는 CreatePermissions 요청을 Turn 서버로 전송하여 피어-서버 통신을 위한 권한 확인 시스템을 만든다.즉, 피어가 최종적으로 접속되어 클라이언트로 중계될 정보를 Turn 서버로 다시 전송하면, Turn 서버는 권한을 사용하여 Peer-to Turn 서버 통신이 유효한지 확인한다.
권한이 생성된 후 클라이언트는 실제 데이터를 전송하기 위해 (1) 전송 메커니즘을 사용할 수 있으며, (2) 채널 바인딩 요청을 사용하여 채널을 예약할 수 있다.Send 메커니즘은 더 간단하지만, Turn 릴레이 대화에서 대역폭을 실질적으로 증가시킬 수 있는 36바이트의 더 큰 헤더를 포함하고 있다.이에 비해 채널 바인딩 방법은 더 가볍다. 헤더는 4바이트에 불과하지만, 다른 고려사항 중에서도 주기적으로 새로 고쳐야 하는 채널을 예약해야 한다.
Send 또는 Channel Binding 중 하나를 사용하여, Turn 서버는 클라이언트로부터 데이터를 수신하고 "할당된 릴레이된 전송 주소"를 포함하는 UDP 데이터그램을 사용하여 피어에 데이터를 릴레이한다.피어는 데이터를 수신하고, 다시 전송 프로토콜로서 UDP 데이터그램을 사용하여, Turn 서버의 릴레이 주소로 UDP 데이터그램을 송신한다.
Turn 서버는 피어 UDP 데이터그램을 수신하여 사용 권한을 확인한 후 유효한 경우 클라이언트에 전달한다.
클라이언트와 피어 모두 통신을 위해 릴레이 IP 주소를 할당한 Turn 서버와 적어도 통신할 수 있기 때문에 이 프로세스는 대칭적인 NAT을 중심으로 진행된다.
Turn은 더 많은 유형의 NAT을 통과하도록 지원한다는 점에서 STON보다 강력한 반면, Turn 커뮤니케이션은 일반적으로 대중을 대면하는 IP 주소를 해결하고 클라이언트와 피어에게 정보를 전달하여 dir에서 사용할 수 있도록 STON 프로토콜보다 훨씬 더 많은 서버 대역폭을 요구하는 서버를 통해 전체 통신을 중계한다.의사소통이 때문에 ICE 프로토콜은 첫 번째 수단으로 STON 사용을 의무화하고, STON을 사용할 수 없는 대칭 NAT 또는 기타 상황을 다룰 때만 Turn 사용을 의무화한다.
