오늘은 RFC 3489와 RFC 5780에서 정의하고 있는 NAT 타입에 대해서 설명을 드리도록 하겠습니다.
지난 시간을 통해 NAT의 Mapping Behavior와 Filtering Behavior에 대해 설명을 드렸는데, 그 내용을 숙지하셔야만 오늘 내용을 이해하실 수 있을 것입니다.
STUN이란?
STUN은 P2P 통신을 위해 두 단말 사이에 NAT의 존재 유무 및 NAT 타입을 식별(discover)하고 또한 NAT에 의해 변경되는 External IP 주소 및 External Port 값을 P2P 단말이 알 수 있도록 해 주는 프로토콜입니다.
본 프로토콜은 2003년도 RFC 3489(Standards)를 통해 먼저 표준화 되었고, 이후 2008년도 RFC 5389(Standard)와 2010년도 RFC 5780(Experimental)을 통해 개정되었습니다.
RFC 5389의 설명에 따르면, "Classic STUN 즉, RFC 3489에 기술된 NAT 타입 식별 알고리즘에는 오류가 있으며, 현재 시중에 나와 있는 NAT 장비를 RFC 3489에 정의된 4가지 타입으로 분류하는데 한계가 있다."라고 되어 있습니다.
이에 RFC 5389를 통해 기존 STUN 프로토콜이 수정(Binding Message의 Attribute 추가) 되었고, 또한 RFC 5780을 통해 NAT 타입 분류 재정의 및 NAT 타입 식별 알고리즘(방식)을 수정하게 되었습니다.
RFC 3489와 RFC 5389 표준에서는 STUN이란 동일 제목을 사용하고 있지만 아래와 같이 그 풀이를 다르게 하고 있습니다.
RFC 3489의 NAT 타입 및 RFC 5780과의 관계
■ Full Cone
[Mapping Behavior] A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. [Filtering Behavior] Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. (RFC 3489)
Full Cone 타입은 RFC 5780에 Endpoint-Independent Mapping(이하 EIM)과 Endpoint-Independent Filtering(이하 EIF)으로 동작하는 방식을 말합니다.
■ Restricted Cone
[Mapping Behavior] A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. [Filtering Behavior] Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. (RFC 3489)
Restricted Cone 타입은 RFC 5780에 EIM과 Address-Dependent Filtering(이하 ADF)으로 동작하는 방식을 말합니다.
■ Port Restricted Cone
[Mapping Behavior] A port restricted cone NAT is like a restricted cone NAT, [Filtering Behavior] but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. (RFC 3489)
Port Restricted Cone 타입은 RFC 5780에 EIM과 Address and Port-Dependent Filtering(이하 APDF)으로 동작하는 방식을 말합니다.
■ Symmetric
[Mapping Behavior] A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. [Filtering Behavior] Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. (RFC 3489)
Symmetric 타입은 RFC 5780에 Address and Port-Dependent Mapping(이하 APDM)과 APDF로 동작하는 방식을 말합니다.
요약
아래 그림은 RFC 5780에서 정의하고 있는 9개의 NAT 타입과 RFC 3489에서 정의하고 있는 4개의 NAT 타입 간의 관계를 보이고 있습니다.
상호: (주)엔앰씨컨설팅그룹 주소: 서울시 강남구 테헤란로 128, 3층 387호 대표이사: 손장우 전화: 02-3444-5747 메일: webmaster@netmanias.com 등록번호: 서울 아03722 제호: 넷매니아즈 등록일자: 2015년 5월 4일 발행/편집인: 손장우 청소년보호책임자: 이수정
주소: 본사: 서울시 강남구 테헤란로 128, 3층 387호 Netmanias USA: 5214 36th Ave. NE Seattle, WA 98105 USA
Copyright ⓒ 2002-2023 NMC Consulting Group. All rights reserved.
|
안녕하세요? 오래전 글인데.. 질문을 드려도 될런지 모르겠네요.
우선 NAT에 관한 여러가지 글을 잘 읽었습니다. 이해에 많은 도움이 되었습니다.
질문은 위 요약의 그림에 있는 여러가지 Type중에서 P2P를 위해서 우회할 수 있는 방안이 각 Type별로 어떻게 되는지 확인 할 수 있을까요?
Type 1은 아무 상관이 없을 듯하구요. 나머지는 Hole Punching으로 모두 커버가 가능한지요?
Type 9는 symmetric이라 Relay방식을 써야 한다고 표현이 되어 있는데, Hole Punching으로 가능하지 않을까요?
홀펀칭은 기본적으로 공인망에 위치한 다수의 노드들인 A, B, C등이 통신 클라이언트로써
서버 역할을 하는 사설망의 노드 S로 먼저 접속을 시도할 수 있도록 하기 위해 사용합니다.
본문 자료에서 Mapping 방식은 NAT에서 내부 매핑 자원 관리에 대한 방법적인 구분이므로
홀펀칭 가능 여부 판단은 “filtering” 방식을 기준으로 판단하면 될 것 같습니다.
“Address & Port dependent mapping”인 경우를 기준으로
예를 들어 S가 홀펀칭을 위해 S의 s란 포트 번호를 사용 해 A의 a 포트로 패킷 (UDP, TCP등)을 먼저 보냈다면
1. Address & Port Dependent 필터링 – type 9)
NAT는 “S & s & A & a & 프로토콜“를 기준으로 패킷을 필터링하므로
B, C 뿐만 아니라 a가 아닌 A의 다른 포트 번호로도 S에게 패킷을 보낼 수 없습니다.
즉, 홀펀칭이 안 되는 것이고, B, C는 A의 a 포트를 경유(relay) 해서 간접적으로만 S와 통신이 가능합니다.
2. Address Dependent 필터링 – type 8)
NAT는 “S & s & A & 프로토콜“를 기준으로 패킷을 필터링하므로
B, C 는 S에게 패킷을 보낼 수 없지만 A는 a가 아닌 다른 포트 번호를 사용해 S의 s로 패킷을 보낼 수 있습니다.
이 역시, 일반적으로 홀펀칭이라 부르진 않고 B, C최소한 A를 경유(relay) 해서 간접적으로만 S와 통신이 가능합니다..
3. Endpoint Independent 필터링 – type 7)
NAT는 “S & s & 프로토콜“를 기준으로 패킷을 필터링하므로
B, C를 포함한 아무나 S의 s로 패킷을 보낼 수 있습니다. (이게 홀펀칭에서 바라는 것이죠 ^^) .
버너님. 자세한 설명 감사합니다.
설명주신 부분에 대해서 추가적인 질문이 있습니다.
보통 홀펀칭이라 함은 한번 홀펀칭을 하면 아무나 들어올 수 있다는 것을 의미하나요? 아니면 홀펀칭을 접속하고자 하는 클라이언트별로 해주는 것을 의미하나요?
접속하는 클라이언트별로 각각 홀펀칭을 해준다라고 해석을 하면, 위에서 설명주신 예를 기반으로
1. Address & Port Dependent 필터링 – type 9)
=. S and s <-> A and a 는 홀펀칭이 된 것이고,
=. B,C도 접속을 위해서는 추가적으로 홀펀칭을 해주어야 한다.
2. Address Dependent 필터링 – type 8)
=. 1과 동일하게 포트만 제한이 없으므로 동일하게 각 클라이언트별로 홀펀칭을 해준다.
3. Endpoint Independent 필터링 – type 7)
=. 이는 아무 제약이 없으므로 구지 홀펀칭을 할 필요가 없는 것이 맞죠?
물론 1,2에서 제가 이해한 것이 맞다면 각 클라이언트별로 홀펀칭을 해주어야 하므로, 필터링 테이블이 과도하게 많아지는 경우도 발생하겠네요.
제가 이해한 것이 맞을런지요?
첫번째 질문)
대상별로 홀펀칭을 하는 방식 또는 한번 홀펀칭으로 아무나 들어오게 하는 방식
모두를 할 수 있는 것을 홀펀칭이라 합니다.
즉, 방법이야 어찌되었든 사설망에 있는 노드를 외부에 있는 임의의 노드들이 접속할 수
있도록 하는 모든 방법을 포괄적으로 홀펀칭이라 말합니다.
1번 질문 ) 네, B, C 별로 홀펀칭해야 합니다.
2번 질문 ) 네, B, C 별로 홀펀칭해야 합니다.
3번 질문 ) NAT가 매핑 테이블을 만들도록 어디든 한번은 홀펀칭을 해야 합니다.
마지막 질문) 네, 많아지겠지요..
구글에서 “hole punch open source” 로 검색하면 오픈소스들도 있으니 참고하시면 되고,
오래전이긴 하지만 예전에는 홀펀칭 라이브러리(?) 전문 개발 업체도 있었습니다.
새로운 공유기 출시될 때마다 홀펀칭을 시험하고 라이브러리를 개량개선해서 라이선스받고 파는 것 같더군요..
대상은 주로 P2P 업체나 온라임 게임 업체 같은 데였던 걸로 기억합니다. (업체명은 기억나지 않음)
홀펀칭을 relay 방식의 보조 수단 (relay 서버의 일부 부하 경감)으로 사용하면 모르겠지만
주 수단으로 사용하긴 제약이 많을 겁니다. (예로 통신 상대 둘이 모두 서로 다른 NAT 장비 뒤에 있을 때.. ^^;)
추가적인 설명도 감사합니다.
P2P와 NAT: NAT 통과 기법 소개 (RFC 5128) - 2편: UDP Hole Punching (https://www.netmanias.com/ko/?m=view&id=blog&no=6263) 자료를 보면, 아래와 같이 EIM만 가능하다고 명시가 되어 있습니다.
----------------------------
RFC 5128에 따르면 UDP Hole Punching은 Endpoint-Independent Mapping을 지원하는 NAT(이하 EIM-NAT)에서만 동작을 한다고 합니다.
----------------------------
즉, 통신 상대 둘이 모두 서로 다른 NAT 장비 뒤에 있을 때,
Type 1,2,3만 UDP Hole Punching으로 통신이 가능하다는 말인데.. 제 생각으로는 모든 Type이 가능할 것으로 보는게 맞겠지요?
"예로 통신 상대 둘이 모두 서로 다른 NAT 장비 뒤에 있을 때.." 라고 언급하셨는데.. 추가적으로 더 고민해야 할 사항으로 어떤 것이 있을까요?
관련 자료가 있다면 공유 부탁드리겠습니다.
감사합니다.