Microsoft MVP성태의 닷넷 이야기
개발 환경 구성: 87. Hyper-V의 네트워크 유형 (3) [링크 복사], [링크+제목 복사],
조회: 21520
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 12개 있습니다.)
개발 환경 구성: 83. Hyper-V의 네트워크 유형 (1)
; https://www.sysnet.pe.kr/2/0/910

개발 환경 구성: 84. Hyper-V의 네트워크 유형 (2)
; https://www.sysnet.pe.kr/2/0/915

개발 환경 구성: 87. Hyper-V의 네트워크 유형 (3)
; https://www.sysnet.pe.kr/2/0/918

Windows: 59. Hyper-V Internal 네트워크 VM의 인터넷 접속
; https://www.sysnet.pe.kr/2/0/1335

개발 환경 구성: 330. Hyper-V VM의 Internal Network를 Private 유형으로 만드는 방법
; https://www.sysnet.pe.kr/2/0/11299

Windows: 174. WSL 2의 네트워크 통신 방법
; https://www.sysnet.pe.kr/2/0/12347

개발 환경 구성: 517. Hyper-V Internal 네트워크에 NAT을 이용한 인터넷 연결 제공
; https://www.sysnet.pe.kr/2/0/12352

개발 환경 구성: 522. WSL2 인스턴스와 호스트 측의 Hyper-V에 운영 중인 VM과 네트워크 연결을 하는 방법
; https://www.sysnet.pe.kr/2/0/12494

개발 환경 구성: 656. Internal Network 유형의 스위치로 공유한 Hyper-V의 VM과 호스트가 통신이 안 되는 경우
; https://www.sysnet.pe.kr/2/0/13199

개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
; https://www.sysnet.pe.kr/2/0/13230

개발 환경 구성: 665. WSL 2의 네트워크 통신 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/13256

개발 환경 구성: 670. WSL 2에서 호스팅 중인 TCP 서버를 외부에서 접근하는 방법
; https://www.sysnet.pe.kr/2/0/13280




Hyper-V의 네트워크 유형 (3)

이번에 살펴볼 내용은, 다음과 같은 시나리오를 위한 것입니다.

  • 호스트 측의 네트워크를 어지럽히지 않고, (즉, 별도의 네트워크로 분리하기 위해 Internal 유형 사용)
  • VM <-> VM
  • VM <-> HOST
  • VM <-> 인터넷
  • VM <-> HOST가 참여하고 있는 네트워크의 다른 PC

정리해 보면, Hyper-V의 네트워크 유형 (2) 글에서 살펴 본 "Internal + ICS" 상태의 네트워크에 다음 기능을 추가한 것입니다.

  • VM <- HOST가 참여하고 있는 네트워크(또는 인터넷)의 다른 PC

그렇군요. 기존 네트워크와 동등한 레벨로 하나의 완전한 독립 네트워크를 생성하기 위한 작업입니다.

참고로, 이에 관한 것은 다음의 글들을 기반으로 작성된 것입니다.

How to use Hyper-V with a wireless network connection
; http://blogs.msdn.com/b/nicold/archive/2008/04/15/how-to-use-hyper-v-with-a-wireless-network-connection.aspx

Access Hyper-V VM Internal Networks from outside the host computer
; http://blogs.msdn.com/b/mihail_popescu/archive/2009/10/22/access-hyper-v-vm-internal-networks-from-outside-the-host-computer.aspx




"Internal" 유형의 네트워크로부터 천천히 한 단계씩 해결해 볼까요? ^^ (만약 기존 실습 과정에서 ICS를 걸어두었다면 해제합니다.)

우선, "Internal" 네트워크는 기본적으로 다음과 같은 통신만 제공합니다.

  • VM <-> VM
  • VM <-> HOST

예제에 사용될 VM 하나와 호스트의 기본 IP 구성은 다음과 같습니다.

A-VM
   IP: 169.254.222.37 / 16

Host 
   (Internal 가상 NIC) IP: 169.254.139.48 / 16
   (물리 NIC) IP: 192.168.1.2 / 24

Internal 네트워크에 대한 관리 편의를 위해 기본 제공되는 IP 대역을 쓰지 않고 임의의 "C 클래스"를 정하겠습니다. (물론, B 클래스도 상관 없는데, 어차피 한 대의 Hyper-V에서 제공되는 VM 수를 생각하면 "C 클래스"로도 충분합니다.)

A-VM
   IP: 192.168.50.2 / 24
   Gateway: 192.168.50.1

Host 
   (Internal 가상 NIC) IP: 192.168.50.1 / 24

   (물리 NIC) IP: 192.168.1.2
              Gateway: 192.168.1.0

Host 네트워크의 다른 PC
   (물리 NIC) IP: 192.168.1.3
              Gateway: 192.168.1.0

당연히, 지금 단계에서 "A-VM <-> Host" 사이에서는 서로 같은 네트워크(192.168.50.0)에 주어진 IP를 가지고 Ping을 하게 되면 응답이 옵니다.

첫 번째 문제는 "A-VM -> 호스트가 참여하고 있는 다른 PC"로의 통신이 가능해야 하는 것인데요. 즉, A-VM에서 "ping 192.168.1.3"이 가능하게 만들어야 합니다.

일단, 길 찾기를 한번 해볼까요?

A-VM에서 "ping 192.168.1.3"을 치면, 게이트웨이가 "192.168.50.1"로 되어 있으니 호스트 PC에 패킷이 전달됩니다. 그런데, 호스트 PC는 "Internal 가상 NIC"에 전달된 그 패킷을 어떻게 처리해야 할지를 모르기 때문에 더 이상 패킷 전달이 안됩니다.

만약, 호스트로 하여금 "192.168.1.3"으로의 패킷 전달을 하도록 만들고 싶다면 호스트 PC를 "라우터"로 만들어야 합니다. 따라서, 앞으로의 실습 진행을 위해서 아래의 글에 따라 ^^ 호스트 PC에 라우터 기능을 설치합니다.

"Routing and Remote Access"의 "Routing" 기능 활성화 방법
; https://www.sysnet.pe.kr/2/0/917

이렇게 설치해 주면, "이론상, VM -> Host 네트워크의 다른 PC"로의 통신은 가능합니다. "ping 192.168.1.3"을 치면,

VM (192.168.50.2) 
==> 디폴트 게이트웨이(192.168.50.1)을 거쳐서 
==> 호스트 PC가 라우터 기능이 있기 때문에 (물리 NIC) 192.168.1.2로 전달
==> (물리 NIC) 192.168.1.2에서 네트워크의 다른 PC(192.168.1.3)에 도착

그런데, 문제는 ICMP 응답입니다. 192.168.1.3으로부터의 응답 IP 헤더에는 주소가 "192.168.50.2"로 되어 있을 텐데, 경로 풀이가 다음과 같이 됩니다.

네트워크의 다른 PC (192.168.1.3)
==> 디폴트 게이트웨이(192.168.1.0)을 거쳐서
==> (192.168.50.1에 대한 라우팅 정보가 없으므로) 디폴트 게이트웨이의 다른 외부망으로 패킷 전달

이 때문에 Ping은 정상 동작하지 않게 됩니다. 따라서, 이런 경우에 네트워크의 대상 PC에 "192.168.50.0" 네트워크 주소에 대한 올바른 라우팅 경로를 VM을 호스팅하고 있는 PC로 다음과 같이 설정해 주어야 합니다.

C:\>route add 192.168.50.0 mask 255.255.255.0 192.168.1.2 
OK!

이렇게 되면 ICMP 응답은 다음과 같이 바뀝니다.

네트워크의 다른 PC (192.168.1.3)
==> PC에 설정된 라우팅 정보에 따라 (192.168.1.2)로 응답이 전송되고
==> 192.168.1.2의 라우팅 서비스에 따라 가상 NIC(192.168.50.1)으로 전달되고
==> A-VM의 192.168.50.2에 도착

결국, Internal 네트워크는 다음과 같이 확장됩니다.

  • VM <-> VM
  • VM <-> HOST
  • VM <-> HOST가 참여하고 있는 네트워크의 다른 PC




그런데, 문제가 2가지 있습니다.

  1. "네트워크의 다른 PC"들에 모두 돌아다니면서 일일이 "route add ..." 정보를 써주는 것은 매우 불편하다는 점과,
  2. VM에서 인터넷이 안된다는 것!

재미있게도 위의 문제는 동시에 풀려질 수 있습니다.

우선, 1번 문제는 위에서 자세히 알아봤으니 생략하고, 그렇다면 2번의 인터넷이 왜 안되는지를 살펴보겠습니다.

사실, 이번에도 "이론상, VM -> 인터넷" 접근은 가능합니다. 예를 들어, "http://203.252.3.60"로 접근하면,

VM (192.168.50.2)
==> 디폴트 게이트웨이(192.168.50.1)를 거쳐서 
==> 호스트 PC가 라우터 기능이 있기 때문에 (물리 NIC) 192.168.1.2로 전달
==> (물리 NIC) 192.168.1.2에 설정된 디폴트 게이트웨이(192.168.1.0)을 거쳐서 
==> 디폴트 게이트웨이(192.168.1.0)는,
    보통 NAT(Network Address Translation) 기능을 이용해서 다음과 같은 맵을 내부적으로 구성하고,
        192.168.50.2 : 포트 12000 <==> 게이트웨이의 공용 IP(121.139.108.3): 포트 12000

    인터넷으로 나가야 될 패킷의 Source IP에 디폴트 게이트웨이에 설정된 공용 IP를 설정합니다.
        Source IP: 121.139.108.3 / Port 12000,
        Dest IP: 203.252.3.60 / Port 80
==> ... 인터넷의 라우터들을 거쳐서 ...
==> 203.252.3.60 웹 서버에 도착

이번에도 문제는 응답인데요, 과정은 다음과 같습니다.

웹 서버 203.252.3.60
==> ... 인터넷의 라우터들을 거쳐서 ...
==> 공용 IP 121.139.108.3을 가진 게이트웨이에 12000 포트로 전달 (즉, 192.168.1.0 게이트웨이)
==> NAT 정보에 의해 내부에 전달해야 할 패킷의 대상이 192.168.50.2 / 포트 12000임을 알고,
==> 192.168.50.2로 전달하려고 하지만 라우팅 정보가 없으므로 다시 인터넷 밖으로 튕김.

자... 이 때문에 인터넷 통신이 안되는 것입니다.

그럼, 해결방법은? 당연히 ^^ 인터넷으로 나가는 게이트웨이(192.168.1.0)로 사용되는 라우터에 "192.168.50.0" 네트워크에 대한 라우팅 정보를 192.168.1.2라고 알려주어야 합니다.

이게 문제라면 문제겠지요?

만약, 여러분이 게이트웨이를 만질 수 있는 권한을 가진 사람이라면 지금 당장 접속해서 설정해 주면 되겠고... 그렇지 않다면 네트워크 관리자에게 부탁을 해야 합니다.

여기서는, ^^ 당연히 제가 만질 수 있는 권한이 있긴 하지만 아쉽게도 시스코 라우터같은 대단한 네트워크 장비는 아니고 그저 우리집에서 사용하고 있는 "ipTime N3004" 무선 액세스 포인트가 실험 대상입니다.

그래서, 다음과 같이 설정 가능합니다.

router_plus_host_pc_1.png

이렇게 호스트 PC의 물리 NIC에서 바라보고 있는 "Default Gateway" 장비 수준에서 라우팅 정보를 지정하게 되면 다른 PC들을 일일이 돌아다니면서 "route add..." 명령어를 내려줄 필요도 없고 인터넷까지 자연스럽게 연결된다는 장점이 있습니다.




팁 성격으로 한 가지 더 살펴볼까요?

그렇다면 A-VM(192.168.50.2)를 웹 서버로 한 경우, 인터넷에 어떻게 노출시켜 줄 수 있을까요? 그렇죠... 게이트웨이 측에서 포트 포워딩 같은 기능을 제공해 주면 됩니다. "ipTime N3004 의 경우에는 다음과 같이 지정해 줄 수 있습니다.

router_plus_host_pc_2.png

즉, Internal 네트워크에 묶인 VM으로의 포트 포워딩도 아주 잘 동작합니다. ^^

[정리: 가능한 접근 방식]

  • VM <-> VM
  • VM <-> HOST
  • VM <-> 같은 Bridge의 다른 어탭터들이 참여하고 있는 네트워크의 PC
  • VM <-> 인터넷
  • VM <-> HOST가 참여하고 있는 네트워크의 다른 PC





[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/19/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13564정성태2/22/20241934Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20241959디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20241986오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20242067닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20242104디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242946오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242187닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241923Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241979Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242129닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241863VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241948닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241899닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242094닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242209Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242511개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242339개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242107개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241970Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241874닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241894오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241919Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241920오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241978VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242105Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242372개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...