1 UDP 구멍뚫기(hole punching) 기법 #

이 기법은 알맞게 디자인된 P2P 어플리케이션들이 미들박스(middlebox)를 경유하도록 "구멍 뚫기"를 실행한다음 직접 서로간에 연결되도록하기위해 일반적인 방화벽과 cone NAT의 특성에 의존합니다. 이 기술은 RFC 3027NAT-PROT의 5.1장에 자세히 언급되어있으며, KEGEL에도 자세히 설명되어있고, TEREDO, ICE와 같은 몇몇 프로토콜에도 현재 사용되고 있습니다. 하지만 불행히도 이름에서 쉽게 알수 있듯이, 이 기법은 UDP에서만 제대로 동작합니다.

여기에서는 두가지 시나리오를 제시하고 이 시나리오들을 다루는데 있어서 어떻게 어플리케이션을 디자인하는지를 보여줄 것입니다. 첫번째로는 가장 일반적인 경우로서 두개의 다른 NAT상에 놓인 P2P 통신 연결을 다루는 경우이고, 두번째는 두 클라이언트 모두 같은 NAT 뒤에 놓인 경우(하지만 이들이 그런 상황이라는 것은 아직 알지 못한 경우)입니다.

클라이언트 A, B는 private IP 주소를 가지고 있고 서로다른 NAT뒤에 놓여있다고 가정합니다. 각각의 A, B에서 실행중인 P2P 어플리케이션은 UDP 포트 1234번을 사용합니다. A,B모두 서버 S와 UDP 통신 세션이 열려있다고 가정하며, 이미 NAT A는 자기 자신의 고정 UDP 포트 62000번을 A에 대한 세션으로 열고 있고, NAT B는 31000번 포트로 B에 대한 세션으로 열고 있다고 가정합니다.

이제 A가 B로 직접 UDP 연결을 시도하려합니다. A가 단순하게 B의 고정주소인 138.76.29.7:31000으로 UDP 메세지를 보내기 시작하면 NAT B는 일반적으로 이 메세지를 취소합니다(NAT가 cone NAT가 아닐 경우) 왜냐하면 원본 주소와 포트 번호가 원래의 외부로 연결된 세션설정인 S와의 설정과 맞지 않기 때문입니다. B에서 A로 연결할 경우도 마찬가지 일겁니다.

자, 이제 A가 B의 고정주소로 메세지를 보내기 시작하면서 동시에 B도 A에게 UDP 메세지를 보내라는 요청을 S를 통하여 B로 릴레이합니다. B의 고정주소(138.76.29.7:31000)으로 A가 전송한 메세지는 NAT A가 A의 private 주소와 B의 고정 주소사이의 신규 통신 채널을 열수 있도록 합니다. 이와 동시에 A의 고정주소(155.99.25.11:62000)으로 B가 전송한 메세지 역시 NAT B로 하여금 B의 private 주소와 A의 고정 주소사이의 신규 통신 채널을 열게 합니다. 한번 새로운 UDP 세션이 각 방향으로 열리면, 클라이언트 A와 B는 더이상 "안내"서버 S에 부하를 주지 않고 직접 서로 통신 할 수 있게 됩니다.

UDP 구멍뚫기 기술은 몇몇 유용한 특징을 가지고 있습니다. 한번 미들박스 뒤의 두 클라이언트 사이에 P2P UDP 연결이 구축되면, 그 연결 상에 있는 다른 (이미 연결된) 동료 peer도 "안내자"의 역할이 가능하며 다른 동료 P2P 연결을 도울수 있습니다. (이는 처음 안내 서버 S의 부하를 최소화시켜줍니다) 위 단계는 클라이언트들이 미들박스 뒤에 있던 아니건 간에 상관없이 잘 동작하므로 어플리케이션은 명시적으로 미들박스의 종류를 진단하려하지 않아도 됩니다. 구멍뚫기 기술은 심지어 여러 단계의 NAT에 걸쳐있는 두 클라이언트 사이에도(다중 NAT의 경우) 잘 동작합니다.

이제 두 클라이언트가 같은 하나의 NAT뒤에 놓여있어 같은 private 포트 주소공간에 있다고 가정합시다. A는 S에 대하여 고정 주소 포트 62000으로 연결되어있고, B는 S에 대하여 62001 포트로 연결되어있다고 가정합시다.

이제 앞서 설명한 UDP 구멍뚫기 기술을 S를 안내서버로 사용하여 A, B에 적용해봅시다. Then A and B will learn each other's public IP addresses and port numbers as observed by server S, and start sending each other messages at those public addresses. The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. We refer to this situation as "loopback translation," because packets arriving at the NAT from the private network are translated and then "looped back" to the private network rather than being passed through to the public network. For example, when A sends a UDP packet to B's public address, the packet initially has a source IP address and port number of 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NAT receives this packet, translates it to have a source of 155.99.25.11:62000 (A's public address) and a destination of 10.1.1.3:1234, and then forwards it on to B. Even if loopback translation is supported by the NAT, this translation and forwarding step is obviously unnecessary in this situation, and is likely to add latency to the dialog between A and B as well as burdening the NAT. The solution to this problem is straightforward, however. When A and B initially exchange address information through server S, they should include their own IP addresses and port numbers as "observed" by themselves, as well as their addresses as observed by S. The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, then the packets directed to their private addresses are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private addresses will fail to reach each other at all, but the clients will hopefully establish connectivity using their respective public addresses. It is important that these packets be authenticated in some way, however, since in the case of different NATs it is entirely possible for A's messages directed at B's private address to reach some other, unrelated node on A's private network, or vice versa.

In some topologies involving multiple NAT devices, it is not possible for two clients to establish an "optimal" P2P route between them without specific knowledge of the topology. Consider for example the following situation.

Suppose NAT X is a large industrial NAT deployed by an internet service provider (ISP) to multiplex many customers onto a few public IP addresses, and NATs A and B are small consumer NAT gateways deployed independently by two of the ISP's customers to multiplex their private home networks onto their respective ISP-provided IP addresses. Only server S and NAT X have globally routable IP addresses; the "public" IP addresses used by NAT A and NAT B are actually private to the ISP's addressing realm, while client A's and B's addresses in turn are private to the addressing realms of NAT A and B, respectively. Each client initiates an outgoing connection to server S as before, causing NATs A and B each to create a single public/private translation, and causing NAT X to establish a public/private translation for each session.

Now suppose clients A and B attempt to establish a direct peer-to-peer UDP connection. The optimal method would be for client A to send messages to client B's public address at NAT B, 192.168.1.2:31000 in the ISP's addressing realm, and for client B to send messages to A's public address at NAT B, namely 192.168.1.1:30000. Unfortunately, A and B have no way to learn these addresses, because server S only sees the "global" public addresses of the clients, 155.99.25.11:62000 and 155.99.25.11:62001. Even if A and B had some way to learn these addresses, there is still no guarantee that they would be usable because the address assignments in the ISP's private addressing realm might conflict with unrelated address assignments in the clients' private realms. The clients therefore have no choice but to use their global public addresses as seen by S for their P2P communication, and rely on NAT X to provide loopback translation.

The hole punching technique has one main caveat: it works only if both NATs are cone NATs (or non-NAT firewalls), which maintain a consistent port binding between a given (private IP, private UDP) pair and a (public IP, public UDP) pair for as long as that UDP port is in use. Assigning a new public port for each new session, as a symmetric NAT does, makes it impossible for a UDP application to reuse an already-established translation for communication with different external destinations. Since cone NATs are the most widespread, the UDP hole punching technique is fairly broadly applicable; nevertheless a substantial fraction of deployed NATs are symmetric and do not support the technique.