VPN이 연결될 때 WSL이 작업 호스트 이름을 잃는 이유는 무엇인가요?

Windows는 내부 호스트를 아무 불평 없이 확인하지만, 같은 이름이 터널이 올라오는 순간 WSL 안에서 실패합니다. 흔한 해결책은 배포판에 공용 리졸버를 적어 넣는 것인데, 그러면 일반 브라우징은 되살아나지만 작업 호스트 이름은 확인할 수 없게 됩니다. 그것은 하나의 실패를 다른 실패와 맞바꾸고, 실제로 깨진 계층을 가립니다. 리졸버 줄을 추가하거나 제거하기 전에 세 계층 중 어느 것이 실패하는지 먼저 밝혀내세요.

먼저 라우팅 실패를 배제하세요

양쪽에서 비슷하게 생긴 두 이름이 아니라 완전히 같은 정규화된 이름을 질의하세요. 같은 문자열에 대해 Windows에서는 성공하고 WSL에서는 실패하는 것은 두 개의 확인 경로가 있다는 서명이며, 이 패턴을 이렇게 깔끔하게 만들어 내는 것은 거의 없습니다. WSL이 알려진 숫자 주소로도 서비스에 도달하지 못한다면 라우팅이나 필터링 문제도 함께 존재합니다. 그 경우 DNS 작업으로는 드러나지 않고, 오후는 잘못된 계층으로 갑니다.

세 가지 증상이 이런 경우의 대부분을 덮으며, 각각 다른 곳을 가리킵니다. 설정 파일을 열기 전에 해당하는 행을 읽어 보세요:

가운데 행은, 그것을 깨뜨린 변경이 몇 주 전에 이루어졌고 그때는 성공해 보였기 때문에 사람들이 잘못 읽는 행입니다. 세 번째 행은, 확인되는 이름이 네트워크가 건강하다는 증거처럼 느껴지기 때문에 사람들이 잘못 진단하는 행입니다. 두 행 모두 아래의 다른 절로 여러분을 보냅니다.

DNS 터널링에는 최소 버전 하한이 있습니다

Microsoft는 가상화 채널을 통해 DNS 요청을 Windows 리졸버로 터널링하는 WSL 네트워킹 모드를 문서화합니다. 지원되는 Windows 11 빌드에서는 기본으로 활성화되어 있으며, 그래서 같은 기업 네트워크의 두 머신이 다르게 동작합니다. 변수는 빌드 번호이지 기업 정책이 아닙니다.

WSL 네트워킹 가이드는 그 모드와 이를 지원하는 버전을 설명합니다. 이 기능이 중요한 이유는 기업 DNS 정책이 보통 Windows 리졸버에 살고, Windows 경로를 물려받는 배포판은 정책도 함께 물려받기 때문입니다. 공용 리졸버에 질의하는 배포판은 자기 설정이 아무리 깔끔해도 사설 이름으로 가는 경로가 없습니다. 그 메커니즘이 증상 전체를 설명하고, 공용 리졸버 우회책이 왜 실패하는지도 설명합니다.

무엇이든 편집하기 전에 빌드를 읽으세요. 더 새로운 설치에서 복사한 설정은 더 오래된 설치가 그것을 구현한다는 증거가 아닙니다. 두 머신의 차이는 거의 항상 정책이 아니라 버전이므로 변경 옆에 빌드 번호를 기록하세요.

오래된 재정의는 그것이 해결한 문제보다 오래 산다

오래된 요리법은 생성되는 리졸버 파일을 비활성화했고, 네임서버를 하드코딩했거나 파일을 불변 속성으로 잠갔습니다. 그런 변경은 그것을 촉발한 연결 문제가 사라진 뒤에도 오래 자리에 남아 있으며, 더 새로운 설정이 아무것도 하지 않는 것처럼 보이는 이유는 대개 이것입니다. 또한 로그인할 때마다 파일을 다시 쓰는 shell 프로필 형태로 배포판 재설치 후에도 살아남습니다. 마지막 것이 가장 찾기 어려운데, 모두가 확인하는 파일에서는 보이지 않기 때문입니다.

손으로 쓴 리졸버 파일, 그 위의 불변 속성, 그리고 그것을 다시 쓰는 시작 스크립트를 찾으세요. 잠긴 파일에 쓰기는 권한 문제처럼 읽히는 방식으로 실패하므로 편집하기 전에 불변 플래그를 확인하세요. 그곳의 스크립트가 여러분의 수정 후 몇 초 안에 옛 내용을 되돌리므로 그다음 shell 프로필을 확인하세요.

재정의를 제거하면 결과가 따르므로 무엇을 제거했고 왜 그랬는지 기록하세요. 다른 목적으로 정말 정적 리졸버가 필요한 배포판은 생성된 파일이 돌아오면 깨집니다.

두 파일, 두 가지 다른 역할

두 설정 파일은 다른 곳에 있고 다른 것을 제어하며, 둘을 혼동하면 잘못된 계층에 편집이 적용됩니다. Windows 쪽 파일은 가상 머신의 속성을 설정하고, 배포판 쪽 파일은 그 배포판이 자체 리졸버 설정을 어떻게 구성하는지 설정합니다. 어느 것도 다른 것을 재정의하지 않으므로 둘이 일치해야 합니다.

이 기능을 지원하는 설치에서 Windows 쪽 조각은 짧습니다. 그것이 그쪽의 변경 전부입니다:

[wsl2]
dnsTunneling=true

그 조각은 Windows 사용자 프로필에 들어가며 단일 배포판이 아니라 가상 머신에 적용됩니다. 터널링은 배포판이 리졸버 생성을 비활성화하지 않았을 것도 요구하므로, 배포판 쪽 파일은 그 동작을 그대로 두어야 합니다. 하나만 바꾸면 모드는 조용히 아무것도 하지 않으며, 이것이 이 수정이 깨진 것으로 보고되는 가장 흔한 방식입니다. 몇 주 간격으로 이루어진 두 편집은 아무도 귀속시킬 수 없는 두 편집이므로 같은 세션에서 두 파일을 모두 확인하세요.

다시 시작한 다음 양쪽에서 질의하세요

이 설정은 환경이 시작될 때 읽히므로, 실행 중인 배포판 안의 새 shell은 그것을 다시 불러오지 않습니다. 모든 배포판이 그것과 함께 멈추므로 shell을 다시 시작하는 대신 환경을 종료하고, 먼저 실행 중인 작업을 저장하세요. 이 하나의 누락만으로 변경이 효과가 없다는 보고의 대부분이 설명됩니다.

그런 다음 양쪽에서 같은 질문을 하세요. 출력은 배포판이 실제로 어느 리졸버로 끝났는지도 보여 줍니다:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

첫 번째 명령은 환경을 끝내고, 두 번째는 배포판이 지금 어느 리졸버를 쓰는지 보여 주며, 마지막 두 개는 같은 질문을 각 쪽에 던집니다. 설정의 상태가 아니라 답을 비교하세요. 두 파일이 모두 올바른 상태에서 깨끗하게 다시 시작한 뒤에도 실패하는 질의는 기업 리졸버 정책을 가리키며, 그 대화의 주인은 다른 사람입니다.