STUN
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
STUN(Session Traversal Utilities for NAT)은 통신 프로토콜이 네트워크 주소 변환기(NAT)를 감지하고 통과하도록 돕는 도구이다. RFC 3489에서 처음 발표되었으며, RFC 5389를 거쳐 현재 RFC 8489가 최신 표준이다. STUN은 클라이언트-서버 모델을 사용하며, 클라이언트는 STUN 서버에 바인딩 요청을 보내 NAT의 동작을 파악한다. STUN은 다양한 NAT 환경에서 작동하지만, 모든 NAT 환경에서 완벽하게 작동하는 것은 아니며, 특히 대칭 NAT에서는 한계가 있다.
더 읽어볼만한 페이지
- 네트워크 주소 변환 - 포트 포워딩
포트 포워딩은 외부 네트워크의 연결 요청을 내부 네트워크의 특정 장치나 서비스로 전달하여 외부에서 내부 서비스에 접근 가능하게 하는 네트워크 기술로, 라우터나 방화벽에서 설정되며 다양한 방식으로 구현되고 활용된다. - 네트워크 주소 변환 - TURN
TURN은 NAT 환경에서 직접 통신이 어려울 때 중계 서버를 통해 통신을 가능하게 하는 프로토콜로, STUN의 한계를 보완하며 멀티미디어, P2P 시스템 등에서 활용되고 ICE와 함께 연결 설정을 최적화하지만, 대역폭 사용량이 많다는 단점이 있다. - 음성 인터넷 프로토콜 - 구글 음성 검색
구글 음성 검색은 전화 기반의 음성 검색 도구로 시작하여 서비스는 종료되었으나, 관련 기술은 다양한 구글 제품에 영향을 주었으며, 모바일 음성 검색 시장에서 중요한 역할을 하고 다양한 구글 서비스와 통합되어 사용자 편의성을 높이고 언어 지원을 확대해왔다. - 음성 인터넷 프로토콜 - 음성 사서함
음성 사서함은 발신자가 녹음된 오디오 메시지를 수신자에게 전달하는 시스템으로, 다양한 사용자 인터페이스와 통신 방법을 통해 발전해 왔으며, 기업의 통신 흐름 개선에 기여한다. - 응용 계층 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다. - 응용 계층 프로토콜 - D-Bus
D-Bus는 2002년에 시작된 프로세스 간 통신 시스템으로, 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다.
| STUN | |
|---|---|
| 개요 | |
| 종류 | 네트워크 프로토콜 |
| 기능 | NAT 환경에서 방화벽을 통과하는 응용 프로그램 지원 |
| RFC | RFC 3489 (구 버전, 폐기됨) RFC 5389 (현재 버전) |
| 기술 상세 | |
| 사용 프로토콜 | UDP |
| 관련 기술 | NAT 순회 TURN ICE |
| 역사 | |
| 개발 | IETF |
| 표준화 | RFC 3489 (2003년, 구 버전), RFC 5389 (2008년, 현재 버전) |
2. 역사
STUN은 RFC 3489에서 처음 발표되었으나,[3] 실제 네트워크 환경의 다양성으로 인해 한계에 직면했다. 이후 RFC 5389에서 업데이트된 방법 집합이 발표되었으며, 제목은 동일한 약어를 유지하면서 내용이 변경되었다.[4] RFC 3489의 방법은 실제 네트워크에서 발견되는 다양한 NAT 구현 및 응용 시나리오에 대처하기에는 너무 신뢰할 수 없는 것으로 판명되어, RFC 5389, RFC 8489 등으로 대체되었다.
2. 1. RFC 3489 (초기 표준)
STUN은 RFC 3489에서 처음 발표되었다.[3] 원래 사양에서는 주소 및 포트 매핑 동작에 따라 NAT 동작을 특성화하는 알고리즘을 정의했다. 이 알고리즘은 안정적으로 성공하지 못하며 배포된 NAT 장치의 하위 집합에만 적용할 수 있었다. 이 알고리즘은 응용 프로그램에서 수행할 일련의 테스트로 구성된다. 다이어그램을 통과하는 경로가 빨간색 상자로 끝나면 UDP 통신이 불가능하고, 노란색 또는 녹색 상자로 끝나면 통신이 가능했다. RFC 3489의 방법은 실제 네트워크에서 발견되는 다양한 NAT 구현 및 응용 시나리오에 대처하기에는 너무 신뢰할 수 없는 것으로 판명되었다.위 그림에서 경로가 빨간색 상자로 끝나는 경우 UDP 통신이 불가능하다. 경로가 노란색 또는 녹색 상자로 끝나는 경우 UDP 통신이 가능하다.
RFC 3489의 방법은 프로덕션 네트워크에서 발생하는 NAT의 다양한 구현 형태와 애플리케이션 시나리오에 대처하기에는 너무 신뢰할 수 없다는 것이 밝혀졌다. 2008년 10월에 이를 대체하는 새로운 방법 https://datatracker.ietf.org/doc/html/rfc5389 RFC5389이 제정되었다.
2. 2. RFC 5389 (개정 표준)
STUN은 RFC 3489에서 처음 발표되었다.[3] 원래 사양에서는 주소 및 포트 매핑 동작에 따라 NAT 동작을 특성화하는 알고리즘을 지정했는데, 이 알고리즘은 안정적으로 성공하지 못하며 배포된 NAT 장치의 하위 집합에만 적용할 수 있었다. 이 알고리즘은 응용 프로그램에서 수행할 일련의 테스트로 구성되며, 다이어그램을 통과하는 경로가 빨간색 상자로 끝나면 UDP 통신이 불가능하고, 노란색 또는 녹색 상자로 끝나면 통신이 가능했다. RFC 3489의 방법은 실제 네트워크에서 발견되는 다양한 NAT 구현 및 응용 시나리오에 대처하기에는 너무 신뢰할 수 없는 것으로 판명되었다.STUN 프로토콜 및 방법은 RFC 5389에서 업데이트되었으며, 원래 사양의 많은 부분을 방법의 하위 집합으로 유지했지만 다른 부분은 제거되었다. 제목은 동일한 약어를 유지하면서 RFC 5389로 게시된 업데이트된 방법 집합의 사양에서 변경되었다.[4] RFC 3489의 방법은 실제 네트워크에서 발생하는 NAT의 다양한 구현 형태와 애플리케이션 시나리오에 대처하기에는 너무 신뢰할 수 없다는 것이 밝혀졌고, 2008년 10월에 이를 대체하는 새로운 방법[https://datatracker.ietf.org/doc/html/rfc5389 RFC5389]이 제정되었다.
2020년 2월에 [https://datatracker.ietf.org/doc/html/rfc8489 RFC8489]가 제정됨에 따라 RFC 5389는 현재 폐지되었다.
2. 3. RFC 8489 (최신 표준)
2020년 2월에 [https://datatracker.ietf.org/doc/html/rfc8489 RFC8489]가 제정됨에 따라 RFC 5389는 폐지되었다.[4]3. 설계
STUN은 클라이언트-서버 프로토콜로 구현되며, 클라이언트는 음성 인터넷 프로토콜(VoIP) 전화나 인스턴트 메신저와 같은 통신 애플리케이션에 내장된다. 클라이언트는 공용 인터넷에 있는 STUN 서버에 바인딩 요청을 보낸다. STUN 서버는 클라이언트의 IP 주소와 포트 번호를 포함하는 성공 응답을 반환하는데, 이는 서버의 관점에서 관찰된 것이다. 이 결과는 배타적 논리합(XOR) 매핑을 통해 난독화되어, 심층 패킷 검사를 수행하는 ALG(Application Layer Gateway)에 의한 패킷 내용 변환을 방지한다.
STUN 메시지는 사용자 데이터그램 프로토콜(UDP) 패킷으로 전송된다. UDP는 신뢰성 (컴퓨터 네트워킹)을 제공하지 않으므로, 신뢰성은 애플리케이션 제어 재전송을 통해 확보된다. STUN 서버는 응답에 대한 신뢰성 메커니즘을 구현하지 않는다.[2] 전송 제어 프로토콜(TCP)을 사용하면 신뢰성을 높일 수 있지만, 네트워크 오버헤드가 발생한다. 보안이 중요한 애플리케이션에서는 STUN을 전송 계층 보안(TLS)으로 전송하고 암호화할 수 있다.
애플리케이션은 도메인 이름 시스템(DNS)의 SRV 레코드를 통해 STUN 서버를 자동으로 찾을 수 있다. 예를 들어, UDP용 `stun` 또는 TCP/TLS용 `stuns` 서버를 쿼리하여 (예: _stun._udp.example.com) 특정 피어와의 통신에 적합한 STUN 서버를 결정할 수 있다. STUN 서버의 표준 수신 포트 번호는 UDP 및 TCP의 경우 3478이고, TLS의 경우 5349이다. DNS 조회를 통해 STUN 서버를 찾을 수 없는 경우, 표준에서는 대상 도메인 이름에 주소 레코드 (A 또는 AAAA)를 쿼리하여 기본 포트 번호와 함께 사용하도록 권장한다.[2]
TLS를 사용한 프로토콜 암호화 외에도, STUN은 특수 STUN 패킷 유형을 통해 내장된 인증 및 메시지 무결성 메커니즘을 갖추고 있다.
클라이언트가 외부 주소를 확인하면, 이 주소를 사설 주소 대신 외부 NAT 주소를 공유하여 피어와 통신하기 위한 후보로 사용할 수 있다. 사설 주소는 공용 네트워크의 피어에서 접근할 수 없기 때문이다.
두 통신 피어가 모두 NAT 뒤의 서로 다른 사설 네트워크에 있는 경우, 피어는 서로 간의 최상의 통신 경로를 결정하기 위해 조정해야 한다. 일부 NAT 동작은 공용 바인딩이 알려진 경우에도 피어 연결을 제한할 수 있다. 대화형 연결 설정(ICE) 프로토콜은 두 피어 간의 최적의 통신 경로를 결정하기 위한 구조화된 메커니즘을 제공한다. 세션 시작 프로토콜(SIP) 확장은 두 호스트 간에 통화를 설정할 때 ICE를 사용할 수 있도록 정의된다.
4. 동작 방식
STUN은 일반적으로 사설 네트워크 내부에서 작동하는 클라이언트가 공용 인터넷의 STUN 서버로 '바인딩 요청'을 보내는 방식으로 동작한다. STUN 서버는 서버 관점에서 관찰된 클라이언트의 IP 주소와 포트 번호를 포함하는 '성공 응답'으로 응답한다.[2] 이 결과는 배타적 논리합(XOR) 매핑을 통해 난독화되어 심층 패킷 검사를 수행하는 응용 계층 게이트웨이(ALG)에 의한 패킷 내용 변환을 방지한다.
클라이언트는 외부 주소를 확인한 후, 이 주소를 사용하여 피어와 통신하기 위한 후보로 사용할 수 있다. 사설 주소는 공용 네트워크의 피어에서 접근할 수 없기 때문이다.
두 통신 피어가 모두 NAT 뒤에 있는 서로 다른 사설 네트워크에 있는 경우, 피어는 서로 간의 최상의 통신 경로를 결정하기 위해 조정해야 한다. 일부 NAT 동작은 공용 바인딩이 알려진 경우에도 피어 연결을 제한할 수 있다. 대화형 연결 설정(ICE) 프로토콜은 두 피어 간의 최적의 통신 경로를 결정하기 위한 구조화된 메커니즘을 제공한다.
STUN 메시지는 사용자 데이터그램 프로토콜(UDP) 패킷으로 전송된다. UDP는 신뢰성 (컴퓨터 네트워킹)을 제공하지 않으므로 신뢰성은 STUN 요청의 애플리케이션 제어 재전송을 통해 달성된다. STUN 서버는 응답에 대한 신뢰성 메커니즘을 구현하지 않는다.[2] 신뢰성이 필수적인 경우 전송 제어 프로토콜(TCP)을 사용할 수 있지만, 추가 네트워크 오버헤드가 발생한다. 보안에 민감한 애플리케이션에서는 STUN을 전송 계층 보안(TLS)으로 전송하고 암호화할 수 있다.
애플리케이션은 도메인 이름 시스템(DNS)에 ''stun'' (UDP용) 또는 ''stuns'' (TCP/TLS용) 서버 (SRV) 리소스 레코드 (예: _stun._udp.example.com)를 쿼리하여 특정 피어와의 통신에 적합한 STUN 서버를 자동으로 결정할 수 있다. STUN 서버의 표준 수신 포트 번호는 UDP 및 TCP의 경우 3478이고 TLS의 경우 5349이다. 또는 서버 구현이 TLS 및 STUN 패킷을 분리할 수 있는 경우 TCP 포트에서 TLS를 실행할 수도 있다. DNS 조회를 사용하여 STUN 서버를 찾을 수 없는 경우 표준에서는 대상 도메인 이름에 주소 레코드 (A 또는 AAAA)를 쿼리하여 기본 포트 번호와 함께 사용하도록 권장한다.[2]
TLS를 사용한 프로토콜 암호화 외에도, STUN은 특수 STUN 패킷 유형을 통해 내장된 인증 및 메시지 무결성 메커니즘을 갖추고 있다.
5. 한계
STUN은 모든 NAT 환경에서 완벽한 해결책이 아니며, 특히 대칭 NAT(양방향 NAT라고도 함)에서는 작동하지 않는다. 대칭형 NAT 환경에서는 TURN과 같은 다른 프로토콜이 더 나은 해결책이 될 수 있다.[3] STUN은 NAT 트래버설을 위한 여러 기술 중 하나이며, ICE, TURN 등과 함께 사용될 수 있다.[2]
STUN은 전체 콘 NAT, 제한 콘 NAT, 및 포트 제한 콘 NAT의 세 가지 유형의 NAT에서 작동한다.[3] 제한 콘 또는 포트 제한 콘 NAT의 경우, 클라이언트는 NAT가 엔드포인트에서 클라이언트로 패킷을 허용하기 전에 엔드포인트로 패킷을 전송해야 한다.[3] STUN 서버의 IP 주소는 엔드포인트의 IP 주소와 다르기 때문에, 대칭 NAT의 경우 NAT 매핑은 STUN 서버와 엔드포인트에 대해 다르게 설정된다.[3]
6. NAT 종류와 STUN
STUN은 전체 콘 NAT, 제한 콘 NAT, 포트 제한 콘 NAT의 세 가지 유형의 NAT에서 작동한다. 제한 콘 또는 포트 제한 콘 NAT의 경우, 클라이언트가 먼저 엔드포인트로 패킷을 보내야 NAT가 엔드포인트에서 클라이언트로의 패킷을 허용한다. 대칭 NAT(양방향 NAT라고도 함)에서는 STUN 서버의 IP 주소와 엔드포인트의 IP 주소가 달라 NAT 매핑이 다르게 설정되므로 STUN이 작동하지 않는다.
7. 응용
STUN은 UDP 연결을 사용하는 RTP, SIP 등에서 음성, 영상, 텍스트 등의 신호 전달 트래픽을 전송하는 데 사용된다.[2] 양쪽 엔드포인트가 모두 NAT 뒤에 있는 이중 NAT 문제는 STUN만으로는 해결하기 어려우며, 일반적으로 애플리케이션 프록시 서버가 필요하다.[2]
참조
[1]
간행물
3489
[2]
간행물
5389
[3]
간행물
3489
[4]
간행물
5389
[5]
간행물
STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
The Internet Society
2003-03
[6]
간행물
Session Traversal Utilities for NAT (STUN)
The Internet Society
2008-10
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com