コンテキストベースのアプリケーションルーティング
アプリが構成されると、アプリケーションURLとその関連ドメインまたはアプリの宛先に対して、アプリ構成の下でルーティングタイプが定義されます。ここで定義されたルーティングタイプは、アプリにアクセスできるすべてのユーザーに適用されます。ただし、管理者がユーザーコンテキストに基づいて同じアプリを異なる方法でルーティングしたいシナリオも考えられます。たとえば、ユーザーが社内ネットワーク内にいる場合、内部アプリのURLまたは宛先は、Secure Private Accessを介するのではなく、直接ルーティングされる必要があります。
これは、アクセスポリシー (特定のユーザー向け) または セッションポリシー (すべてのユーザー向け) の ルーティング例外 を使用して構成できます。アクセスポリシーのルーティング例外構成により、管理者はポリシーで定義された条件に一致するユーザーまたはマシンのルーティングタイプを編集できます。この設定はアクセスポリシーの一部であるため、そのポリシーに含まれるユーザーとマシンにのみ適用されます。
注:
アクセスポリシー内にルーティング構成がある場合、それはアプリ構成を上書きします。
次の例は、ルーティング例外のユースケースを示しています。
ユースケース: コンテキストベースのルーティング
シナリオ:
-
グループAユーザー: 会社ABCの従業員で、NetScaler Gatewayを介してOutlookアプリとMicrosoft Teamsアプリにアクセスし、内部的にルーティングされます。
-
グループBユーザー: ABCと協力しているサードパーティ企業の従業員。彼らはNetScaler Gatewayを介して特定のアプリケーション（Outlookを除く）にアクセスします。また、インターネット経由でアクセスする独自のOutlookアプリケーションを持っており、OutlookトラフィックをNetScaler Gateway経由でルーティングしたくありません。
問題:
-
グループBユーザーは、ABCアプリにアクセスするためにSecure Accessクライアントにログインします。
-
彼らがネイティブブラウザを介してOutlookにアクセスしようとすると、そのリクエストはNetScaler Gateway経由でルーティングされ、アクセス拒否につながります。
-
Outlookアプリケーションの宛先ドメインは、グループAとグループBのユーザーの両方で同じです。
-
アクセス ポリシーはグループAのユーザーのみにアクセスを許可しているため、グループBのユーザーがMicrosoft TeamsまたはOutlookを起動しようとするとアクセスが拒否されます。
-
このルーティングの問題により、グループBのユーザーは会社のOutlookにアクセスできません。
解決策:
ABC社の管理者は、この問題を解決するために以下の構成変更を行うことができます。
-
Office 365アプリにアクセスするグループBのユーザー専用の新しいアクセス ポリシーを定義します。
-
アクセス ポリシーで、ルーティング例外オプションを有効にします。管理者は、アクセス ポリシーに関連付けられているすべての内部アプリのすべてのURLと関連ドメインのリストを表示できます。
-
すべてのOffice 365アプリのURLについて、ルーティングが外部で行われるように構成します。これにより、グループBのユーザーがOutlookアプリケーションにアクセスするためのリクエストがインターネット経由でルーティングされ、NetScaler Gatewayをバイパスすることが保証されます。これらの変更を実装することで、グループBのユーザーはNetScaler Gatewayを経由せずにインターネット経由で会社のOutlookアプリケーションにアクセスでき、必要に応じて他のABCアプリケーションへのアクセスも維持できます。
ルーティングの種類を変更する手順
-
アクセス ポリシーを作成または編集します。詳細な手順については、「アクセス ポリシーの構成」を参照してください。
-
アクセス ポリシーで、ルーティング例外トグルをオンに設定します。
-
アクセス ポリシーに関連付けられているアプリのURLと関連ドメインのリストから、ルーティングの種類を変更したいドメインを見つけます。
-
適用したいユーザーコンテキストに基づいて、選択したドメインのルーティングタイプを変更します（例：InternalからExternalへ）。
-
アクセス ポリシーを保存します。
ルーティング例外(/en-us/citrix-secure-private-access/media/spa-hybrid-routing-exceptions.png)
ユースケース: 社内ユーザーをバックエンドアプリケーションに直接ルーティングする
管理者は、NetScaler Gateway を介してトラフィックをトンネリングすることなく、社内ユーザーをバックエンドアプリに直接ルーティングするようにセッションポリシーを設定できます。セッションポリシーは、ネットワークロケーションやデバイスのポスチャなどの要因に基づいて動的なルーティングを提供します。
セッションポリシーの設定の詳細については、「セッションポリシーの設定」を参照してください。
注:
-
セッションポリシー設定は、特定のアプリケーションに紐付けられるのではなく、すべてのアプリケーションにセッションレベルで適用されます。
-
セッションポリシーは、すべてのユーザーまたはユーザーのサブセットに割り当てることができます。
ルーティングの優先順位
セッションポリシーはアクセスポリシーと連携して機能し、競合がある場合はアクセスポリシーが優先されます。このようなシナリオでは、アクセスポリシーのルーティング例外がセッションポリシーを上書きします。 アクセスポリシーもセッションポリシーも設定されていない場合は、グローバルルーティング設定（Settings > Application Domain）が適用されます。
サポートされているCitrix Secure Access™クライアント
以下のバージョンのCitrix Secure Accessクライアントは、ユーザーをバックエンドアプリケーションに直接ルーティングすることをサポートしています。
-
macOS - 24.11.1以降。
-
Windows - 24.11.1.17以降。また、EnableContextualAccess VPNクライアントレジストリを有効にする必要があります。詳細については、「NetScaler Gateway Windows VPNクライアントレジストリキー」を参照してください。
使用例
シナリオ:
病院では、ユーザーが病院ネットワーク「hospital_network1」に接続されている場合、これらのアプリは病院ネットワーク上で直接到達可能であるため、アプリからのトラフィックはバックエンドアプリに直接流れる必要があります。ユーザーが病院ネットワークの外部にいる場合、アプリのトラフィックはトンネル経由で送信される必要があります。
解決策:
-
ルーティングを内部に設定して、app1、app2を追加します。
-
アプリ (app1、app2) のアクセス権を付与するためのアクセスポリシーを追加します。
-
アクセスを許可する際に考慮する必要があるユーザーグループとネットワークロケーションを指定する条件を設定するために、セッションポリシーを追加します。
-
ユーザー条件を選択し、すべてのユーザーに設定します。
-
ネットワークロケーション条件を追加します。これをいずれかに一致に設定し、ネットワークロケーション「hospital_network1」を指定します。これにより、「hospital_network1」からのトラフィックがバックエンドアプリに直接流れるようになります。
このシナリオでは、ルーティング例外を有効にすることもできます。たとえば、app1が病院ネットワーク上でも常にトンネル経由で送信される必要がある場合、アクセスポリシーでapp1のドメインに対してルーティング例外を設定できます。これが完了すると、ルーティング例外がセッションポリシーよりも優先されます。
セッションポリシーを使用して病院ネットワーク内で直接ルーティングを構成する
セッションポリシーを使用して、NetScaler Gatewayのトンネリングをバイパスして、ユーザーがバックエンドアプリケーションに直接アクセスできるようにすることができます。
セッションポリシーの設定の詳細については、「セッションポリシーの構成」を参照してください。
