NAT

사무실이나 데이터센터의 장치들은 대부분 10.0.0.x, 192.168.x.x 같은 사설 IP를 씁니다. 이 주소는 인터넷 라우터가 경로를 모르기 때문에 그대로는 외부로 나갈 수 없습니다. 그렇다고 수십, 수백 대 장치 각각에 공인 IP를 하나씩 할당하는 것은 IPv4 주소 고갈 상황에서 사실상 불가능하고, 비용도 현실적이지 않습니다. 사설망을 유지하면서 외부와 통신하려면 경계에서 주소를 바꿔 주는 무언가가 필요합니다.

1990년대 초 인터넷이 상업화되면서 연결 장치 수가 폭발적으로 늘었고, IPv4가 제공하는 약 43억 개의 주소가 예상보다 빠르게 소진될 조짐을 보였습니다. IPv6로의 전환이 논의됐지만 기존 인프라를 단기간에 바꾸는 것은 현실적이지 않았습니다. 이 간격을 메울 실용적인 방법으로 RFC 1631에 NAT가 공식 제안됩니다. NAT는 근본적인 해결책이 아니라 시간을 버는 기술이었는데, 오히려 사설망 은닉이라는 부가 효과가 운영 측면에서 매력적으로 받아들여지면서 지금까지 네트워크 경계의 표준 요소로 자리 잡았습니다.

NAT 장비는 내부 호스트가 외부로 나가는 패킷의 출발지 사설 IP와 포트를 공인 IP와 새 포트로 바꾸고, 그 매핑을 테이블에 기록합니다. 예를 들어 192.168.1.10:54321에서 나간 패킷은 203.0.113.1:4001로 바뀌어 외부에 전달됩니다. 외부 서버가 203.0.113.1:4001로 응답을 보내면 NAT 장비가 테이블을 찾아 다시 192.168.1.10:54321로 변환해 내부 호스트에 돌려줍니다. 외부에서 보면 수십 개의 내부 장치가 하나의 공인 주소 뒤에 있는 것처럼 보이지만, NAT 테이블 덕분에 각 세션은 정확히 구분됩니다. 이 방식을 PAT(Port Address Translation) 혹은 NAPT라고도 부릅니다.

NAT와 방화벽은 둘 다 네트워크 경계에 놓이지만 하는 일이 다릅니다. NAT는 주소를 바꿔 사설망과 공인망 사이에 통신 경로를 만드는 역할이고, 방화벽은 그 경로로 들어오고 나가는 트래픽 중 무엇을 허용하고 차단할지 결정합니다. 인터넷으로 나가는 길을 만들려면 NAT가 필요하고, 그 길을 누구에게 열지 제어하려면 방화벽이 필요합니다. 둘은 역할이 겹치지 않아서 실제 환경에서는 같은 장비에 함께 구성되는 경우가 많습니다. NAT만 있으면 보안 통제가 없고, 방화벽만 있으면 사설 주소가 외부로 나갈 수 없습니다.

클라우드나 온프레미스에서 내부 서버가 외부 패키지 저장소, API, 업데이트 서버에 접속해야 할 때 NAT가 나옵니다. 공인 IP 없이 외부로 나가는 길을 열어야 하는 상황이면 거의 항상 NAT가 관여합니다. 반대로 외부에서 내부의 특정 서버로 직접 들어와야 하는 구조라면 NAT만으로는 해결되지 않습니다. 외부에서 시작된 연결은 NAT 테이블에 먼저 매핑이 없으므로 내부로 전달되지 않기 때문입니다. 이 경우 포트 포워딩이나 별도의 공개 주소, 리버스 프록시 같은 방법을 함께 써야 합니다. 장애 진단에서는 NAT 장비의 매핑 테이블이 꽉 찼거나 세션이 너무 빨리 만료되어 연결이 끊기는 경우가 생기므로, 대용량 동시 연결 환경에서는 NAT 테이블 한계를 미리 확인해야 합니다.