WSL 2에서 호스팅 중인 TCP 서버를 외부에서 접근하는 방법
예전에 아래의 글을 통해,
WSL 2의 네트워크 통신 방법
; https://www.sysnet.pe.kr/2/0/12347
netsh 명령어를 이용하면 외부에서 WSL을 호스팅하는 운영체제를 경유해 WSL 인스턴스의 TCP 서버를 접속할 수 있다고 했습니다.
가령, WSL에서 15000번 포트로 열고 있으면 다음의 명령어를 윈도우 운영체제 측에서 실행해 주면,
// WSL 측의 IP 주소가 172.18.178.192라고 가정
netsh interface portproxy add v4tov4 listenport=15000 listenaddress=0.0.0.0 connectport=15000 connectaddress=172.18.178.192
// 삭제는 이렇게.
netsh interface portproxy delete v4tov4 listenport=15000 listenaddress=0.0.0.0
외부에서 해당 서비스로, 가령 윈도우 측의 IP 주소가 192.168.100.50이라면 다음과 같이 테스트할 수 있습니다.
// WSL 측에서 HTTP 서비스를 열고 있다는 가정으로,
curl http://192.168.100.50:15000
이때 애매한 것이 WSL 인스턴스의 IP 주소인데요, 이것은 hostname의 "-I"으로 쉽게 구할 수 있습니다.
// WSL 2에서 "-i" 옵션은 127.0.1.1을 반환하고,
C:\temp> wsl hostname -i
127.0.1.1
// "-I" 옵션은 WSL 2 인스턴스의 IP 주소를 반환
C:\temp> wsl hostname -I
172.18.178.192
참고로,
WSL 2 인스턴스들은 네트워크를 공유합니다. 예를 들어 Ubuntu 20.04와 Ubuntu 18.04를 설치해도 2개 모두 IP가 같으므로 "wsl hostname -I" 명령어로 모두 해결이 됩니다.
그런데 위에서 살짝 귀찮은 점이 있다면 WSL 측의 IP 주소인 172.18.178.192를 매번 구해서 설정하는 것이 귀찮다는 점입니다. 그런데... 최근에 쓴 글에서,
WSL 2의 네트워크 통신 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/13256
WSL 2의 경우 Any(0.0.0.0) 주소로 열어둔 소켓이 호스트 측에서는 127.0.0.1로 바인딩된다고 했습니다. 그렇다면, 굳이 WSL의 내부 IP 주소를 쓸 필요 없이 connectaddress로 127.0.0.1을 사용해도 될 것입니다.
netsh interface portproxy add v4tov4 listenport=15000 listenaddress=0.0.0.0 connectport=15000 connectaddress=127.0.0.1
물론, 테스트해 보면 잘 동작하는 것을 확인할 수 있습니다.
그렇긴 한데, 다소 귀찮은 이유로 인해 127.0.0.1로 바인딩을 하지 않는 것이 좋습니다. 이유는 알 수 없지만, 저렇게 netsh로 먼저 portproxy를 설정한 후 WSL 2의 TCP 서버를 0.0.0.0으로 바인딩하면 윈도우 호스트 측에 "127.0.0.1"로 바인딩 연결이 안 됩니다.
// netsh/portproxy 실행 후 WSL 2의 TCP 서버를 실행한 경우
c:\temp> netstat -ano | findstr 15000
TCP 0.0.0.0:15000 0.0.0.0:0 LISTENING 31200
즉, 반드시 WSL 2에서 TCP 서버를 0.0.0.0으로 시작한 후, netsh/portproxy를 실행해야만 정상적으로 WSL 2 TCP 서버의 소켓이 윈도우 호스트 측으로 연결됩니다.
// WSL 2의 TCP 서버를 실행 후 netsh/portproxy 실행한 경우
c:\temp> netstat -ano | findstr 15000
TCP 0.0.0.0:15000 0.0.0.0:0 LISTENING 31200
TCP 127.0.0.1:15000 0.0.0.0:0 LISTENING 39500
게다가 전자의 경우처럼 설정하면 심각한 문제가 하나 발생합니다. 즉, "0.0.0.0:15000"으로만 TCP 바인딩이 되어 있는 상태이기 때문에, netsh/portproxy로 127.0.0.1로 포트 포워딩이 재귀적으로 적용돼 무수한 FIN_WAIT_2, CLOSE_WAIT 소켓이 생성되는 문제가 발생합니다. 즉, 외부에서 "curl
http://192.168.100.50:15000"으로 연결하면, "0.0.0.0:15000"으로 대기하던 소켓이 연결을 받게 되고, 이어서 "127.0.0.1:15000"으로 포트포워딩을 하면서 다시 "0.0.0.0:15000"으로 연결이 됩니다. (이후 무한 반복으로 소켓 포트 고갈)
따라서, 127.0.0.1을 사용하는 경우 실행 순서를 반드시 지켜줘야 합니다.
"
WSL 2의 네트워크 통신 방법"의 덧글에서 UDP에 대한 portproxy도 가능한지 물었는데요, netsh/portproxy 명령을 내린 후 netstat로 상황을 보면,
c:\temp> netsh interface portproxy add v4tov4 listenport=15000 listenaddress=0.0.0.0 connectport=15000 connectaddress=172.18.178.192
c:\temp> netsh interface portproxy show v4tov4
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
0.0.0.0 15000 172.18.178.192 15000
c:\temp> netstat -ano | findstr 15000
TCP 0.0.0.0:15000 0.0.0.0:0 LISTENING 5276
TCP 소켓으로만 바인딩된 것을 볼 수 있습니다. 즉, UDP로의 portproxy는 지원하지 않습니다. 아쉽게도 netsh 명령어 중에 udp에 대한 포트포워딩 기능은 없다고 하며,
socat 등의 도구를 이용하는 우회 방법들을 사용해야 한다고!
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]