VPN 연결 후 WSL2의 DNS가 끊겼나요? 두 가지 원인

오래된 resolver 파일과 경쟁하는 경로 메트릭이 WSL2 안에서 같은 증상을 만듭니다. 양쪽을 모두 기록한 뒤 실제로 고장 난 쪽을 고치세요.

주소로 하는 ping은 배포판 안에서 동작하지만 패키지 설치와 git 가져오기는 동작하지 않으며, 장애는 터널이 올라온 직후 나타났습니다. 이름 해석만 멈췄다는 점은 연결성이 아니라 DNS를 가리킵니다. 여기서 가장 흔한 잘못된 첫 조치는 패키지를 다시 설치하는 것입니다. WSL2에는 정확히 그 증상을 만드는 독립적인 경로가 두 가지 있으며, 각각 다른 수리가 필요합니다.

배포판이 자체 resolver를 유지하는 이유

Windows의 DNS 클라이언트는 배포판 안에서 사용되지 않습니다. WSL2는 시작할 때 자체 resolver 파일을 만들며, Windows가 유틸리티 VM용 가상 스위치에 게시하는 stub 주소를 가리킵니다.

이 구조는 한 번 기록하고 재사용하므로 일반적인 네트워크 변경에 안정적입니다. 그러나 유틸리티 VM이 이미 시작된 뒤 터널 클라이언트가 호스트의 어댑터 목록을 다시 쓰면 이 구조는 더 이상 올바르지 않습니다.

배포판 안의 어떤 것도 그 변경을 감시하지 않으므로 파일은 더 이상 경로에 없을 수 있는 주소를 계속 가리킵니다. 다음 조회는 그러면 기다리거나 시간 초과되거나, 내부 영역을 들어본 적 없는 서버에서 답을 받습니다. 안쪽에서는 resolver가 그저 응답을 멈추고, 모든 이름이 한꺼번에 실패합니다.

먼저 양쪽에서 증거를 모으세요

무엇이든 바꾸기 전에 배포판이 보는 것, 그다음 Windows가 보는 것을 기록하세요. 두 시점을 함께 봐야 실패 유형이 구분됩니다.

배포판 안에서 resolver 파일, 라우팅 테이블, 내부 조회와 공개 조회를 하나씩 출력하세요:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Windows에서는 어댑터별 DNS 서버와 메트릭이 포함된 IPv4 테이블을 나열하세요. VPN 클라이언트는 보통 WSL2 서브넷에 대한 경로를 설치하며, 그 메트릭이 해당 트래픽이 터널로 나갈지 로컬에 남을지를 결정합니다.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

경로 메트릭인가 오래된 파일인가

첫 번째 고장은 오래된 파일입니다. resolver는 시작 시점의 어댑터 상태에 맞춰 작성되었고, 터널이 그 상태를 바꿨습니다. stub 주소는 이제 도달할 수 없거나, 내부 영역에 대해 아무것도 모르는 서버를 가리킬 수 있습니다.

두 번째는 라우팅 문제입니다. VPN이 WSL2 서브넷을 덮는 경로를 호스트 링크 경로보다 낮은 메트릭으로 추가하면, 유틸리티 VM으로 향한 패킷이 터널로 들어갑니다. 그러면 DNS뿐 아니라 모든 WSL2 서비스가 시간 초과됩니다.

구분하는 시험은 한 줄이면 됩니다. 공개 resolver 같은 숫자 주소가 이름이 실패하는 동안에도 ping에 응답한다면 경로는 온전하고 문제는 DNS입니다. 이것이 resolver 변경이 정당화되는 경우이며, 그렇지 않은 경우도 분명해집니다. 숫자 시험도 실패한다면 유틸리티 VM이 경로를 잃은 것이고 어떤 resolver 파일도 그것을 고치지 못합니다.

라우팅의 경우 터널 어댑터의 자동 메트릭을 없애고 WSL2 링크 경로보다 높은 숫자를 주세요:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

종료가 중요합니다. 메트릭을 바꾸어도 실행 중인 유틸리티 VM은 다시 작성되지 않으므로, 변경이 보이려면 배포판을 다시 만들어야 합니다.

파일을 의도적으로 넘겨받으세요

라우팅이 올바르고 내부 이름만 실패한다면 resolver가 원인이므로 생성기를 멈출 수 있습니다. 이것은 유지 비용이 따르는 의도적인 변경이며, 가볍게 적용할 임시방편이 아닙니다.

배포판 안에서 생성을 끄는 네트워크 섹션과 함께 /etc/wsl.conf 파일을 만들고, 그다음 resolver 파일을 직접 작성하되, 회사 서버를 먼저, 공개 대체를 그다음에 둡니다:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

순서가 중요합니다. 공개 resolver는 내부 이름에 답할 수 없고, 대체는 인터넷 조회에만 존재합니다. 파일이 당신의 것이 되면 아무것도 그것을 다시 생성하지 않으므로, 이전하는 회사 resolver는 직접 알아차려야 하는 장애가 됩니다.

이름을 확인하고, 그다음 패키지를 확인하세요

시스템 resolver로 내부 이름과 공개 이름을 하나씩 검증한 뒤 실패한 작업을 반복하세요. 패키지 관리자는 때때로 자체 resolver를 사용하므로, 동작하는 getent이 깨진 설치와 공존할 수 있습니다.

다시 쓰기를 자동화한다면 멱등하게 만들고, 터널이 없을 때는 빈 서버 목록을 쓰는 대신 이미 있는 파일을 유지합니다.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

배포판 안에서 내부 조회와 공개 조회가 모두 동작하는 것이 기록할 가치가 있는 결과입니다. 호스트의 초록 VPN 아이콘은 둘 다 증명하지 않습니다.

관련 글