VPNアダプターの名前が別のプロトコルを隠すことがある理由

VPNアダプターの横のラベルは、そのインターフェースを作成したソフトウェアを表しており、それは実際にネットワークを通過するパケットより一段上の層です。プラグインは、ネットワーク上のカプセル化ではなく、プラグイン自身の分類を反映した名前のアダプターを表示することがあります。クライアント、プロファイル、ピアを読むことで、名前では答えられないことが分かります。設定メニューで同じに見える二つの接続が、キャプチャではまったく異なる動作をすることがあります。

名前は回線ではなくプロバイダーに由来する

Windows は組み込みの VPN クライアント向けに接続の種類の短い一覧を定義しており、サードパーティ製品はその横に独自のスタックをインストールします。ネットワーク一覧に表示されるアダプターは、その接続を所有するドライバーが作成するため、名前はドライバーに関する証拠であり、外側のプロトコルに関する保証ではありません。あるクライアントをアンインストールしてもアダプター名が残ることがあるのもそのためです。

VPN 接続の種類に関する Microsoft のドキュメントは、その種類がその接続に対するクライアントの構成を表すと明記しています。プラグインが関与する場合、表示される種類はプラグインが登録した内容に従い、実際のカプセル化はまったく別のものである可能性があります。

同じ階層化は他の場所にも現れます。Linux ホスト上の仮想アダプター、TAP デバイス、モバイル VPN サービスの拡張は、いずれもソフトウェアが作成するインターフェースであり、インターフェース名はサーバーと交渉するのではなく、そのソフトウェアが選びます。

ポートとアドレスから分かること、分からないこと

各層は異なる証拠を残し、それらを別々に読めば、ラベルは判定ではなくなります。

TCP 443 が最も明確な例です。それは SSTP、OpenVPN TCP トンネル、SoftEther SSL-VPN セッション、あるいは通常の Web トラフィックを運ぶことができ、ポート番号だけではそれらを区別できません。したがって、443 を許可するファイアウォール規則は、どのクライアントが使われているかの証拠にはなりません。外側のインターフェースでのキャプチャがそれを確定し、数秒で確定します。

プロファイルの形式とピアを読む

構成ファイルはアダプターより強い手がかりです。OpenVPN プロファイルには remote、proto、ca といったディレクティブが含まれ、WireGuard 構成には秘密鍵を持つ [Interface] セクションと許可 IP を持つ [Peer] セクションが含まれ、Windows の電話帳エントリは接続の種類を独自の形式で保存します。それぞれの構文は単一の実装に属します。

次にピアのドキュメントとログを見ます。サーバーはどのプロトコルハンドラーがセッションを受け入れたかを把握しており、そのログは完了した段階を示します。この証拠は、パケットが実際に解釈された場所で記録されるため、どのデスクトップのラベルにも勝ります。

ラベルではなくプロトコルで手順書を選ぶ

OpenVPN のディレクティブは OpenVPN のものであり、WireGuard の鍵と許可 IP は WireGuard のものであり、SSTP プロファイルはどちらでもありません。アダプター名が互換性のあるように聞こえたからといって、あるクライアントのオプションを別のものに貼り付けると、動作していた構成が壊れます。

プロトコルを特定したら、クライアント自身のログ、サーバーのプロトコル固有のログ、外側のやり取りを示すキャプチャという対応するトラブルシューティングの道筋を選びます。そこからは、障害にはラベルではなく名前が付きます。