KLDPWiki: NAT

NAT

[edit]

NAT ¶

작성자
조재혁 (minzkn@minzkn.com)
고친과정
2010년 10월 24일 : 처음씀

[edit]

NAT의 필요성 ¶

NAT은 다음과 같은 요구사항을 충족하기 위해서 탄생하였습니다.

공인 IP의 부족
NAT하위에서는 사설 IP를 사용하고, 외부 Internet주소로 접속시 사설 IP를 공인 IP주소로 변환하도록 함으로써 공인 IP주소의 부족문제를 해결합니다.
NAT하위의 네트웍을 외부로부터 보호
직접적으로 외부로부터 NAT의 내부로 접근이 제한되며 내부 사설 IP대역의 트래픽이 외부 Internet으로 접속하려는 경우가 아니면 기본적으로 Routing되지 않으므로 외부로부터 보호됩니다.

[edit]

NAT의 종류 ¶

일반적으로 NAT은 주소변환을 하기 위하여 Packet의 다음사항을 조정합니다.

IP header의 IP address부분
UDP header의 port부분
TCP header의 port부분

다음은 Internal위치에서 OutputBound시에 어떻게 External위치로 바뀌는가의 주소변환규칙에 의거한 분류에 의한 명칭입니다.

Full Cone
Internal위치에서 UDP packet을 목적지로 보낼때 NAT에서는 해당 Interal IP와 Port를 일시적으로 기억하고 NAT의 Port와 mapping하여 주며 해당 Port로 Data가 들어오면 출발지를 상관하지 않고 기억하였던 Internal위치로 forward해줍니다.
Port Restricted Cone
Internal위치에서 UDP packet을 목적지로 보낼때 NAT에서는 해당 Interal IP와 Port, 그리고 목적지 IP와 Port를 일시적으로 기억하고 NAT의 Port와 mapping하여 주며 해당 Port로 Data가 들어오면 출발지IP 및 Port와 기억하고 있는 목적지 IP 및 Port가 같을때 해당 Internal위치로 forward해줍니다.
Restrict Cone
Internal위치에서 UDP packet을 목적지로 보낼때 NAT에서는 해당 Interal IP와 Port, 그리고 목적지 IP를 일시적으로 기억하고 NAT의 Port와 mapping하여 주며 해당 Port로 Data가 들어오면 출발지IP와 기억하고 있는 목적지 IP가 같을때 해당 Internal위치로 forward해줍니다.
Symmetric Cone
Internal위치에서 UDP packet을 목적지로 보낼때 NAT에서는 해당 Interal IP와 Port, 그리고 목적지 IP와 Port를 일시적으로 기억하고 NAT의 Port와 mapping하여 주는데 목적지 Port가 바뀌면 역시 새로운 Port로 mapping합니다. 해당 Port로 Data가 들어오면 출발지IP 및 Port와 기억하고 있는 목적지 IP 및 Port가 같을때 해당 Internal위치로 forward해줍니다.

NAT의 구현방법에 따라서 다음과 같이 분류됩니다. NAT은 Exclude => Redirect => Reverse => Normal 의 순서로 적용되도록 구현하는것이 일반적이며 적용순서가 다른 경우 정상적으로 동작하지 않을수도 있습니다.

Normal NAT
사설 IP를 1개의 공인 IP로 바꾸는 형태로 동시에 Session을 약 50000~65535개정도까지만 처리할수 있는것이 보통이며 이것은 더이상 Port를 할당할수 없기 때문에 발생하는 제약사항입니다. 그러나 이 경우 공인IP를 2개이상을 묶어서 구현하게 되면 그 만큼 동시처리 Session 을 연장할수 있기도 합니다.
Reverse NAT
Normal NAT에서 설정된 공인 IP로부터 내부 사설망으로 접속요구를 받는 경우 여러개의 사설 IP중에서 어떤 IP로 변환해야 하는지 알수 없게 됩니다. 이 경우에 주소변환에 대한 설정이 따로 있어야 합니다. 이때 설정을 Reverse NAT로 1:1 Mapping 또는 Static mapping이라고 부르기도 합니다.
Redirect NAT
목적지 주소를 재지향(변환)하는것을 말합니다.
Exclude NAT
NAT과 Router사이에 서버가 있고 내부 사설IP사용자가 이 서버로 접속을 할수 있도로 하기 위해서 Normal NAT의 적용을 받지 않도록 하는 것을 말합니다.

[edit]

UDP Hole-punching ¶

[PNG image (47.7 KB)]

Client A와 B는 모두 일반적으로 30초(NAT공유기의 설정에 의존적)를 넘지 않는 간격으로 Server와 UDP송수신을 수행합니다. 이때 ClientA 와 B는 Server로 먼저 UDP packet을 전송하게 되며 이때 반드시 Server 는 수신된 UDP packet의 Source IP와 Source Port로 응답해주어야 합니다.
(1) : Client A와 B에서 Server로 전송한 Packet은 NAT을 통과하면서 SourceIP는 ExternalIP로 변환되며 SourcePort는 임의의 ExternalPort로 일시적인 시간동은 Mapping되어 유지됩니다.
(2) : Server로 도착된 Packet은 SourceIP:SourcePort가 NAT의 ExternalIP와 임의로 Mapping된 Port로 하여 수신됩니다.
(3) : Server는 도착된 Packet의 SourceIP:SourcePort로 응답패킷을 전송합니다.
(4) : Server로부터 전송된 Packet은 NAT에 도달하면 해당 Port mapping이 유효할때 해당 PrivateIP와 Port로 변환하여 Client로 전달합니다. 이로써 해당 주소와 포트를 통해서 상호간 양방향 통신이 가능해집니다.
(5) : 이제 Server로부터의 응답패킷에 각각의 Client는 상대방 Client의 ExternalIP와 ExternalPort를 수신하여 해당 주소로 Packet을 전송합니다.
(6) : 적어도 한쪽Client의 Packet이 전송에 성공하게 되며(단, 양단이 Symmetric Cone인 경우는 실패할수 있음) 이후 상대방 Client로부터 도착한 Packet의 SourceIP:SourcePort로 전송할수 있게 됩니다.
(7) : 만약 Client A와 Client B가 같은 NAT에 있다면 서로 같은 NAT에서 ExternalIP로 전송하는것은 전달되지 않을수 있으며 이 경우 서로 Broadcast등을 통해서 확인해야 합니다.
통상적으로 이 방식은 양단이 둘다 Symmetric Cone이 아닌 경우에 한해서 성공확률이 매우 높다는데 커다란 장점이 있다. 그러나 UDP protocol을 사용하므로 양단간에 신뢰성을 보장할수 있는 방안이 보완되어야 하며 전송효율을 위해서 재전송을 효율적으로 관리하도록 설계해야 한다는 점에서 단점이라면 단점이라고 할수 있다.

[edit]

TCP Hole-punching ¶

[PNG image (56.47 KB)]

TCP의 기초지식 사항 - 3 way handshake (일반적인 Connection에 대한 절차)
- A에서 B로 연결하는 경우 A는 SYN flag가 ON이고 Seq값을 임의로 설정한 패킷을 B로 전송합니다.
  - A는 SYN_SENT 상태
  - B는 SYN_RECEIVED 상태
- B는 ACK flag와 SYN flag가 ON이고 AckSeq?는 A로 부터 받은 Seq에 1을 더한값으로 설정하고 Seq값을 임의로 설정한 패킷을 A로 전송합니다.
  - A와 B는 HALF_OPEN 상태
  - 이 경우 B에서는 HALF_OPEN상태는 Backlog Queue에서 관리됩니다.
- A는 ACK flag만 ON이고 AckSeq?는 B로부터 받은 Seq에 1을 더한값을 설정하고 B로 전송하여 연결성립을 완성합니다.
  - A와 B는 ESTABLISHED 상태
TCP Hole-punching의 기본 원리는 SYN-ACK의 패킷을 받아들이도록 한다는데 있다.
통상적으로 이 방식이 성공하기는 매우 어렵다. 하지만 제대로 성공한다면 트래픽이 100% Client양단간에서 처리하게 되고 TCP를 기반으로 하기 때문에 신뢰성도 어느정도 혜택을 얻을수 있으며 트래픽이 Server로 집중되는 것을 막을수 있다.

[edit]

참고자료 ¶

Make a wish, it might come true.

OpenSourceHacker
SoftIrqsAndTasklets
genelix
u1y4m

KLDP

last modified 2015-02-06 16:18:42
Processing time 0.0080 sec