호스트 VPN이 연결되면 Hyper-V 게스트가 DNS를 잃는다

게스트는 오늘 아침까지 정상이었습니다. 그런데 호스트가 Cisco AnyConnect를 켜자, 내부에서는 아무것도 바뀌지 않았는데도 VM이 DNS, 도메인 신뢰, 공유 폴더를 잃었습니다. 호스트 터널과 게스트 네트워크는 별개의 경로이며, 하나를 연결한다고 다른 하나가 움직이지 않습니다. 게스트 안쪽에서 바깥으로 작업하고, 무엇이든 바꾸기 전에 보이는 것을 적어 두십시오.

게스트가 여전히 볼 수 있는 것

VM에서 주소, 기본 게이트웨이, 리졸버를 호스트 연결 전에 한 번, 연결 후에 한 번 기록하십시오. 주소를 유지하고 이름 확인만 잃은 게스트는 리졸버 문제입니다. 경로가 한 번도 없었던 게스트는 경로 문제이며, 둘은 다른 작업을 요구합니다. 호스트에서는 둘을 구별할 수 없으므로 읽기는 안쪽에서 나와야 합니다.

그 세 가지 읽기를 두 번 취한 것이 기준선입니다. 이후의 모든 것은 그것과 비교해 측정합니다.

게스트가 사용하는 출구

Hyper-V는 두 명령으로 답합니다: Get-VMSwitch 는 스위치를 나열하고, Get-VMNetworkAdapter -VMName TestVM 는 게스트가 연결된 스위치를 보여 줍니다. Default Switch는 Windows가 관리하는 NAT 네트워크이고, 외부 스위치는 트래픽을 물리 어댑터로 넘기며, 내부 스위치는 누군가 NAT나 라우터를 추가할 때까지 아무것도 나르지 않습니다. VirtualBox도 같은 세 가지 개념을 NAT, NAT Network, bridged로 제시합니다.

모드가 호스트 터널이 과연 중요할 수 있는지를 결정합니다. NAT 게스트는 WinNAT가 변환한 뒤 호스트 스택이 전달하므로 호스트 경로 테이블을 따르며, 전체 터널 클라이언트에서는 그 트래픽이 VPN 어댑터로 들어가는 트래픽이며, 클라이언트가 로컬 서브넷을 차단하면 버려집니다. 외부 스위치에 브리지된 게스트는 프레임이 물리 NIC에서 직접 나가므로 호스트 라우팅에 전혀 도달하지 않으며, 터널과 클라이언트의 로컬 LAN 정책을 모두 우회합니다.

호스트 터널을 Hyper-V와 공유하기

게스트에 터널이 필요하고 자체 클라이언트를 실행할 수 없다면 Windows가 VPN 연결을 공유할 수 있습니다. VPN 어댑터의 속성을 열고 공유로 이동한 뒤 다른 네트워크 사용자가 이를 통해 연결하도록 허용하십시오. 홈 네트워킹 연결을 Hyper-V 어댑터로 지정한 다음, vEthernet (Default Switch)게스트 안쪽에서 새 요청을 시험하십시오.

이 구성은 실제로 그렇게 동작하므로 실험실용 해결책으로 취급하십시오. 연결 해제, 재연결, 호스트 재부팅 후에 다시 적용해야 합니다. 일부 Windows 11 빌드에서는 어댑터가 드롭다운에 아예 없고, 그때는 이 경로가 닫힙니다.

Hyper-V 기능을 다시 설치하면 고집 센 게스트 몇 개가 살아났습니다. 그것은 마지막으로 미루고 먼저 게스트 상태를 기록하십시오.

서브넷이 필터링될 때의 포트 전달

게스트의 NAT 서브넷을 필터링하는 호스트 VPN은 이름 확인이 아니라 직접 접근을 깨뜨립니다. VM은 실행 중인데도 ssh [email protected] 멈추고, 하이퍼바이저 변환은 여전히 동작합니다. 작업에 필요한 포트를 전달하고 대신 호스트 주소로 연결하십시오. 아래 Vagrantfile 줄은 SSH와 HTTPS 서비스 하나를 다루며, 둘 다 다시 불러오기 전에 넣습니다.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

이름 확인은 별개의 결정이며 그 자체의 수정이 필요합니다. 해당 NAT 어댑터에 대해 호스트 리졸버 기능을 켜십시오, 또는 게스트 안의 내부 DNS 서버를 직접 구성하십시오. 게스트를 공용 리졸버로 지정하면 브라우징은 되지만 모든 내부 이름이 깨지며, 성공처럼 보이기 때문에 장애보다 나쁩니다. 내부 리졸버만 아는 이름으로 시험하십시오.

제대로 되었는지 알려 주는 확인

이 변경 중 하나를 한 뒤에는 호스트 VPN이 연결된 상태에서, 그 전이 아니라 게스트 안쪽에서 새 요청을 실행하십시오. 둘 중 하나만 견디는 수정은 수정이 아니므로 재연결 후와 재부팅 후에 공유를 다시 확인하십시오. 게스트 리졸버 목록이 트래픽이 실제로 쓰는 네트워크와 일치하는지 확인하십시오. 게스트에서 시험하는 것은 아무것도 증명하지 않으므로 호스트 주소에서 포트 전달을 시험하십시오. 게스트 안쪽에서 두 가지 PowerShell 확인이 리졸버와 전달된 포트를 다룹니다:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

스위치나 드라이버 변경은 되돌리는 단계와 함께 기록하십시오. Microsoft의 Hyper-V NAT 가이드 는 Default Switch가 실제로 무엇인지 설명하며, 그것과 충돌하는 두 번째 NAT 네트워크를 만들기 전에 읽을 가치가 있습니다.