ゼロトラストの最前線：HTTP/2マルチプレクシングとSASEインスペクションの「見えない壁」を突破する
現場でネットワーク設計をしていると、「HTTP/2になってからパケットキャプチャが難しくなった」という嘆きをよく耳にします。かつてのHTTP/1.1なら、tcpdumpで流し見ればリクエストの境界線が明白でしたが、HTTP/2はそうはいかない。単一のTCPコネクションの中で複数のストリームが複雑に絡み合う「マルチプレクシング（多重化）」は、Webの高速化には不可欠ですが、セキュリティエンジニアにとっては頭痛の種です。
今日は、SASE（Secure Access Service Edge）のレイヤー7プロキシが、この「混線するパケット」をどう紐解き、脅威を検査しているのか。その深淵に触れてみましょう。
—
1. HTTP/2の多重化とプロキシのジレンマ
HTTP/2の肝は、バイナリフレーミングレイヤーにあります。1つのTCPコネクション上で複数の Stream ID を持つフレームが交互に流れるため、SASEのようなクラウドプロキシは、一度TCPセッションを終端（Terminate）し、コンテンツを再構築してからスキャンしなければなりません。
もし、SASEが適切にこの多重化をハンドリングできていなければどうなるか？
- 部分的な検査の欠落: 特定のストリームだけがスキャンをすり抜ける。
- リソース枯渇: 巨大な
Window Sizeを持つストリームの処理でプロキシのメモリが爆発する。 - 接続断: フレームの順序制御（Flow Control）の不整合による
RST_STREAMの多発。
これらはすべて、実務で遭遇する「謎の接続エラー」の正体です。
—
2. 実践：マルチプレクシングを考慮したインスペクションの確認
まず、手元の環境でHTTP/2のストリームがどのように流れているか確認してみましょう。curl を使うのが最も手軽です。
# HTTP/2通信を追跡し、ストリームIDを確認するコマンド
# --http2 オプションで強制的にHTTP/2を指定
curl -v --http2 https://api.example.com/data \
-H "X-Debug-Trace: true"このとき、SASEを経由している場合、レスポンスヘッダーに Via や X-Proxy-ID といった値が付与されているはずです。これらが付与されていれば、プロキシが一度中身を解凍（TLS復号）し、再暗号化して流している証拠です。
—
3. SASEの検査エンジンを悩ませるパラメーター
プロキシ設計において、特に注意すべきは SETTINGS_INITIAL_WINDOW_SIZE と SETTINGS_MAX_CONCURRENT_STREAMS です。
SETTINGS_INITIAL_WINDOW_SIZE: SASEが一度にバッファできるデータ量です。これが小さいと、大容量APIレスポンスの受信時にスループットが極端に落ちます。SETTINGS_MAX_CONCURRENT_STREAMS: 同時に何本のストリームを並列処理するか。ここを無制限にすると、悪意のあるクライアントが大量のストリームを開いてプロキシのリソースを食いつぶす「ストリーム多重化攻撃」の標的になります。
Pythonでのテストコード例
Pythonの httpx ライブラリを使用して、あえて複数のストリームを同時に投げ、プロキシの負荷耐性をテストする際のコード例を挙げます。
import httpx
import asyncio
async def fetch_data(client, url):
# 非同期で複数のストリームを同一セッションで発行
response = await client.get(url)
print(f"Status: {response.status_code}, Stream ID: {response.extensions.get('http_version')}")
async def main():
# HTTP/2を明示的に有効にしたクライアント
async with httpx.AsyncClient(http2=True) as client:
tasks = [fetch_data(client, "https://api.example.com/data") for _ in range(10)]
await asyncio.gather(*tasks)
if __name__ == "__main__":
asyncio.run(main())このコードを実行し、プロキシ側のログで「同時に10個のリクエストが1つのTCP接続で処理されているか」を確認してください。もしSASEがHTTP/1.1にダウングレードさせているなら、それは「インスペクション能力不足」のサインです。
—
4. 凄腕エンジニアへの道：トラブルシューティングの勘所
現場でよくある「特定のAPIだけがSASE経由だと502エラーになる」という問題。これは多くの場合、HTTP/2のコネクション再利用（Connection Pooling）と、プロキシのセッションタイムアウトの不整合が原因です。
1. フレーム解析: nghttp コマンドを使って、サーバーとクライアント間で流れているフレームを詳細に追いましょう。
# nghttp2ツールキットを利用した詳細解析
nghttp -v https://api.example.com2. ログ相関分析: SASEの管理画面で「HTTP/2 Stream ID」と「TCP Source Port」を突き合わせます。特定のIDで GOAWAY フレームが頻発していないかチェックしてください。
3. MTU調整: SASEのデータセンターとの間でMTU（Maximum Transmission Unit）の不一致があると、大きなHTTP/2フレームが断片化され、再構築コストが跳ね上がります。これはレイテンシ増加の主犯格です。
—
まとめ：防御は「見える化」から始まる
ゼロトラストにおいて、SASEは単なる「ゲートウェイ」ではなく、「プロトコルの調停者」です。HTTP/2の複雑さを理解し、SASEがストリームをどのように切り分け、どのタイミングでインスペクションを実行しているかを把握することは、現代のネットワークエンジニアにとって必須の教養といえます。
「通信が繋がらない」と嘆く前に、まずはその通信がHTTP/2のどのストリームで、どのフレームが拒絶されているのか。そこまで深く潜り込んでこそ、真の解決が見えてきます。皆さんの現場のセキュアな通信環境構築に、少しでもこの知見が役立てば幸いです。
それでは、また次回の深掘りでお会いしましょう。現場からは以上です。
コメント