ホームラボのハイパーバイザーにVPN経由で到達できない：どこを見るか

トンネルは上がり、ハイパーバイザーのWeb画面はタイムアウトし、クライアントは接続済みだと言う。この組み合わせは驚くほど多くを除外する：VPNのハンドシェイクは機能し、クライアントにはアドレスがあり、エンドポイントには到達できる。残るのはルーティングとポリシーに関する短い問いのリストで、自然な順序がある。クライアントから内側へではなくハイパーバイザーから外側へと進めるのは、ハイパーバイザー自身の状態が最も安く確認できるものだからだ。

管理セグメントから始める

ハイパーバイザーの管理アドレスとそこで待ち受けるサービスを確認し、遠隔の何かを診断する前に、同じセグメントの別のホストから画面が読み込まれることを確認する。失敗するローカルテストはVPNの問題ではなく、一時間を節約する五分の確認である。

次に二つの経路。VPNクライアントは管理ネットワークへの経路を必要とし、通常はクライアントのAllowedIPsまたはプッシュされた経路にそのサブネットが含まれる。ハイパーバイザー、またはそのデフォルトゲートウェイはクライアントのアドレスプールへの戻り経路が必要であり、設計が入口で送信元を意図的に変換している場合を除く。これは二つの別個の事実であり、どちらが欠けても同じタイムアウトになる。別々に確認する：クライアントでip route get 192.168.10.20、そしてハイパーバイザーのホストでパケットが届いたかどうかを示すキャプチャだ。

実際の遠隔管理者を許可する

認可は到達可能性とは別の問いである。ゲートウェイとホストのポリシーを、管理アクセスを必要とする送信元とサービスに限定する。ラボのアプリを一つ必要とするゲストVPNアカウントがそれによって管理プレーンに届くべきではなく、トンネルのサブネット全体を許可する平坦なルールがそうなる原因だ。

ハイパーバイザー自身の認証と証明書の確認は有効のままにする。プライベートな経路は、予期しない識別の警告をクリックして通過する理由にはならない。

警告は障害物ではなく発見として扱う価値がある。証明書が使った名前と一致しないなら、名前が間違っているか、サービスが思っているものではないかのどちらかであり、どちらの答えも管理インターフェースでは他のどこよりも重要だ。証明書が発行された名前で画面に到達し、DNSがその名前をトンネルのアドレスに向けるようにする。LANとトンネルの間で一貫せずに解決されるプライベート名は、VPNの不具合に見える証明書の苦情のよくある原因だ。

二次的な接続を確認する

一部の機能はWeb画面が使わない接続を使う。コンソールセッション、ISOのアップロード、VNCやSPICEのプロキシ、移行チャネルはそれぞれ別のポートや別のホストアドレスを使うことがある。画面が読み込まれて一つの機能が失敗したら、ホストのすべてのポートを開けるのではなく、その製品の要件を読む。

すべてを開けることが、管理インターフェースを管理されないインターフェースに変える道だ。追加のポートはそれぞれパッチを当て続ける待ち受けであり、ハイパーバイザーはすでに十分に公開している。その機能が必要とする具体的な接続を特定し、トンネル経由で到達できることを確認し、残りは閉じたままにする。機能がトンネル経由でルーティングできないホストアドレスへの直接接続を要求するなら、それは意図的に回避すべき設計上の制約であり、範囲を転送する理由ではない。

ネットワークに触れる前に戻り道を確保する

自分のVPNを運ぶ仮想ネットワークを変更する前に、ローカルまたは独立した戻り道があることを確認する。

VPNのエンドポイントが到達しようとしているハイパーバイザー自身の仮想マシンであることが多いため、これはホームラボで最も重要だ。仮想スイッチ、ブリッジ、ファイアウォールのルールを遠隔で変更すると、使っている経路が消えることがあり、セッションはそれが起きるのを見るのに十分なほど生き残ることがある。

LANからではなくラボの外から試し、許可だけでなく拒否も確認する。トンネルから到達できないままであるべきネットワークは、変更後も到達できないままであるべきであり、それは管理画面の読み込みとは別の主張だ。二つ目こそが飛ばされ、ラボが成長したときに重要になるものだから、両方の結果を書き留める。

残すべき記録は短く、管理アドレスとサービス、両側に必要な経路、到達を許可された識別、そして復旧の道である。それだけで次の人が動作状態を再導出せずに再現できる。

それでも画面がタイムアウトするなら、別のルールを変える前にハイパーバイザーでキャプチャし、パケットを探す。決して届かないパケットはルーティングかファイアウォールの問いであり、届いて拒否されるパケットはサービスかポリシーの問いであり、クライアントが待つ間に届いて応答されるパケットは戻り経路の問いだ。strongSwanの転送に関する文書は、Linuxゲートウェイがトンネルのトラフィックを内部ホストへ転送する方法を扱っている。三つのキャプチャはもう一つの推測に勝る。