従来のADCとリバースプロキシのアーキテクチャでは、新しいドメインはほとんど常に新しいリスナー、新しい仮想サービス、新しいIPアドレス、または複雑なルーティングルールのセットを意味します。小規模ではこれは管理可能ですが、ドメイン数が数十になり、テナントが数百になり、マルチ環境の分離が必要になると、運用の表面が急速に崩壊します。
TLS側では問題がより鋭くなります。HTTPのHostヘッダーはTLSが終端されるまで見えないため、TLSトラフィックを正しいサービスにルーティングするにはSNIレベルで決定する必要があります — ハンドシェイクが完了する前に。適切なSNI分離がなければ、同じIPを共有するドメインが交差し、誤った証明書が提供され、またはトラフィックが誤ったバックエンドに送られます。
ワイルドカードドメインの管理はさらなる負担を加えます。`*.tenant.app`のようなパターンはSaaSやMSPのシナリオで一般的ですが、すべてのサブドメインを手動で定義することは持続可能ではありません。ワイルドカードは正しい正規表現に変換され、適切にエスケープされ、意図しないドメインにマッチしないよう制約する必要があります。
HTTP/2とモダンなTLSセマンティクスは、ドメインの不一致ハンドリングをより敏感にします。SNIとHostヘッダーが一致しない場合、クライアントは明確に定義された動作を期待します。プラットフォームがそれを生成できない場合、接続が誤ったプールに送られるかセキュリティコントロールがバイパスされます。
TR7 ADCはバーチャルホストをドメイン + マッチャー + プールの関係として扱います。同じIPとポート上でSNIまたはHostヘッダーによりドメインを分離し、ワイルドカードドメインを自動的に処理し、各ドメインを独自のサービスポリシーにバインドします。
TR7はバーチャルホスト管理から手動リスナーの複製を排除し、オブジェクトモデル、自動マッチャー生成、ゼロダウンタイムリロードプロセスを通じてドメインベースルーティングを処理します。
TLSトラフィックの場合はSNI値に基づいて決定され、HTTPトラフィックではHostヘッダーが使用されます。TLSの早期分離シナリオとクラシックなHTTPリバースプロキシのシナリオの両方が、同じバーチャルホストモデルの下で処理されます。
`*.example.com`のようなワイルドカードエントリは自動的に安全なマッチングパターンに変換されます。オペレーターは正規表現を手書きする必要はありません。単一のワイルドカード定義で無制限のサブドメインを正しいプールにルーティングします。
VIPを共有するすべてのドメインは異なるプールをターゲットにできます。あるドメインはWAAPプロファイルを持ち、別のドメインはmTLS、さらに別のドメインはキャッシュまたはカスタムログプロファイルを持てます。ドメインの分離はルーティングだけでなく、ポリシーの分離です。
TR7はバーチャルホストの設定をソートされた決定論的な順序で生成します。同じ入力は常に同じ出力を生成するため、不要なリロードが回避されます。実際の変更が検出されたときのみソフトリロードが適用され、ライブ接続が保持されます。
バーチャルホストは同一のIPとポート上でドメインベースの分離、ワイルドカード管理、証明書バインディング、テナント分離、ゼロダウンタイム更新を提供します。
TLSトラフィックでクライアントが提示したSNI値が読み取られ、マッチするドメインが正しいプールに送られます。これによりTLS接続の最も早い段階でドメイン分離が可能です。単一のポート443で複数のTLSサービスを実行するためのコアメカニズムです。
HTTPモードでTR7はバーチャルホストマッチングに`Host`ヘッダー値を使用します。プレーンHTTPおよびTLS終端後のHTTPトラフィックでクラシックなvhost動作が実現します。同一のIPとポート上の異なるドメインが別々のサービスプールに転送されます。
`*.example.com`のようなワイルドカード名が自動的にマッチングルールに変換されます。オペレーターはすべてのサブドメインに対して個別のルールを書く必要はありません。SaaSテナントドメイン、顧客サブドメイン、マルチ環境の分離に特に強力です。
各バーチャルドメインはプールIDにバインドされます。同じVIP上の`shop.example.com`、`api.example.com`、`admin.example.com`は異なるバックエンドをターゲットにできます。各プールはバックエンドリスト、ヘルスチェック、WAAP、トラフィックルールを独立して管理します。
バーチャルホストは単なるルーティング決定ではなく、各ドメインがバインドされているプールを通じてセキュリティと運用ポリシーも分岐します。一方のドメインは厳格なWAAPプロファイルを適用し、別のドメインはキャッシュプロファイルで高速化できます。ログフォーマットとレポートはドメインとプールごとに設定できます。
同一のIPとポートで複数の証明書が使用される場合、TR7はSNI値に基づいて正しい証明書とプールチェーンを実行します。ワイルドカード証明書とワイルドカードvhostを一緒に使用でき、マルチドメインTLS操作が簡素化されます。
バーチャルホスト層はトラフィックルーティング中にクライアントと地理的コンテキスト情報を下流の層に転送することをサポートします。バックエンドプール、ログ記録、地理ベースの決定、ポリシーチェーンはドメイン分離後も必要なコンテキストを使用し続けることができます。
バーチャルホスト層は分離された内部接続を通じてトラフィックを関連するプールに転送します。このアーキテクチャは中央の点でドメイン分離を行いながら、各プールのワークスペースを分離したまま保ちます。ポータル、AAM、または別のプールからのトラフィックも同じモデルで処理できます。
マルチテナントデプロイメントでは、各ゾーンが独自のバーチャルホストリストを管理します。あるテナントのドメインリストが別のテナントのドメインと混在しません。ドメインの競合、権限の境界、可視性はテナントの境界内に保持されます。
バーチャルホストグループは高接続数のために別々のワークスペースに保持されます。マルチドメインのトラフィックは接続容量を制約することなく集中管理されます。一方のドメイングループでの運用変更が他のグループに不必要に影響しません。
ドメイン、プール、または証明書が変更されると、TR7が設定の差分を検出します。影響を受けるコンポーネントのみがソフトリロードで更新されます。既存の接続がドレインされる間、新しいトラフィックは更新された設定の下で受け入れられます。
未定義のHostまたはSNI値をデフォルトのバックエンド、エラーレスポンス、またはセキュリティポリシーに送ることができます。これによりサブドメインハイジャックと予期しないドメインアクセスのシナリオで制御された動作が提供されます。
バーチャルホスト機能はドメインマッチングだけでなく、リロード戦略、テナント分離、ワイルドカードの正規化、高接続数の操作も一緒に対処します。
同じIP、ポート、操作タイプを共有するバーチャルホストはグループとして扱われます。グループ内のドメインマッピングはソートされた決定論的な順序で生成されます。この構造により不正な設定の差分が防がれます。
正確なドメイン値は直接文字列マッチングで処理され、ワイルドカードドメインは自動パターンマッチングで処理されます。オペレーターが手動で正規表現を書かないため、エラーのリスクが削減されます。ドメインの文字は安全にエスケープされます。
TLSモードでは決定はSNI値に基づき、HTTPモードではHostヘッダーに基づきます。この分離は自動的に行われます。オペレーターは各シナリオに対して異なるルーティングロジックを書く必要はありません。
TR7は現在の設定と生成されるべき設定を比較します。リロードまたは再起動の決定は実際の差分が存在する場合のみ行われます。何も変更されていない場合はアクションは取られません。
稼働中のプロキシ設定が変更された場合のみソフトリロードが適用されます。これによりアクティブな接続の不必要な中断が防がれます。より深いワークスペースの変更が必要な場合は、制御された再起動が実行されます。
各ゾーンは独自のドメインとvhost設定を確認します。マルチ顧客またはマルチ部門のデプロイメントでドメイン管理が分離されます。このアプローチにより運用セキュリティと管理の簡素性が向上します。
バーチャルホストルーティングは関連するプールがアクティブで正常な場合のみ意味をなします。プールのヘルスチェック、バックエンドの状態、証明書、WAAPプロファイルがドメイントラフィックの最終的な決定チェーンを決定します。
モダンなクライアントでは、SNIとHostヘッダーの不一致によりトラフィックが誤ったバックエンドに到達する可能性があります。TR7はそのような状況をバーチャルホストとセキュリティプロファイルチェーンを通じて制御可能にします。
`tenant1.app.com`、`tenant2.app.com`、`tenant3.app.com`がすべて同じVIPを共有します。ワイルドカードドメインルールにより、すべてのテナントサブドメインが単一のエントリの下でキャプチャされ、各テナントは独自のプールとWAAPプロファイルにルーティングされます。
`shop.example.com`はパブリックストアのプールに送られ、`admin.example.com`はmTLSと厳格なアクセスポリシーを持つ管理プールに送られます。単一のポート443が使用され、セキュリティポリシーはドメインレベルで分離されます。
`api.example.com`は新しいAPIプールにルーティングされ、`api-v2.example.com`はレガシープールに送られます。移行中は両方のサービスが同じIPを共有し、DNSとファイアウォールのアーキテクチャは変更されません。
バーチャルホスト層がドメインを分離し、下流のプール層が地理情報に基づいて異なるトラフィックルールまたはセキュリティプロファイルを適用します。ドメインとロケーションの決定チェーンがエンドツーエンドで動作します。
未定義または予期しないサブドメインリクエストはデフォルトのセキュリティ動作の下に置かれます。ワイルドカード証明書が使用されている場合でも、予期しないサブドメインが管理されていないバックエンドに到達することができません。
`portal.example.com`はインターネットユーザーにオープンで、`partner-api.example.com`はmTLSとIPアローリストでのみアクセス可能です。両方のサービスは同じIPとポートを共有し、それぞれ独自のセキュリティ層の下にあります。
SNIとHostヘッダーの分離、ワイルドカードドメインサポート、ドメインごとのWAAP、ゼロダウンタイムリロード。お客様自身のインフラストラクチャでライブセットアップをご案内します。