NAT는 페이로드가 아니라 헤더에서만 작동하며, 이것은 SNMP와 함께 사용될 때 문제를 일으킨다. SNMP는 가장 일상적으로 배치되는 네트워크 관리 데이터 소스다. SNMP는 또한 네트워크 장비들로부터 어드레스들을 전달한다. 수집된 데이터의 쉬운 예로는 MIB II의 AT 테이블과 네트워크 트랩의 근원에서 발견되는 값들이 있다. 이런 MIB 엔트리들은 건드려지지 않고 남겨지며, NAT에 의해 번역되지 않는다.
이것은 자신들이 관리하는 전체 도메인에서 고유 어드레스에 의존하는 네트워크 관리 시스템에게는 문제가 된다. 고유 어드레스는 오류 및 성능 통계를 데이터베이스 엔트리들과 연결짓는다. 네트워크 토폴로지는 부분적으로 라우팅 테이블 및 라우팅 캐시에서 발견되는 어드레싱 및 마스크 조합들로부터 파생된다. IP 어드레스가 중복될 경우, 그 결과는 잘돼야 모호한 정도다. 하지만 보다 일상적으로, 중복은 네트워크 관리 시스템이 잘못되고 혼돈을 일으키는 토폴로지와 가용성 억측을 유발하게 만드는 산만한 네트워크 데이터를 가져오는 경우가 많다.
가장 완벽한 솔루션은 매니지드 네트워크를 리어드레싱(readdressing)하고 NAT를 모두 잊는 게 될 것이다. 하지만, 이것은 말만큼 쉬운 일이 아니다. NAT는 라우팅되는 한 인터페이스의 소스 및 목적지 헤더 어드레스를 라우팅되는 다른 인터페이스의 다른 어드레스로 번역함으로써 비고유 IP 어드레싱 문제를 해결해준다. 네트워크는 그 자체로는 중복 어드레스를 만들어내지 않지만, RFC 1918의 전용 어드레스들을 배치해온 네트워크는 중복 어드레스를 갖게 될 것이며, 따라서 NAT를 필요로 한다.
리어드레싱은 많은 경우에 실용적이거나 재정적으로 가능한 방안이 아닌데, 이것은 네트워크를 리어드레싱하는 데 필요한 작업의 양이 엄청나기 때문이다. 네트워크 관리가 아웃소싱되고 있다면, 일은 훨씬 더 힘들어질 것이다. 고객은 리어드레싱의 고통(및 비용)을 견디기 위해 관리 서비스 사업자에게 받아들이기 힘들만큼 큰 노력을 기울여야 할 것이다.
또 다른 방안은 내부에 있음으로써, 혹은 내부에다 외부에 보고를 하는 어플라이언스를 설치함으로써 네트워크를 관리하는 것이다. 실버백 테크놀로지스(SilverBack Technologies)에서는 이런 어플라이언스를 사용하는 서비스를 제공하고 있으며, 페러그린 시스템즈(Peregrine Systems)의 인프라툴즈(InfraTools)는 이 방안을 사용하고 있다. 이 방안을 위해서는 모든 사이트에 반드시 하나의 어플라이언스가 있어야 하며, 트레이드 오프는 확장성이다. 이 방안은 리어드레싱 문제를 제거하지만, 단일 네트워크에서 중복 어드레스를 사용하는 상황에서는 네트워크 관리 도메인을 오버파티션(overpartition) 시킨다.
보다 실용적인 다른 두 가지 방안들이 있다. 어떤 것도 완벽하진 않지만 두 가지 모두 주효하기는 하다. 하나는 NNM(Network Node Manager)용으로 휴렛팩커드에서 제공하는 무료 구성 방안이며, 다른 하나는 IBM의 번역 제품인 CNAT(Comprehensive Network Address Translation)다. 이런 솔루션들은 새로운 네트워크가 NAT를 통해 연결될 때마다 관리 시스템에서 매번 부딪히는 사일로(silo) 문제를 제거해준다.
NAT의 세 가지 기술
NAT는 세 가지 종류의 기술을 설명할 수 있는데, 정적, 동적, 그리고 포트 혹은 시스코시스템즈식으로 말하자면 과부하가 그것이다. 어드레스들은 NAT의 한 쪽 측면에서 다른 쪽으로 일 대 일 매핑돼야 한다. NAT를 통해 관리를 하려면 정적 매핑을 가져야 한다.
그렇다면 우리가 NAT라는 말로 무엇을 의미하는지 확실히 해보자. NAT 라우터는 어떤 인터페이스가 어떤 어드레스 도메인을 나타내는지를 식별해준다. 이러한 인터페이스들은 내장 및 외장 인터페이스 혹은 진정한 표준화된 인터페이스, 혹은 전용 및 공중 인터페이스라 불린다. 가장 일상적인 관계는 전용 측이 RFC 1918 어드레스를 나타내고, 공중 측이 인터넷 라우터블 어드레스를 나타내는 것이지만, 우리의 목표에 맞는 관계는 중복되는(전용) 어드레스들과 고유의(공중) 어드레스들에 대한 것이다.
보통 NAT는 많은 전용 어드레스로 하나의 공중 어드레스를 매핑하는 프로세스를 설명하는 데 사용된다. 이 프로세스는 PAT(Port Address Translation)로 알려져 있으며, 또한 NAPT(Network Address Port Translation)라 불리기도 하고, 소호(SOHO) 애플리케이션용으로 종종 사용되고 있다. 두 번째로 흔히 배치되는 NAT 방안은 동적 NAT로, 여기서는 동적 NAT 라우터의 공중, 혹은 전용측에 있는 어드레스 풀이 NAT 장비를 가로지르는 세션의 어드레스 번역을 위한 임시 매핑을 제공하는 데 사용된다.
동적 NAT나 PAT는 모두 고유 어드레스를 보장할 수 없다. PAT의 경우 모든 장비에 대한 어드레스는 하나의 어드레스가 될 것이며, 때문에 SNMP 통계는 믿을 만한 게 못 된다. 트래픽은 종류별로 모니터링될 수 있지만, 타깃 기계에서의 SNMP 통계가 모니터링 되려 한다면, 특정 어드레스가 네트워크 관리 데이터베이스에서 매핑돼야 한다. 종적 NAT의 경우, 어드레스가 나타내는 실질적 장비는 SNMP get에서 get으로 바뀔 수 있을 것이며, 따라서 통계와 가용성을 잘못 조절하게 된다. 이러한 이유로, 공중 어드레스를 전용 어드레스로 정적 매핑을 하기 위해서는 NAT 접속 네트워크에 있는 SNMP 데이터의 집합을 반드시 처리해야 한다.
휴렛팩커드의 피트 쯔웨이테코프가 쓴 ‘NNM으로 중복 IP 어드레스 도메인 관리하기’ 백서에서는 HP의 오픈뷰 NNM을 구성하기 위한 방법을 설명하고 있다. 이 방안은 디폴트 데이터베이스 파퓰레이션 방안을 변경함으로써 NNM으로 하여금 장비에게 중복 어드레스들을 전달하게 강요한다.
