P2P와 NAT: NAT 통과 기법 소개 (RFC 5128) - 1편: Relaying & Connection Reversal

P2P & NAT: NAT Traversal Technic (RFC 5128) - Part 1: Relaying & Connection Reversal

March 28, 2014 | By 유창모 (cmyoo@netmanias.com)

코멘트 (6)

오늘은 사설 IP 주소를 가지는 두 단말 간에 P2P 통신이 가능하도록 하는 기술(NAT Traversal이라 부름)에 대해 소개 해 드리겠습니다.
RFC 5128(State of P2P Communication across NATs - Informational)에서 설명하고 있는 NAT Traversal 기술은 크게 3가지입니다.

Relaying
Connection Reversal
UDP Hole Punching

이번 시간에는 Relaying과 Connection Reversal에 대해서 알아보고 다음 시간에 UDP Hole Punching에 대해서 설명 드리도록 하겠습니다.
P2P (NAT Traversal) 입장에서 가장 곤혹스러운 NAT Behavior가 Address and Port-Dependent Mapping(이하 APDM) & Address and Port-Dependent Filtering(이하 APDF) 입니다. 오늘 소개해 드릴 Relaying과 Connection Reversal 모두 적용의 한계(문제점)가 있기는 하지만 위 방식의 NAT Behavior에서도 NAT Traversal이 가능한 기술입니다.

1. Relaying

■ 개념

Relaying 방법은 사설 IP 주소를 가지는 두 단말 간에 직접 통신을 할 수 없다면 공인 IP 주소를 가지는 외부 서버를 통해 P2P 데이터 패킷을 Relay하자는 개념입니다.
Host A와 Host B는 사설 IP 주소를 가지고 있고, Server S(Relay 서버 혹은 표준에서는 Rendezvous Server라 칭함)는 반드시 공인 IP 주소를 가져야 합니다.

■ 절차

	1.		Host A와 B는 각각 Server S로 TCP 혹은 UDP 연결 메시지(Registry Session)를 보냅니다.
	2.		이 메시지들은 NAT A/B를 통과해 Server S로 도달하여 Host A와 Server S, Host B와 Server S간에 TCP 혹은 UDP 연결이 이루어집니다. 또한 NAT A/B에는 다음과 같이 Binding Entry와 Filtering Entry가 생성됩니다. NAT A Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.1.1.1:4000, 5.1.1.1:60000} Filtering Entry: Allow Inbound Packet if Source info {100.1.1.1:1234}, Destination info {5.1.1.1:60000} NAT B Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.2.2.2:5000, 6.2.2.2:30000} Filtering Entry: Allow Inbound Packet if Source info {100.1.1.1:1234}, Destination info {6.2.2.2:30000}
	3.		이제 Server S는 Host A/B의 Public IP/Port 정보(NAT에 의해 변환된 정보)를 알수 있게 됩니다.
	4.		Host A는 2번 과정에서 생성된 연결을 통해 Server S로 P2P 데이터 패킷을 보내는데, 이 때 해당 패킷의 Payload에는 목적지 주소 6.2.2.2가 포함되며 (참고: Peer 목적지 주소 6.2.2.2를 알아내는 방법에 대해서는 표준에 정의되어 있지 않음),
	5.		이 패킷은 NAT A를 통과하여 Server S가 수신합니다.
	6.		Server S는 수신 패킷의 Payload를 통해 목적지 주소를 알아낸 후, 역시 2번 과정에서 생성된 연결을 통해 Host B로 P2P 데이터 패킷을 송신(릴레이)하며 이 때 Host B가 패킷을 수신 할 수 있도록 다음과 같이 패킷 정보를 변경합니다. [IP Header] Destination IP: 100.1.1.1 -> 6.2.2.2, Source IP: 5.1.1.1 -> 100.1.1.1 [TCP/UDP Header] Destination Port: 1234 -> 30000, Source Port: 60000 -> 1234 [Payload] Peer 정보(6.2.2.2) 필드 제거
	7.		NAT B는 다음과 같은 과정을 거쳐 수신 패킷을 Host B로 전달합니다. Check Filtering Table: 수신 패킷의 정보와 Filtering Entry가 일치하므로 이 패킷을 허용 수신 패킷 정보: Source info {100.1.1.1:1234}, Destination info {6.2.2.2:30000} Filtering Entry: Allow Inbound Packet if Source info {100.1.1.1:1234}, Destination info {6.2.2.2:30000} Check Binding Table: 수신 패킷의 목적지 정보가 Binding Entry와 일치하여 목적지 정보를 {6.2.2.2:30000}에서 {10.2.2.2:5000}으로 변경 수신 패킷의 목적지 정보: {6.2.2.2:30000} Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.2.2.2:5000, 6.2.2.2:30000}

■ 장점

NAT의 동작 특성(NAT Behavior)에 상관없이 100% NAT 통과 성공율을 자랑합니다.
- 지원 NAT Mapping Behavior: Endpoint-Independent Mapping, Address-Dependent Mapping, Address and Port-Dependent Mapping
- 지원 NAT Filtering Behavior: Endpoint-Independent Filtering, Address-Dependent Filtering, Address and Port-Dependent Filtering

■ 단점

모든 P2P 데이터 패킷이 Relay 서버를 거쳐야 하므로 아래와 같은 문제점이 발생할 수 있습니다.
- Relay 서버의 부하 증가 (server processing power)
- Relay 서버의 네트워크 대역폭 이슈 발생 (server network bandwidth)
- Relay 서버가 분산 배치되지 않은 환경에서는 P2P 통신의 지연 발생 (communication latency)

■ 요약

이 방법은 "NAT 통과 성공율 100%"의 NAT Traversal 기법이지만 위와 같은 문제점으로 인해 "최후의 수단"으로 사용해야 하는 기법입니다. (The most reliable, but least efficient)
TURN(Traversal Using Relays around NAT, RFC 5766)이 바로 이와 같은 Relay 서버를 통한 NAT Traversal을 정의하고 있습니다.

2. Connection Reversal

■ 개념

Connection Reversal 방법은 P2P 통신을 하고자 하는 두 단말 중 하나는 공인 IP 주소를 가지는 경우에 적용이 가능합니다.
위 그림에서 사설 IP 주소를 가지는 Host A가 먼저 공인 IP 주소를 가지는 Host B로 연결을 요청하는 경우(NAT Outbound Traffic이 먼저 발생) 아무 문제 없이 통신이 이루어집니다. (마치 Host A가 웹서버와 통신하는 것과 동일)
그런데 만약 Host B(공인 IP)가 Host A(사설 IP)로 먼저 연결 요청을 하는 경우(NAT Inbound Traffic이 먼저 발생) 상황은 달라집니다. Host A가 먼저 트래픽을 발생하지 않았기 때문에 NAT의 Binding Table/Filtering Table에 세션 엔트리가 생성되지 않았고, 따라서 Host B가 Host A로 보내는 패킷은 NAT에 의해 폐기됩니다.
이와 같이 공인 IP를 가진 Host B가 사설 IP를 가진 Host A로 먼저 연결 요청을 해야 하는 경우, Host B는 Server S를 통해 연결 요청 메시지("Host A야! 내가 너랑 통신하고 싶으니까, 네가 먼저 나한테 연결 요청 메시지를 보내라!")를 Host A로 전달하고, 이후 Host A가 Host B로 연결 요청을 하도록 하는 방법입니다. 결국 NAT Outbound Traffic을 먼저 발생시킴으로써 NAT를 통과하겠다는 개념이지요.

■ 절차

	1.		Host A는 Server S로 TCP 혹은 UDP 연결 메시지(Registry Session)를 보냅니다.
	2.		이 메시지는 NAT A를 통과하여 Server S로 도달하여 Host A와 Server S간에 TCP 혹은 UDP 연결이 됩니다. 또한 NAT A에는 다음과 같이 Binding Entry 및 Filtering Entry가 생성됩니다. Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.1.1.1:4000, 5.1.1.1:60000} Filtering Entry: Allow Inbound Packet if Source info {100.1.1.1:1234}, Destination info {5.1.1.1:60000}
	3.		이제 Server S는 Host A의 Public IP/Port 정보(NAT에 의해 변환된 정보)를 알수 있게 됩니다.
	4.		Host A와 통신을 하려는 Host B는 Server S로 연결 요청 메시지(Reverse Connection Request)를 보내고, 이 메시지에는 자신의 주소/포트 정보(200.1.1.1:2000)와 연결을 원하는 목적지(Host A) 정보가 포함됩니다 (참고: Peer 목적지 주소 5.1.1.1을 알아내는 방법에 대해서는 표준에 정의되어 있지 않음).
	5.		연경 요청 메시지를 수신한 Server S는 2번에서 생성한 TCP 혹은 UDP 연결을 통해 이 메시지를 Host A로 전송하는데, 이 때 패킷 정보는 다음과 같이 변경됩니다. [IP Header] Destination IP: 100.1.1.1 -> 5.1.1.1, Source IP: 200.1.1.1 -> 100.1.1.1 [TCP/UDP Header] Destination Port: 1234 -> 60000, Source Port: 2000 -> 1234 [Payload] Reverse Connection을 요청한 Host B의 정보(200.1.1.1:2000) 추가
	6.		NAT A는 다음과 같은 과정을 거쳐 수신 패킷을 Host A로 전달합니다. Check Filtering Table: 수신 패킷의 정보와 Filtering Entry가 일치하므로 이 패킷을 허용 수신 패킷 정보: Source info {100.1.1.1:1234}, Destination info {5.1.1.1:60000} Filtering Entry: Allow Inbound Packet if Source info {100.1.1.1:1234}, Destination info {5.1.1.1:60000} Check Binding Table: 수신 패킷의 목적지 정보가 Binding Entry와 일치하여 목적지 정보를 {5.1.1.1:60000}에서 {10.1.1.1:4000}으로 변경 수신 패킷의 목적지 정보: {5.1.1.1:60000} Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.1.1.1:4000, 5.1.1.1:60000}
	7.		이제 Host A는 Host B로 연결 요청(Connection Request)을 합니다. 이 때 목적지 정보(200.1.1.1:2000)는 6번 메시지의 Payload에 포함된 값을 이용합니다.
	8.		이 메시지는 NAT A를 통과하여 Host B로 전달이 되고, 이를 통해 Host A와 Host B간에 TCP 혹은 UDP 연결이 생성됩니다. 또한 그 과정 중에 NAT A에는 아래와 같이 Binding Entry 및 Filtering Entry가 생성 됩니다. Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.1.1.1:5000, 5.1.1.1:70000} Filtering Entry: Allow Inbound Packet if Source info {200.1.1.1:2000}, Destination info {5.1.1.1:70000}
	9.		이제 Host B는 이 연결을 통해 Host A로 P2P 데이터 패킷을 보내면,
	10.		NAT A는 다음과 같은 과정을 거쳐 수신 패킷을 Host A로 전달합니다. Check Filtering Table: 수신 패킷의 정보와 Filtering Entry가 일치하므로 이 패킷을 허용 수신 패킷 정보: Source info {200.1.1.1:2000}, Destination info {5.1.1.1:70000} Filtering Entry: Allow Inbound Packet if Source info {200.1.1.1:1234}, Destination info {5.1.1.1:70000} Check Binding Table: 수신 패킷의 목적지 정보가 Binding Entry와 일치하여 목적지 정보를 {5.1.1.1:70000}에서 {10.1.1.1:5000}으로 변경 수신 패킷의 목적지 정보: {5.1.1.1:70000} Binding Entry: {Internal IP:Internal Port, External IP:External Port} = {10.1.1.1:5000, 5.1.1.1:70000}

■ 장점

Relaying 방식과의 가장 큰 차이점(장점)은 P2P 데애터 패킷이 Sever를 통하지 않는다는 점입니다.
Relaying 방식과 같이 모든 NAT Behavior (Mapping & Filtering)에서 NAT 통과가 가능합니다.

■ 단점

P2P 단말 중 하나는 반드시 공인 IP 주소를 가져야 하는 환경적인 제약이 있습니다. 즉, 두 단말 모두 사설 IP 주소를 가지는 환경에서는 적용이 불가능한 방법입니다.

■ 요약

위와 같은 제약 사항으로 인해 Connection Reversal 기법도 최선의 NAT Traversal 솔루션은 아니며, Relaying 기법을 사용하기 전에 시도해 볼 만한 방법 정도로 생각하시면 될 듯 합니다. (Because connection reversal is not a general solution to the problem, it is NOT recommended as a primary strategy)

Yang 2016-03-16 21:19:52

너무너무 정리가 잘되어있습니다! 아직 학부생이라 많이 부족해서 다른 정리자료들을 봤지만

가장 잘 이해가됩니다 ^ㅡ^

baobab 2017-06-23 15:58:50

이해가 쏙쏙 잘 되게 설명해주셔서 감사합니다. 자세하게 수업 들은 기분입니다 ;))

유창모 2017-06-23 16:22:41

도움 되셨다니 저도 좋네요... ^^*

개발자 2018-02-23 13:55:03

관련 글 중 가장 정리가 잘된 글이 아닌가 생각됩니다.

좋은 글을 써주셔서 감사합니다.~ 도움이 많이 됐습니다. 글을 보면서 헷갈리는것은 UDP로만 홀펀칭이 가능한지요?

유창모 2018-02-24 14:12:20

문서 작성 때의 기억을 되살려 보면 (2014년.... 오래 지났네요), TCP hole puching은 쉽지 않다고 했던것 같습니다.

구글링 해 보니 TCP hole puching에 대한 글을이 보이는데, 이게 현실적인 방안인지는 저도 잘 모르겠습니다. ^^*

https://en.wikipedia.org/wiki/TCP_hole_punching

http://ice.hufs.ac.kr/w/img_auth.php/7/7a/%EA%B0%95%EA%B1%B4%EC%9A%B0.pdf

회식은칠리새우 2020-11-11 20:46:03

정말 깔끔한 설명입니다. 감사합니다!

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.

Comment