PROGRAM PARK

Peer-to-Peer Communication Across Network Address Translators

Bryan Ford
Massachusetts Institute of Technology
baford (at) mit.edu

Pyda Srisuresh
Caymas Systems, Inc.
srisuresh (at) yahoo.com

Dan Kegel
dank (at) kegel.com

J'fais des trous, des petits trous
toujours des petits trous
- S. Gainsbourg

P2P관련된 기술 중 하나인 홀 펀칭에 대한 아주 좋은 논문을 번역해 봤습니다. 다행히 원작자인 Bryan Ford님이 번역본의 게재를 허락해주셨습니다. 하지만 제 번역을 너무 믿지 마시고 원문과 함께 읽기를 권해드립니다. 오역된 부분을 발견하시면 꼭 이메일로 알려주시길 부탁드립니다.

번역자 - 리안 (양영욱)
youngwook.yang (at) gmail.com

http://young2write.wordpress.com/

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 이용허락조건을 보려면, http://creativecommons.org/licenses/by-nc-nd/2.0/kr/을 클릭하거나, 크리에이티브 커먼즈 코리아에 문의하세요.

원문 : http://www.brynosaurus.com/pub/net/p2pnat/

Abstract:

네트워크 주소 변환 (NAT)은 P2P통신에 있어서 잘 알려진 어려움들을 야기한다. 이는 관련 Peer들이 임의의 global IP주소와 연결되지 않을 수도 있기 때문이다. 몇몇 NAT 선회 기법들이 알려져 있으나 문서화가 미미하고 또한 그들의 확실성, 상대적인 장점등에 관한 데이터는 더욱 불충분하다. 이 문서는 이들 기법중 가장 간단하지만 가장 확실하고 실용적인 NAT 선회 기법, "홀 펀칭" 을 분석한다. 홀 펀칭은 UDP 통신에 대해서는 어느 정도 이해되어져 있지만, 우리는 이것이 어떻게 TCP 통신에서도 믿을만 하게 이용되는지 살펴 볼 것 이다. 이 기법의 신뢰도 데이터를 다양한 NAT들을 상대로 하여 테스트한 결과, 해당 NAT들 중 82%가 UDP에 대한 홀 펀칭을 지원하고 약 64%가 TCP에 대한 홀 펀칭을 지원했다. NAT 벤더들이 점점 Voice over IP와 온라인 게임 프로토콜과 같은 중요한 P2P 어플리케이션의 필요를 알아감에 따라 미래에는 홀 펀칭에 대한 지원이 증가하게 될 것이다.

1. Introduction

인터넷의 거대한 성장과 방대한 보안 과제들이 결합되어 많은 어플리케이션들의 삶을 힘들게 많드는 방향으로 인터넷이 진화하게끔 해왔다. 인터넷 본래의 유니폼 주소 체계, 다시 말해 모든 노드들이 고유의 global IP주소를 가지고 다른 노드들과 직접 통신을 하는 방식은 사실상 지금 현존하는 주소 체계로 바뀌게 되었다. 지금 방식은 global 주소들로 이루어진 세계와 private 주소들로 이루어진 세계들이 네트워크 주소 변환 (NAT)를 통하여 연결되는 주소 체계이다. 이 새로운 주소 체계에서는 그림 1에서 보여지는 바와 같이 오직 "main"에 있는 노드들, 즉 global 주소 세계에 있는 노드들 만이 네트워크 상의 다른 노드들과 쉽게 연결할 수 있다. 오직 이들만이 global하게 전달 가능한(routable) IP 주소들을 가지기 때문이다. Private 세계에 있는 노드들은 같은 네트워크 안에 있는 노드들과 연결을 할 수 있으며, global주소 세계에 사는 "잘 알려진" 노드와 TCP 혹은 UDP 연결을 할 수 있다. 이 과정에서 NAT들은 안에서 밖으로 향하는 연결에 대하여 임시적으로 public 종점을 할당하고 이 세션을 구성하는 패킷들에 있는 주소와 포트를 변환한다. 이와 달리, 일반적으로 밖에서 안으로 향하는 모든 트래픽에 대해선 특별한 설정이 되어있지 않는 한 차단한다.

Figure 1: Public and private IP address domains

이 방식은 클라이언트가 private 네트워크에 있고 서버가 global 세계에 존재하는 전형적인 클라이언트/서버 통신에 적합하다. 반면에, 텔레컨퍼런싱이나 온라인 게임에 사용되는 P2P 통신 프로토콜에 중요한, 즉 서로 다른 private 네트워크에 존재하는 두 노드가 직접적으로 통신하게 하는 것을 어렵게 한다. 당연히 NAT들이 존재하는 이 상황에서도 이런 프로토콜들을 잘 작동하게 하는 방법이 필요하다.

서로 다른 private 네트워크에 존재하는 호스트들 간의 P2P 연결을 구성하는 가장 효과적인 방법중 하나가 "홀 펀칭"이라는 이름으로 알려져 있다. 이 방법은 이미 UDP기반의 어플리케이션들 사이에서 널리 이용되고 있으며 또한 본질적으로 TCP에도 적용된다. 이름이 주는 인상과 달리 홀 펀칭은 private 네트워크의 보안을 해치지 않는다. 대신, 홀 펀칭은 대부분의 NAT들의 기본 보안 정책 안에서 어플레이케이션이 작동하도록 한다. 경로 상의 NAT들에게 효과적으로 신호를 보내 P2P 통신의 세션들을 "요청"하게 함으로써 이 세션들이 수락되게 한다. 이 문서는 UDP와 TCP에 대한 홀 펀칭을 위한 것이며 홀 펀칭을 가능하게 하는데 중요한 어플레이케이션의 요소와 NAT 방식에 대해 세세히 살펴볼 것이다.

불행하게도, 모든 NAT에서 작동하는 선회 방법은 없다. 왜냐하면 NAT 작동 방식이 표준화되 있지 않기 때문이다. 이 문서는 현존하는 NAT들의 홀 펀칭 지원에 대한 실험의 결과를 제공한다. 우리의 데이터는 유저들이 인터넷을 통해 서로 다른 벤더들의 다양한 NAT들을 넘어 우리의 "NAT Check" 툴을 실행하여 제공된 결과에서 나온 것이다. 이 정보들은 자발적으로 선택된 유저들로 부터 모아진 관계로 실제로 출시된 NAT들의 분포상황을 반영하지는 않는다. 하지만 결과는 전반적으로 고무적이다.

기본적인 홀 펀칭을 알아보는 한편, 우리는 또한 보다 복잡함의 대가를 치루고서 더욱 다양한 NAT들에 대해 홀 펀칭이 작동하도록 하는 변칙들도 짚어 볼 것이다. 하지만 우리의 주 관심사는 합당한 네트워크망 상에서 "잘 작동하는" NAT들에 대해 명확하고 안정적으로 작동하는 가장 간단한 홀 펀칭 기법을 개발하는 것이다. 우리는 의도적으로 과도하게 영리한 기법들은 다루지 않았다. 이들이 비록 "깨진" NAT들에 대해 일시적인 호환성을 제공할지 모르나 이는 항상 동작하는 것도 아니거니와 장기적으로 볼 때 예측 불가능성과 네트워크 취약성을 일으킬 수 있기 때문이다.

비록 IPv6 [3]의 보다 큰 주소 공간이 결국에는 NAT의 필요성을 줄일지도 모르나, 단기적으로 오히려 이는 NAT의 필요성을 더욱 증가 시킬 것이다. 왜냐하면 NAT 자체가 바로 IPv4와 IPv6주소 도메인 사이의 상호 운영성을 이룰 수 있는 가장 쉬운 방법을 제공하기 때문이다 [24]. 거기다 더해, private 네트워크 상에 있는 호스트들의 익명성과 비접근성은 보안과 비공개의 장점들로 여겨진다. 충분한 IP 주소들이 있다 하여도 방화벽이 사라지진 않을 것이다. IPv6 방화벽들도 내부로 향하는 요청되지 않은 트래픽을 기본적으로 막을 것이고 이는 홀 펀칭을 IPv6 어플리케이션들 에게도 유용하게 만들 것이다.

이 문서의 나머지는 다음과 같이 정리되어 있다. 섹션 2는 기본적이 용어와 NAT 선회에 대한 개념을 소개한다. 섹션 3은 UDP에 대한 홀 펀칭에 대해 자세히 알아보고 섹션 4는 TCP에 대한 홀 펀칭을 소개한다. 섹션 5는 NAT가 홀 펀칭을 위해서 반드시 가져야하는 중요한 특성들을 요약한다. 섹션 6은 대중적인 NAT들의 홀 펀칭 지원 여부에 대한 실험 결과를 보여주고 섹션 7은 관련된 연구들에 대해 논의하며 섹션 8에서 결론을 짓는다.

2 General Concepts

이 섹션에서는 이 문서에서 사용되는 기본적인 NAT 용어들을 소개한다. 그리고 UDP와 TCP에 같이 적용되는 일반적인 NAT 선회기법들을 개괄한다.

2.1 NAT Terminology

이 문서는 RFC 2663 [21]에 정의된 NAT 용어들과 분류법, 그리고 RFC 3489 [19]에 최근 추가로 정의된 용어들을 사용한다.

특별히 중요한 개념은 세션이다. TCP 혹은 UDP를 위한 세션 종점은 IP 주소와 포트 번호로 이루어진 하나의 쌍이며 하나의 고유한 세션은 두 개의 세션 종점들로 이루어진다. 연관된 호스트들 중 한 호스트의 관점에서 보면, 세션은 4개의 요소(로컬 IP, 로컬 포트, 리모트 IP, 리모트 포트)들로 효과적으로 식별된다. 세션의 방향은 보통 세션을 처음 시작한 패킷의 흐름 방향이다. 즉, TCP의 경우 초기 SYN 패킷이고 UDP의 경우 첫 번째 유저 데이터 그램이다.

다양한 NAT의 방식 중 가장 일반적인 형은 traditional 혹은 outbound NAT이다. 이 방식은 private 네트워크와 public 네트워크 사이의 비대칭(asymmetric) 다리를 제공한다. 기본적으로 outbound NAT는 오직 외부로 향하는 (outbound) 세션들만이 NAT를 선회할 수 있게 허용한다. 내부로 향하는 패킷들의 경우, NAT가 이 패킷들이 속한 세션이 자신의 private 네트워크에서 시작된 세션이라고 식별하지 않는 한 차단된다. Outbound NAT는 P2P 프로토콜들과 충돌을 일으키는데 이는 두 peer들이 서로 다른 두 NAT "뒤에" 존재하는 상황에서 서로 통신을 하려할 때 , 누가 세션을 시작할려고 하든 상대방 peer의 NAT가 이를 거절하기 때문이다. NAT 선회는 양쪽 NAT들에게 P2P 세션들이 "밖으로 향하는" 세션들로 보이도록 만든다.

Outbound NAT는 두 개의 변형을 가진다. Basic NAT는 오직 IP 주소만을 변환하고 Network Address/Port Translation (NAPT)는 전체 세션 종점을 변환한다. 더 일반적인 형인 NAPT는 가장 보편화가 되었는데 이는 private 네트워크에 있는 호스트들이 하나의 public IP주소를 공유 할수 있게 해주기 때문이다. 이 문서에서 우리는 NAT가 NAPT라고 가정할 것 이나, 우리가 논의할 기본 원리와 기법들은 Basic NAT에도 똑같이 잘 (때때로 차이를 무시해도 상관없이) 적용된다.

2.2 Relaying

NAT를 넘나드는 가장 확실한 (그러나 가장 비효과적인) P2P 통신 방법은 중계(relaying)를 통해서 간단하게 표준 클라이언트/서버 모델 처럼 만드는 것 이다. 두 호스트 A와 B가 잘 알려진 서버 S에 UDP 혹은 TCP 연결을 시작했다고 하자. 이 때 S의 IP 주소는 18.181.0.31, 포트 번호는 1234라 하자. 그림 2에서 보이듯, 두 클라이언트는 서로 다른 private 네트워크 상에 존재하며 각각의 상응하는 NAT가 상대 클라이언트와 직접적으로 연결을 시작하는 것을 막고 있다. 직접 연결하는 대신에 두 클라이언트는 둘 사이의 메세지를 중계해주는 역할로 서버 S를 이용할 수 있다. 예를 들어, 클라이언트 B에게 메세지를 보내려면 클라이언트 A는 그냥 그 메세지를 서버 S로 이미 구성된 클라이언트/서버 연결을 통하여 보낸다. 그러면 서버 S는 이미 존재하는 B와의 클라이언트/서버 연결을 이용해 이를 클라이언트 B로 전달한다.

Figure 2: NAT Traversal by Relaying

두 클라이언트가 서버에 연결할 수 있는 한 중계는 항상 작동한다. 이 기법의 단점은 서버의 프로세싱 파워와 네트워크 대역폭을 소모한다는 것 이다. 또한 아무리 서버가 잘 연결되어 있다 하더라도 두 클라이언트 사이의 통신 지연이 늘어날 가능성이 있다. 그럼에도 불구하고, 모든 NAT들을 상대로 확실히 동작하는 효과적인 기법이 없기 때문에, 최대의 확실성이 요구된다면 중계는 유용한 대책이다. TURN 프로토콜 [18]은 중계를 상대적으로 안전하게 구현하는 법을 정의한다.

2.3 Connection Reversal

어떤 P2P 어플리케이션들은 보다 명확하지만 제한적인 기법을 사용한다. 이 기법은 "거꾸로 연결"(connection reversal) 이라고 알려져 있는데, 그림 3에 나오듯, 두 호스트가 모두 잘 알려진 랑데뷰 서버 S에 연결되어 있고 오직 하나의 피어(peer)만이 NAT 뒤에 있을 경우 통신을 가능케 한다. 만약에 A가 B를 향해 연결을 시작하려 하면 이 직접 연결 시도는 자동적으로 작동한다. 왜냐하면 B는 NAT뒤에 있지 않고 A의 NAT는 이 연결을 밖으로 향하는 세션으로 해석하기 때문이다. 하지만, 만약 B가 A를 향해서 연결을 시작하려 하면, A를 향한 어떤 직접 연결 시도든 A의 NAT에 의해 차단 당하게 된다. 그 대신에 B는 잘 알려진 서버 S를 통해서 연결 요청을 중계할 수 있다. 다시 말해 A에게 B를 향해 거꾸로 연결을 시도하라고 요청하는 것 이다. 이 기법의 명확한 한계와 상관없이, 랑데뷰 서버를 이용해서 P2P 연결의 셋업을 돕는 핵심 아이디어는 다음에 기술되는 더 일반적인 홀 펀칭 기법의 기본이 된다.

Figure 3: NAT Traversal by Connection Reversal

3 UDP Hole Punching

UDP 홀 펀칭은 두 클라인언트가 모두 NAT 뒤에 있다고 하더라도 잘 알려진 랑데뷰 서버를 통해서 직접적인 P2P UDP 세션을 구성케 하는 기법이다. 이 기법은 RFC 3027의 5.1 섹션 [10]에 언급되었으며, 이 웹 [13]에서 더 완전히 문서화가 되었고 최근의 실험적인 인터넷 프로토콜들 [17,11]에서 사용되었다. 또한 온라인 게임을 위한 다양한 고유의 프로토콜들도 역시 UDP 홀 펀칭을 사용한다.

3.1 The Rendezvous Server

3.2 Establishing Peer-to-Peer Sessions

이제 우리는 UDP 홀 펀칭이 3가지 각각 특정의 네트워크 상황을 어떻게 다루는지 생각할 것이다. "쉬운" 경우라고 할 수 있는 첫번째 상황은 바로 두 클라이언트가 같은 NAT 뒤에 존재하는 경우이다. 두번째 경우는 가장 일반적인 것으로 클라이언트들이 서로 다른 NAT 뒤에 사는 것이다. 세번째 경우는 각각의 클라이언트가 두 레벨의 NAT 뒤에 있는 상황이다. 인터넷 서비스 제공 업체에서 배치된 일반적인 "첫 번째 레벨" NAT와 홈 네트워크를 위한 별개의 "두 번째 레벨" NAT 라우터들이 예가 된다.

어플리케이션 자신이 정확하게 물리적인 네트워크 레이아웃을 판별하기란 대개 어렵거나 불가능하다. 따라서 주어진 시간에 위의 상황들 (혹은 다른 많은 가능한 상황들) 식별하는 것도 마찬가지다. STUN [19]과 같은 프로토콜들이 통신 경로 상의 NAT들에 대한 일정 정보를 제공할 수 있지만 이런 정보들이 항상 완전하거나 믿을만 한 것은 아니다. 특히 다중 레벨의 NAT들이 연관되었을 때 그렇다. 이런 상황에도 불구하고, 홀 펀칭은 이 모든 경우에 대해 어플리케이션이 특정 네트워크 구성을 알 필요가 없이 자동적으로 동작한다. 단, 연관된 NAT들이 합리적인 방식으로 동작할 경우에 한해서다. (NAT의 "합리적인" 동작들에 대해서 섹션 5에서 설명될 것이다.)

3.3 Peers Behind a Common NAT

첫번째로 생객해 볼 상황은 두 클라이언트가 (아마도 모르게) 같은 NAT 뒤에 사는 경우이다. 따라서 그림 4에서 보여지듯, 이들은 같은 private IP 주소 세상에 자리하고 있게 된다. 클라이언트 A는 서버 S와 UDP 세션을 구성하였고 NAT는 자신만의 public 포트 번호 62000을 이에 할당 하였다. 클라이언트 B도 비슷하게 S와 UDP연결을 구성했으며 NAT는 이에 public 포트 번호 62005를 할당 하였다.

Figure 4: UDP Hole Punching, Peers Behind a Common NAT

클라이언트 A가 위에서 개괄된 홀 펀칭 기법을 사용하여 서버 S를 소개자로 이용, B와 UDP 세션을 구성한다고 해보자. 클라이언트 A는 S에게 B에 대한 연결 요청 메세지를 보낸다. S는 A에게 B의 public과 private 종점들로 답을 하고 또한 A의 public과 private 종점들을 B로 전달한다. 이후 양쪽 클라이언트 모두 이들 종점들을 향해서 UDP 데이터그램을 상대방에게 직접적으로 보내길 시도한다. public 종점으로 향하는 메세지들은 그들의 종착지에 갈 수도 있고 못 갈수도 있는데 이는 해당 NAT가 아래 섹션 3.5에서 기술되는 hairpin 변환을 지원하냐 안하냐에 달려있다. 반면에, private 종점들로 향하는 메세지들은 그들의 종착지에 도달한다. 그리고 또한 private 네트워크를 통한 이 직접 루트가 NAT를 통하는 간접 루트 보다 빠를 것 이므로, 클라이언트들은 이후의 정식 연결을 위해서 십중팔구 private 종점들을 선택할 것이다.

NAT가 hairpin 변환을 지원한다고 가정하면, private 종점들에게도 public 종점들과 같이 연결을 시도해야하는 복잡함을 없앨 수도 있다. 이는 어플리케이션이 같은 NAT 뒤에 있는 로컬 연결을 해당 NAT를 불필요하게 거쳐가게 하는 것을 대가를 치뤄야한다. 하지만 섹션 6에서 우리의 결과가 보여주듯, hairpin 변환은 다른 "P2P에 친근한" NAT 동작들에 비해 아주 적게 퍼져있다. 따라서, 지금 당장은 어플레이케이션들이 public과 private 종점들을 모두 사용함으로써 실제의 이득을 얻을 것 같다.

3.4 Peers Behind Different NATs

그림 5에서 나오듯, 클라이언트 A와 B가 서로 다른 NAT들 뒤에 private 주소를 가진다고 해보자. A와 B는 각자 그들의 로컬 포트 4321에서 서버 S의 포트 1234로 UDP 연결을 시작했다. 이 outbound 세션들을 다루기 위해, NAT A는 S와 연결된 A의 세션에 포트 62000을 자신의 public IP, 155.99.25.11에 할당 하였다. NAT B는 S와 연결된 B세션에 포트 310000을 자신의 IP주소, 138.76.29.7에 할당했다.

Figure 5: UDP Hole Punching, Peers Behind Different NATs

A는 자신의 private 종점 10.0.0.1:4321을 자신의 등록 메세지를 통해 서버로 보낸다. 이때 10.0.0.1은 자신의 private 네트워크 상에서의 IP주소이다. S는 전달된 A의 private 종점과 함께 자신이 보는 A의 public 종점도 함께 기록한다. 이 경우에, A의 public 종점은 155.99.25.11:62000이다. 이는 NAT에 의해 해당 세션에 임의로 할당된 종점이다. 이와 비슷하게 B가 등록을 할 경우에 S는 B의 private 종점인 10.1.1.3:4321과 B의 public 종점인 138.76.29.7:31000을 기록한다.

인제 클라이언트 A는 B와의 직접적인 UDP 통신 세션을 만들기 위해 위에서 설명된 홀펀칭 방식을 따르게 된다. 먼저, A는 S에게 B와의 연결을 위한 도움을 요청하는 메세지를 보낸다. S는 이에 대한 답으로 B의 public과 private 종점을 A에게 보낸다. 또한 A의 public과 private 종점을 B로 보낸다. A와 B는 각각 서로의 종점들을 향해 UDP 데이터그램을 보내기를 시작한다.

A와 B가 서로 다른 private 네트워크 상에 있기 때문에 그들 각각의 private IP주소는 전역적으로 전달 가능하지 않다. 따라서 이들 종점으로 보내진 메세지들은 잘못된 호스트에 도달하거나 아니면 어떤 호스트에도 도달하지 않을 것이다. 많은 NAT들이 DHCP서버로서의 역할을 하고 있는데 주로 NAT벤더들에 의해 기본으로 선택된 private 주소 pool로 부터 아주 결정론적인 방식으로 IP주소들을 할당하는 식이다. 이 때문에 실질적으로는, B의 private 종점으로 향하는 A의 메세지는 A의 private 네트워크 상에 있는 B와 같은 private IP주소를 가지게 된 어떤 다른 호스트로 전달될 것이다. 따라서 어플레케이션은 반드시 모든 메세지들을 무슨 방식으로든 인증함으로써 이런 길잃은 메세지들을 강하게 걸러내야 한다.

자 인제 그림 5에서 보여지듯, B의 public 종점으로 보내진 A의 첫번째 메세지를 생각해보자. 이 밖으로 향하는 메세지가 A의 NAT를 통과함에 따라, NAT는 이 메세지가 밖으로 향하는 새로운 세션의 첫번째 UDP 패킷임을 알게 된다. 이 새로운 세션의 시작 종점(10.0.0.1:4321)은 A와 S사이에 이미 존재하는 세션과 같다. 하지만 도착 종점은 다르다. 만약 NAT A가 잘 작동한다면, A의 private 종점의 ID를 보존한다. 이는 private 시작 종점인 10.0.0.1:4321 주소로 부터 이 해당되는 pubilc 시작 종점인 155.99.25.11:62000 주소로 일관적으로 변환하는 ID이다. 따라서 B의 public 종점으로 항하는 A의 첫번째 메세지는 사실 상 A의 NAT에 "구멍을 뚫은 것이다." 이 홀펀칭은 바로 새로운 세션을 위한 것인데, 이 세션은 A의 private 네트워크상에서 두 종점들 (10.0.0.1:4321 - A의 private 주소, 138.76.29.7:31000 - B의 public 주소)로 정의된다. 또한 이 세션은 메인 인터넷 상에서 두 종점들(155.99.25.11:62000 - A의 public 주소, 138.76.29.7:31000 - B의 public 주소)로 정의된다.

만약 B의 public 종점으로 향하는 이 A의 메세지가 B의 NAT이 도달했는데 아직 A를 향하는 B의 첫번째 메세지가 B의 NAT를 건너기 전 이라고 하자. 이 경우 B의 NAT는 내부로 향하는 A의 메세지를 요청되지 않은 트래픽으로 분류, 걸러낼 것이다. 반면에, A의 public 주소로 향하는 B의 첫번째 메세지는 앞서 설명과 마찬가지로 B의 NAT에 구멍을 열게 된다. 이는 새 세션을 위한 것으로 B의 private 네트워크에서 두 종점들(10.1.1.3:4321 - B의 private 주소, 155.99.25.11:62000- A의 public 주소)로 정의됨과 동시에 인터넷 상에서는 (138.76.29.7:31000 - B의 public 주소, 155.99.25.11:62000 - A의 public 주소)로 정의된다. A와 B가 각자 자신들의 NAT들을 한번 건너기만 하면, 구멍들이 각각의 방향으로 열리고 UDP 통신이 정상적으로 진행될 수 있다. 클라이언트들은 public 종점들이 작동한다는 것을 한번 확인하고 나면 또 다른 방편이였던 private 종점들로 메세지들을 보내는 것을 멈출 수 있다.

3.5 Peers Behind Multiple Levels of NAT

다중 NAT 장치들에 연관된 어떤 망들에서는, 두 클라이언트가 그 망의 특정한 지식이 없이는 "최적의" P2P연결을 구성을 할 수가 없다. 그림 6에 나와있는 마지막 상황을 생각해보자. 인터넷 서비스 제공 업체 (ISP)가 많은 고객들을 적은 public IP주소 만으로 다중 수신하기 위해 큰 기업형 NAT C를 설치했다고 해보자. 여기에 해당 인터넷 업체의 고객들이 집에서 그들의 홈 네트워크를 구성하기 위해 각자의 ISP 제공 IP주소에 NAT A와 B를 설치했다고 해보자. 서버 S와 NAT C만이 오직 전역적으로 전달 가능한 IP 주소를 가지고 있다. NAT A와 B의 public 주소는 사실 ISP 주소 세계 안에 있는 private 주소이다. 한편, 클라이언트 A와 B의 주소는 NAT A와 B의 세계에 있는 private 주소인 것이다. 전과 마찬가지로 각각의 클라이언트가 서버를 향해 밖으로 향하는 연결을 시작한다. 이는 NAT A와 B 각각 하나의 public/private 변환을 생성하며 또한 NAT C가 이 각각의 세션에 해당하는 public/private 세션 구성을 야기한다.

Figure 6: UDP Hole Punching, Peers Behind Multiple Levels of NAT

자 인제 A와 B가 홀 펀칭을 통해서 직접 P2P 연결 구성을 시도한다고 해보자. 아마 최적의 라우팅 방식은 클라이언트 A가 NAT B에 있는 클라이언트 B의 "semi-public" 주소, 10.0.1.2:55000 (ISP 주소 공간), 으로 메세지를 보내고 클라이언트 B역시 NAT A에 있는 클라이언트 A의 "semin-public" 주소, 10.0.1.2:45000 으로 보내는 방식일 것이다. 하지만 불행히도, A와 B가 이 주소를 알 방법은 없다. 왜냐하면 서버 S는 오직 클라이언트의 진정한 전역 public 주소만 보기 때문이다. 또한 A와 B가 이 주소들을 어떻게든 알았다 하여도 이들이 사용가능 할지는 미지수이다. 이는 ISP의 prviate 주소 세계의 IP주소 할당과 클라이언트의 private 세계에서의 IP 주소 할당이 충돌할 수 있기 때문이다. (예를 들어서, NAT C에서 NAT A로 할당한 IP주소가 NAT B에서 클라이언트 B로 할당한 주소인 10.1.1.3 일지도 모르는 것이다. (역주: 이러면 B는 자기 자신에게 메세지를 보내는 결과가 나와버린다.)

따라서 P2P통신을 위해 클라이언트들은 서버 S에게 보여지는 그들의 전역 public 주소를 이용하는 수 밖에는 없다. 그리고 NAT C에서 제공하는 hairpin 혹은 loopback 변환에 의존해야한다. A가 B의 전역 종점, 155.99.25.11:62005으로 UDP 데이터그램을 보낼 때 NAT A는 먼저 데이터그램의 시작 종점을 10.0.0.1:4321을 10.0.1.1:45000으로 변환한다. 이제 이 데이터그램은 NAT C에 도착하고 이 데이터그램의 도착 주소가 NAT C의 변환된 public 종점들 중에 하나라는 것을 알아차린다. 만약 NAT C가 잘 동작한다면, 데이터그램의 시작과 도착 종점을 모두 변환하고 이 데이터그램을 "돌려서" private 네트워크로 보낸다. 이제 데이터그램의 시작 종점은 155.99.25.11:62000 이고 도착 종점은 10.0.1.2:55000 이다. 끝으로 B의 private 네트워크로 이 데이터그램이 들어가면서 NAT B가 이 데이터그램의 도착 주소를 변환, B에 도착하게 된다. A로 가는 길도 비슷하게 작동한다. 많은 NAT들은 아직 hairpin 변환을 지원하지 않는다. 하지만 NAT 벤더들이 이 문제를 인지함에 따라서 점점 보편화 될 것이다.

3.6 UDP Idle Timeouts

4 TCP Hole Punching

4.1 Sockets and TCP Port Reuse

동시에 서버 S와 임의의 개수의 상대방과의 통신을 하기 위해 딱 하나의 소켓만을 필요로 하는 UDP와 달리. 각각의 TCP 클리언트 어플리케이션은 그림 7에 나오듯 하나의 로컬 TCP 포트에 바운드된 여러개의 소켓을 다뤄야한다. 각각의 클라이어트들은 서버 S와의 연결을 나타내는 소켓, 안으로 향하는 연결을 수락하기 위한 수신 소켓, 그리고 상대방의 public과 private TCP 종점들을 향해 밖으로 향하는 연결을 시작하기 위한 최소한 두 개이상의 소켓이 필요하다.

Figure 7: Sockets versus Ports for TCP Hole Punching

그림 5에 나오듯, A와 B가 서로 다른 NAT들 뒤에 있는 일반적인 경우를 따져보자. 포트 번호들이 UDP 포트가 아니라 TCP 포트라고 해보자. A와 B의 private 종점으로 향하는 연결들은 실패하거나 잘못된 호스트와 연결된다. UDP의 경우와 같이, TCP 어플리케이션들도 그들의 P2P 세션들을 인증하는 것이 중요한다. 로컬 네트워크 상에 있는 호스트가 원래 연결하고자 하는 원격 private 네트워크상의 호스트와 똑같은 private IP를 가지는 경우에, 실수로 잘못된 연결이 생길수 있는 가능성이 있기 때문이다.

반면에 각자의 public 종점으로 향하는 연결들의 경우, 이에 해당하는 NAT들로 하여금 A와 B의 직접적인 TCP연결을 활성화 시켜주는 "구멍"을 열게한다. 만약 이 NAT들이 잘 작동한다면, 그들 사이의 새로운 P2P TCP 연결이 자동적으로 형성된다. 만약 B의 첫번째 SYN패킷(A로 향하는)이 B의 NAT에 닿기 전에, A의 첫번째 SYN 패킷(B로 향하는)이 B의 NAT에 닿으면, B의 NAT는 이를 요구되지 않은 안으로 향하는 연결로 간주, 이 패킷을 버린다. 하지만, 이후에 B의 첫번째 SYN 패킷(A로 향하는)은 통과되게 되는데, 이는 A의 NAT가 이 SYN을 B로의 향하는 연결의 한 부분으로 간주하기 때문이다. B로의 밖으로 향하는 연결을 A의 SYN이 시작했다고 보는 것이다. (역주: 간단히 말해 A의 SYN 패킷이 이미 A의 NAT에 "구멍"을 뚫어 놓은 것이다.)

4.3 Behavior Observed by the Application