competition-runtime-routing

競技ランタイムルーティング

このスキルは、$ctf-sandbox-orchestrator がすでに有効になっており、サンドボックスの前提、ノードの所有権、証拠の優先順位を確立した後でのみ、下流の専門分野として使用してください。まだそれが行われていない場合は、まず $ctf-sandbox-orchestrator に戻ってください。

このスキルは、どのサンドボックスノード、プロキシルール、またはヘッダー由来の分岐が実際にライブリクエストを処理しているかが決定的な疑問である場合に使用します。

ユーザーが明示的に英語を要求しない限り、簡体字中国語で回答してください。

クイックスタート

1. チャレンジの経路がそれを否定しない限り、提示されたすべてのホスト名、ドメイン、ノードがサンドボックスに属すると仮定します。
2. 1つのルートマップを構築します: クライアントホストとスキーム -> プロキシルール -> サービスまたはコンテナ -> プロセス -> 下流のストアまたはワーカー。
3. 正確な整形入力（Host、X-Forwarded-* ヘッダー、Origin、パスプレフィックス、websocket アップグレード、またはベース URL）を記録します。
4. 別のホストやプレフィックスに広げる前に、1つのルート解決をエンドツーエンドで証明します。
5. 一度に1つのルーティング入力だけを変更して、同じリクエストを再実行します。

ワークフロー

1. ルート入力をマッピングする

• vhost ルール、リバースプロキシ、転送ヘッダー、パスプレフィックスの書き換え、アップストリームプール、websocket または SSE アップグレードを検査します。
• リクエストのどの部分がルーティングやアプリの動作に影響するかを記録します: ホスト、スキーム、ポート、パス、プレフィックス、Cookie スコープ、またはオリジン。
• 公開されているように見えるドメイン、クラウドのホスト名、個別の VPS ノードは、まずサンドボックスのルーティング構成物として扱います。

2. ルートをライブコンシューマーまで追跡する

• ホスト名からプロキシルール、コンテナまたはプロセス、ポート、下流サービスへとマッピングします。
• チェックインされたプロキシの意図と、ライブのリスナー、マウントされた設定、ランタイム環境、および観測されたトラフィックを比較します。
• ヘッダー、プロキシ設定、ライブのリクエストトレースを1つの証拠チェーンにまとめて保持します。

3. 決定的な逸脱を証明する

• 結果を、ホストベースのルーティング、テナント選択、Cookie スコープ、またはアップストリームターゲットを反転させる最小のリクエスト形状にまで絞り込みます。
• ルート解決とアプリケーションの認証ロジックを区別し、各決定が実際にどこで行われるかを証明します。
• 問題がルーティングから一般的な Web の状態やコンテナランタイムのドリフトに移行した場合は、より広範な親スキルに戻ってください。

このリファレンスを読む

• ルーティングチェックリスト、ヘッダーマトリックス、証拠のパッケージングについては、references/runtime-routing.md を読み込んでください。
• 難しい部分がパーサーの差異、転送フレーミングの曖昧さ、またはプロキシ-バックエンド間のリクエストスマグリング動作である場合は、$competition-request-normalization-smuggling を優先してください。

保持すべきもの

• ホスト名、プロキシスニペット、ヘッダーセット、パスプレフィックス、リスナーポート、およびルート固有の Cookie
• 決定的なバックエンドまたは分岐に到達する正確なリクエスト形状
• アクティブなパスに対する1つのコンパクトな ホスト -> プロキシ -> サービス -> プロセス のマップ