ホスト側の 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 を切ることや態勢検査を弱めることを中立な切り分けとして扱わないでください。