NAT와 방화벽 (3) - NAT 트래버설과 P2P 통신 - soo:bak

작성일 : 2026년 01월 20일

NAT 뒤의 장치끼리 어떻게 통신하는가

인터넷은 원래 모든 장치가 고유한 주소를 갖고 서로 직접 통신하는 구조로 설계되었습니다.

초기 인터넷의 근간은 종단간 원칙(End-to-End Principle)이었습니다.

네트워크 중간의 라우터와 스위치는 패킷을 목적지까지 전달만 하고, 패킷 안에 무엇이 들어있는지 해석하거나 조작하지 않습니다.

오류 복구, 암호화, 데이터 해석 같은 “지능적인” 기능은 통신하는 양쪽 끝(애플리케이션)이 담당합니다.

Part 1에서 다룬 것처럼, IPv4 주소 고갈로 등장한 NAT는 이 원칙을 깨뜨렸습니다.

NAT는 내부에서 외부로 나가는 패킷(아웃바운드)을 기준으로 변환 테이블 항목을 생성하므로, 내부에서 먼저 연결을 시작해야 외부와 통신할 수 있습니다.

테이블에 항목이 없으면 외부 패킷을 어느 내부 장치로 보내야 할지 판단할 수 없어 폐기합니다.

Part 2에서 다룬 방화벽의 상태 추적도 같은 방식으로 동작합니다.

그렇다면 두 장치가 모두 NAT 안쪽에서 사설 IP를 쓰고 있으면 어떻게 될까요?

A의 네트워크                                B의 네트워크
┌─────────────────┐                        ┌─────────────────┐
│  A              │                        │  B              │
│  192.168.1.10   │                        │  10.0.0.20      │
└────────┬────────┘                        └────────┬────────┘
         │                                          │
    ┌────┴────┐                                ┌────┴────┐
    │  A NAT  │                                │  B NAT  │
    │ (공인IP:│                                │ (공인IP:│
    │ 203.0.  │                                │ 198.51. │
    │ 113.5)  │                                │ 100.7)  │
    └────┬────┘                                └────┬────┘
         │                                          │
         └─────────────── 인터넷 ───────────────────┘

A가 B에게 패킷을 보내면, B의 NAT는 변환 테이블을 확인합니다. B가 A에게 먼저 보낸 적이 없으므로 매핑이 없습니다. NAT는 이 패킷을 내부의 어느 장치로 전달해야 할지 알 수 없어 폐기합니다.

B가 먼저 A에게 보내도 마찬가지입니다. A의 NAT에 매핑이 없으므로 차단됩니다.

어느 쪽도 먼저 연결을 열 수 없습니다.

1990년대까지는 이 제약이 큰 문제가 되지 않았습니다. 당시 인터넷 사용 패턴은 대부분 클라이언트-서버 모델이었습니다. 사용자가 웹 브라우저로 서버에 요청하고, 서버가 응답하는 구조입니다. 서버는 공인 IP를 가지므로 항상 접근 가능했고, 사용자(클라이언트)가 먼저 요청을 보내므로 NAT 매핑이 자연스럽게 생성되었습니다.

2000년대에 들어서면서 상황이 달라집니다. VoIP(Skype, 2003년), 파일 공유(BitTorrent, 2001년), 실시간 멀티플레이어 게임처럼 두 사용자가 직접 연결해야 하는 애플리케이션이 늘어났습니다. 양쪽 모두 NAT 안쪽에 있는 일반 사용자이므로, 앞서 본 문제가 그대로 적용됩니다.

P2P 애플리케이션의 어려움

양쪽이 모두 NAT 안쪽에 있으면 직접 연결이 막힙니다.

가장 단순한 우회책은 중앙 서버를 경유하는 것입니다. A가 서버에 데이터를 보내고, 서버가 B에게 전달합니다.

양쪽 모두 서버에 먼저 연결을 열기 때문에 NAT 매핑이 생기고, 서버의 응답은 그 매핑을 통해 들어올 수 있습니다.

동작은 하지만, 대가가 따릅니다.

지연: 서울의 두 사용자가 직접 연결하면 5ms 미만이지만, 도쿄의 서버를 경유하면 50ms 이상으로 늘어납니다. VoIP 통화는 편도 지연이 150ms를 넘으면 대화가 부자연스러워지고, 실시간 게임은 10ms 차이도 체감됩니다.

비용: 720p 화상 스트림 하나가 약 2~4 Mbps입니다. 100만 명이 동시에 1:1 통화를 하면 서버가 중계할 트래픽은 수 Tbps에 달하고, 이 비용은 고스란히 서비스 제공자 몫입니다.

개인정보: 모든 트래픽이 서버를 거치므로, 서버 운영자가 통화 내용이나 파일에 접근할 수 있습니다.

이 대가를 피하려면 NAT를 통과해서 직접 연결해야 합니다. NAT 트래버설(NAT Traversal)이 이를 가능하게 하며, 접근법은 두 가지입니다.

직접 연결: NAT의 동작 방식을 역으로 이용합니다. STUN과 홀 펀칭이 여기에 해당합니다.
릴레이: 직접 연결이 불가능할 때, 중계 서버를 거칩니다. TURN이 이 역할을 합니다.

ICE는 두 접근법을 자동으로 조율하는 프레임워크입니다.

트래버설 난이도는 NAT 유형에 따라 크게 달라집니다. 구체적인 기법을 살펴보기 전에, NAT 유형부터 정리하겠습니다.

NAT 유형과 트래버설 난이도

모든 NAT가 같은 방식으로 동작하지는 않습니다. RFC 3489(2003)는 NAT를 네 가지 유형으로 분류했고, 이 분류는 트래버설 난이도를 파악하는 데 여전히 유용합니다.

네 유형을 가르는 기준은 두 가지입니다.

(1) 매핑: 같은 내부 소켓이 목적지가 달라져도 같은 외부 포트를 쓰는가?

(2) 필터링: 외부에서 들어오는 패킷을 어떤 조건으로 허용하는가?

Full Cone NAT (1:1 NAT)

내부 호스트가 패킷을 한 번 보내면 매핑이 생성됩니다. 이후 어떤 외부 호스트든 그 매핑된 포트로 패킷을 보낼 수 있습니다. 출발지 IP나 포트를 검사하지 않습니다.

내부: 192.168.1.10:12345
외부: 203.0.113.5:40001 (매핑됨)

한 번 매핑이 생성되면:
- 어떤 외부 호스트도 40001로 연결 가능
- 출발지 IP나 포트를 확인하지 않음

외부에서 매핑된 포트만 알면 접근할 수 있으므로 트래버설이 가장 쉽습니다.

반면 보안은 가장 취약합니다. 공격자가 매핑된 포트를 알아내면 원치 않는 패킷을 보낼 수 있기 때문입니다. 오늘날 가정용 공유기에서는 거의 사용되지 않습니다.

Restricted Cone NAT

매핑 규칙은 Full Cone과 같습니다. 같은 내부 소켓은 목적지가 달라져도 항상 같은 외부 포트를 사용합니다.

차이는 수신 조건입니다. 이전에 패킷을 보낸 적 있는 IP에서 온 패킷만 허용합니다. 포트는 확인하지 않습니다.

내부: 192.168.1.10:12345
외부: 203.0.113.5:40001

93.184.216.34로 패킷을 보낸 적 있다면:
- 93.184.216.34의 어떤 포트에서든 40001로 오는 패킷 → 허용
- 다른 IP에서 40001로 오는 패킷 → 차단

상대 IP로 먼저 패킷을 보내야 NAT가 그 IP를 허용합니다. 양쪽이 거의 동시에 패킷을 보내면 서로의 NAT에 허용 항목이 생기고, 이후 통신이 가능해집니다.

Port Restricted Cone NAT

Restricted Cone보다 한 단계 엄격합니다. IP뿐 아니라 포트까지 일치해야 수신을 허용합니다.

내부: 192.168.1.10:12345
외부: 203.0.113.5:40001

93.184.216.34:80으로 패킷을 보낸 적 있다면:
- 93.184.216.34:80에서 40001로 오는 패킷 → 허용
- 93.184.216.34:443에서 오는 패킷 → 차단 (포트 불일치)

Restricted Cone에서는 IP만 맞으면 됐지만, 여기서는 포트까지 맞아야 합니다.

다만, 매핑 자체는 여전히 고정(같은 내부 소켓이면 같은 외부 포트)이므로 상대의 외부 포트를 예측할 수는 있습니다.

많은 가정용 공유기가 이 방식을 사용합니다.

Symmetric NAT

앞의 세 유형과 다르게, 같은 내부 소켓이라도 목적지마다 다른 외부 포트를 할당합니다.

192.168.1.10:12345 → 93.184.216.34:80
  → 외부 매핑: 203.0.113.5:40001

192.168.1.10:12345 → 142.250.185.46:443
  → 외부 매핑: 203.0.113.5:40002  (다른 포트!)

앞의 세 유형은 같은 내부 소켓에 대해 항상 동일한 외부 포트를 씁니다. 목적지가 달라져도 외부 포트는 그대로입니다. 이를 EIM(Endpoint-Independent Mapping), 목적지와 무관한 매핑이라 부릅니다.

Symmetric NAT는 목적지에 따라 매핑이 달라집니다. 이를 EDM(Endpoint-Dependent Mapping), 목적지에 의존하는 매핑이라 부릅니다.

트래버설 관점에서 이 차이는 치명적입니다. 어떤 서버를 통해 외부 포트를 알아내더라도, 실제 상대방에게 패킷을 보낼 때는 목적지가 달라지므로 NAT가 다른 포트를 새로 할당합니다. 외부 포트를 예측할 수 없습니다.

기업 네트워크와 이동통신사의 NAT에서 주로 나타납니다.

NAT 유형 비교

NAT 유형              매핑                   필터링
───────────────────────────────────────────────────────────────────────
Full Cone             EIM (목적지 무관 고정)  제한 없음
Restricted Cone       EIM (목적지 무관 고정)  이전에 보낸 IP만
Port Restricted Cone  EIM (목적지 무관 고정)  이전에 보낸 IP+포트만
Symmetric             EDM (목적지마다 다름)   이전에 보낸 IP+포트만

두 기준 중 트래버설에 더 결정적인 것은 매핑입니다.

EIM이면 한 번 알아낸 외부 포트가 다른 상대와 통신할 때도 유효하지만, EDM이면 상대마다 포트가 달라져 예측이 불가능합니다.

필터링은 조건이 까다로울수록 트래버설이 어려워지지만, 매핑이 EIM이면 방법이 있습니다.

STUN: 자신의 외부 주소 발견

왜 외부 주소를 알아야 하는가

앞 절에서 본 것처럼, NAT 안쪽의 두 장치가 직접 통신하려면 상대방 NAT에 패킷을 보내야 합니다.

그런데 NAT 안쪽의 장치는 자신의 사설 주소(192.168.1.10)만 알고 있습니다.

NAT가 부여한 공인 주소(203.0.113.5:40001)는 알 방법이 없고, 사설 주소를 상대에게 알려줘도 인터넷에서 라우팅되지 않습니다.

어떤 트래버설 전략을 쓰든, 첫 단계는 자신의 NAT가 부여한 공인 주소를 알아내는 것입니다. 이 역할을 하는 프로토콜이 STUN입니다.

STUN이란

원리는 단순합니다. NAT 바깥의 서버에게 패킷을 보내면, 그 서버는 NAT가 변환한 공인 주소를 볼 수 있습니다.

STUN(Session Traversal Utilities for NAT)이 하는 일이 이것입니다. NAT 안쪽의 클라이언트가 자신의 공인 IP와 포트를 알아내는 프로토콜입니다.

클라이언트가 STUN 서버에 패킷을 보내면, NAT를 통과하면서 출발지가 공인 주소로 바뀝니다. STUN 서버는 도착한 패킷의 출발지를 읽어 응답합니다.

┌─────────────┐         ┌───────┐         ┌─────────────┐
│  클라이언트  │         │  NAT  │         │ STUN 서버   │
│ 192.168.1.10│         │       │         │ (공인 IP)   │
└──────┬──────┘         └───┬───┘         └──────┬──────┘
       │                    │                    │
       │ ── Request ──────► │ ── Request ──────► │
       │    :12345          │    :40001          │
       │                    │                    │
       │ ◄── Response ───── │ ◄── Response ───── │
       │                    │  203.0.113.5:40001 │
       │                                         │

STUN은 2003년 RFC 3489로 처음 등장했습니다. 원래 이름은 Simple Traversal of UDP through NATs로, NAT 유형을 자동 판별하는 알고리즘도 포함되어 있었습니다. 하지만 실제 NAT가 네 가지 유형으로 명확히 구분되는 경우가 드물어 신뢰성이 낮았습니다.

2008년 RFC 5389에서 유형 판별 기능이 제거되고, 외부 주소 발견에 집중하는 도구로 재정의되었습니다. 이때 이름도 Session Traversal Utilities for NAT로 바뀌었습니다. 현재 표준은 2020년의 RFC 8489입니다.

STUN 메시지 구조

모든 STUN 메시지는 20바이트 고정 헤더로 시작합니다.

┌─────────────────┬─────────────────┐
│   메시지 타입    │   메시지 길이    │  4바이트
├─────────────────┴─────────────────┤
│       매직 쿠키 (0x2112A442)       │  4바이트
├───────────────────────────────────┤
│                                   │
│        트랜잭션 ID (96비트)        │  12바이트
│                                   │
└───────────────────────────────────┘
              총 20바이트

메시지 타입: Binding Request인지 Binding Response인지 등을 나타냅니다. 처음 2비트는 항상 00으로, 같은 포트에서 다른 프로토콜(RTP 등)과 구분하는 데 쓰입니다.
매직 쿠키: 고정값 0x2112A442입니다. 이 값으로 STUN 메시지임을 식별합니다.
트랜잭션 ID: 요청과 응답을 짝짓습니다. 여러 요청을 동시에 보낼 때 어떤 응답이 어떤 요청에 대한 것인지 구분합니다.

XOR-MAPPED-ADDRESS와 ALG 문제

STUN 응답의 핵심 속성은 XOR-MAPPED-ADDRESS입니다. NAT가 부여한 공인 주소를 매직 쿠키와 XOR 연산하여 인코딩한 값입니다.

공인 주소를 그대로 넣지 않는 이유가 있습니다. 일부 NAT는 패킷의 페이로드까지 검사하여, IP 주소가 포함되어 있으면 자동으로 변환합니다. 이 기능이 ALG(Application Layer Gateway)입니다.

ALG는 FTP나 SIP처럼 데이터 안에 IP 주소를 포함하는 프로토콜을 위해 만들어졌습니다. FTP의 PORT 명령에는 클라이언트의 사설 IP가 텍스트로 들어가는데, NAT가 이것을 공인 주소로 바꿔줘야 FTP가 정상 동작합니다.

하지만 STUN 응답에서는 이 동작이 문제가 됩니다. STUN 서버가 “당신의 공인 주소는 203.0.113.5입니다”라고 응답을 보냅니다.

이 응답이 NAT를 통과할 때, ALG가 페이로드에서 203.0.113.5를 발견합니다.

ALG는 “이건 내 공인 IP니까 사설 IP로 바꿔줘야지”라고 판단하고, 192.168.1.10으로 변환해버립니다. 결과적으로 클라이언트는 자신의 공인 주소가 아닌 사설 주소를 받게 됩니다.

XOR 인코딩은 이 문제를 방지합니다. IP 주소를 매직 쿠키와 XOR하면 원래 주소와 전혀 다른 비트 패턴이 되어, ALG가 IP 주소로 인식하지 못합니다.

XOR-MAPPED-ADDRESS 인코딩 예시:

공인 IP:    203.0.113.5    → 16진수: 0xCB007105
매직 쿠키:                           0x2112A442
XOR 결과:                            0xEA12D547  → 패킷에 이 값을 담음

클라이언트는 수신 후 다시 XOR하여 원래 주소를 복원:
0xEA12D547 XOR 0x2112A442 = 0xCB007105 → 203.0.113.5

STUN 동작 과정

Binding Request: 클라이언트가 STUN 서버에 요청을 보냅니다.
NAT 변환: 패킷이 NAT를 통과하면서 출발지가 공인 주소로 바뀝니다.
출발지 확인: STUN 서버가 도착한 패킷의 출발지 IP:포트를 읽습니다.
Binding Response: 확인한 주소를 XOR 인코딩하여 응답합니다.
주소 획득: 클라이언트가 XOR 디코딩으로 자신의 공인 주소를 얻습니다.

바인딩 수명과 갱신

NAT 매핑은 영구적이지 않습니다. Part 2에서 다룬 것처럼, 일정 시간 동안 트래픽이 없으면 NAT가 매핑을 제거합니다. UDP의 경우 30초~2분이 일반적이고, RFC 4787은 최소 2분 유지를 권장합니다.

STUN으로 알아낸 외부 주소를 유지하려면, 매핑 만료 전에 주기적으로 패킷을 보내야 합니다. 이 주기적 패킷을 킵얼라이브(Keepalive)라고 합니다. 대부분의 NAT에서 최소 유지 시간이 30초이므로, RFC 5245(ICE)는 15초 간격을 권장합니다.

STUN의 한계

STUN은 외부 주소를 알려줄 뿐입니다. 연결 자체를 성립시키지는 않습니다.

A가 STUN으로 자신의 공인 주소를 알아내고, B도 마찬가지로 알아냈습니다. 양쪽이 서로의 공인 주소를 교환했더라도, A가 B에게 패킷을 보내면 B의 NAT가 차단합니다. B의 NAT 입장에서 A는 이전에 통신한 적 없는 외부 호스트이기 때문입니다. 이 문제를 해결하는 방법이 다음 절에서 다룰 홀 펀칭입니다.

Symmetric NAT에서는 문제가 더 복잡합니다. 앞 절에서 다룬 것처럼, Symmetric NAT는 목적지마다 다른 외부 포트를 할당합니다. STUN 서버에 보낸 패킷에는 포트 40001이 할당되었지만, B에게 보내는 패킷에는 포트 40002가 할당될 수 있습니다. 목적지가 바뀌면 외부 포트도 달라지므로, 상대방에게 알려줄 유효한 주소 자체가 없습니다.

홀 펀칭 (Hole Punching)

왜 홀 펀칭이 필요한가

STUN으로 양쪽의 공인 주소를 알아냈습니다. 하지만 주소를 안다고 바로 통신할 수 있는 것은 아닙니다.

A가 B의 공인 주소로 패킷을 보내면, B의 NAT는 A에 대한 매핑이 없으므로 차단합니다. B가 먼저 A에게 보내도 마찬가지입니다. 양쪽 NAT 모두 상대방의 패킷을 먼저 받아야 허용하므로, 교착 상태가 됩니다.

이 교착을 깨려면 양쪽이 거의 동시에 상대방에게 패킷을 보내야 합니다. 이 방법이 홀 펀칭(Hole Punching)입니다. 2005년 Bryan Ford 등의 논문 “Peer-to-Peer Communication Across Network Address Translators”에서 체계화되었습니다.

아웃바운드 매핑의 원리

홀 펀칭의 핵심은 NAT가 매핑을 생성하는 시점입니다.

NAT 안쪽의 장치가 외부로 패킷을 보내는 순간, NAT는 변환 테이블에 새 항목을 추가합니다. 이 항목이 아웃바운드 매핑입니다. A가 198.51.100.7:50001(B의 공인 주소)로 패킷을 보내면, A의 NAT에 192.168.1.10:12345 ↔ 203.0.113.5:40001, 목적지 198.51.100.7:50001이라는 매핑이 생깁니다.

이 매핑이 존재하면, 그 목적지에서 돌아오는 패킷은 NAT가 허용합니다.

A가 B에게 패킷을 보낸 직후부터, B의 주소에서 오는 패킷은 A의 NAT를 통과할 수 있습니다. 이것이 NAT에 뚫린 구멍(hole)입니다.

UDP 홀 펀칭

A                 중개 서버              B
(NAT 안쪽)                              (NAT 안쪽)

1. A가 중개 서버에 연결, STUN으로 외부 주소 확인
   A의 외부 주소: 203.0.113.5:40001

2. B가 중개 서버에 연결
   B의 외부 주소: 198.51.100.7:50001

3. 중개 서버가 양쪽에 상대방 주소 전달
   → A에게: B는 198.51.100.7:50001
   → B에게: A는 203.0.113.5:40001

4. A가 B의 외부 주소로 패킷 전송
   → A의 NAT에 아웃바운드 매핑 생성 (B 방향)
   → B의 NAT가 차단 (아직 A에 대한 매핑 없음)
   → 패킷은 버려지지만, A 쪽 NAT에 구멍이 뚫림

5. B가 A의 외부 주소로 패킷 전송
   → B의 NAT에 아웃바운드 매핑 생성 (A 방향)
   → A의 NAT는 허용 (4에서 B 방향 매핑이 이미 존재)

6. A가 다시 B에게 패킷 전송
   → B의 NAT도 허용 (5에서 A 방향 매핑이 존재)

7. 양방향 통신 성립

4단계에서 A가 보낸 패킷은 B의 NAT에 의해 버려집니다. 하지만 그 패킷의 역할은 A 쪽 NAT에 구멍을 뚫는 것이므로, 도착 여부는 중요하지 않습니다. 중개 서버가 양쪽에 동시에 전송 신호를 보내 타이밍을 맞추고, 실패에 대비해 수백 밀리초 간격으로 여러 번 반복합니다.

시간
 │
 │  t=0      중개 서버가 양쪽에 상대방 주소 전달
 │
 │  t=100ms  A → B ─┬─ 거의 동시에 전송
 │           B → A ─┘
 │           (각자 상대방 NAT에서 차단되지만, 자기 NAT에 구멍 생성)
 │
 │  t=200ms  재시도 → 양방향 통신 성립
 ▼

NAT 유형 조합별 홀 펀칭 성공 여부

홀 펀칭이 항상 성공하는 것은 아닙니다. 성패는 양쪽 NAT 유형 조합에 달려 있습니다.

A의 NAT             B의 NAT              UDP 홀 펀칭
─────────────────────────────────────────────────────
Full Cone           Full Cone            성공
Full Cone           Restricted Cone      성공
Full Cone           Port Restricted      성공
Restricted Cone     Restricted Cone      성공
Restricted Cone     Port Restricted      성공
Port Restricted     Port Restricted      성공
─────────────────────────────────────────────────────
Symmetric           EIM 유형             대부분 실패
Symmetric           Symmetric            실패

앞의 세 유형(Full Cone, Restricted Cone, Port Restricted Cone)은 모두 EIM입니다. 목적지와 무관하게 같은 외부 포트를 사용하므로, STUN 서버를 통해 알아낸 외부 포트가 실제 상대방과 통신할 때도 그대로 유효합니다.

Symmetric NAT는 EDM이므로 목적지가 바뀌면 외부 포트도 달라집니다. STUN 서버를 통해 알아낸 포트와 상대방에게 보낼 때 할당되는 포트가 다르므로, 홀 펀칭은 실패합니다.

일부 Symmetric NAT는 포트를 순차적으로 할당합니다(40001, 40002, 40003…). 다음 포트를 예측하여 시도하는 포트 예측(Port Prediction) 기법이 있지만, 무작위 할당을 사용하는 NAT에서는 통하지 않습니다.

TCP 홀 펀칭

UDP는 비연결형 프로토콜이라 홀 펀칭이 비교적 단순합니다. 패킷을 보내기만 하면 NAT에 매핑이 생깁니다. TCP는 다릅니다.

TCP는 연결을 열기 위해 3-Way Handshake(SYN → SYN-ACK → ACK)를 거쳐야 합니다. 일반적인 구조에서는 한쪽이 SYN을 보내고 다른 쪽이 SYN-ACK으로 응답합니다. 그런데 양쪽 모두 NAT 안쪽에 있으면, 먼저 보낸 SYN이 상대방 NAT에서 차단됩니다.

TCP 명세 자체에 해법이 있습니다. RFC 793에는 일반적인 3-Way Handshake 외에, 양쪽이 동시에 SYN을 보내는 동시 개방(Simultaneous Open)이 정의되어 있습니다.

일반 3-Way Handshake:
A ───SYN────► B
A ◄──SYN-ACK─ B
A ───ACK────► B

동시 개방 (Simultaneous Open):
A ───SYN────►   ◄────SYN─── B   (동시)
A ◄──SYN-ACK─   ─SYN-ACK──► B   (동시)
            연결 수립

동시 개방에서는 양쪽이 거의 같은 시점에 SYN을 보냅니다. A가 SYN을 보내면 A의 NAT에 아웃바운드 매핑이 생기고, B가 SYN을 보내면 B의 NAT에도 매핑이 생깁니다. 각 SYN이 상대방 NAT에 도달할 때 이미 매핑이 존재하므로 통과할 수 있습니다. 양쪽 모두 SYN을 받으면 SYN-ACK으로 응답하고 연결이 수립됩니다.

하지만 실무에서 TCP 홀 펀칭은 여러 제약이 있습니다.

타이밍 정밀도: 양쪽 SYN이 수십 밀리초 이내에 교차해야 합니다. UDP는 패킷이 버려져도 재시도하면 되지만, TCP는 SYN이 상대 NAT에 의해 RST(연결 거부)로 응답되면 OS가 연결 실패로 처리할 수 있습니다.
NAT/방화벽 호환성: 일부 NAT 장비와 방화벽은 동시 개방 패턴을 인식하지 못하거나, 정상적인 3-Way Handshake가 아닌 SYN 패킷을 비정상으로 간주하여 차단합니다.
OS 소켓 API 제약: 대부분의 OS에서 connect()를 호출하면 로컬 포트가 자동 할당됩니다. 양쪽이 같은 포트 쌍을 사용하도록 맞추려면 SO_REUSEADDR 등의 옵션을 명시적으로 설정해야 합니다.

실무에서는 UDP 홀 펀칭이 먼저 시도됩니다. TCP 홀 펀칭은 UDP가 차단된 환경(일부 기업 방화벽은 UDP를 허용하지 않음)에서 보조 수단으로 사용됩니다.

TURN: 최후의 수단

홀 펀칭은 양쪽 NAT가 협조적일 때만 성공합니다. Symmetric NAT처럼 매핑 예측이 불가능한 환경, 또는 엄격한 방화벽이 UDP를 차단하는 환경에서는 어떤 홀 펀칭도 통하지 않습니다. 하지만 연결 불가로 끝낼 수는 없습니다. 화상 회의 참가자 10명 중 1명이라도 Symmetric NAT 안쪽에 있으면, 그 1명은 영상이 끊깁니다.

이때 사용하는 것이 TURN(Traversal Using Relays around NAT)입니다. RFC 5766(2010)에서 처음 정의되었고, RFC 8656(2020)에서 갱신되었습니다.

TURN은 공인 IP를 가진 릴레이 서버를 중간에 두고, 양쪽 트래픽을 이 서버를 경유해 중계합니다. 양쪽 클라이언트 모두 TURN 서버에 대해 아웃바운드 연결을 열기 때문에, NAT 유형과 무관하게 동작합니다. 앞서 다룬 중앙 서버 경유 방식과 본질적으로 같습니다. 다만 TURN은 항상 사용하는 것이 아니라, 홀 펀칭이 실패했을 때에만 투입되는 최후의 폴백입니다.

A (NAT 안쪽) ────► TURN 서버 (공인 IP) ◄──── B (NAT 안쪽)
                         │
                         ▼
                 A ↔ B 트래픽 중계

TURN 할당 과정

TURN을 사용하려면 먼저 릴레이 서버에 포트 예약을 요청해야 합니다. 이 예약이 할당(Allocation)입니다. TURN 서버가 자신의 공인 IP에서 포트 하나를 클라이언트 전용으로 확보해 두는 절차입니다.

클라이언트가 TURN 서버에 Allocate 요청을 보냅니다.
서버는 인증을 확인한 후, 자신의 공인 IP에 포트 하나를 할당합니다. 이 포트가 릴레이 전송 주소(Relayed Transport Address)입니다. 외부에서 이 클라이언트에게 패킷을 보낼 때 사용하는 TURN 서버 측 주소입니다.
클라이언트는 이 릴레이 주소를 상대방에게 알려줍니다.
상대방이 릴레이 주소로 패킷을 보내면, TURN 서버가 그 패킷을 클라이언트에게 전달합니다.

클라이언트 → TURN 서버: Allocate 요청 (인증 포함)
TURN 서버 → 클라이언트: Allocate 응답
  - 릴레이 주소: 198.51.100.1:49152
  - 할당 수명: 600초 (기본 10분)

할당은 영구적이지 않습니다. 기본 수명은 10분이며, 클라이언트가 만료 전에 Refresh 요청으로 갱신해야 유지됩니다. 갱신하지 않으면 할당이 해제되고 릴레이 주소로 오는 패킷도 더 이상 전달되지 않습니다.

권한과 채널 바인딩

할당을 받았다고 해서 아무나 릴레이를 통해 패킷을 보낼 수 있는 것은 아닙니다. 제한 없이 중계하면 TURN 서버가 오픈 프록시(누구나 사용할 수 있는 중계 서버)가 되어, 스팸이나 DDoS 공격의 경유지로 악용될 수 있습니다.

TURN은 이를 막기 위해 권한(Permission) 메커니즘을 둡니다. 클라이언트가 CreatePermission 요청으로 허용할 IP 주소를 등록하면, 그 IP에서 오는 패킷만 전달됩니다. 권한이 없는 IP에서 온 패킷은 폐기되며, 권한 자체도 5분마다 갱신하지 않으면 자동 만료됩니다.

데이터 전달 방식은 두 가지입니다.

Send/Data Indication: STUN 메시지 형식으로 피어(통신 상대방) 주소와 데이터를 함께 전송합니다. 매번 36바이트 이상의 헤더가 붙어 오버헤드가 큽니다. 설정이 간단하여 소량의 데이터 교환에 적합합니다.

채널 바인딩(Channel Binding): 특정 피어 주소를 2바이트 채널 번호에 바인딩합니다. 이후에는 4바이트 헤더만으로 데이터를 전송할 수 있어, 오버헤드가 약 1/9로 줄어듭니다. 음성이나 영상처럼 초당 수십~수백 개의 패킷이 오가는 실시간 스트림에 적합합니다.

Send Indication:   [STUN 헤더 20B][속성들 16B+][데이터]  → 오버헤드 36B+
ChannelData:       [채널 번호 2B][길이 2B][데이터]        → 오버헤드 4B

예를 들어, 20ms 간격으로 음성 패킷(160바이트)을 보내는 VoIP 통화에서 Send Indication을 사용하면 오버헤드가 전체 트래픽의 약 18%(36/196)를 차지하지만, ChannelData로 바꾸면 약 2.4%(4/164)로 줄어듭니다.

TURN의 비용

TURN은 NAT 유형과 무관하게 동작하지만, 비용이 따릅니다.

지연 증가: 중간 경유지가 추가되어 왕복 시간이 늘어남. 서울-서울 직접 연결이 5ms 미만인 반면, 서울-도쿄(TURN 서버)-서울 경로는 50ms 이상 걸릴 수 있음
대역폭 비용: 서버가 모든 미디어 트래픽을 중계하므로 대역폭 부담이 큼. 720p 화상 통화 한 건에 약 1.5~4 Mbps가 필요하고, 서버는 수신과 송신을 모두 처리하므로 실질적으로 3~8 Mbps를 소비
P2P가 아님: 실제로는 클라이언트-서버-클라이언트 구조
인증 필수: 인증 없이는 릴레이가 오픈 프록시가 되므로, TURN 서버는 사용자 인증을 요구함

TURN은 직접 연결이 불가능할 때의 폴백(Fallback) 수단입니다. WebRTC 통계에 따르면 전체 연결의 약 80~85%는 홀 펀칭에 성공하고, TURN 릴레이가 필요한 경우는 약 15~20%입니다.

ICE: 최적의 경로 찾기

STUN은 Symmetric NAT에서 실패하고, 홀 펀칭은 NAT 유형 조합에 따라 성패가 갈리며, TURN은 동작하지만 비용이 높습니다.

어떤 방식이 통할지는 네트워크 환경마다 다릅니다.

애플리케이션 개발자가 이 판단을 직접 구현하려면 NAT 유형 판별, 홀 펀칭 타이밍 조율, TURN 폴백 로직을 모두 작성해야 합니다.

ICE(Interactive Connectivity Establishment)는 이 선택을 자동화하는 프레임워크입니다.

RFC 5245(2010)에서 처음 정의되었고 RFC 8445(2018)로 갱신되었습니다.

직접 연결, STUN 홀 펀칭, TURN 릴레이를 모두 시도한 뒤 가장 효율적인 경로를 선택합니다. 개발자는 ICE에 STUN/TURN 서버 주소만 전달하면 됩니다.

ICE 후보(Candidate) 수집

ICE의 첫 단계는 후보 수집입니다. 각 피어는 자신이 사용할 수 있는 IP:포트 조합을 세 가지 유형으로 수집합니다.

호스트 후보(Host Candidate): 로컬 네트워크 인터페이스의 IP 주소입니다. 같은 LAN에 있는 피어와는 이 주소로 직접 통신할 수 있습니다.

서버 반사 후보(Server Reflexive Candidate): STUN 서버를 통해 알아낸 공인 주소로, NAT 안쪽에 있는 피어의 외부 주소를 나타냅니다.

릴레이 후보(Relay Candidate): TURN 서버에서 할당받은 릴레이 주소입니다. 직접 연결과 홀 펀칭이 모두 실패할 때 사용하는 폴백 경로입니다.

우선순위

후보가 여러 개일 때 ICE는 각 후보에 우선순위를 부여하고, 높은 순서부터 검사합니다. RFC 8445가 정의하는 공식은 다음과 같습니다.

우선순위 = (2^24 × 유형 선호도) + (2^8 × 로컬 선호도) + (256 - 컴포넌트 ID)

공식에서 유형 선호도가 가장 큰 가중치(2^24 = 16,777,216)를 차지하므로, 후보 유형이 우선순위를 사실상 결정합니다. 로컬 선호도는 네트워크 인터페이스가 여러 개일 때(유선 vs 무선 등) 구분하는 데 쓰이고, 컴포넌트 ID는 하나의 세션에서 음성(1)과 영상(2) 같은 미디어 스트림을 구분합니다.

유형 선호도 권장값은 호스트 126, 서버 반사 100, 릴레이 0입니다.

ICE 후보 목록 예시:

유형 선호도  유형           주소
───────────────────────────────────────
126         호스트         192.168.1.10:12345
100         서버 반사      203.0.113.5:40001
0           릴레이         198.51.100.1:49152

우선순위가 높을수록 지연이 짧고 비용이 낮은 경로입니다. 호스트 후보는 중간 서버를 거치지 않으므로 가장 빠르고, 릴레이 후보는 TURN 서버를 경유하므로 가장 느립니다.

연결성 검사

후보가 모이면 양쪽의 후보를 모든 조합으로 쌍지어 실제로 패킷을 주고받으며 테스트합니다. 이 과정에서 STUN Binding Request를 사용합니다.

A 후보        B 후보          테스트 결과
───────────────────────────────────────────────
호스트        호스트          실패 (다른 NAT 안쪽)
호스트        서버 반사       실패
서버 반사     호스트          실패
서버 반사     서버 반사       성공 (홀 펀칭)
릴레이        릴레이          성공 (폴백)

성공한 조합 중 우선순위가 가장 높은 것, 즉 가장 직접적이고 빠른 경로가 최종 선택됩니다.

에이전트 역할과 지명

연결성 검사에서 여러 후보 쌍이 성공할 수 있습니다. 양쪽이 각각 다른 쌍을 최종 경로로 선택하면 통신이 엇갈립니다.

이 문제를 방지하기 위해 ICE는 역할을 나눕니다. 한쪽이 제어 에이전트(Controlling Agent), 다른 쪽이 피제어 에이전트(Controlled Agent)를 맡습니다.

최종 후보 쌍을 지명(Nominate)하는 권한은 제어 에이전트만 갖습니다. 역할 배정은 Offer/Answer 교환 시 자동으로 결정됩니다(Offer를 보낸 쪽이 제어 에이전트).

지명 방식은 두 가지입니다.

일반 지명(Regular Nomination): 모든 연결성 검사가 완료된 후, 제어 에이전트가 가장 적합한 쌍을 선택하여 USE-CANDIDATE 플래그와 함께 최종 확인 요청을 보냅니다. 최적 경로를 선택할 수 있지만, 모든 검사가 끝날 때까지 기다려야 합니다.

공격적 지명(Aggressive Nomination): 모든 연결성 검사에 USE-CANDIDATE 플래그를 포함합니다. 처음 성공한 쌍이 곧바로 선택되므로 빠르지만, 더 나은 경로를 놓칠 수 있습니다.

Trickle ICE

기본 ICE에서는 모든 후보 수집이 끝나야 연결성 검사를 시작할 수 있습니다. TURN 서버 응답이 느리면 그만큼 전체 연결 설정이 지연됩니다.

Trickle ICE는 이 병목을 없앱니다. 후보가 하나씩 발견될 때마다 상대에게 점진적으로 전달하고, 전달받은 즉시 연결성 검사를 시작합니다. 수집과 검사가 병렬로 진행되어 연결 설정 시간이 줄어듭니다.

ICE 재시작

연결 수립 후에도 네트워크 환경은 변할 수 있습니다. 스마트폰으로 화상 통화 중 Wi-Fi 범위를 벗어나 셀룰러로 전환되거나, NAT 매핑이 만료되는 경우입니다. ICE 재시작은 통화를 끊지 않고 경로를 갱신합니다.

ICE 재시작이 시작되면 새로운 자격 증명인 ice-ufrag와 ice-pwd를 생성합니다.

이 자격 증명은 연결성 검사 시 STUN 메시지에 포함되어 양쪽이 서로를 인증하는 데 쓰입니다.

새 자격 증명이 발급되면 이전 후보는 무효화되고, 후보 수집부터 다시 진행하여 기존 미디어 세션을 중단 없이 새 경로로 전환합니다.

WebRTC와 ICE

ICE가 실제로 가장 널리 쓰이는 곳은 WebRTC(Web Real-Time Communication)입니다. W3C와 IETF가 공동으로 표준화한 WebRTC는 별도의 플러그인이나 앱 설치 없이, 브라우저의 JavaScript API만으로 화상 통화, 화면 공유, 파일 전송을 가능하게 합니다. 이때 양쪽 브라우저가 서로를 찾아 연결하는 과정을 ICE가 담당합니다.

시그널링

ICE가 동작하려면 양쪽 피어가 사전에 후보 목록과 지원 코덱 정보를 교환해야 합니다. 아직 P2P 연결이 수립되기 전이므로 이 초기 정보를 전달할 별도의 경로가 필요합니다. 이 경로를 제공하는 것이 시그널링 서버입니다.

시그널링 서버는 양쪽 피어의 연결 정보를 중개합니다. 실제 음성/영상 데이터는 지나가지 않고, 연결 설정에 필요한 메타데이터만 전달합니다. WebRTC는 의도적으로 시그널링 프로토콜을 표준화하지 않았습니다. 기존 인프라(채팅 서버, 웹 서버 등)를 자유롭게 활용할 수 있도록 한 설계 결정으로, WebSocket, HTTP, 수동 복사-붙여넣기도 시그널링 수단이 될 수 있습니다.

교환되는 정보는 SDP(Session Description Protocol, RFC 8866) 형식으로 기술됩니다. SDP는 지원하는 미디어 유형을 텍스트로 서술하는 형식으로, 미디어 코덱, ICE 후보 목록, 암호화 매개변수 등이 포함됩니다.

시그널링 흐름:

A                시그널링 서버              B
│                      │                      │
│ ── Offer (SDP) ────► │ ── Offer (SDP) ────► │
│                      │                      │
│ ◄── Answer (SDP) ── │ ◄── Answer (SDP) ── │
│                      │                      │
│ ── ICE 후보 ───────► │ ── ICE 후보 ───────► │
│ ◄── ICE 후보 ────── │ ◄── ICE 후보 ────── │
│                      │                      │
│ ◄──── ICE 연결성 검사 후 직접 연결 ────────► │

연결 설정 과정

WebRTC에서 ICE 서버는 RTCPeerConnection 생성 시 설정합니다.

const configuration = {
  iceServers: [
    { urls: 'stun:stun.example.com:3478' },
    {
      urls: 'turn:turn.example.com:3478',
      username: 'user',
      credential: 'password'
    }
  ]
};

const peerConnection = new RTCPeerConnection(configuration);

연결은 다음 단계를 거칩니다.

RTCPeerConnection 생성: STUN/TURN 서버 정보를 설정합니다.
ICE 후보 수집: 브라우저가 호스트, 서버 반사, 릴레이 후보를 자동으로 수집합니다.
Offer/Answer 교환: 한쪽이 SDP Offer(지원 코덱, ICE 후보 포함)를 만들어 시그널링 서버를 통해 전달합니다. 상대방은 자신의 코덱과 후보를 담은 SDP Answer로 응답합니다.
ICE 후보 교환: Trickle ICE로 후보가 발견될 때마다 시그널링 서버를 통해 교환합니다.
연결성 검사 및 경로 선택: ICE가 최적 경로를 선택합니다.
보안 연결 수립: DTLS(Datagram Transport Layer Security)로 암호화된 연결을 수립합니다. DTLS는 UDP 위에서 TLS 수준의 보안을 제공합니다. WebRTC는 항상 암호화를 강제하므로 평문 통신은 허용되지 않습니다.
미디어/데이터 전송: 선택된 경로를 통해 음성, 영상, 데이터를 주고받습니다.

시그널링 서버와 미디어 경로는 분리되어 있습니다. 시그널링 서버는 ICE 후보와 SDP 교환만 중개하고, 실제 미디어 트래픽은 거치지 않습니다. TURN 폴백 시에도 미디어 트래픽은 TURN 서버를 거칩니다. 시그널링 서버가 처리하는 데이터는 수 KB 수준의 텍스트 메시지뿐이므로, 미디어 트래픽(Mbps 단위)에 비하면 부하는 무시할 수준입니다.

포트 포워딩

STUN, TURN, ICE는 모두 NAT 매핑을 동적으로 생성하거나 우회하는 접근입니다. 반대로 라우터에 규칙을 미리 설정하는 정적 접근도 있습니다.

포트 포워딩(Port Forwarding)은 라우터에서 특정 외부 포트를 내부 장비의 특정 포트로 고정 매핑합니다. 내부에서 먼저 통신을 시작하지 않아도 외부에서 접근할 수 있습니다.

라우터 설정:

외부 포트 8080 → 192.168.1.10:80

외부에서 203.0.113.5:8080으로 접속
→ 내부의 192.168.1.10:80으로 전달

홈 서버 운영, 게임 서버 호스팅, 원격 접속 등에 널리 쓰입니다.

포트 포워딩의 한계

수동 설정: 라우터 관리 페이지에 접속하여 직접 규칙을 추가해야 합니다. 포트 번호, 내부 IP, 프로토콜(TCP/UDP)을 각각 지정해야 합니다.

IP 변동: ISP가 공인 IP를 동적으로 할당하면, IP가 변경될 때 외부에서 접근이 끊깁니다. DDNS(Dynamic DNS)로 우회할 수 있지만 추가 설정이 필요합니다.

이중 NAT 문제: IPv4 주소가 고갈되면서 일부 ISP는 가입자에게 공인 IP 대신 ISP 내부의 사설 IP를 할당하기 시작했습니다. ISP 자체 NAT를 한 단계 더 거쳐 인터넷에 연결하는 방식을 CGNAT(Carrier-Grade NAT)라 합니다. CGNAT 환경에서는 가정용 공유기가 공인 IP라고 인식하는 주소(예: 100.64.0.0/10 대역)가 실제로는 ISP 내부의 사설 IP입니다.

인터넷 ←→ [ISP의 CGNAT] ←→ [가정용 공유기 NAT] ←→ 내부 장치
          공인 IP           100.64.x.x (ISP 사설)   192.168.x.x

가정용 공유기에 포트 포워딩을 설정해도, 그 바깥의 ISP CGNAT가 외부 트래픽을 차단합니다. ISP의 CGNAT는 사용자가 설정할 수 없으므로, 이중 NAT 환경에서는 포트 포워딩이 사실상 불가능합니다.

보안: 포워딩된 포트는 항상 열려 있으므로, 내부 서비스의 취약점이 외부에 직접 노출됩니다. 불필요한 포트 포워딩은 제거하고, 열어 둔 포트의 서비스는 최신 상태로 유지해야 합니다.

UPnP와 NAT-PMP

포트 포워딩은 유용하지만 매번 수동으로 설정해야 합니다. 애플리케이션이 라우터에 직접 매핑을 요청할 수 있다면 이 과정을 자동화할 수 있습니다.

UPnP IGD

UPnP(Universal Plug and Play)의 IGD(Internet Gateway Device) 프로토콜이 대표적입니다. 애플리케이션이 라우터에 포트 매핑을 자동으로 요청합니다.

애플리케이션이 SSDP로 네트워크의 IGD 장치(라우터)를 검색
라우터가 자신의 제어 URL을 응답
애플리케이션 → 라우터: 외부 포트 12345를 192.168.1.10:12345로 매핑 요청
라우터: 매핑 생성 완료

게임 콘솔, BitTorrent 클라이언트, 화상 회의 애플리케이션 등이 이 방식을 사용합니다. 사용자가 라우터 설정 페이지에 접속하지 않아도 애플리케이션이 자동으로 필요한 포트를 열 수 있습니다.

NAT-PMP와 PCP

Apple은 같은 목적으로 NAT-PMP(NAT Port Mapping Protocol, RFC 6886)를 개발했습니다. UPnP IGD보다 단순하고, 외부 IP 주소 변경 감지 기능이 내장되어 있습니다.

NAT-PMP는 이후 PCP(Port Control Protocol, RFC 6887)로 발전했습니다. PCP는 IPv6 환경을 지원하고, 서드파티 매핑(다른 장치를 대신하여 매핑 생성) 같은 확장 기능을 제공합니다.

보안 문제

UPnP IGD에는 인증 절차가 없습니다. 내부 네트워크에 접근할 수 있는 프로그램이면 무엇이든 포트를 열 수 있습니다. 악성코드가 이를 악용하면 다음과 같은 위협이 발생합니다.

방화벽 규칙 우회: 관리자가 차단한 포트를 UPnP로 다시 열 수 있음
내부 서비스 외부 노출: 내부에서만 접근 가능하던 서비스가 인터넷에 공개됨
공격 경로 생성: 외부 공격자가 내부에 침투한 악성코드를 통해 UPnP로 터널을 생성

2013년 Rapid7 조사에서 인터넷에서 접근 가능한 UPnP 장치가 8,100만 대 이상 발견되었습니다. 보안 전문가들이 UPnP 비활성화를 권장하는 이유입니다.

IPv6와 NAT 트래버설의 미래

NAT 트래버설 기법은 모두 IPv4 주소 부족이 만든 문제를 우회합니다. 128비트 주소 공간을 가진 IPv6는 사실상 무한한 주소를 제공하므로, 모든 장비에 고유한 공인 주소를 부여할 수 있습니다. 원칙적으로 NAT 자체가 불필요해지고, 종단간 원칙이 복원되며, P2P 통신도 단순해집니다.

그러나 현실은 다릅니다.

전환 속도: 2025년 기준 전 세계 IPv6 도입률은 약 40~45%이며, 국가와 ISP에 따라 편차가 큽니다. IPv4 전용 네트워크가 사라지기까지는 오랜 시간이 걸립니다.

NAT66: 일부 네트워크는 IPv6에서도 NAT66(IPv6 주소 간 변환)을 도입하고 있습니다. 내부 IPv6 주소를 외부에 노출하지 않으려는 정책적 이유입니다. NAT의 복잡성이 IPv6에서도 재현될 수 있습니다.

혼용 환경: IPv4와 IPv6가 공존하는 듀얼 스택(Dual Stack) 환경에서는 한쪽은 IPv6로 직접 연결이 가능하고 다른 쪽은 IPv4 NAT 안쪽에 있는 상황이 발생합니다. 이 경우에도 NAT 트래버설은 필요합니다.

IPv6가 완전히 보급되기 전까지 STUN, TURN, ICE 같은 NAT 트래버설 기술은 계속 필요합니다.

마무리

NAT 트래버설의 전형적인 흐름을 정리하면 다음과 같습니다.

STUN으로 외부 주소 발견: NAT가 부여한 공인 IP와 포트를 알아냄
홀 펀칭 시도: 양쪽이 동시에 패킷을 보내 NAT에 구멍을 만듦
실패 시 TURN 릴레이로 폴백: 릴레이 서버를 통해 트래픽 중계
ICE가 전체 과정을 조율: 후보 수집, 연결성 검사, 최적 경로 선택을 자동화

NAT 유형에 따라 홀 펀칭 성공률이 달라집니다.

NAT 유형               홀 펀칭 성공률
──────────────────────────────────────
Full Cone              높음
Restricted Cone        중간
Port Restricted        중간~낮음
Symmetric              낮음 (TURN 필요)

동적 트래버설 외에, 포트 포워딩이나 UPnP/NAT-PMP처럼 라우터에 매핑을 미리 설정하는 정적 접근도 있습니다. 설정이 가능한 환경에서는 유효하지만, 수동 관리 부담과 보안 위험이 따릅니다.

NAT는 IPv4 주소 고갈을 해결한 대신, 종단간 원칙을 깨뜨리고 P2P 연결을 어렵게 만들었습니다. STUN, TURN, ICE는 이 깨진 원칙 위에서 P2P 통신을 가능하게 만든 우회 기술입니다. IPv6가 완전히 보급되면 NAT 자체가 불필요해질 수 있겠지만, 전환이 더딘 현실에서 트래버설 기술은 당분간 P2P 통신의 핵심 기반으로 남을 것입니다.

Part 1에서 NAT의 주소 변환 원리를, Part 2에서 방화벽의 상태 추적을, 이번 Part 3에서 NAT 트래버설 기법을 다루었습니다.

관련 글

시리즈