수많은 다른 모습의 네트웍 구성 방식이 있겠지만,. 많은 구성방법이 택하고 있는 것은 데스크탑 머신들이 놓여 있고 서버들이 매스커레이드 서브넷에 자리하고 있으며 일반적인 접근이 가능한 컴퓨터들이 유효한 대외적인 IP를 갖고 있는 형태일 것이다.유효한 대외적인 IP를 갖고 있는 컴퓨터들은 이 문서 에서는 ``노출된 호스트''라는 명칭을 사용하여 나타낼 것이다. 다음은 일반적인 예가 될 구성 방식이다.
+--------------+
| | +---------------+
| ISP-supplied |---------------| FTP server |
| router | | +---------------+
| | |
+--------------+ | +---------------+
|------| WWW server #1 |
| +---------------+
|
| +---------------+
|------| WWW server #2 |
| +---------------+
|
~
~
|
| +---------------+
|------| Private |
| Network |
| Gateway |
+---------------+
|
|
|
|
+------------+ | +-------------------+
| Desktop #1 |-------------------|------| Private server #1 |
+------------+ | +-------------------+
|
. -------------------|-------- .
. | .
. -------------------|-------- .
|
+------------+ | +-------------------+
| Desktop #N |-------------------|------| Private server #N |
+------------+ +-------------------+
이 예에서 라우터는 ISP (인터넷 서비스 공급자), FTP 서버, WWW 서버, 그리고 ``공개되지 않은 네트웍 게이트웨이'' 라고 불리는 컴퓨터에게 외부로 나가는 IP 번호를 공급받는다. 그리고 데스크탑이나 사설 서버의 IP는 RFC 1918 www.ietf.org/rfc/rfc1918.txt에 의해 공급된다. 당신이 사설 네트웍(모든 컴퓨터들이 사설 게이트웨이 아래에 구축되는)에 사용하기 위해 선택한 IP 번호는 당신이 관리하는 호스트 아래에 있는 다른 어떤 컴퓨터도 사용하지 않는 유일한 것이 되어야 한다. 그러나 각각의 독립되어 있는 서브넷이나 가상적인 네트웍일 경우에는 그리 되더라도 충돌을 일으키지는 않을 것이다. 네트웍을 합병할 때도 그런 식으로 재배열 하면 될 것이다. RFC의 개요는 당신이 192.168.0.* 에서 시작하여 192.168.255.* 로 끝나는 어떤 C 클래스의 네트웍이나 혹은 172.16.*.* 에서 172.31.*.*로 가는 B 클래스의 네트웍, 아니면 10.*.*.*의 A 클래스의 주소를 할당하는 데 있다. 이 문서의 나머지 부분은 당신이 만들기를 선택한 C 클래스의 사설 네트웍을 설명할 것이다. 그리고 인터넷 공급자가 공급한 IP 번호 중 하나인 IP 번호가 10.1.1.9인 네트웍 게이트웨이에 관한 것도 포함된다. (좀 전에 예로 든 것은 유효한 IP가 아닌 그저 예제로 사용하는 번호임을 미리 밝혀 둔다.) 나는 10.1.1.10의 IP를 가지고 웹서버와 FTP 서버를 겸하는 betty.example.com에 대해서도 다룰 것이다.
당신의 컴퓨터에 필요한 외부 IP 번호에 관해 메모하라. 당신은 각각의 컴퓨터마다 외부의 다른 컴퓨터와 구별되는 하나씩의 IP주소가 필요할 것이다. 이와 같은 셈은 라우터에 의해 주어졌거나 내부에서만 통용되는 IP 번호들을 포함하지는 않는다. 당신은 당신의 인터넷 공급자에게서 각각의 기계에 부여하기 충분할 정도로 많은 갯수의 IP번호들을 얻을 수 있을 것이다. 예를 들면, ISP로부터 8개의 IP를 공급받은 나의 사무실 네트웍에서 나의 컴퓨터 중 3대는 4대의 밖으로 나가는 게이트웨이에만 충분했을 뿐이었던 IP 주소 때문에 사용 불능이어서 게이트웨이 자신에 추가할 수 밖에 없었다.(문맥이 매끄럽지 않군요..... 이런...... T.T)
이 네트웍 구조는 모든 이에게 옳은 것은 아니다. 그러나 그것은 특별한 경우를 제외한 대부분의 설정에서 합당한 출발점이라 할 수 있다. 이러한 설정을 채택할 때의 이점은 다음과 같다.
? 확장이 용이하다. 만일 당신이 곧 당신의 노드를 두 배로 확장할 계획 이라면 당신은 인터넷 공급자로부터 새로은 IP 블록을 얻는다던가 당신의 컴퓨터의 인터페이스를 완전히 재설정할 걱정은 안 해도 될 것이다.
? 지역 네트웍의 관리시. 새로운 워크스테이션을 당신의 네트웍에 당신의 인터넷 공급자와의 커뮤니케이션 없이 추가하기를 원할 때를 생각해 보자. 필요한 일들(ssh나 ftpd는 DNS와의 연결된 피드백이 없이는 불평을 하게 된다.)을 할 때 마다 DNS(도메인 네임 서버)와의 함수적인 연결 관계가 필요한 공개된 노드와는 다른 일이 되겠다. 역전된 DNS 쿼리는 IP 번호에서부터 호스트의 이름을 얻어내게 된다.
주요 보안에 관하여. 사설 네트웍 게이트웨이는 그 네트웍에 연결된 각각의 데스크탑에 어떤 표준적인 것을 인스톨하는 대신에 전체의 사설 네트웍에 관하여 패킷을 필터링하거나 로그인 공격에 대한 보안을 실시할 수 있다. 이것은 내부로 들어오는 패킷에 관한 것만이 아닌 밖으로 나가는 패킷에도 해당되는 것이다. 따라서 설정되지 않은 데스크탑은 인터넷이라 불리우는 외부를 향해 데이터를 내보낼 수도 없는 것이다.
? 이동의 용이성이 또 다른 중요한 문제이다. 당신의 네트웍 안의 IP 주소들은 당신이 원하는 한 언제까지라도 당신 고유의 것들이다. 당신은 사설 네트웍의 설정을 변경하지 않고도 전체 네트웍을 새로운 IP 주소값으로 변경할 수 있다. 따라서 공공연히 위험에 노출된 호스트들은 새로이 설정되어야 할 것이다.
인터넷 연결의 투명성. 당신의 사설 네트웍에 연결된 컴퓨터들은 FTP, telnet, WWW 그리고 약간의 장애를 동반한 채로 리눅스 매스커레이딩 라우터가 떠맡는 다른 서비스들을 이용할 수 있다. 사용자들은 그들의 컴퓨터가 외부적에서 보이지 않는 IP 번호라는 사실을 깨닫지 못하면서 말이다.
이런 식으로 설정을 할 때의 불편함으로 대두될 가능성이 있는 것들은 다음과 같다.
어떤 서비스는 내부 네트웍에 연결된 컴퓨터에서 즉각 이용할 수 없게 될 지도 모른다. 외부 호스트에 대한 NTP 의 일치는 커널의 매스커레이딩 규칙을 포함하지 않는 서비스를 어느정도 덮어 감추게 한다. 또한 .shost 인증은 외부의 노드로부터의 접근은 어렵게 혹은 불가능하게 하지만, 내부에서는 거의 언제나 가능하게 한다.
네트웍 하드웨어에 관한 경비가 더 많이 든다. 사설 네트웍 게이트웨이 는 2개의 네트웍 카드와, 외부로 노출된 네트웍과 사설 네트웍을 위한 최소 2개의 허브, 스위치를 필요로 하게 된다.
?사설 네트웍 안의 컴퓨터가 그 외부의 컴퓨터들과 한 번에 연결되게 하는 것은 쉬운 일이 결코 아니다. 외부의 컴퓨터들과 연결될 때 맨 처음 일어나는 일은 먼저 네트웍 게이트웨이를 지나며 외부 호스트로의 연결에 대한 로그를 남기는 것이다. 이것은 라우터의 패킷들이 투명성을 유지하며 방화벽을 지나는 것으로 가능해 지지만, 그것은 보안상의 문제에 대한 충고를 배제 한다. 이에 관한 것은 다음 섹션에서 마저 논하겠다.
당신은 당신의 네트웍 구성에 있어 그러한 점들을 숙고하고 당신의 상황에 꼭 적당하게 외부로 보이는 네트웍을 결정해 낼 수 있을 것이다. 이 문서의 나머지에서 나는 당신의 네트웍에서 보여지는 것 이상의 설정에 관해 논할 것이다. 만약 당신이 당신에게 꼭 맞는 네트웍을 구성하기로 결정했다면, 세부적인 다른 부분에 관해 나는 이 문서에세 추가로 서술하도록 할 것이다.
특별한 케이스로, 만약 당신이 외부로 보여지는 서버는 아예 필요가 없다면, ISP 서플라이드 라우터는 당신의 사설 네트웍 게이트웨이에 있는 외부 인터페이스에 (허브보다 나은 대안으로)바로 소속될 수 있을 것이다.