ドメインフロンティングは VPN ではない：二つの名前、一つのリクエスト

この二つの技法は、どちらも仲介者を介し、どちらも隠すように聞こえるために同じ棚に置かれる。しかし働きかける対象が違う。ドメインフロンティングは、一つの HTTPS リクエストのどの層にどの名前が現れるかという話である。VPN は、どのパケットがどの経路でピアまで運ばれるかという話である。フロンティングを VPN の一種と呼ぶと、動作しない設計と、的外れな問いをするレビューが生まれる。

二つの名前、二つの層

TLS 接続はハンドシェイクでサーバー名を運ぶことができる。接続ができると、HTTP リクエストは要求するオーソリティを識別する。通常は Host ヘッダーで示す。これは二つの異なる時点で、二つの異なるソフトウェアが読む二つのフィールドである。

ドメインフロンティングは最初の二つの層の差を利用し、フロンティングサービスに接続を受け入れさせたうえで、リクエストを別の場所へ経路づける。それが働くのは、そのサービスが経路づけを許す場合に限られ、これはプロトコルの小技ではなくプロバイダーのポリシーの問題である。

フロンティングは技法ではなくプロバイダーに依存する

限られた例として、 Front Door のよくある質問 Azure のドキュメントはドメインフロンティングへの対策を記録している。同じサブスクリプション内および構成済みルート内のドメインについては許容される不一致があること、そして不一致の保護がリクエストを遮断した場合に 421 Misdirected Request を返すことが説明されている。

その一つの文書化されたポリシーが、二つのスローガンを同時に崩す。異なる名前の組がすべて機能するわけではなく、すべての不一致が禁止されるわけでもない。他のサービスには独自の検査、独自の配備要件、独自のエラーコードがある。

これは別のネットワークの制限を回避するための手順でもない。プロバイダーの経路ルールを読み、何を許しているかを理解するのは設計の仕事である。そのルールを回避のレシピとして扱うのは、別の結果を伴う別の行為だ。書く文書の中では、この二つの行為を切り分けておく。レビューで設計が却下されるのは後者のほうである。

VPN が実際に選ぶもの

ネットワーク VPN では、経路制御とプラットフォームのポリシーが、ピアへ向かうトンネルに入れる内部トラフィックを選ぶ。構成によっては複数のアプリケーションや定義済みの一部を対象にでき、HTTP リクエストをまったく持たないプロトコルも運べる。

フロンティングはそのどれもしない。フロンティングサービス経由で HTTPS リクエストを一つ手配しても、プライベートネットワークの経路は入らず、任意の UDP アプリケーションは運ばれず、端末上のすべてのプログラムがそのサービスを使うようになるわけでもない。その範囲が必要なら、必要なのはプロキシかトンネルであって、名前の小技ではない。

レビューで両者が混同されるのは、どちらも仲介者として説明され、どちらもアクセスに関する文書に現れるからだ。それぞれが提供するインターフェースはまったく違い、ネットワークの経路であるのは片方だけである。

可視性は二値ではない

比較も単純に隠れているか見えているかではない。DNS 問い合わせ、宛先アドレス、ハンドシェイクの特徴、パケットサイズ、タイミングは、それを見られる位置にいる者にとってはすべて観測可能なままであり、その観測者が何を学ぶかはどこにいるかで変わる。

アプリケーションのデータも、それを終端する端点では見える。リクエストを経路づけるフロンティングサービスはその端点の一つであり、VPN のピアはもう一つである。どちらの構成でも、あなたにサービスを提供するために内容を読む必要のある相手に対して内容が不透明になるわけではない。

三つの箱を描く

設計レビューのために、TLS の端点、HTTP の経路サービス、最終的なアプリケーションを三つの別々の箱として描き、そのうえで VPN のピアはまた別の場所に描く。ウェブの宛先を選ぶ場所と、プライベートネットワークのパケットを運ぶ場所は、同じシステムである必要はなく、実際たいてい同じではない。

箱が分かれれば、問いは答えられるものになる。このプロバイダーはどの名前を受け入れるのか、どのプロトコルに運搬が必要か、どの当事者が何を見られるのか。それらを一つにまとめた図は、誰も実装できない設計と、語彙をめぐって争うレビューを生む。