VPN をホストで動かすか VM 内で動かすか：判断の手引き

トンネルの所有者が何が何を覆うかを決めます。ホスト側かゲスト側の配置を選び、ゲスト内のルート・DNS・出口の検査で確認します。

ゲスト内にトンネルを構築することとホスト側に構築することは、どちらもブラウザが報告するアドレスを変えますが、似ているのはそこまでです。ゲストが所有するトンネルは、鍵・既定ルート・リゾルバをゲストのカーネル内に保ち、ホストは暗号化されたパケットを一つの遠隔アドレスへ転送します。ホストが所有するトンネルはその裏返しで、ホストのクライアントがセッションを保持してルートとポリシーを適用し、ゲストは出てくるものを受け取るだけです。所有者を間違えると、その後の症状はすべて間違ったマシンへ導きます。二つのコマンドで約一分で決着がつき、この手引きの残りはその答えをどう使うかです。

クライアントに触れる前に所有者を決める

規則が扱うのは暗号文がどこで作られるかであり、どのマシンが VPN アイコンを表示するかではありません。ゲストが作るなら、ゲストには VPN サーバーへの有効なルートが必要で、ホストからは何も要りません。ホストが作るなら、ホストのクライアントがローカル通信に課すポリシーがあっても、ゲストはホスト経由の経路を生き延びさせる必要があります。

通常は 三つの質問で配置が決まります。ゲストの通信はホスト上の企業クライアントを越える必要がありますか。それならトンネルはゲスト内です。複数のゲストが一つの資格情報と一つの出口アドレスを共有しますか。それならホスト側で、転送を意図的に構成します。ゲストの通信はホストの VPN から完全に外れるべきですか。それならゲスト内のトンネルだけが、構造上それを実現します。

答えを VM 名の横に 一行で書き留めます：guest-owned か host-owned か。六台のラボでは、このメモが以下のどの手順よりも時間を節約します。ログインしているマシンに存在しないトンネルを調査しなくて済むからです。

WSL1 と WSL2 は正反対の事例

WSL1 は仮想マシンではないので、配置の問いはほぼ消えます。Linux のバイナリは変換層を通じて Windows のネットワークスタック上で動き、Linux の VPN クライアントには設定すべき独立したインターフェースがありません。機能するのは Windows 側のトンネルで、ディストリビューションは何も所有せずに結果だけを使います。

WSL2 は逆です。Hyper-V 仮想スイッチの背後にある軽量なユーティリティ VM で本物のカーネルを動かし、そのアドレス空間はホスト側アダプターを通じて NAT されます。そのためディストリビューション内の Linux クライアントは物理 Linux 機と同じように振る舞います。つまり tun0 または wg0 を作り、独自のルートを入れ、動作します。障害はホスト側にあります。Windows の VPN クライアントがローカルネットワーク上の通信を遮断するポリシーで接続すると、WSL2 のサブネットを信頼できないローカルネットワークとみなし、NAT 経路を切ります。するとディストリビューションは DNS と外向きのアクセスを失いますが、トンネル自体は健全なままです：wg show はハンドシェイクを報告し、ip route は正しく見え、curl は固まります。

どの修正を使えるかは Windows のビルド次第です。古い方法はホストのクライアントの WSL サブネット向け例外で、クライアントのローカルネットワーク設定か分割トンネル設定の下に追加します。新しい方法は、対応する Windows 11 ビルドでのミラー型ネットワークです。%UserProfile%\.wslconfig の [wsl2] セクションに networkingMode=mirrored を置き、wsl --shutdown を実行すると、ディストリビューションはプライベート NAT サブネットではなくホストのインターフェースを共有します。ミラー型は localhost と受信ポートの挙動も変えるので、切り替えではなく移行として扱ってください。

NAT、ブリッジ、そしてホストから何が見えるか

NAT の下では、ゲストのトンネルパケットは VPN サーバーの公開アドレス宛に送られ、暗号化された UDP または TCP としてホストのアダプターから出ていきます。ホストが見るのは 一つのフローとそのバイト数だけで、内部の宛先は分かりません。ブリッジアダプターの下では、ゲストは物理 LAN 上で独自のレイヤー 2 の身元を持ち、独自の DHCP リースを取得し、MAC ベースのポリシーには 二台目のデバイスとして映ります。どちらのモードでもホストはトンネルのペイロードを読めません。ブリッジされたゲストは、周囲のネットワークからはるかに見えやすいだけです。

分離には下限もあります。ゲストは自分のメモリを所有するマシンからは隠れられず、ホストを支配する者はゲストの RAM から鍵を読めます。ゲスト内のトンネルが与えるのはルーティングの境界とマルウェアの境界であり、ノート PC を手にしている人物からの保護ではありません。文書化されたアダプターモードは選ぶ間だけ開いておくとよいでしょう。モードはホストから見えるものと LAN から見えるものの両方を変えるからです。

手引き：配置し、構成し、証明する

新しいゲストのシェルでこの四つの検査を順に実行し、書き留めた所有者と食い違う最初の検査で止めます。

  1. ip route get 1.1.1.1 が tun0 か wg0 を返せばゲスト所有、プライベートな次ホップ付きの eth0 を返せばホスト所有です。
  2. resolvectl query example.com、またはゲストがリゾルバサービスを動かしていない場所では /etc/resolv.conf を読みます。通信は運ぶが DNS を運ばないトンネルは、最もよくある半端な構成状態です。
  3. 出口を比べます：ゲストで curl -4 -s https://ifconfig.me、ホストで curl.exe -4 -s https://ifconfig.me。アドレスが違えばゲストがトンネルを所有しており、VPN 上のホストに対してゲストが自宅の ISP を見せているなら、何も引き継がれていない事例です。
  4. 両方を -6 で繰り返します。v4 だけのトンネルは、クライアントが遮断もしくはルーティングしない限り v6 を漏らします。多くのクライアントは既定で v6 を物理インターフェースに残します。

複数のゲストが 一つのトンネルを共有するホストゲートウェイ構成では、ホストが転送と変換を行う必要があります。Linux ホストでは 三つの部品になり、どれかが欠けるとゲストは黙って通常のルートへ戻ります：

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

WireGuard 側では、ホストのピアの AllowedIPs にゲストのサブネットを含める必要があります。たとえば 192.168.122.0/24 です。含めないと戻りのパケットが届かず、設定はファイアウォールの問題のように見えます。Windows ホストはインターネット接続の共有か Hyper-V スイッチ上の NAT 規則で同じ結果を得ますが、同じ戻り経路の検査が必要です。

配置がまだ固まっていない場合、この表がよくある構成を網羅します：

SituationOwnerCheck first
One VM, host also on a corporate VPNGuestDoes the host client block local networks?
Six lab VMs, one exit addressHost plus forwardingip_forward, NAT rule, server AllowedIPs
Malware or research VMGuest, NATSnapshot age and resolver state
Bridged VM on an office LANGuestDHCP lease and port security

二つのトンネル、二つのゲスト、そしてその間の衝突

同時に二つの出口が必要なとき、持ちこたえるのはゲストごとに 一つのトンネルという形です。各 VM は自分の既定ルートとリゾルバを保ち、ホストは通常のネットワークに留まり、二つのトンネルが同じルーティングテーブルを争うことはありません。二つのゲストをブリッジしてもルートは統合されません。仮想ネットワークは経路を提供するだけで、このローカル通信がトンネルを迂回してよいと各クライアントに伝える必要は残ります。

ホストのトンネルとゲストのトンネルを併用するのは正当で、意図的な入れ子がまさに望みどおりのこともあります。ゲストが自分のトンネルから出て、そのトンネルがホストのトンネルから出る形です。これを障害に変えるのは、どの端点にどの層で到達すべきかを誰も書き留めていないことです。宛先と所有者の 二列の一覧を保てば、ルートの衝突は午後を費やす発見ではなく 一回の照会になります。

検証し、その後は復旧も所有者に任せる

ゲストの内側から試します。新しいアプリケーションプロセスで、通信・名前解決・両方のアドレスファミリー・トンネルが落ちたときの挙動を確認します。ホストの VPN アイコンはゲストの適用範囲を何も語らず、これがこの領域で最も多い誤った確認です。

復旧も所有者のものです。ゲストが所有するトンネルは、ゲスト自身のクライアントとそれが書いたルートで復旧します。ホストが所有する構成はホストの起動順で復旧し、転送規則は unit や起動タスクが再適用しない限り再起動を越えません。復元されたスナップショットは展開であって取り消しではありません。ディスクと一緒に古い資格情報と古いルートを戻すからです。作業を完了と呼ぶ前に、所有者が書き留めた行と一致していること、DNS と両方のアドレスファミリーがゲスト内で解決すること、死んだトンネルがブラックホールではなく使えるネットワークを残すこと、再起動やスナップショット復元が同じ状態を再現することを確認してください。

関連記事