Hyper-V 호스트에 VPN 클라이언트를 설치하고 그곳에서 브라우저를 열면 출구 주소가 바뀌지만, 같은 페이지를 가상 머신 안에서 열면 예전 주소가 보이거나 아무것도 보이지 않을 수 있다. 흔한 결론은 가상 머신이 고장 났거나 분할 터널링을 켜야 한다는 것이다. 둘 다 따라 나오지 않는다. VPN 클라이언트는 머신의 속성이 아니라 경로의 집합이고 가상 어댑터이며 흔히 특정 인터페이스에 붙은 필터다. 게스트 트래픽이 그 장치를 만나는지는 게스트가 쓰는 가상 스위치에 달려 있다.

신화를 솔직히 말하면

가상 머신은 그 머신에서 도는 프로세스일 뿐이므로 호스트에 설치한 VPN이 가상 머신까지 포함해 머신 전체를 보호한다는 믿음이 있다. 안티바이러스와 호스트 방화벽이 보통 그렇게 행동하므로 편안한 믿음이다. 네트워크 경로는 그렇지 않다.

게스트의 프레임은 호스트가 라우팅하거나 필터링할 때만 호스트의 VPN 스택에 닿는다. 아래의 모든 사례가 그 변형이므로 이 문장을 메모지에 적어 두자.

세 가지 스위치 유형, 세 가지 경로

외부 스위치는 가상 어댑터를 물리 네트워크 카드에 묶고, 게스트는 자기 MAC 주소로 그 묶음을 통해 프레임을 보낸다. 게스트는 물리 네트워크에서 대등한 구성원이 되어 자체 DHCP 임대, 게이트웨이, DNS 서버를 갖는다. 호스트의 VPN 기본 경로는 호스트를 거쳐 라우팅되지 않고 브리지되기 때문에 호스트 스택에 머물며 그 프레임을 옮기지 않는다. Wi-Fi 어댑터 위의 외부 스위치가 나쁜 생각인 것도 같은 이유로, 대부분의 무선 드라이버가 두 번째 MAC 주소용 프레임을 나르지 않는다.

내부 스위치는 게스트를 호스트의 가상 어댑터에 연결한다. 그 자체로는 인터넷 출구가 없으며 호스트의 NAT 개체가 변환을 제공하는데, 자세한 내용은 Hyper-V NAT 가이드에 있다. 이제 게스트의 패킷이 실제로 호스트의 라우팅과 NAT 경로로 들어가므로 VPN 클라이언트의 경로와 필터가 다시 중요해진다. 가상 머신이 정말로 호스트 VPN을 따르는 구성이자 킬 스위치가 게스트를 완전히 끊을 수 있는 구성이다.

사설 스위치에는 호스트 어댑터도 업링크도 없다. 게스트는 서로만 대화하고 다른 무엇과도 대화하지 않으므로, 사설 스위치의 가상 머신에 인터넷이 없다면 원인은 빠진 라우터이고 VPN은 무관하다.

기본 스위치는 그 자체로 별도의 구성이다

Windows는 내부 스위치를 NAT 및 DNS 프록시와 결합한 기본 스위치를 제공한다. 서브넷은 호스트가 고르고 재부팅 후 바뀔 수 있으며, 직접 만드는 NAT 네트워크와 같은 개체가 아니다. 이것을 실험실 네트워크처럼 다시 만들면 NAT이 둘이 되고 게스트는 여전히 경로가 없는 결말에 이르기 쉽다.

가상 머신이 기본 스위치에 있다면 게스트가 받은 주소를 읽고 VPN 클라이언트를 건드리기 전에 호스트의 NAT 표와 비교한다. 게스트 게이트웨이와 NAT 접두사의 불일치는 어떤 클라이언트 설정보다 많은 장애를 설명한다.

질문을 끝내는 네 가지 사실

무엇이든 바꾸기 전에 스위치 유형과 업링크, 가상 머신에 연결된 어댑터, 게스트 자체의 주소·게이트웨이·DNS, 호스트의 NAT와 기본 경로 상태를 모은다. 읽기 전용 명령은 Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, 그리고 Get-NetRoute -DestinationPrefix 0.0.0.0/0이며, 게스트 안에서는 ipconfig /all가 나머지를 알려 준다.

그다음 게스트가 무엇을 해야 하는지 정한다. VPN 밖에 두어야 한다면 호스트 실행 파일을 제외해도 전달되는 가상 머신 트래픽은 제외되지 않으므로 바로 그 경로에 대한 공급자의 지원 예외를 받는다. VPN을 써야 한다면 호스트 브라우저의 시험으로 충분하다고 단정하지 말고 클라이언트가 가상 머신 트래픽을 어떻게 처리한다고 문서화했는지 확인한다.

게스트 안에서의 시험만이 의미 있는 증거다. 게스트에서 출구 주소를 확인하고 내부 이름을 확인한 뒤 VPN을 다시 연결해 반복한다. 호스트 브라우저의 결과는 그중 어느 것도 대신하지 못한다.

신화의 대가

사람들은 시험을 통과시키려고 킬 스위치를 끄고 정적 경로를 추가하며 스위치를 지웠다 다시 만든다. 모든 지름길은 고장 방식을 바꾸어, 게스트가 아무도 의도하지 않은 경로로 인터넷에 나가거나 외부 스위치가 물리 카드를 다시 묶을 때 호스트가 연결을 잃을 수 있다.

외부 스위치를 다시 묶으면 호스트 자체의 접근이 끊기므로 대역 외 경로를 열어 두고 아직 진단하는 동안 스위치를 지우지 않는다. 올바른 결과는 게스트가 어떻게 다시 연결되고 어떻게 실패하는지까지 포함한 의도한 경로이지, 한 번의 페이지 로드에서 나오는 녹색 체크가 아니다.

오래가는 답은 인벤터리의 가상 머신마다 한 줄, 어떤 스위치를 쓰고 어떤 구성 요소가 게이트웨이를 공급하는지다. 그것이 적혀 있으면 다음 VPN 변경은 오후 내내 추측하는 대신 한 번 찾아보는 일이 된다.

관련 글