Wsl2 와 Hyver V 사이에 무엇이 있길래, 호스트와 VM간 통신이 바로 안될까?

Summary WSL2는 Hyper-V 기반의 가상화 계층에서 리눅스 커널을 실행하며, 호스트와 인스턴스가 별도의 서브넷을 구성하여 네트워크 통신에 제약이 있습니다. NAT 모드의 내부 가상 스위치로 인해 인스턴스는 동적으로 할당된 프라이빗 IP를 사용하며, 외부에서의 접속은 포트 포워딩 설정이 필요합니다. 또한, Hyper-V의 가상 스위치가 네트워크 구성을 관리하여 게스트 OS의 IP 변경이 통신에 영향을 미칠 수 있습니다.

[주제 1: WSL2의 아키텍처적 특성과 가상화 계층의 도입]

WSL2는 리눅스 커널의 시스템 콜을 윈도우 API로 변환하던 WSL1의 방식에서 벗어나, Hyper-V 기술을 기반으로 한 가상화 계층 위에서 실제 리눅스 커널을 구동하는 구조를 채택하였습니다. 이로 인해 리눅스 인스턴스는 호스트 OS인 윈도우의 커널과 분리되어 별도의 하드웨어 리소스를 할당받는 가상 머신(VM)으로 존재하게 됩니다. 이러한 구조적 변화는 파일 시스템 성능과 시스템 콜 호환성을 대폭 향상시켰으나, 네트워크 측면에서는 호스트와 인스턴스가 논리적으로 분리된 별개의 서브넷을 구성하게 되는 결과를 초래하였습니다.

[주제 2: NAT 기반 가상 스위치 및 IP 주소 할당 메커니즘]

WSL2 및 Hyper-V의 기본 네트워크 인터페이스는 NAT(Network Address Translation) 모드로 작동하는 내부 가상 스위치(Internal Virtual Switch)에 연결됩니다. 인스턴스가 실행될 때마다 Hyper-V는 호스트의 내부 가상 어댑터(vEthernet)와 통신할 수 있는 172.x.x.x 대역의 프라이빗 IP를 동적으로 할당합니다.

이 과정에서 호스트 OS는 가상 네트워크의 게이트웨이 및 DNS 서버 역할을 수행하게 되며, 인스턴스 내부에서 외부망으로 나가는 아웃바운드 트래픽은 NAT를 통해 정상적으로 처리되지만, 외부망에서 인스턴스로 들어오는 인바운드 트래픽은 호스트의 IP 주소와 인스턴스의 내부 IP 주소 간의 대응 관계가 정의되지 않아 기본적으로 차단됩니다.

[주제 3: 외부 접속 제약 및 포트 프록시(Port Proxy)의 필요성]

윈도우 호스트가 외부로부터 수신한 패킷을 특정 WSL2 인스턴스로 전달하기 위해서는 명시적인 포트 포워딩 설정이 필수적입니다. WSL2는 기본적으로 호스트의 포트를 자동으로 점유하거나 리스닝하지 않기 때문에, netsh interface portproxy 명령어를 사용하여 호스트의 특정 IP와 포트를 인스턴스의 IP와 포트로 1:1 매핑하는 작업이 선행되어야 합니다.

또한, 윈도우는 사용자의 편의를 위해 localhost 요청을 WSL2 IP로 자동 전달하는 기능을 제공하지만, 네트워크 인터페이스의 바인딩 설정(예: 0.0.0.0이 아닌 127.0.0.1로 서버 실행)이나 윈도우 방화벽 규칙에 의해 이 통신이 빈번하게 차단되는 특성을 보입니다.

[주제 4: Hyper-V 가상 스위치의 제어권과 게스트 OS 설정 무효화 사유]

가상 머신 내부에서 사용자가 직접 IP 주소나 서브넷 마스크를 변경하더라도 통신이 불가하거나 초기화되는 이유는 네트워크 구성의 주권이 게이트웨이 역할을 하는 호스트의 가상 스위치 관리자에게 있기 때문입니다. Hyper-V의 NAT 환경에서는 가상 스위치가 DHCP 서버 역할을 수행하며, 인스턴스의 MAC 주소에 기반하여 IP를 강제 할당합니다.

만약 게스트 OS 내부에서 가상 스위치의 서브넷 범위(예: 172.x.x.x)를 벗어나는 IP를 정적으로 설정할 경우, 상위 계층인 가상 스위치는 이를 유효하지 않은 패킷으로 간주하여 라우팅을 거부합니다. 따라서 게스트 내부가 아닌 호스트 레벨에서 Static IP를 예약하거나, 외부 물리망과 직접 브리지되는 External Switch로 설정을 변경해야만 영구적인 네트워크 환경 변동이 적용됩니다.