VM はホストの VPN を使っているのか？ゲスト内部から検証する

ホストのパブリック IP を確認し、そこに VPN が表示されたので、VM も保護されていると結論づける。その結論は、この検証では裏づけられない。 ゲストは独自のルーティングテーブル、独自のリゾルバー、独自のインターフェースを持っている。そして、ホストの出口アドレスはそれらについて何も語らない。

検証はゲストの内部で実行する必要があり、何を測定したのかを明示しなければならない。

ホストのブラウザーではなく、ゲストの内部から始める

まずハイパーバイザーのネットワークモードを記録する。NAT、ブリッジ、ホストオンリー、macvtap のいずれかである。NAT モードではホストがゲストのトラフィックをルーティングするため、クライアントがルートをどうインストールするかによって、ホストのトンネルが適用される場合とされない場合がある。ブリッジモードではゲストは物理 LAN 上のピアであり、ホストのトンネルは無関係である。この二つのモードは、同じホスト設定から正反対の答えを出す。

何かを変更する前にモードを書き留める。結果が何を意味しうるかを決めるのはこのモードだからである。

宛先がわかっているリクエストを一つ送る

自分が見た送信元アドレスを報告するサービスに対して、無害なリクエストを送る。次に、その宛先に対するゲスト自身のルーティング判断を確認する。ip route get 203.0.113.5は、ゲストが使用するインターフェースとゲートウェイを表示する。

インターフェースがゲストの通常の NIC であれば、そのトラフィックはゲスト内部のトンネルを通っていない。

二つ目のアダプター、プロキシ設定、ゲスト側の VPN クライアントは、あるアプリケーションの答えを変えても別のアプリケーションの答えは変えないことがある。シェルからの一般的なリクエストではなく、実際に重要なアプリケーションを検証すること。

リゾルバーは別に確認する

出口アドレスが変わっても、そのホスト名をどのリゾルバーが処理したかはわからない。プラットフォームに合ったツールで名前を明示的に問い合わせ、どのサーバーが応答したかを記録する。Split DNS とは、リゾルバーの問いとルーティングの問いが別の答えを持つことである。

この二つはどちらの方向にも食い違うことがあり、その食い違いが実際のバグであることが多い。

systemd のホストでは、resolvectl queryが応答の背後にあるインターフェースと DNS サーバーを表示する。古い構成では dig の出力にサーバーが表示される。いずれにせよ要点は、応答が届いたかどうかではなく、どのサーバーが応答したかを見ることである。

成功だけでなく、失敗時のポリシーを検証する

トンネルの外にトラフィックを一切出さないことが要件なら、リクエストが成功しても何の証明にもならない。クライアントがサポートする制御された失敗テストを使う。サポートされた方法でトンネルを停止し、新しいゲストのリクエストがブロックされるかを見る。ホスト側クライアントのキルスイッチが、あらゆる仮想フォワーディング構成をカバーすると決めつけてはならない。頼れるのは、文書化された適用範囲だけである。

トンネルが切れたときに物理 NIC にフォールバックするゲストは、NAT モードが許すとおりの動作をしている。

モードと適用範囲を記録する

ハイパーバイザーのモード、ゲストのインターフェースとルート、リゾルバー、検証したアプリケーションを書き留める。日付も加える。スナップショットの復元やハイパーバイザーの更新で、この四つはすべて変わりうる。

IPv4 がトンネルに従ったなら、そう書く。その主張を IPv6、別の名前空間、別のネットワーク上の別の VM にまで広げてはならない。