업데이트됨 1개월 전
집에 있는 모든 기기—노트북, 스마트폰, 스마트 TV, 게임 콘솔—는 외부 세계에 하나의 동일한 기기처럼 보인다. 이것은 라우터가 당신을 대신해 치는 거짓말이다. NAT이 바로 그 방법이다.
기다릴 여유가 없었던 문제
IPv4는 인터넷 전체에 43억 개의 주소를 제공했다. 1990년대 초, 이것으로는 부족하다는 사실이 명백해졌다. IPv6은 해결책을 약속했다—10의 38제곱 개에 달하는 주소, 지구상의 모든 원자가 수십억 개의 IP를 가질 수 있을 만큼—하지만 전환에는 수십 년이 걸릴 것이었다.
NAT은 그 다리로 등장했다. 해결책이 아니라 임시방편으로. 주소를 배급하거나 새로운 프로토콜 도입을 강제하는 대신, NAT은 수천 개의 기기가 하나의 공인 IP 뒤에 숨을 수 있게 해주었다. 인터넷은 계속 성장했다. IPv6은 계속 기다렸다.
삼십 년이 지난 지금도 우리는 기다리고 있다. NAT이 시간을 벌어주었다. 우리는 그 시간을 임시방편 위에 인프라를 쌓는 데 써버렸다.
눈속임 같은 주소 변환
192.168.1.100인 노트북이 웹페이지를 요청한다. 패킷이 라우터에 도달하면, 라우터는 교체 작업을 수행한다: 사설 주소를 공인 주소(예: 203.0.113.5)로 바꾸고, 변환 내역을 테이블에 기록한 뒤, 패킷을 전달한다.
서버가 203.0.113.5로 응답하면, 라우터는 테이블을 확인한다: "이 응답은 192.168.1.100의 것이다." 변환을 역으로 되돌리고 패킷을 노트북에 전달한다.
서버 입장에서는 노트북과 대화한 적이 없다. 203.0.113.5와 대화했을 뿐이다. 노트북은 인터넷에 직접 연결된 것으로 생각한다. 중간에서 모든 것을 처리한 라우터는 보이지 않는다.
모든 것을 기억하는 테이블
NAT 테이블은 누가 무엇을 요청했는지를 실시간으로 기록하는 장부다. 각 항목은 내부 주소와 포트를 외부 주소와 포트에 대응시킨다:
이 테이블이 없으면 돌아오는 트래픽이 어디로 가야 할지 알 수 없다. 203.0.113.5에 패킷이 도착했을 때—노트북의 것인가, 스마트폰의 것인가, TV의 것인가? 모두 같은 공인 주소를 쓰고 있다.
테이블은 활성 세션만 추적한다. 연결이 끊기거나 시간이 초과되면 해당 항목은 삭제된다. 이 상태 관리가 NAT의 강점이자 약점이다: 주소 공유를 가능하게 하지만, 라우터가 통과하는 모든 통신을 기억해야 한다.
세 가지 변환 방식
정적 NAT은 영구적인 일대일 매핑을 만든다. 내부 서버 192.168.1.50은 항상 공인 IP 203.0.113.10으로 변환된다. 안정적인 주소가 필요한 서버에 유용하지만, 주소 절약이라는 목적을 무너뜨린다—각 기기에 여전히 공인 IP가 하나씩 필요하기 때문이다.
동적 NAT은 공인 IP 풀을 유지한다. 기기가 연결을 시작하면 풀에서 주소를 할당받는다. 세션이 끝나면 주소는 풀로 반환된다. 정적 NAT보다 낫지만, 풀 크기의 제약을 벗어날 수는 없다.
PAT(포트 주소 변환)이 실제로 가정용 라우터에서 동작하는 방식이다. 주소와 포트를 모두 변환한다. 노트북은 포트 54321로 연결하고, 스마트폰도 같은 포트를 사용한다. 라우터는 서로 다른 외부 포트를 배정한다—노트북에는 62000, 스마트폰에는 62001—그리고 어느 것이 어느 기기의 것인지 추적한다.
IP 하나당 65,535개의 포트를 지원하므로, PAT은 단일 공인 주소로 수만 개의 연결을 동시에 처리할 수 있다. 가정에서 하나의 IP를 여러 기기가 함께 쓸 수 있는 것도 이 덕분이다.
NAT이 치르는 대가
NAT은 주소를 절약했다. 그리고 인터넷의 근본적인 약속을 깨뜨렸다: 어떤 기기든 다른 기기와 직접 통신할 수 있다는 것.
NAT 뒤에 있는 기기는 먼저 요청하지 않은 연결을 받을 수 없다. 밖으로 전화를 걸 수는 있어도, 전화를 받을 수는 없다. 서버-클라이언트 모델은 잘 작동한다. P2P는 그렇지 않다.
FTP, SIP, 일부 VPN처럼 페이로드 안에 IP 주소를 담는 프로토콜은 NAT을 통과하면서 오작동한다. 애플리케이션 레이어 게이트웨이가 패킷 내용을 수정해 이 문제를 해결하려 하지만, 취약하고 프로토콜마다 별도 구현이 필요하다.
NAT 라우터는 모든 활성 연결 상태를 유지해야 한다. 패킷을 그냥 전달하기만 하는 스테이트리스 라우터와 달리, NAT 기기는 상태 고갈 공격에 취약하다: 연결 요청을 폭주시켜 테이블을 가득 채우면 라우터가 다운된다.
P2P 문제
NAT 뒤에 있는 두 기기는 난감한 상황에 처한다: 양쪽 모두 들어오는 연결을 받을 수 없다. 어떻게 통신할 수 있을까?
불가능하다. 직접적으로는.
STUN은 기기가 외부 서버에 접속해 자신의 공인 IP와 포트를 알아내도록 한다. 두 피어가 각자 알아낸 주소를 공유하면, 때로는 NAT에 구멍을 뚫을 수 있다—NAT의 동작 방식을 역이용해 방화벽을 통과하는 것이다.
TURN은 사실상 직접 연결을 포기한다. 릴레이 서버가 두 기기 사이에서 트래픽을 중계한다. 안정적으로 작동하지만, 모든 데이터가 제3자를 거친다.
ICE는 여러 방법을 순서대로 시도한다—직접 연결, STUN, TURN—그중 작동하는 것을 사용한다.
이 기술들은 대부분의 경우 통한다. 하지만 "대부분"은 "항상"이 아니다. 대칭형 NAT(기업 네트워크에서 흔한)과 통신사급 NAT(ISP가 자체적으로 또 하나의 변환 계층을 추가하는 경우)는 홀 펀칭을 완전히 막아버린다. STUN이 실패하면 애플리케이션은 릴레이 서버로 후퇴한다.
임시방편이 또 다른 임시방편을 필요로 하게 되었다.
끝나지 않는 임시방편
IPv6 배포는 마침내 실질적인 규모에 이르렀다—현재 Google 트래픽의 약 45%가 IPv6를 사용하며, 프랑스, 독일, 인도 같은 나라는 70%를 넘어섰다. 하지만 IPv4와 NAT은 여전히 굳건히 자리를 지키고 있다. 수많은 아키텍처가 NAT을 전제로 설계되었다: 모바일 앱은 피어 기기가 아닌 서버에 연결되도록 만들어졌고, 클라우드 서비스는 직접 통신을 허용하는 대신 데이터 센터로 트래픽을 집중시킨다.
NAT은 임시방편이어야 했다. 그런데 인프라가 되었다. IPv4의 수명을 늘린 것에 그치지 않고—인터넷이 무엇을 위한 것인지에 대한 우리의 생각 자체를 바꾸어놓았다. 이 상황에서 벗어나려면 단순히 IPv6을 도입하는 것을 넘어 애플리케이션 설계 자체를 다시 생각해야 한다.
NAT은 여러 기기를 쓰는 우리 집을 가능하게 해주는 보이지 않는 번역자다. 너무 잘 작동해서 임시방편이었다는 사실을 잊어버린 꼼수. 원래 대체할 의도조차 없었던 무언가를 마침내 대체할 것이 나타날 때까지, 우리는 계속 이것을 쓸 것이다.
NAT에 관해 자주 묻는 질문
NAT이 보안을 제공하나요?
그다지 그렇지 않다. NAT은 내부 주소를 외부에서 볼 수 없게 숨겨 직접적인 공격을 어렵게 만들지만, 이것은 보안 기능이 아니라 부산물이다. NAT은 트래픽을 검사하거나, 악성코드를 차단하거나, 연결을 인증하지 않는다. 그저 기기들을 하나의 주소 뒤에 감출 뿐이다. 실제 보안은 제대로 된 방화벽이 담당한다.
집에서 게임 서버를 열거나 서비스를 운영할 수 없는 이유가 무엇인가요?
NAT이 요청하지 않은 외부 연결을 차단하기 때문이다. 누군가 공인 IP로 연결을 시도하면, 라우터는 어떤 내부 기기에 전달해야 할지 모른다—변환 테이블에 해당 항목이 없기 때문이다. 포트 포워딩은 영구적인 규칙을 만들어 이 문제를 해결한다: "포트 25565로 들어오는 모든 연결은 192.168.1.50으로 보내라." 이것은 직접 연결이라면 자동으로 해결될 것을 손수 설정하는 것이다.
IPv6이 NAT을 없애줄까요?
이론적으로는 그렇다. IPv6은 모든 기기가 고유한 공인 IP를 가질 수 있을 만큼 충분한 주소를 제공하여, 종단 간 연결을 복원한다. 하지만 현실에서는 NAT이 네트워크 설계와 보안 관행에 너무 깊이 뿌리내려, 많은 조직이 IPv6 환경에서도 NAT을 계속 사용한다. 기술적 필요성은 사라지지만, 조직의 관성은 남는다.
통신사급 NAT이란 무엇인가요?
ISP가 트래픽이 가입자의 라우터에 도달하기도 전에 자체 망에서 NAT을 적용하는 경우가 있다. 이렇게 되면 두 겹의 NAT 뒤에 놓이게 된다: 가입자 라우터의 NAT과 ISP의 NAT. 통신사급 NAT 환경에서는 집에서 서비스를 외부에 공개하는 것이 거의 불가능해진다—라우터에 포트 포워딩을 설정해도 ISP의 NAT이 막아버린다. 이것은 NAT의 논리적 극단이며, IPv4 주소가 얼마나 바닥을 드러내고 있는지를 보여주는 신호다.
출처
이 페이지가 도움이 되었나요?