필자는 집에서 놀고 있는 노트북으로 Linux 서버를 돌리고 있었다. 하지만 큰 작업도 없는데 계속 전기만 잡아먹고 있는 노트북으로 인해 4월 말 경에 Linux 서버를 종료한 상태다. 현재는 Linux 서버를 VMware에서만 돌리고 있는 상황이다. 문제는, 필자가 여기저기 옮겨다니면서 노트북 작업을 진행하다보니, VM 네트워크 설정으로 골머리를 앓고 있다.
집에서만 VM을 동작한다면, 공유기를 사용하여 Host Bridge 타입으로 연결하고 설정을 유지한 채 사용하면 되지만, 외부에서는 Host Bridge를 연결할 수 있는 여건이 안 될 수도 있기 때문에 NAT 설정으로 연결을 진행해야 한다. 문제는, 외부에서 NAT로 네트워크 설정을 하면 - 필자의 실력 부족인지 - 리눅스에서 인터넷으로 붙을 수 없는 상황이 잦아져서, 시간을 꽤 잡아먹고 있다.
필자가 VM Network 설정과 관련한 개념을 이전의 Linux 포스팅에서 언급한 바 있지만, 이 포스팅 자체가 VM Network 설정에 초점이 맞춰진 것이 아니다보니, 이론적인 내용만 간략하게 언급하고 넘어갔다. 아마 필자와 동일한 상황으로 인해 고민하는 분들이 있을 것이라는 생각에 VMWare의 네트워크 설정 방법에 대해 디테일하게 포스팅을 해보려한다. 필자도 추후 참고 자료도 쓸 겸 말이다.
** 사용 전 IP와 Subnet 개념이 필요하시거나 간략하게 VM 네트워크 설정을 진행하실 분들은 이 포스팅을 참고하자.
1. VMWare 네트워크 동작 원리
가상 머신은, 하나의 PC안에 가상의 공간을 만들어 별도의 OS나 프로그램을 돌릴 수 있도록 하는 프로그램이다. 따라서 일반적인 PC와 동일하게 네트워크 설정이나 기타 시스템 설정도 진행할 수 있다. 이 말인 즉, 가상머신이 하나의 PC 내부에 종속되어 있는 상태긴 하더라도 인터넷과 네트워크 연결도 가능하다는 이야기다.
VMWare와 VMware가 종속된 PC의 상태는 아래의 그림과 같다.
위의 그림 상태에서 VM의 NIC은 다른 NIC 또는 공유기로 연결된 선이 없기 때문에 인터넷 통신이 불가한 상황이다. 더군다나 VM은 물리적인 장치가 아니라 컴퓨터 내부에 존재하는 논리적인 장치기 때문에 사람이 직접 VM에 네트워크 선을 물리는 것은 불가능하다. 따라서 VMWare는 VM으로 OS를 설치하기 전에 VM의 NIC를 다른 장치에 연결할 수 있도록 별도의 설정을 먼저 진행한다.
(1) VM의 NIC 생성
새 가상머신(VM)을 생성하고 이런 저런 설정을 진행하다보면 가상머신의 하드웨어 설정을 진행하는 단계가 나타난다. 즉, 저장 공간의 크기를 얼마로 할 지, 메모리 크기는 어느 정도로 지정할 지 등등 말이다. VM의 NIC 역시 하드웨어 설정에서 부여한다. VMware에서는 Network Adapter라는 이름으로 등장한다. 필자는 VM의 NIC를 두 개 생성해보았다.
Network Adpater를 보면 Network Connection 방식 세 가지가 우측에 표시된다. Bridged, Host-Only, NAT다. 이들은 VM의 NIC를 어디에 어떻게 연결할지를 지정하는 것이라 보면 된다. 우선 필자는 하나의 NetworkAdapter는 Bridged로, 다른 하는 NAT(혹은 Custome의 VMnet8)를 지정했다. 이제 네트워크를 연결하는 세 가지 방식 중, 외부 통신을 가능하도록하는 Bridged와 NAT에 대해 하나씩 알아보자.
(1) Bridged
VM NIC를 Bridged로 설정하면, VM NIC가 직접적으로 공유기 또는 라우터 내부 네트워크 영역에 속하는 효과가 나타난다.
그런데, VM은 앞서 언급한대로 물리적 장치가 아니기 때문에 직접적으로 공유기와 연결될 수 없다. 그럼 어떻게 공유기 내부 네트워크 대역으로 편입될 수 있는 것일까?
VMWare 프로그램 상단의 메뉴바에서 "Edit"->"Virtual Network Editor"를 클릭하고,
팝업된 창의 우측 하단에 위치한 "Change Settings" 버튼을 클릭해보자.
클릭하면 팝업 화면이 Refresh 되면서 상단에 Bridge 타입의 네트워크가 추가되어 표시된다(클릭 전에는 NAT나 Host-only 타입만 존재했을 것이다).
이 창에 표시된 VMnet이라는 녀석들의 정체는 VMWare에서 제공하는 가상 스위치(Virtual Switch)다. 이 가상스위치는 실제 PC 내부에 논리적으로 존재하면서 VM NIC와 공유기를 연결한다. 공유기의 신호는 실제 PC로 들어오지만, 이 신호가 VMnet0의 스위치를 통해 논리적인 스위치까지도 도달할 수 있기 때문에 VM에서도 인터넷으로의 접근이 가능해지는 것이다.
실제 사례를 보자. 필자가 VM에 올린 Linux는 두 개의 NIC를 가지며, 첫 NIC(인터페이스 이름: ens32)가 Bridge로 설정되어 있다. 필자가 현재 작업하고 있는 공유기는 172.30.1.0 / 24 대역대다.
그림으로 나타내면 아래와 같은 상태다.
이 경우 필자의 PC에서 VM으로 접근 시, 공유기 -> VMnet0을 거치는 경로를 사용하게 된다.
(2) NAT
VM을 Bridge로 설정하는 방식은 매우 간편하다. 하지만 문제가 있는데, 공유기 대역대에 위치한 다른 장비에서 VM으로의 접근이 방어가 되지 않는다는 것이다. 실제로 필자가 위치한 곳의 카페의 공유기에 스마트폰을 연결하고 이 VM에 접속을 진행하면 아무런 문제 없이 접속이 되는 것을 확인할 수 있다.
따라서 공유기 내의 다른 사람들이 필자의 VM에 접속하지 못하도록 하면서 VM에서 인터넷 접속이 가능하도록 만들어 줄 필요도 있는데, 이 때 사용하는 방식이 NAT(Network Address Translation)이다.
앞서 보았던 것처럼, VMWare의 Virtual Network Editor를 들어가면, 현재 존재하는 가상 스위치의 목록이 나타난다. 여기서 Add Network를 클릭하면 VMnet 0~19까지 선택할 수 있다(실제 생성된 VMnet 번호는 리스트에서 보이지 않는다).
VMWare는 보통 VMnet 0번은 단순히 Bridge를 위한 가상 스위치로 사용되며, VMnet 8은 NAT를 위한 가상 스위치로 사용된다. 나머지는 인터넷과 연결하지 않아도 되는 분리된 네트워크(소위 인트라넷)를 생성할 때 사용한다. NAT 타입의 가상 스위치가 추가되지 않았다면 추가한 뒤, 창 우측 하단의 Apply 버튼을 눌러 변경사항을 저장해보자.
이제 VMWare가 설치된 window의 cmd 창에서 ipconfig 명령어로 네트워크 인터페이스 정보를 확인해보자. VMnet8 정보가 표시되는 것이 확인된다.
현재 상태를 그림으로 나타내면 아래와 같다.
VMnet8 NAT로 설정하면 VM의 NIC IP는 Bridge와 마찬가지로 dhcp에 의해 IP를 할당받는다. 단, 할당하는 주체가 공유기가 아닌 실제 PC의 ethernet Adapter VMnet8이다. 따라서 VM NIC IP는 VMnet의 네트워크 대역대를 따라가게 된다. 대여 가능한 IP 범위는 Virtual Network Editor에서 확인하거나 수정할 수 있다.
** lease time은 dhcp로 할당한 IP를 빌려줄 수 있는 최대 시간을 명시하는 부분이다. 만약 IP 부여를 시작하고 최대 Lease 시간이 초과되었을 때, VM이 네트워크 접속이 되지 않은 것이 확인되면 부여한 IP는 회수된다.
** NAT 설정에서 두 개의 체크박스가 보이는데, 체크가 되어 있는 경우 상단의 체크박스는 EthernetAdapter 8에 VMnet8 가상 스위치를 연결한다는 말이고, 하단의 체크박스는 VMnet8 가상 스위치와 연결된 VM의 IP를 자동할당한다는 의미다. 필자는 IP 대여가 192.30.1.2 ~ 192.30.1.10으로 설정되어 있기 때문에 3~10 사이의 IP를 VM Linux에 부여받게 된다.
뭔가 이상함을 느끼신 분들도 있을 것이다. "2번부터 대여라고 설정되어 있는데, 왜 3번부터 VM에 대여되나요?"
기본 설정인 경우 네트워크 대역대의 2번 IP는 VMnet 8 가상 스위치에 우선 부여된다. "Virtual Network Editor의 "NAT Setting" 버튼을 누르면 Gateway가 지정된 것이 보이는데, 이 IP가 VMnet8 가상스위치의 IP다.
그림으로는 아래와 같이 나타낼 수 있다.
Linux를 Putty로 접속한 뒤, 기존의 ens32는 실행을 중지시키고, ens33만 동작시켰을 때, 192.30.1.1과 192.30.1.2까지 ping이 날아가는지 확인해보자.
그럼 인터넷까지도 ping이 날아갈 수 있을까? 한국의 DNS 서버인 168.126.63.1로 ping을 날려보자.
"네트워크 접근 불가"라는 결과가 뜨는 분들도 있을텐데, 이는 포스팅의 마지막 부분에서 다시 언급하려 한다.
2. dhcp 말고 수동으로 VM IP를 지정하고 싶은데...
dhcp로 NIC IP를 부여받도록 설정하면, 별도로 IP를 부여하는 작업을 하지 않아도 되지만, IP 할당 가능 범위를 초과하는 VM이 생성되는 경우, VM의 NIC IP가 지속적으로 변경될 가능성이 있기 때문에 접속이 되지 않을 때마다 VM 터미널에서 IP를 확인해야하는 불편함이 있다. 이러한 이유로 VM NIC에 수동으로 IP를 부여해야하는 경우가 생기는데 이는 linux의 설정 파일을 변경함으로써 해결할 수 있다.
Linux의 NIC 설정을 진행하는 파일이 위치한 경로는 아래와 같다.
* 경로: /etc/sysconfig/network-scripts/
파일명은 ifcfg-로 시작하는데, 대시(-) 뒤에는 NIC 이름을 지정해주면 해당 NIC의 설정이 저장된 파일이 나타난다.
vi 편집기로 각 파일을 열어보면 설정정보가 나타나는데, 먼저 보아야 할 부분은 IP의 할당 방식이다. 나열된 필드 중, "BOOTPROTO"라는 필드가 보일텐데 해당 필드의 값이 ens32, ens33모두 dhcp로 되어 있을 것이다.
이는 각각 공유기와 VMnet8 Adapter로부터 VM IP를 자동 할당 받겠다는 의미이며, IP를 수동으로 지정하고자 한다면 이 값을 변경해야한다. Bridged NIC는 이 값을 none으로, NAT NIC는 manual로 변경하자. vi 사용법은 이 포스팅을 참고하자.
IP를 수동으로 할당받는 것으로 설정을 변경했으니, 할당하고자 하는 IP 주소와 PREFIX, Gateway 정보도 추가해주어야 한다.
설정사항을 저장하고, network 서비스를 재기동하자. 그리고 ifconfig 명령어로 각 NIC의 IP를 확인해보자.
이 상태에서 NIC를 하나씩만 살린 뒤, 실제 공유기와 인터넷으로 ping이 되는지 확인하자.
4. 설정 후 인터넷 ping 사용 시, Network "접근 불가"가 뜨는 경우
설정 문제가 주 원인이다. 원인은 크게 두 가지다. 먼저 GATEWAY 주소가 잘못 입력된 경우다. 오랜 시간 네트워크 설정을 건드리고 있지 않은 경우, NAT의 가상 스위치(VMnet8) IP가 Gateway 역할을 한다는 사실을 잊어버리고 공유기 IP를 작성하면서 발생하는 경우가 많다. 반드시 VMnet8의 Gateway 주소를 Virtual Network Editor에서 확인하고 설정파일에 넣어주도록 하자.
두 번 째는 Default Gateway 라우팅이 제대로 지정되지 않은 경우 발생한다. NIC 설정 파일은 ifcfg 파일을 열어보면 DEFROUTE 설정이 있는데, 이는 해당 NIC를 기본 라우팅으로 사용할 것인지를 지정하는 설정이라 보면 된다. 이 값이 yes로 설정된 경우, NIC의 대역대가 아닌 통신은 모두 Gateway를 통하도록 되어 있다.
예시를 그림으로 보자.
VMnet8 가상 스위치는 192.30.1.0 / 24 대역대에 위치한다. 따라서 스위치는 192.30.1.0 / 24 대역에 포함되는 통신은 가능하다. 이 외 범위의 네트워크 IP 주소는 DEFROUTE가 yes로 설정된 경우에 한해 192.30.1.2 Gateway로 빠져나가게 된다. 하지만 DEFROUTE 설정이 no로 지정된 경우, 192.30.1.0 / 24 대역에 포함되지 않은 IP는 가상스위치에서 어디로 전송해야할지 결정하지 못한다. 실제로 DEFROUTE가 no로 되어있는 경우, Linux의 Default Routing 정보가 사라진 상태임을 route 명령어로 확인할 수 있다.
이제 이 문제를 해결해보자. 해결 방법은 두 가지다. NIC 설정 파일에서 DEFROUTE 값은 yes로 지정하던지, 아니면 수동으로 routing을 추가하던지.
첫 번째 방법을 적용하여 결과를 확인해보자.
정상적으로 외부 통신이 가능함을 확인할 수 있다. 이제, default routing을 수동으로 삭제하고 다시 외부 통신을 시도해보자.
위의 내용이 의미하는 것은 단순하다. ifcfg 파일의 DEFROUTE가 no로 설정되어 있더라도 default routing을 수동으로 추가하면 모든 문제가 해결된다는 말이다. ifcfg 파일의 DEFROUTE를 no로 변경하고 default routing을 수동으로 지정해보자.
휴... 이제는 VM 네트워크 때문에 고생할 일은 없을 듯 하다.
Fin.
'ОКБ (실험 설계국) > Trouble Shooting' 카테고리의 다른 글
| 17. [Python] firewall-cmd rich rule 제어 오류 (0) | 2023.09.06 |
|---|---|
| 16. [Linux] Putty 로그인 시 입력 프롬프트가 늦게 나타나는 경우 해결 방법 (0) | 2022.10.07 |
| 14. [Python] tkinter로 생성한 Window 창 x버튼 클릭 시 동작 설정 (0) | 2022.01.19 |
| 13. [Python] 비밀번호 입력 시, Asterisk(* 별표)가 출력되는 코드 작성 (0) | 2021.08.07 |
| 12. [CentOS7, Python] Django Sqlite 버전 관련 에러 해결법 (0) | 2021.06.04 |
댓글