요약

  • NAT는 네트워크 경계에서 전역 고유 IPv4 주소를 절약할 수 있었지만, 주소 값에 의존하는 애플리케이션에는 변환된 IP 헤더 너머의 추가 복구 작업이 필요했다.
  • RFC 2993의 역사적 경고는 그 복구가 어디에 떨어졌는지에 관한 것이었다. 애플리케이션 게이트웨이, 단말 측의 조율된 변경, 로컬 네이밍과 지원 — 라우터 경로에 놓인 한 대의 장비만이 아니었다.

변환기는 설정된 재작성을 정확히 수행하면서도 애플리케이션이 접속하지 못한 상태로 남을 수 있다. 그 실패가 반드시 잘못된 변환 테이블에서 비롯되는 것은 아니다. 같은 주소가 사설 네트워크 안에서는 하나의 의미를, 밖에서는 다른 의미를, 그리고 애플리케이션 자신의 메시지 안에서는 세 번째 사본을 갖기 시작할 때 문제는 시작될 수 있다.

이 구분은 이미 1994년 제안에서 드러나 있었다. RFC 1631은 네트워크 주소 변환(Network Address Translation)을 IPv4 주소 압박에 대한 점진적 대응으로 제시했다. 스텁 네트워크는 내부 주소를 재사용할 수 있고, 경계 장비가 전역 주소 공간으로 넘어가는 트래픽의 일부를 변환한다는 것이었다. 이 메모는 그 교환도 인정했다. IP 주소의 종단 간 의미는 축소되어 네트워크 안의 상태로 대체되었다. 하나의 사이트가 여러 출구를 갖는 경우, 변환기들은 매핑에 대한 일관된 시각을 필요로 했다. 이것은 실용적 가교였지, 그 아키텍처에 비용이 없다는 주장이 아니었다.

2000년 11월, Tony Hain의RFC 2993은 6년간의 관심과 배포 성장 이후의 NAT를 살펴보았다. 그 중심 질문은 더 이상 라우터가 주소를 다른 주소로 바꿀 수 있는가가 아니었다. 변환기가 들여다보지 않는 곳에 주소가 나타날 때 서비스가 계속 동작할 수 있는가였다.

답은 애플리케이션에 달려 있었다. 하나의 NAT를 통한 두 단말 사이의 단순 교환은 관리 가능할 수 있었다. 그러나 어떤 프로토콜은 페이로드 안에 IP 주소를 담고 있었고, 다른 프로토콜들은 체크섬, 인증 또는 보안 처리를 위해 패킷 헤더가 일관되게 유지된다는 가정에 의존했다. 헤더만 다루는 변환기는 그러한 가정 전부를 복구할 수 없었다. 애플리케이션 계층 게이트웨이(ALG)와 프록시가 도움이 될 수 있었지만, 각각은 자신이 복구하는 프로토콜을 이해해야 했다. RFC 2775는 그해 앞서 관련 지적을 했다. 주소 의존적인 새 애플리케이션이 등장하면 ALG나 프록시에 업데이트가 필요하다는 것이었다.

이것은 "투명함"을 조건부 약속으로 바꾸었다. 애플리케이션이 변환된 주소를 노출하지도, 의존하지도 않는다면 경계 기능은 보이지 않는 상태를 유지할 수 있었다. 그렇다면 누군가는 그 애플리케이션이 실행되는 여러 지점에 걸쳐 우회 방법을 조율해야 했다. RFC 2993은 비교적 단순한 두 단말 사례를 이중화된 NAT 경로 및 문서 공유 같은 다자간 애플리케이션과 대조했다. 조율 복잡도는 단말 수에 따라 기하급수적으로 커진다고 명시했다. 이 메모는 어떤 방정식이나 측정된 비용 곡선도 제공하지 않는다. 그 표현은 벤치마크가 아니라 아키텍처적 확장 문제를 서술한다.

이중화는 경계를 두 번째 방식으로 상태화(stateful)했다. 대체 경로상의 두 변환기는 어떤 장비에 대한 매핑에 대해 합의해야 했다. 연결의 상태가 한 경로에 존재하는데 트래픽이 다른 경로로 옮겨가면, 새 경로는 다른 매핑을 만들 수 있었다. 옛 경로를 복원한다고 해서 반드시 원래 대화가 복원되는 것은 아니었다. 따라서 패킷에 기록된 주소만이 전체 상태는 아니었다. 변환기의 매핑과 그것이 경로에서 차지하는 위치도 중요했다.

비용은 조직 간에 이동할 수 있었다. RFC 2993은 ISP가 관리하는 NAT가 한쪽의 지원 면을 단순화하는 동시에 로컬 주소 및 이름 관리 부담을 늘릴 수 있다고 지적했다. 이것은 메모 안의 부담 이전 주장이며, 모든 운영자의 총비용이 올라갔다는 측정된 진술이 아니다. 로컬 관리자는 이제 합병 이후 겹치는 사설 주소를 조정하거나, 내부·외부 이름 응답을 맞추거나, 이전에는 서비스 제공자에게 보이지 않았던 애플리케이션 수정 조율을 처리해야 할 수 있었다.

보안은 변환과 정책 사이의 구분을 더 예리하게 만들었다. RFC 2993은 NAT — 특히 포트 변환 — 가 방화벽의 의도적인 접근 제어 의도 없이 보안 장벽이라는 인상을 만들 수 있다고 경고했다. 또한 IPsec의 호환성 문제, DNS 관련 동작, SNMPv3 인증을 논의했다. 이들은 프로토콜 및 구성에 의존하는 메커니즘이며, 모든 NAT 장비가 모든 보안 프로토콜을 무력화한다는 증명이 아니다. 변환기는 주소 의존적 증거를 바꾼다. 그것 자체가 어떤 트래픽을 허용할지를 결정하지는 않는다.

이후의 기록은 문제가 사라진 것이 아니라 작업이 더 명시적이 되었음을 보여준다. RFC 3022는 2001년에 RFC 1631을 대체하며 전통적 NAT를 서술했다. RFC 3235는 2002년에 애플리케이션 설계자에게 NAT 친화적 지침을 제공했다. 이 문서들은 RFC 2993이 특정 배포를 야기했거나 모든 소프트웨어가 그 지침을 따랐다는 증명이 아니다. 이들은 경계 기법이 주위에 애플리케이션 설계 문헌을 형성해 갔음을 보여줄 뿐이다.

따라서 RFC 2993의 유용한 역사적 기여는 NAT가 항상 실패한다는 판정이 아니다. 그것은 경계의 주소 절약 동작을, 그 위에서 필요한 호환성 작업으로부터 분리한다. 변환기는 하나의 게이트웨이에 설치될 수 있었지만, 복구는 수많은 단말의 애플리케이션 변경, 여러 경로에 걸친 일관된 매핑 상태, 이름에 대한 로컬 통제를 요구할 수 있었다. 네트워크는 그 작업을 없애지 않았다. 누가 그것을 인지하고 조율해야 하는지를 바꾸었다.

출처