Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 14개 있습니다.)
개발 환경 구성: 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. WSL 2 인스턴스와 호스트 측의 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

개발 환경 구성: 712. Windows - WSL 2의 네트워크 통신 방법 - 세 번째 이야기 (같은 IP를 공유하는 WSL 2 인스턴스)
; https://www.sysnet.pe.kr/2/0/13647

개발 환경 구성: 714. WSL 2 인스턴스와 호스트 측의 Hyper-V에 운영 중인 VM과 네트워크 연결을 하는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/13658




Windows - WSL 2의 네트워크 통신 방법 - 세 번째 이야기 (같은 IP를 공유하는 WSL 2 인스턴스)

(현재도 존재하고 있지만) 과거 WSL 1의 아키텍처는 Windows Subsystem for Linux라는 이름에 걸맞게 "Subsystem"에 불과합니다. 검색해 보니 적당한 그림이 나오는군요. ^^

[Overview of WSL 1 - 출처: Exploring the differences between WSL 1 and 2]
wsl_network_1.webp

반면, WSL 2는 Hyper-V의 기술 위에 경량화시킨 Managed VM으로 뜨는데요, 간단하게 말해서 그냥 로딩이 빠른 VM이라고 보시면 됩니다. 역시 이에 대한 아키텍처를 동일한 글에서 찾을 수 있습니다.

[Overview of WSL 2 - 출처: Exploring the differences between WSL 1 and 2]
wsl_network_2.webp

VM이다 보니, 당연히 완전한 유형의 리눅스 커널이 올라옵니다. 해당 커널은 마이크로소프트 측에서 기존 리눅스 커널을 WSL 기능을 위해 맞춤 변형한 것인데요, 이것도 공개 소스 코드로 운영하니 궁금하신 분은 살펴보시면 됩니다. (참고: https://github.com/microsoft/WSL2-Linux-Kernel)

WSL 2로의 이러한 변화에 Docker Desktop 관련 이야기를 하지 않을 수가 없습니다. Docker Desktop은 초기엔 윈도우 환경에서 linux container 서비스를 하기 위해 "DockerDesktopVM"이라는, Hyper-V에 별도의 리눅스 VM을 생성하고 거기서 컨테이너 서비스를 했습니다.

왜냐하면, 컨테이너 서비스를 위해서는 Linux Kernel의 폭넓은 기능이 필요했는데, WSL 1은 단순히 기존 윈도우 커널에 리눅스 호출에 대한 "translation layer"를 덧씌워 준 것이라서 linux container 서비스까지 제공할 수는 없었습니다.

그러던 것이, VM 유형의 "WSL 2"가 나오면서 Docker Desktop 측에서도 별도의 VM이 아닌, "WSL 2" VM 위에서 container 서비스를 할 수 있었던 것입니다.




그런데 "Overview of WSL 2" 그림을 보면 재미있는 특징이 하나 있습니다. 바로 VM이 하나라는 점입니다. 즉, WSL 2를 지원하는 다양한 "Linux distros"들은 결국 하나의 VM 위에서, 그것들 역시 Containerization 기술로 격리돼 돌아가는 것에 불과합니다.

확인을 위해 아무 배포판의 WSL 2 인스턴스를 띄우고 Linux 커널 버전을 확인해 보면,

# uname -r
5.15.146.1-microsoft-standard-WSL2

동일하게 저 커널 문자열이 출력되면서 배포판 버전만 다른 것을 확인할 수 있습니다.

// WSL 2 Kali Linux 배포판에서 실행

$ lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux Rolling
Release:        2024.2
Codename:       kali-rolling

// WSL 2 Ubuntu 배포판에서 실행

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

결국 하나의 VM에서 동작하는 것이기 때문에 Linux 배포판의 WSL 2 인스턴스는 같은 IP를 공유하게 됩니다.

그리고 해당 IP가 갖는 네트워크는 윈도우 호스트 측에서 "vEthernet (WSL)" 이름으로 불리는 네트워크 어댑터로 연결됩니다. 현재는 제어판에서 더 이상 "vEthernet (WSL)" 항목이 출력되지 않지만 그래도 없어진 것은 아닙니다. 실제로 ipconfig으로도 확인이 가능하고,

C:\temp> ipconfig

Windows IP Configuration

...[생략]...

Ethernet adapter vEthernet (WSL (Hyper-V firewall)):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::4817:b6e:4576:c2c3%62
   IPv4 Address. . . . . . . . . . . : 172.19.128.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

위의 어댑터가 참여하는 (이름이 비슷한) 가상 스위치를 PowerShell에서 Get-NetAdapterBinding 명령어로도 확인할 수 있습니다.

PS C:\WINDOWS\system32> Get-NetAdapterBinding -Name "vSwitch (WSL (Hyper-V firewall))" -IncludeHidden

Name                           DisplayName                                        ComponentID          Enabled
----                           -----------                                        -----------          -------
vSwitch (WSL (Hyper-V firew... Hyper-V Virtual Switch Extension Filter            vms_vsf              True
vSwitch (WSL (Hyper-V firew... Microsoft Windows Filtering Platform               ms_wfplwf_vswitch    False
vSwitch (WSL (Hyper-V firew... Hyper-V Virtual Switch Extension Protocol          vms_vsp              True

또한, 쉽게는 Hyper-V의 Virtual Switches 항목에 "WSL (Hyper-V firewall)" 이름으로 확인이 됩니다.




윈도우 호스트 측의 ipconfig 출력 정보를 보면, subnet masrk가 255.255.240.0으로 3번째의 240(1111 0000 비트)을 포함해 상위 20비트가 네트워크, 하위 12비트가 호스트 범위를 가집니다.

C:\Windows\System32> hnsdiag list networks
...[생략]...

Network : 790E58B4-7939-4434-9358-89AE7DDBE87E
    Name             : WSL (Hyper-V firewall)
    Type             : ICS
    Subnet Address   : 172.19.128.0/20
    Gateway          : 172.19.128.1

...[생략]...

// 또는, 레지스트리 경로를 이용해
// HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss
// NatGatewayIpAddress (REG_SZ) : 172.19.128.1
// NatNetwork (REG_SZ) : 172.19.128.0/20

따라서 212 == 0 ~ 4,095 범위의 호스트를 가질 수 있는 172.19.128.0 ~ 172.19.143.255 네트워크가 나옵니다. 일례로 WSL 2 인스턴스를 하나 띄워서 IP를 확인해 보면,

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.19.132.144  netmask 255.255.240.0  broadcast 172.19.143.255
        inet6 fe80::215:5dff:fe73:e10e  prefixlen 64  scopeid 0x20<link>
        ...[생략]...

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        ...[생략]...

$ ip route show
default via 172.19.128.1 dev eth0 proto kernel
172.19.128.0/20 dev eth0 proto kernel scope link src 172.19.132.144

동일한 netmask를 가지면서 IP가 "172.19.132.144"로 나오니 역시나 172.19.128.0 ~ 172.19.143.255 범위에 속하므로 호스트 측과 동일한 네트워크에 속합니다. 결국, "WSL (Hyper-V firewall)" 네트워크 구성으로 인해 윈도우 호스트 측과 WSL 간의 통신이 가능한 것입니다.

참고로, WSL 2 배포판마다 개별/공유 설정되는 것은 아래의 글에서 답변으로 볼 수 있습니다.

WSL2 two separate Centos distributions have same eth0 inet address
; https://superuser.com/questions/1715273/wsl2-two-separate-centos-distributions-have-same-eth0-inet-address

Each WSL2 instance has a separate:

* PID namespace
* Mount namespace
* IPC namespace
* UTS namespace
* WSLg System Distribution

However, they all share the following with the parent WSL2 VM (and thus each other):

* User namespace
* (the only one we really care about here) Network namespace
* Cgroup namespace
* Device tree (other than /dev/pts)
* CPU/Kernel/Memory/Swap (obviously)
* /init binary (but not process)

"network namespace"의 경우 윈도우와의 매끄러운 통합을 위해 "WSL (Hyper-V firewall)" 네트워크로 공유했겠지만 마찬가지로 분리하는 것도 가능합니다. 그 한 가지 대표적인 사례가 바로 "Docker desktop for Windows"가 설치하는 "docker-desktop" WSL 2 인스턴스인데요, 이것은 개별 "network namespace"로 분리돼 있습니다. (이에 관한 이야기는 다음에.)




개인적인 의견으로는, 마이크로소프트가 처음부터 WSL 2 방식으로 리눅스 서비스를 했다면 아마도 "vEthernet (WSL)" 네트워크에서의 localhost/127.0.0.1 통합과 같은 기이한, 어찌 보면 편리한 동작을 제공하지 않아도 문제가 없었을 거라고 봅니다. 즉, 개발자들은 자연스럽게, 결국 VM으로 구현된 것이니까 "localhost/127.0.0.1"에 대한 통합을 하지 않았어도 아무런 거부감 없이 네트워크 구조를 받아들였을 것입니다.

하지만, "Subsystem" 개념으로 윈도우에 통합하는 "WSL 1" 방식으로 인해 "localhost"에 대한 처리가 "WSL 2"로 바뀌면서까지 이어져야 했고, 그런 과정에서 너무 불필요하게 네트워크 구조가 복잡해진 것이 아닌가 싶습니다.




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 6/16/2024]

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

비밀번호

댓글 작성자
 



2024-08-26 09시29분
How to use the Microsoft Linux kernel v6 on Windows Subsystem for Linux version 2 (WSL2)
; https://learn.microsoft.com/en-us/community/content/wsl-user-msft-kernel-v6

참고로 현재 버전은 "uname -r"로 확인할 수 있는 문자열("5.15.153.1-microsoft-standard-WSL2")로 보아 5.15.153.1일 듯합니다.
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13880정성태2/5/2025235오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/2025291오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/2025599오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20251017닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20251138닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20251094스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20251122스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20251055디버깅 기술: 217. WinDbg - PCI 장치 열거
13872정성태1/23/20251036오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20251153Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20251217개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20251239개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20251177Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20251286오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20251292개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20251376오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20251327Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20251268Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20251208Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20251318Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20251245디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20251311디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
13858정성태1/8/20251382개발 환경 구성: 738. PowerShell - 원격 호출 시 "powershell.exe"가 아닌 "pwsh.exe" 환경으로 명령어를 실행하는 방법
13857정성태1/7/20251392C/C++: 187. Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경파일 다운로드1
13856정성태1/6/20251623디버깅 기술: 214. Windbg - syscall 단계까지의 Win32 API 호출 (예: Sleep)
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...