コンテキストベースのアプリルーティングとリソースの場所の選択
アプリが構成されると、アプリの URL が 1 つのルーティング タイプに割り当てられ、内部でルーティングされる URL ごとにリソースの場所が選択されます。 アプリケーションが公開されると、管理者はドメイン ルーティング タイプやリソースの場所を編集できなくなります。 次のようなシナリオが考えられます。
- トラフィックが Secure Private Access サービスにルーティングされないようにするには、内部アプリの URL を外部にルーティングする必要があります。
- パフォーマンスを向上させるには、リソースの場所を変更して、リクエストを最適なデータ センターにルーティングする必要があります。
アクセス ポリシーの動的ドメイン ルーティング構成 (ルーティング例外) により、管理者はユーザー コンテキストに基づいて URL ごとに内部ルーティング タイプを編集できます。 管理者は、ユーザー要求が最適なデータ センターにルーティングされるようにリソースの場所を変更し、ユーザー要求が効率的に処理され、パフォーマンスが最適化されるようにすることができます。
次の例は、動的ドメイン ルーティング構成の使用例を示しています。
ユースケース: コンテキストベースのルーティング
シナリオ：
- グループ A ユーザー: 内部でルーティングされるセキュア プライベート アクセス経由で Outlook アプリと Microsoft Teams アプリにアクセスする ABC 社の従業員。
- グループ B ユーザー: ABC と連携しているサードパーティ企業の従業員。 特定のアプリケーション (Outlook を除く) には、Secure Private Access 経由でアクセスします。 また、インターネット経由でアクセスする独自の Outlook アプリケーションがあり、Outlook トラフィックを Secure Private Access 経由でルーティングすることは望んでいません。
問題:
- グループ B のユーザーは、Secure Access Agent にログインして ABC アプリにアクセスします。
- ネイティブ ブラウザー経由で Outlook にアクセスする要求は、Secure Private Access を経由してルーティングされ、アクセスが拒否されます。
- Outlook アプリケーションの送信先ドメインは、グループ A ユーザーとグループ B ユーザーの両方で同じです。
- アクセス ポリシーにより、グループ A のユーザーのみにアクセスが許可され、グループ B のユーザーが Microsoft Teams または Outlook を起動しようとするとアクセスが拒否されます。
- このルーティングの問題により、グループ B のユーザーは会社の Outlook にアクセスできません。
解決策:
ABC 社の管理者は、次の構成変更を行うことでこの問題を解決できます。
- Office 365 アプリにアクセスするグループ B ユーザー専用の新しいアクセス ポリシーを定義します。
-
アクセス ポリシーで、動的ドメイン ルーティング構成を有効にします (ルーティング例外)。
管理者は、アクセス ポリシーに関連付けられているすべての内部アプリのすべての URL と関連ドメインのリストを表示できます。
-
すべての Office365 アプリ URL に対して、ルーティングが外部で行われるように構成します。
これにより、グループ B ユーザーの Outlook アプリケーションへのアクセス要求が、セキュア プライベート アクセスをバイパスしてインターネット経由でルーティングされるようになります。
これらの変更を実装することで、グループ B のユーザーは、Secure Private Access を経由せずにインターネット経由で会社の Outlook アプリケーションにアクセスできるようになります。同時に、必要に応じて他の ABC アプリケーションへのアクセスも維持されます。
ユースケース: ユーザーのコンテキストに基づくリソースの場所の選択
シナリオ:
- XYZ 社: 米国東海岸と米国西海岸に 2 セットのユーザーがいます。
- データ センター: 2 つのデータ センター (1 つは東海岸、もう 1 つは西海岸) があり、どちらも同じ Jira アプリケーションをホストしています。
- 目的: 管理者は、ユーザー コンテキスト (地理的位置、ネットワークの場所、ユーザー名、ユーザー グループ) に基づいて、エンド ユーザーのアクセス要求を選択したリソースの場所にルーティングし、最適なパフォーマンスとルーティングを確保したいと考えています。
解決策:
- 新しいルーティング要件に対応するために、Jira アプリケーションに関連付けられているアクセス ポリシーを編集します。
- アクセス ポリシー内で、動的ドメイン ルーティング構成を有効にします (ルーティング例外)。
- ユーザー コンテキストごとにリソースの場所を変更します。
管理者は、ユーザーのリクエストがコンテキストに基づいて最適なデータセンターにルーティングされるようにすることで、パフォーマンスを向上させ、社内のすべてのユーザーのルーティングを効果的に管理できます。
ルーティングタイプまたはリソースの場所を変更する手順
- アクセス ポリシーを作成または編集します。 詳細については、「 アクセス ポリシーの作成」を参照してください。
-
ステップ 3: アクション ページで、 ルーティング例外 トグル スイッチをスライドして、コンテキスト ルーティング ドメイン構成を有効にします。
ルーティング例外 トグルを使用すると、アプリケーション内で構成されたドメインのリソースの場所とルーティング情報を編集できます。
- トグルがオンの場合: 内部でルーティングされるすべてのアプリの URL と関連ドメインのリストが表形式で表示されます。 ドメインの横にある編集アイコンをクリックすると、リソースの場所とルーティング タイプを変更できます。 このルーティング例外は、アクセス ポリシー内のすべてのユーザーにのみ適用されます。
- トグルがオフの場合: ドメインの既存のルーティング例外は削除され、適用されなくなります。 エンド ユーザーは、アプリケーションのセットアップ時に設定されたグローバル構成に基づいてのみルーティングされます。 このルーティング例外は、アクセス ポリシー内のすべてのユーザーにのみ適用されます。
注意:
表の FQDN/ID 列には、アプリケーションの FQDN とホスト名のみがリストされ、IP アドレスはリストされません。
- ルーティング タイプを変更するドメインの横にある編集アイコンをクリックします。
-
ドメインの編集 の詳細で、ルーティング タイプを選択します。
-
内部: トラフィックはコネクタアプライアンスを経由して流れます。
- Web アプリの場合、トラフィックはデータセンター内で流れます。
- SaaS アプリの場合、トラフィックはコネクタ アプライアンスを介してネットワーク外部にルーティングされます。
- 内部 – プロキシをバイパス: ドメイン トラフィックは、Citrix Cloud Connector アプライアンスを介してルーティングされ、コネクタ アプライアンスで構成された顧客の Web プロキシをバイパスします。
- 外部: トラフィックはインターネットに直接流れます。
-
内部: トラフィックはコネクタアプライアンスを経由して流れます。
- 必要に応じてリソースの場所を変更します。 このオプションは、内部ルーティングされたドメインにのみ適用されます。
- ［保存］ をクリックします。
注意:
- ルーティングとリソースの場所を変更することしかできず、ルーティング テーブル内のルーティング ドメインを追加または削除することはできません。
- メイン ルーティング テーブルからコンテキスト ルーティングが有効になっているドメインを削除しても、アクセス ポリシー内の ルーティング例外 テーブルからはドメインが削除されません。 つまり、そのドメインのコンテキスト ルーティング構成はアクセス ポリシー内でそのまま残ります。
- コンテキスト ルーティングが有効になっているアプリを削除すると、アクセス ポリシー内の ルーティング例外 テーブルからドメインが削除されます。 これは、そのアプリに関連付けられているすべてのコンテキスト ルーティング構成がアクセス ポリシーから削除されることを意味します。
- 選択した関連ドメインは、このアクセス ポリシーの一部であるユーザーの条件が満たされた場合に、デフォルト設定を上書きします。 それ以外の場合は、デフォルトのルーティングが適用されます。
- ルーティングが変更されていない場合、またはルーティング例外機能が有効になっていない場合、ルーティングはメイン ルーティング テーブルの既定の設定 (設定 > アプリケーション ドメイン) に基づいて行われます。