MASQUE（HTTP/3ベースのトンネリング）

トンネリングを「HTTPのメソッド」として定義し直す

MASQUE（Multiplexed Application Substrate over QUIC Encryption）は、任意のトラフィックをHTTP/3の上にトンネルするためのIETF標準群です。発想の核心は単純で、これまでSOCKSやIPsecが独自プロトコルとして実装していた「中継してほしいデータを運ぶ」という役割を、HTTPのメソッド拡張として定義し直した点にあります。土台となるQUICのストリーム多重化・0-RTTについては/network/quic-internals/で扱った内部構造がそのまま活きます。

もともとHTTP/1.1にはCONNECTメソッドがあり、プロキシ経由でTCP接続を張る（典型的にはHTTPS通信をプロキシに中継させる）用途に使われてきました。MASQUEはこれを拡張し、TCP以外の中身もHTTP/3上でトンネルできるようにします。

CONNECT-UDP：UDPデータグラムを運ぶ

CONNECT-UDP（RFC 9298）は、UDPペイロードをHTTP/3のリクエストとして中継する仕組みです。クライアントは次のようなテンプレート化されたURIでプロキシにリクエストを送り、宛先ホスト・ポートを指定します。

:method = CONNECT-UDP
:protocol = connect-udp
:scheme = https
:path = /.well-known/masque/udp/{target_host}/{target_port}/

このリクエストが成立すると、以降クライアントとプロキシの間では、宛先UDPパケットの中身がQUICのHTTPデータグラム（RFC 9297で定義される、ストリームの順序保証や再送を伴わない軽量なフレーム）に載せて運ばれます。UDPはそもそも再送や順序保証を持たないため、これを運ぶ側もQUICストリームではなくデータグラム機構を使うのが自然な設計です。プロキシは受け取った中身を実際の宛先へUDPで転送し、応答も同じ経路で送り返します。

CONNECT-IP：IPパケットそのものを運ぶ

CONNECT-UDPが個々のUDPペイロードを中継するのに対し、CONNECT-IP（RFC 9484）はさらに一段抽象度を上げ、IPパケットそのものをカプセル化して運びます。クライアントはCONNECT-IPリクエストが成立すると、プロキシから仮想的なIPアドレスを払い出され（IP Address Assignment）、以降そのアドレス宛・発の全パケットをQUICのHTTPデータグラムに包んで送受信します。

:method = CONNECT-IP
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/

クライアント → プロキシ: 割り当てIPを使いたい旨を交渉
プロキシ    → クライアント: 割り当てIP・経路情報を通知
以降: IPパケット全体をHTTPデータグラムでカプセル化して送受信

これはIP層をまるごとトンネルするという点で、上位プロトコルがTCPかUDPかを問わず運べます。つまりCONNECT-IPを使えば、既存のVPNクライアントが提供していたのと同等の「全トラフィックをトンネルに流す」体験を、HTTP/3の上で構築できます。

既存VPNとの違い：トンネルの「見え方」が変わる

IPsecやWireGuardなどの従来型VPNは、独自のUDPポートやESPといった専用プロトコルを使うため、パケットの見た目からVPN通信であることが比較的わかりやすく、ネットワーク境界でのプロトコル単位の遮断・検知がしやすい面がありました。暗号スイート固定によるダウングレード耐性など従来VPNの設計は/network/wireguard-protocol/で詳しく扱っています。

MASQUEベースのトンネルは、これと根本的に異なる土俵に立ちます。

IETF標準化の経緯

MASQUEはIETFのMASQUE Working Groupで標準化が進められました。経緯を簡単に整理すると、まずHTTP/2時代のExtended CONNECT（RFC 8441）でCONNECTメソッドにプロトコルネゴシエーション機能が加わり、これがHTTP/3でも使えるよう一般化されました。その上でCONNECT-UDP（RFC 9298）がUDPペイロードのカプセル化を、CONNECT-IP（RFC 9484）がIP層全体のカプセル化を定義し、両者はHTTPデータグラム（RFC 9297）という共通の下地の上に構築されています。

実運用としては、AppleのiCloud Private Relay（CONNECT-UDPベースの二段中継でユーザーのIPと閲覧先を単一の事業者に見せない仕組み）や、各種プロキシ製品でのHTTP/3対応がすでに存在します。中継先を経由してもエンドツーエンドの経路特性を維持したい用途（例えばNATを越えたP2P的な直結の可否判断）は/network/nat-traversal-hole-punching/で扱った考え方とも関係が深く、MASQUEプロキシ自体がNAT配下に置かれる場合は同様の制約を受けます。

まとめ

MASQUEは新しい暗号プロトコルではなく、既にあるHTTP/3・QUICというインフラの上に「CONNECT系メソッドで中身を運ぶ」という薄い抽象化を足したものです。CONNECT-UDPは個々のUDPペイロードを、CONNECT-IPはIPパケットそのものをHTTPデータグラムでカプセル化し、結果としてトンネル通信が通常のHTTPSトラフィックと区別しにくくなります。従来VPNが独自プロトコルゆえに識別・遮断されやすかったのに対し、MASQUEはウェブの標準スタックに溶け込むことでその課題を回避しますが、同じ性質が可視性を必要とするネットワーク運用側には新たな課題を突きつけている点も押さえておくべきです。