호스트 VPN인가 Genymotion 내부 클라이언트인가: 터널의 주인을 정하십시오

데스크톱 VPN은 Genymotion에 두 곳에서 영향을 주며, 한쪽을 고쳐도 다른 쪽에 대해서는 아무것도 증명하지 못합니다. 첫째는 데스크톱 앱이 가상 장치를 제어하는 데 쓰는 연결이고, 둘째는 가상 Android 앱이 사설 서비스로 가는 경로입니다. 어댑터를 건드리기 전에 둘 중 실제로 무엇을 바꾸는지 정하고, 그다음 Genymotion Desktop 버전과 호스트 운영체제, 하이퍼바이저를 기록하십시오(VirtualBox의 호스트 전용 어댑터용으로 쓰인 안내는 QEMU 장치나 클라우드에서 호스팅되는 세션에는 그대로 적용되지 않습니다).

한 머신 위의 두 경로

제어 경로는 Genymotion 데스크톱 앱에서 가상 장치로 이어지며, 흔히 호스트 전용 네트워크를 지납니다. 앱 경로는 Android 내부에서 앱이 대화하는 대상 쪽으로 나갑니다. 호스트 VPN은 둘째를 실어 나르면서 첫째를 끊을 수 있고, 그래서 데스크톱에서 브라우저가 열린다는 사실은 거의 아무것도 증명하지 못합니다. 하나의 터널이 두 경로를 모두 맡거나 하나만 맡을 수 있으며, 그 배치는 우연이 아니라 결정입니다.

어느 경로를 진단하는지 적어 두십시오. 이 분야에서 낭비되는 시간의 대부분은 장치가 아예 뜨지 않았는데 사설 앱의 DNS를 바꾸거나, 앱이 그저 잘못된 리졸버를 썼는데 호스트 VPN을 느슨하게 푸는 데서 나옵니다.

제어 연결을 살려 두십시오

Genymotion 자체의 Desktop 지원 노트는 VirtualBox 사례를 기록합니다: 호스트 VPN이 올라오면 Desktop은 가상 장치를 더 이상 보지 못하며, 중요한 예외는 VirtualBox 네트워크 관리자에 나열된 실제 호스트 전용 어댑터입니다. 범위를 짐작하는 대신 그 어댑터를 나열하십시오:

VBoxManage list hostonlyifs

문서에 인쇄된 기본 범위는 모든 머신에서 사설 네트워크를 통째로 우회할 구실이 아닙니다. 사용 중인 어댑터를 덮는 가장 작은 예외를 추가하고 VPN 관리자의 승인을 받으십시오: 관리형 클라이언트는 로컬 네트워크를 일부러 막을 수 있기 때문입니다. 예외는 어댑터 이름과 승인 날짜와 함께 적어 두십시오. 반년 뒤에는 그 메모만이 규칙이 왜 존재하는지 설명합니다.

같은 노트는 QEMU 조합이 VPN과 함께 시험되지 않았다고 말합니다. 이를 호환성 한계로 다루고, 브리지 네트워크로 바꾸면 고쳐진다는 암시로 다루지 마십시오(어댑터를 바꾸면 실패의 모양이 달라질 뿐, 시험되지 않은 조합이 해결되지는 않습니다).

선택지 하나: 호스트가 트래픽을 나르게 하기

이 선택에서는 게스트의 패킷이 VPN이 허용하고 암호화하는 인터페이스에 도달해야 합니다. 이는 상태등이 아니라 라우팅의 문제입니다: 게스트의 패킷은 VPN이 암호화할 인터페이스에 도달해야 하고, 응답은 돌아올 길을 찾아야 합니다.

호스트의 브라우저는 호스트의 경로를 증명할 뿐, 가상 장치 출처가 받아들여지는지에 대해서는 아무것도 말하지 않습니다. 일부 VPN 클라이언트는 전달되거나 변환된 트래픽을 로컬에서 생성된 트래픽과 다르게 취급하므로, 터널이 동작한다고 결론 내리기 전에 Android 내부에서 시험하십시오. Android의 리졸버도 호스트의 리졸버가 아닙니다. 이름이 데스크톱에서는 풀리고 앱에서는 실패한다면, VPN 프로파일을 건드리기 전에 게스트의 리졸버 설정을 읽으십시오.

선택지 둘: Android 내부에서 지원되는 클라이언트 실행

여기서 게스트는 자체 프로파일과 자격 증명, 경로, 리졸버 정책을 가집니다. 일반적인 Android VPN 인터페이스는 루트 권한이 필요 없으므로 표준 클라이언트가 가상 장치 내부에 설치되어 연결됩니다. 사람들이 건너뛰는 부분이 승인입니다. 조직이 그 클라이언트와 그 가상 장치 환경을 허용해야 하며, 깨끗하게 가져왔다고 해서 장치 등록이나 상태 점검이 저절로 충족되지는 않습니다. 그 위에 작업 흐름을 세우기 전에 물어보십시오.

두 선택지는 겹칠 수도 있습니다: Android 내부의 터널이 이미 호스트에서 돌고 있는 터널을 통해 자기 서버에 닿을 수 있습니다. 그런 배치에는 도달 가능한 종단점과 실제로 허용한 포워딩이 필요하며, 우연히 함께 켜진 초록불 두 개로는 부족합니다.

앱에서 확인하고 배치를 기록하십시오

모든 시험에 같은 Android 앱을 쓰고 무엇을 보고하는지 읽으십시오: 주소가 응답하는지, 사설 이름이 풀리는지, 앱이 무엇을 돌려주는지입니다. 세 가지 관찰이 라우팅 실패와 리졸버 실패, 정책 거부를 갈라 줍니다.

장치가 뜨지 않거나 Desktop이 장치를 잃으면, DNS 장애가 아니라 제어 경로 장애로 다루십시오. 그 증상은 첫째 경로에 속하고, 고칠 곳은 Android 내부가 아니라 호스트입니다. 마지막으로 네 가지 사실을 기록하십시오: Genymotion Desktop 버전, 하이퍼바이저, 어느 쪽이 터널을 소유하는지, 그리고 추가했다면 정확한 호스트 전용 예외입니다. 네트워크 소유자가 지지하는 문서화된 배치를 고르고, 사설 서비스가 그에 의존할 때 기업 VPN을 끄거나 상태 점검을 약화하는 일을 중립적인 문제 해결로 다루지 마십시오.