-------------------------------------------------------- [서 문] ------------------------------------------------
IT 분야의 전문가가 되기 위해서는 VMware와 같은 가상화 소프트웨어의 사용은 거의 필수적이다. 'VMware 체험'은 SuriMan이 수년간 VMware Workstation을 직접 체험하면서 축적한 노하우를 정리한 글들을 모은 시리즈의 이름이다.
시리즈의 세 번째인 이 글은 VMware의 네트워크 설정에 관한 것으로, VMware 사용에서 가장 난해하고 혼란스러운 내용을 SuriMan의 경험과 실험을 통해 얻은 노하우로 최대한 자세히 그리고 알기 쉽게 설명하려고 노력했다. 참고로, 이 글 작성에 사용한 VMware Workstation 버전은 6.0.4.93057이다.
----------------------------------------------------------------------------------------------------------------

VMware 네트워크 개요

왜 어려운가?

많은 사람들이 VMware 네트워크에 대한 부정확한 지식 때문에 많은 시간을 낭비하고 있다. 인터넷 검색을 해보면 많은 사람들이 이것 때문에 여러 날 밤을 새면서 고생하다가(소위 '삽질'이라고 부른다) 나름대로 이상한(?) 결론을 내린 후, 비효율적으로 네트워크를 설정해서 사용하고 있는 것을 목격할 수 있다.

그 이유는 먼저 '네트워크' 자체가 난해한 분야인데다, VMware 네트워크는 일반적인 네트워크(예를 들어 Windows의 네트워크 설정)보다 훨씬 더 복잡하고 다양한 기능을 제공하는 반면, 자세하고 충분한 도큐먼트가 없기 때문이다(매뉴얼만으로 그 복잡한 VMware 네트워크를 모두 이해할 수 있다면 그는 네트워크 전문가이거나 천재일 것이다!).

이 글을 계속 읽어나가기 전에, 네트워크 기초 지식이 전혀 없는 사람이라면 네트워크 기초에 관한 책이나 인터넷 자료를 읽어볼 것을 권한다(그렇지 않다면 모르는 용어가 나올 때 네트워크 관련 용어 사전을 참고하는 것도 하나의 방법이 될 것이다).

VMware 네트워크의 종류

'VM > Settings...'를 실행한 후 장치 목록에서 Ethernet을 선택하면 [그림 1]과 같이 네 종류의 네트워크 중 하나를 선택할 수 있다.

[그림 1]

참고로, 게스트 OS를 설치하는 마법사의 'Network Type' 지정 페이지에서는 이중 'Custom'이 빠지고 'Do not use a network connection' 항목이 추가되는데, 'Custom'은 설치 과정의 복잡도를 낮추기 위해 생략한 것으로 보이며, 네트워크를 사용하지 않는 경우는 거론할 필요가 없을 것이다(따라서 VMware 네트워크의 종류는 [그림 1]과 같다고 보면 된다).

이어서 각각의 네트워크 종류에 대해 자세히 알아보기로 하자.

호스트 OS의 설정 상태

게스트 OS들의 다양한 네트워크 종류를 알아보기 전에, 호스트 OS의 네트워크 설정 상태를 파악해 볼 필요가 있다(게스트 OS와 밀접한 연관성을 가지므로). 호스트 OS(Windows XP Pro)에서 'ipconfig /all' 명령을 실행한 결과는 [그림 2]와 같다.

[그림 2]

로컬 영역 연결의 IP 주소(하얗게 표시해 놓은 부분)가 192.168.0.100이고 Default Gateway는 192.168.0.1이라는 것을 기억해 놓자. 나머지에 관해서는 차차 설명해 나갈 것이다.

VMware가 설치되면 호스트 OS에 [그림 3]과 같은 몇 가지 서비스들이 추가된다. 특히 VMware DHCP Service와 VMware NAT Service를 눈여겨 봐두기 바란다.

[그림 3]

Bridged 네트워킹

Bridged 네트워킹은 마치 호스트 OS가 연결되어 있는 물리적 공유기에 게스트 OS를 직접 연결하는 것과 같은 결과를 얻도록 해주는 방식이다.

VMware의 Bridged 네트워킹의 구성도는 [그림 4]와 같다.

[그림 4]
(그림 출처 : Virtual Machines & VMware, Part II)

[그림 4]의 VMnet0 ~ VMnet8(이 그림에는 VMnet9가 빠져있다)은 VMware에서 제공하는 가상 네트워크 스위치(고속 허브)이다. 이중 VMnet0는 Bridged 네트워킹을 위한 전용 스위치이다.
Bridged 네트워킹에서는 게스트 OS들이 VMnet0와 호스트 OS 내에 있는 Bridge를 거치고 호스트 OS의 물리적 NIC(네트워크 카드)를 경유해서 인터넷으로 연결된다.

실제로 Bridged 네트워킹으로 구성한 Windows XP 게스트 OS에서 ipconfig /all 명령을 실행한 결과는 [그림 5]와 같다.

[그림 5]

인터넷 공유기를 사용하고 있을 경우, 게스트 OS들은 실제로 인터넷 공유기에 직접 연결된 것처럼 동작한다. [그림 5]와 [그림 2]의 ipconfig 실행 결과를 비교해보면 동일한 네트워크(192.168.0)와 Default Gateway(192.168.0.1)를 사용하고 있는 것을 보더라도 이 사실을 알 수 있다. 즉, Bridged 네트워킹으로 구성한 게스트 OS는 외부의 인터넷 공유기에 직접 연결된 것과 같다. 그리고 이것은 NAT에서와 같은 변환 처리를 필요로 하지도 않으므로 가장 효율적이다.

따라서 특별한 이유나 문제가 없다면 Bridged 네트워킹으로 지정하는 것이 기장 좋다(NAT가 기본인 것처럼 지정하는 사례를 많이 볼 수 있는데, 그것은 잘못된 것이다).

NAT 네트워킹

NAT(Network Address Translation)는 외부 네트워크와 내부 네트워크를 연결해주는 변환기로, 내부 네트워크로 들어오거나 외부 네트워크로 나가는 네트워크 패킷의 IP 주소를 변환해준다. 예를 들어 인터넷 공유기를 사용할 경우, 공유기 내부의 NAT에 의해 ISP에 연결된 공식 IP 주소(예: 121.123.207.42)와 192.168.0.100과 같은 내부(비공식) IP 주소를 서로 변환해준다. 공유기에 3대의 PC가 연결되어 있다고 할 때 각각의 PC에는 내부 IP 주소가 할당되어 있지만 공유기의 NAT를 거치면서 공식 IP 주소로 변환되어 인터넷을 사용할 수 있는 것이다.

VMware의 NAT 네트워킹의 구성도는 [그림 6]과 같다.

[그림 6]
(그림 출처 : Virtual Machines & VMware, Part II)

[그림 6]에서 VMnet8은 NAT 네트워킹을 위한 전용 스위치이다. [그림 6]의 NAT(실제로는 호스트 OS의 'VMware NAT Service' 서비스이다)를 통해 호스트 OS가 속해 있는 외부 네트워크와 게스트 OS가 속해 있는 내부 네트워크(VMnet8)가 연결된다. 게스트 OS들은 DHCP(실제로는 호스트 OS의 'VMware DHCP Service' 서비스이다)를 통해 동적으로 IP를 할당받는다(물론 정적으로 IP를 할당할 수도 있다).

실제로 NAT 네트워킹으로 구성한 Windows XP 게스트 OS에서 ipconfig /all 명령을 실행한 결과는 [그림 7]과 같다.

[그림 7]

앞의 [그림 2]에서 호스트 OS의 IP Address가 192.168.0.100인데, 이것이 [그림 6]의 NAT를 거쳐 192.168.73.1([그림 2] 중 'Ethernet adapter VMware Network Adapter VMnet8:'의 IP Address 참고)로 변환된 후, VMnet8에 연결된다. 그리고 [그림 7]에서 Default Gateway, DNS Servers, Primary WINS Server에 할당된 192.168.73.2도 실제로는 호스트 OS의 IP 주소이다.

VMware의 NAT 네트워킹은 Bridged 네트워킹보다 비효율적이지만, 다음과 같이 Bridged 네트워킹으로 설정할 수 없는 상황에서 차선책이 되는 네트워킹 방식이다.

• (인터넷 공유기가 있더라도) ISP(인터넷 서비스 제공업체)에서 Bridged 네트워킹을 지원하지 않을 경우(이런 경우를 과거에 SuriMan이 직접 경험한 적이 있다)
• 인터넷 공유기가 없어서 인터넷에 직접 연결한 경우(회사의 LAN 환경은 제외)
• 호스트 OS에서 무선 LAN 카드만 사용할 경우(802.11 프로토콜의 보안 특성 때문에 게스트 OS의 Bridged 네트워킹은 작동하지 않는다고 함)
• 호스트 OS가 다이얼업 접속, 토큰 링과 같은 이더넷이 아닌 망에 접속되어 있을 경우

Host-only 네트워킹

Host-only 네트워킹은 말 그대로 호스트 OS까지만 통신을 하고, 그 바깥 세상(인터넷 등)과는 통신할 수 없는 방식이다.

VMware의 Host-only 네트워킹의 구성도는 [그림 8]과 같다.

[그림 8]
(그림 출처 : Virtual Machines & VMware, Part II)

[그림 8]에서 VMnet1은 Host-only 네트워킹을 위한 전용 스위치이다. [그림 8]에서 보다시피, 게스트 OS는 호스트 OS까지만 연결이 되고 호스트 OS의 Physical NIC와 연결되지 않는다. 따라서 인터넷 접속 등은 되지 않는 것이다.

실제로 Host-only 네트워킹으로 구성한 Windows XP 게스트 OS에서 ipconfig /all 명령을 실행한 결과는 [그림 9]와 같다.

[그림 9]

[그림 9]에서도 알 수 있듯이, 외부와의 라우팅을 위한 Default Gateway가 없다. 그리고 DNS Server의 IP 주소는 [그림 2]의 'Ethernet adapter VMware Network Adapter VMnet1:'의 IP 주소와 일치하는 것을 알 수 있다. 즉, 게스트 OS의 DNS Server는 호스트 OS이며, VMnet1 스위치를 통해 서로가 연결되어 있다.

Host-only 네트워킹의 용도는 게스트 OS가 외부와는 완전히 단절되고 호스트 OS와만 통신하는  것인데, SuriMan이 생각하기에 이런 경우는 드물 것으로 생각된다.

Custom 네트워킹

Custom 네트워킹은 말 그대로 맞춤식 네트워크를 구성하는 방식이다. 기본적인 Custom 네트워킹은 아무 것도 설정해주지 않으므로 처음에는 전혀 네트워킹이 되지 않는다.

그런데 이래서는 전혀 이해가 되지 않기 때문에 SuriMan이 하나의 예를 들어보기로 한다. Custom1과 Custom2라는 두 개의 게스트 OS를 만들고 이들을 VMnet2 스위치에 연결하고 수동으로 TCP/IP 설정을 하여 이 둘 사이에만 통신을 하도록 해보겠다.

1. 먼저, Custom 네트워킹에 VMnet2 스위치를 사용하기로 하고(VMnet2 ~ 7, 9를 사용할 수 있다), 여기에 서브넷을 구성한다. [그림 10]처럼 Virtual Network Editor의 Host Virtual Network Mapping 탭을 클릭하고 VMnet2 오른쪽의 '>' 버튼을 클릭한 후, 팝업 메뉴에서 Subnet을 선택한다.
   
   

   [그림 10]

2. [그림 11]처럼 VMnet2 서브넷의 IP Address에 192.168.2.0을 입력하고(네트워크의 IP 주소 끝자리는 반드시 0이어야 함), Subnet Mask는 기본값인 255.255.255.0으로 설정한다.
   
   

   [그림 11]

3. Custom1 게스트 OS에서 VMware 창 제일 아래쪽의 알림 영역에 있는 Ethernet 아이콘([그림 12]의 제일 아래쪽 오른쪽에서 세 번째에 있는 NIC 모양의 아이콘)을 더블 클릭하고, [그림 12]처럼 Custom을 선택하고, 드롭다운 목록상자에서 VMnet2를 선택한다.
   
   

   [그림 12]

4. Custom2 게스트 OS에서도 같은 방식으로 Custom과 VMnet2를 선택한다.
5. Custom1의 '바탕화면 > 내 네트워크 환경'에서 오른쪽 클릭을 하고 속성을 선택한다. 그리고 로컬 영역 연결에서 오른쪽 클릭을 하고 속성을 선택한다. 이어서 '인터넷 프로토콜(TCP/IP)'를 더블 클릭한 후, [그림 13]과 같이 IP 주소로 192.168.2.1을 입력한다(Subnet Mask는 기본값인 255.255.255.0으로 설정한다). 계속 확인을 클릭하여 설정을 마친다.
   
   

   [그림 13]

6. 위와 비슷한 절차를 밟아 Custom2의 IP 주소를 192.168.2.2로 설정한다.
7. Custom1과 Custom2에서 각각 명령 프롬프트를 열고 ipconfig /all 명령어를 실행하여 [그림 14]와 같은 결과를 확인한다(Custom2에서는 당연히 IP 주소가 192.168.2.2로 표시될 것이다).
   
   

   [그림 14]

8. 이제 모든 준비가 끝났다. 방금 설정한 Custom 네트워킹 방식 외에, 지금까지 설명한 모든 네트워킹 방식에 대해서 지금부터 실제 작동 테스트를 해 볼 것이다.

네트워킹 테스트

테스트 개요

지금까지 알아본 4종류의 VMware 네트워크 방식에 대해서 SuriMan이 다양한 테스트를 해 보았다. 특정 네트워크 방식을 적용한 게스트 OS와 호스트 OS 간에는 물론이고, 같은 네트워크 방식을 적용한 게스트 OS들 간에, 그리고 다른 네트워크 방식을 적용한 게스트 OS들 간에 네트워킹이 성공하는지, 거의 모든 경우에 대해 실험을 통해 테스트해 보았다.

이 결과는 VMware에서 제공하는 다양한 네트워킹 방식을 최대한 활용하는데 도움이 될 것으로 생각한다. 특수한 요구 사항이 발생할 경우, SuriMan이 테스트한 네트워크 방식들의 조합이 꼭 필요할 수도 있기 때문이다. 본 실험은 이런 경우에 각자가 새로이 테스트하는 시간을 줄여 줄 것이다(테스트 내용을 보면 알겠지만, 이 실험을 하는 데는 상당히 많은 시간이 걸렸다).

테스트 준비

네트워킹이 되는지 테스트하고자 할 때 가장 먼저 떠오르는 도구는 ping이다. 그러나 OS, 방화벽, ISP 등의 설정 때문에, 분명히 연결은 되어 있는데도 ping 테스트가 실패하는 경우가 많다.

따라서 본 테스트에서는 telnet을 테스트 도구로 사용한다. telnet은 원격 컴퓨터에 로그온하여 텍스트 모드의 명령어를 실행할 수 있도록 해준다. telnet은 원래 UNIX에서 유래한 것인데, 이것에 생소한 사람들은 Windows의 '원격 데스크톱 연결'의 텍스트 모드 버전이라고 생각하면 이해가 쉽다.

telnet은 Windows XP에서 기본으로 제공하지만, 보안 취약점 때문에 자동으로 활성화되지는 않는다. 그리고 방화벽에서도 자동으로 telnet 패킷을 통과시켜 주지 않으므로, 다음과 같은 준비를 해야 한다.

• telnet 서비스를 제공할 OS에서 [그림 15]와 같이 telnet 서비스를 시작한다(테스트가 끝날 때까지는 시작 유형을 '자동'으로 해두는 것도 좋다).
  
  

  [그림 15]

• telnet 서비스를 제공할 OS의 방화벽에서 telnet 포트를 추가해준다. 예를 들어 Windows 방화벽을 사용하고 있다면, '제어판 > Windows 방화벽'을 실행하고 '예외' 탭을 클릭한 후 '포트 추가' 버튼을 누르고 [그림 16]과 같이 포트 번호로 23(telnet의 포트 번호이다)을 입력한다.
  
  

  [그림 16]

테스트 방법

모든 테스트는 2개 OS 간의 테스트이다. 예를 들어, NAT 네트워킹으로 설정한 게스트 OS를 원천(source)으로 하고, Bridged 네트워킹으로 설정한 게스트 OS를 대상(destination)으로 했을 때의 테스트 절차는 다음과 같다.

1. 대상에서 [그림 15] 및 [그림 16]처럼 telnet 서비스를 시작한다.
2. 원천에서 [그림 17]과 같이 telnet 명령어를 실행한다(대상의 IP 주소를 지정해야 한다).
   
   

   [그림 18]

3. 그러면 [그림 18]과 같은 경고 프롬프트가 나오는데, 여기서 y를 입력하고 Enter를 누른다.
   
   

   [그림 18]

4. 이어서 [그림 19]와 같이 로그온을 한다(대상 OS의 로그인과 패스워드를 입력해야 한다).
   
   

   [그림 19]

5. [그림 20]과 같이 'Microsoft 텔넷 서벗 시작'이라는 메시지가 표시되고 로그온한 사용자 폴더로 이동된다.
   
   

   [그림 20]

6. 대상이 맞는지 확인한다([그림 20]에서는 대상 OS의 C:\ 폴더에 '_Bridged_'라는 파일을 미리 만들어 놓고 이것을 확인했다).
7. telnet 테스트를 마친다(exit 명령어로 telnet 세션을 끝낸다).

telnet 테스트 절차에서 한 가지 예외가 있는데, 이것은 게스트 OS가 NAT 방식일 때 호스트 OS에서만 발생하는 것이다. 호스트 OS에서는 telnet 서비스와 VMware NAT Service 서비스를 동시에 시작할 수 없고(그 이유는 아직 파악하지 못했음), 둘 중 하나만 시작할 수 있다. 따라서 NAT 네트워킹 방식을 사용하는 게스트 OS에서 호스트 OS로 telnet 테스트를 할 때는 VMware NAT Service 서비스를 일시적으로 중지시킨다(이렇게 하더라도 네트워크 설정이 바뀌지는 않는다).

테스트 결과 (같은 네트워킹 방식 간)

같은 네트워킹 방식을 사용하는 두 게스트 OS 사이의 네트워킹 테스트 결과는 [표 1]과 같다.

[표 1]

이것은 당연한 결과로 생각될 수도 있지만, 그렇지 않다. 예를 들어, 원천과 대상이 둘 다 Host-Only 방식일 경우, 게스트 OS와 호스트 OS와의 사이에서 뿐만 아니라 두 게스트 OS끼리 서로 네트워킹이 된다는 사실은 결코 당연한 일이 아니다! 그리고 심지어 호스트 OS와도 네트워킹이 되지 않는 Custom 방식의 두 게스트 OS끼리 서로 네트워킹이 된다는 사실도 신기한 것이다(실제로 이것은 앞의 'Custom 네트워킹' 절에서 SuriMan이 그렇게 설정해 놓았기 때문이지만).

위 표 내의 원천과 대상을 서로 바꾸어 테스트해도 telnet 결과는 동일했다(이건 당연하다).

테스트 결과 (다른 네트워킹 방식 간)

서로 다른 네트워킹 방식을 사용하는 두 게스트 OS 간, 그리고 게스트 OS와 호스트 OS 간의 네트워킹 테스트 결과는 [표 2]와 같다. 왼쪽에 아래로 열거된 1-1, 1-2...는 원천들을 나타내고 윗쪽에 오른쪽으로 열거된 1-1, 1-2...는 대상들을 나타낸다. 그리고 왼쪽의 원천 중 하나와 윗쪽의 대상 하나 사이의 네트워킹이 성공하면 O, 실패하면 X로 표시했다(-는 테스트에서 제외된 것을 나타낸다).

[표 2]

1. 원천 및 대상을 나타내는 숫자들의 의미는 다음과 같다.
   
   
   • 1-1 : 호스트 OS의 물리적 NIC(IP 주소는 192.168.0.100)
   • 1-2 : 호스트 OS의 VMnet8(NAT 스위치)용 가상 NIC(IP 주소는 192.168.73.1)
   • 1-3 : 호스트 OS의 VMnet1(Host-only 스위치)용 가상 NIC(IP 주소는 192.168.6.1)
   • 2 : Bridged 네트워킹 방식의 게스트 OS(IP 주소는 192.168.0.13)
   • 3 : NAT 네트워킹 방식의 게스트 OS(IP 주소는 192.168.73.129)
   • 4 : Host-Only 네트워킹 방식의 게스트 OS(IP 주소는 192.168.6.128)
   • 5 : Custom(Vmnet2 사용) 네트워킹 방식의 게스트 OS(IP 주소는 192.168.2.1)
2. 호스트 OS를 원천으로 할 경우, 가상 NIC(1-2, 1-3)를 사용할 수 없으므로 테스트에서 제외시켰다(호스트 OS가 대상이 될 경우에는 게스트 OS에서 1-1, 1-2, 또는 1-3을 명시적으로 지정할 수 있다. 예를 들어, 'telnet 192.168.73.1'과 같은 명령어를 실행할 수 있는 것이다. 그러나 결과에서 보듯이, 항상 1-1, 1-2, 1-3 중 하나와만 성공한다).
3. 호스트 OS에서 VMware NAT Service 서비스를 일시적으로 중지시키고 테스트한 경우는 다음과 같다.
   • 1-1 → 1-2
   • 3 → 1-2
4. 테스트 결과를 요약해보면 다음과 같다.
   • Custom 방식의 게스트 OS는 모든 다른 방식의 원천 및 대상과의 네트워킹에 실패했다(따라서 아래의 요약 내용에서도 논외로 취급하겠다).
   • 호스트 OS는 모든 대상과의 네트워킹에 성공했다(이것은 당연한 듯 보인다).
   • Bridged 방식의 게스트 OS는 호스트 OS와 Host-Only 방식의 게스트 OS와의 네트워킹에는 성공했지만, NAT 방식의 게스트 OS를 대상으로 한 테스트에서는 실패했다(원천과 대상을 바꾸면 성공하므로, 이 결과는 다소 의아스럽다).
   • NAT 방식의 게스트 OS는 모든 대상과의 네트워킹에 성공했다(이 결과도 다소 신기하다).
   • Host-Only 방식의 게스트 OS는 호스트 OS를 제외한 모든 대상과의 네트워킹에 실패했다(그래서 'Host-Only'라는 이름을 붙인 듯 하다).

기타

포트 포워딩

일반적으로 내부 네트워크에서 NAT를 경유하여 외부 네트워크를 액세스할 때는 별 문제가 없지만, 반대로 외부 네트워크에서 NAT를 경유하여 내부 네트워크를 액세스할 때는 포트 포워딩(Port Forwarding)이 필요하다. 포트 포워딩이란, 사용하고자 하는 외부 포트와 내부 포트를 매핑시켜주는 작업이다.

VMware에서 NAT 방식을 지원하는 VMnet8 스위치에서 포트 포워딩을 설정하는 절차는 다음과 같다.

1. 호스트 OS에서 '시작 > 프로그램 > VMware > Manage Virtual Networks'를 실행한다.
   
2. [그림 21]과 같은 Virtual Network Editor에서 NAT 탭을 클릭한다.
   
   

   [그림 21]

3. 'Edit...' 버튼을 클릭한다. 이때 [그림 22]와 같은 NAT Settings 대화상자가 열린다.
   
   

   [그림 22]

4. 'Port Forwarding... ' 버튼을 클릭한다. 이때 [그림 23]과 같은 Port Forwarding 대화상자가 열리는데, 여기서 'Add...' 버튼을 클릭하면 'Map Incoming Port' 대화상자가 열린다.
   
   

   [그림 23]

5. 다음과 같이 입력한다.
   • Host port : 외부 네트워크(호스트 OS가 있는 곳)의 포트 번호
   • Virtual Machine IP Address : 게스트 OS의 IP 주소
   • Port : 게스트 OS의 포트 번호
   • Description : 설명
6. 여기서는 FTP에 해당하는 포트 21을 지정했다.
7. OK 버튼을 3번 누르면 [그림 24]와 같은 Virtual Network Editor로 돌아오는데, 여기서 Restart 버튼과 확인 버튼을 연속적으로 눌러, 방금 변경한 설정을 NAT 서비스에 적용한다.
   
   

   [그림 24]

그런데 SuriMan이 직접 테스트한 바로는, VMware의 NAT에서는 Port Forwarding으로 별다른 효과를 얻지 못하였다. 즉, 위와 같이 FTP에 대한 Port Forwarding을 하더라도 전혀 달라지는 점이 없었다. 앞에서 일련의 telnet 테스트를 할 때도 Port Forwarding은 전혀 설정하지 않았었다.

Linux/UNIX에서의 네트워크 설정

게스트 OS가 Linux 또는 UNIX일 때도 위에서 설명한 개념들은 마찬가지로 적용되며, 단지 게스트 OS에 네트워크를 설정하는 부분만 다르다. 참고로, 이 글에서는 대부분의 경우(Custom 네트워킹 방식만 제외하고) Windows XP의 기본 네트워크 설정인 '자동으로 IP 주소 받기'와 '자동으로 DNS 서버 주소 사용'으로 지정하므로 게스트 OS에서 특별한 네트워크 설정이 필요하지 않았다. 그러나 Linux/UNIX에서는 약간의 설정이 필요하다.

이에 대해서는 아래의 링크들을 참고하기 바란다(정확성에 대한 보장은 하지 못한다. 예를 들어, 첫번째 링크의 포트 포워딩에 대한 설명 부분은 SuriMan이 보기에 정확하지 않다).

• Swan's Blog - vmware 네트웍 옵션
• 싸님의 블로그 - VMware 6.0에서 솔라리스 9.0버전 NAT 네트워크 설정하기

복합 응용 예

[그림 25]는 VMware 네트워크 방식들을 복합적으로 응용한 예이다. 호스트 OS, Bridged 방식의 스위치(VMnet0) 1개, Custom 방식의 스위치 2개(VMnet2, Vmnet3), 게스트 OS 4대(1대는 웹 서버, 2대는 방화벽, 1대는 내부 PC 역할을 담당한다)로 구성된다. 이 그림을 보더라도 VMware를 이용하면, 물리적 PC 1대와 물리적 NIC 하나만 가지고도 매우 복잡하고 다양한 네트워크를 구성할 수 있음을 알 수 있다.

[그림 25]
(그림 출처 : Workstation 6.0 User’s Manual : Figure 13-4. Custom Configuration That Uses Two Firewalls)

마무리

역시 '네트워크'는 어려운 분야인 듯하다. SuriMan이 미처 파악하지 못한 부분(예를 들면 VMware의 Port Forwarding 관련)을 알려주시거나, 위 글에서 잘못된 부분을 지적해주시는 분이 있다면 감사드리겠다.

본 시리즈의 다음 글에서는 VMware의 나머지 다양한 셋업 방법에 관해 알아보기로 한다.