設計上の決定:StoreFrontとゲートウェイ統合の設計
この記事の目的は、Citrix GatewayとStoreFront との統合（設定の意味と構成方法に関する設計上の考慮事項）についてもう少し詳しく説明することです。
ゲートウェイ URL、コールバック URL、および GSLB URL
StoreFront では、管理者は、1つのストアでGatewayパススルー認証に使用できる複数のGatewayを定義できます。この機能は、大規模なグローバル展開環境で構成する必要があるストア数を最小限に抑えるため、非常に役立ちます。この統合を正常に機能させるには、Citrix Gateway URL、仮想サーバーのIPアドレス、コールバックURL、およびGSLB URLの4つの主要なパラメータがあります。これらについては、以下のセクションで説明します。
Gateway URL
ゲートウェイの設定の最初の設定画面では、管理者に対して、わかりやすい表示名とゲートウェイの URL（ユーザーが入力した URL）を入力するように求められます。次に示すように、
1: 一般設定
StoreFront では、その構成で定義されているゲートウェイからのゲートウェイパススルーのみが許可されます。Citrix Gatewayは、ユーザーのWebブラウザまたはワークスペースアプリ（Receiver）クライアントに入力されたURLを取得し、HTTPヘッダー（XCITRIXVIA）に挿入します。この情報は、StoreFront に渡されます。StoreFront は、定義されたゲートウェイURLのいずれかに対してこの値を照合しようとします。StoreFrontへのゲートウェイパススルーを使用するには、ユーザーのWebブラウザまたはワークスペースアプリ（Receiver）に入力する内容と一致する必要があります。
コールバック URL と仮想サーバの IP アドレス
次に、仮想サーバーの IP アドレスとコールバック URL のいくつかのオプションフィールドについて説明します。その使用方法は関連し、まとめて説明します。次のように、これらのフィールドは、ゲートウェイ構成ウィザードの［認証設定］画面に表示されます。
2: 認証設定
コールバックURLは、ユーザーのGatewayセッションに関する追加情報を収集するためにStoreFront によって使用されます。認証には厳密には使用されません。代わりに、ユーザーのセッションに適用されたゲートウェイセッションポリシーの名前などを照会します。これらの追加情報は、CVAD Access Controlベース (SmartAccess) ポリシーフィルタの一部として使用できます。また、ユーザーのゲートウェイセッションで追加の検証を実行するためにスマートカードと SAML が使用されている場合など、「パスワードなし」認証シナリオでも必要です。グローバルサイト負荷分散（GSLB）環境では、コールバックURLとvServerIPアドレスの両方が使用されます。これらのシナリオについては、この記事の後半で説明します。これらのシナリオのいずれかが実行されていない場合は、[コールバック URL] フィールドと [仮想サーバー IP アドレス] フィールドの両方が必須ではなく、空白のままにすることができます。
コールバックURLが必要で、複数のゲートウェイが1つのストアにリンクされている場合、StoreFront では、トラフィックがゲートウェイを経由しているかどうかだけでなく、トラフィックが送信されているGateway仮想サーバーを正しく識別して、ユーザーのセッション。StoreFront は、最初にゲートウェイURLを照合することによって、このアクションを実行します。これは、以前に説明したように、XCITRIXVIA HTTPヘッダーを介して受信します。同じゲートウェイURLが指定されている複数のゲートウェイがある場合（同じURLが複数の個々のGateway仮想サーバーに解決されるGSLBアーキテクチャで発生します）、StoreFront はIPアドレスを使用してゲートウェイを識別します。これは一意の値です。StoreFront は、ゲートウェイから別のHTTPヘッダー（XCITRIXVIAVIP）を介して仮想サーバーのVIPアドレスを受け取ります。受信されると、割り当てられたゲートウェイの 1 つのvServer IP アドレスフィールドの値との照合を試みます。StoreFront が仮想サーバーのIPアドレスの一致に基づいて1つのゲートウェイを識別できると仮定すると、コールバックは正常に完了します。したがって、仮想サーバーの IP アドレスが必要となるのは、コールバック URL が指定され、同じゲートウェイ URL が定義されているストアに複数のゲートウェイがバインドされている場合のみです。
GSLB URLs
最後に、GUI に表示されないパラメータ:GSLB URL。StoreFront バージョン3.9では、PowerShell経由でGSLBURLパラメーターをゲートウェイ定義に指定する機能が導入されました。このGSLB URLは、StoreFront が同じGateway定義に対する認証要求を受け入れる代替ソースとして機能します。このパラメータは、Get-stfroamingGatewayコマンドの出力に表示されます。このパラメータの目的は、管理を簡素化するために、単一のストアに対して定義する必要のあるGatewayの総数を減らすことです。Gateway オブジェクトを使用しない場合、Gateway オブジェクトは、ユーザーが使用できるすべてのゲートウェイ URL +一意のコールバック URL の組み合わせに対して定義する必要があります。この組み合わせは、エンタープライズ環境ですばやく追加できます。
たとえば、統一された GSLB アドレスの背後にある 3 つのグローバルGateway (https://www.nsg.com) があります。1 つはアメリカ、1 つはヨーロッパ、もう 1 つはアジアで、それぞれ一意のコールバック URL を持つ場合、3 つの定義済みGatewayが必要です。それに加えて、これらの管理者は、各ゲートウェイで個別に認証をテストできるようにしたいと考えています。これは、GSLB の問題があるかどうかを理解する上で重要です。その結果、ゲートウェイごとに別の一意の名前が定義されます。このインスタンスは、ストア用に合計 6 つのゲートウェイを構成する必要があることを意味し、次のようになります。
| 表示名 | ゲートウェイ URL | 仮想サーバーのIPアドレス | コールバック URL |
|---|---|---|---|
| GSLB US | https://www.nsg.com |
1.1.1.1 | https://callback-us.nsg.com |
| GSLB EU | https://www.nsg.com |
2.2.2 | https://callback-eu.nsg.com |
| GSLB AP | https://www.nsg.com |
3.3.3.3 | https://callback-ap.nsg.com |
| 我们的网关 | https://us.nsg.com |
1.1.1.1 | https://callback-us.nsg.com |
| EU ゲートウェイ | https://eu.nsg.com |
2.2.2 | https://callback-eu.nsg.com |
| AP ゲートウェイ | https://ap.nsg.com |
3.3.3.3 | https://callback-ap.nsg.com |
表1：完全なGatewayリスト
代わりにGSLB URLパラメータを適用することで,定義されたゲートウェイの数を半分に減らすことができます。ただし、ユーザーはすべての GSLB アドレスと一意のゲートウェイアドレスを介して次のように接続できます。
| 表示名 | ゲートウェイ URL | 仮想サーバーのIPアドレス | コールバック URL | GSLBのURL |
|---|---|---|---|---|
| 我们的网关 | https://us.nsg.com |
1.1.1.1 | https://callback-us.nsg.com |
https://www.nsg.com |
| EU ゲートウェイ | https://eu.nsg.com |
2.2.2 | https://callback-eu.nsg.com |
https://www.nsg.com |
| AP ゲートウェイ | https://ap.nsg.com |
3.3.3.3 | https://callback-ap.nsg.com |
https://www.nsg.com |
表 2: GSLB URL を使用した統合Gatewayリスト
パラメータは「GSLBurl」と呼ばれていますが、そのゲートウェイ定義の代替ホスト名として機能します。GSLBアドレスである必要はありません。同じ Gateway 仮想サーバーにアクセスできる別の名前だけです。別のユースケースとして、同じ仮想サーバーにルーティングされる外部/内部 Gateway アドレスを使用して DNS を分割できます。
このパラメーターは Workspace アプリ（Receiver）では認識されません。したがって、通常、上記の例の URL は反転され、Workspace アプリ（Receiver）クライアントは引き続きGSLBアドレスを使用でき、Webブラウザ経由で接続するときにゲートウェイ単位の URL を使用できます。
| 表示名 | ゲートウェイ URL | 仮想サーバの IP アドレス | コールバック URL | GSLBのURL |
|---|---|---|---|---|
| 我们的网关 | https://www.nsg.com |
1.1.1.1 | https://callback-us.nsg.com |
https://us.nsg.com |
| EU ゲートウェイ | https://www.nsg.com |
2.2.2 | https://callback-eu.nsg.com |
https://eu.nsg.com |
| AP ゲートウェイ | https://www.nsg.com |
3.3.3.3 | https://callback-ap.nsg.com |
https://ap.nsg.com |
表3：ReceiverおよびWorkspaceアプリ用に調整されたGSLB URL
デザインのポイント
前のセクションをまとめると、次のようになります。
- Gateway URLは常に必要であり、WebブラウザまたはWorkspaceアプリ（Receiver）クライアントに入力するものと一致する必要があります。
- コールバックURLは、SmartAccess CVADポリシー、パスワードなしの認証方法 (スマートカード、SAMLなど)、またはGSLB URLが使用されている場合にのみ必要です
- 仮想サーバーの IP アドレスは、コールバック URL が指定され、ストアにバインドされたゲートウェイが同じゲートウェイ URL が指定されている複数のゲートウェイがある場合にのみ必要です。
- GSLB URLは、StoreFront 3.9で追加された新しいパラメーターです。1つのGateway仮想サーバーに複数のURLからアクセスできる場合、URLはStoreFront とのGateway統合を簡素化します
- ワークスペースアプリ（Receiver）は、GSLB URL パラメーターを読み取らないため、ゲートウェイ URL は常にそれらのクライアントで使用される URL であり、GSLB URL は Web ブラウザーベースの接続で使用できる代替の URL です
「デフォルトアプライアンス」の選択
管理者がストアのリモートアクセスを有効にする場合は、スクリーンショットに示すように「デフォルトアプライアンス」を定義する必要があります。
3: デフォルトアプライアンス
Webブラウザベースのアクセスの場合、「デフォルトアプライアンス」設定は影響しません。Workspaceアプリ（Receiver）ベースのアクセスの場合、この設定はストア構成の一部としてストアへの接続時にReceiverにダウンロードされます。ゲートウェイは、その後デフォルトで使用されます。定義されたすべてのゲートウェイがゲートウェイURLを共有している場合、この場合も、発生に影響はありません（Receiverはそのゲートウェイ定義を使用してURLをプルして認証を行うため、GSLB構成では、そのクエリはGSLBルーティングされます）。前述のように、Workspaceアプリ（Receiver）は「GSLB URL」パラメータを読み取らないため、前のセクションの「表3: ReceiverとWorkspaceアプリ用に調整されたGSLB URL」に示すように、デフォルトアプライアンスとして定義されたゲートウェイには、適切なゲートウェイURLが定義されている必要があります。
ストアにバインドされたGatewayに異なるGateway URLがある場合、デフォルトとして定義されているもののいずれかが、すべてのReceiverクライアントで使用されます。この発生は、異なるユーザーセットによって異なるゲートウェイを定義した場合に問題になります。たとえば、トークンを使用するユーザーに対して LDAP+RADIUS 認証が設定されたGatewayと、スマートカード認証が設定されたGatewayが 1 つあるとします。ユーザーがワークスペースアプリ（Receiver）にスマートカードゲートウェイURLを入力し、StoreFront でLDAP+RADIUSゲートウェイがデフォルトとして定義されている場合、ワークスペースアプリ（Receiver）がStoreFront に接続して構成をキャッシュした後、今後すべての認証要求がLDAP+RADIUSゲートウェイに送信されます。ユーザーが最初に入力した内容にもかかわらず。この問題を回避する唯一の方法は、別のストアまたはサーバーグループです。
デザインのポイント
要約すると:
- リモートアクセスを有効にしたストアには、ワークスペースアプリ（Receiver）クライアントが使用するゲートウェイURLを定義するデフォルトゲートウェイがあります
- 複数のゲートウェイURLとワークスペースアプリ（Receiver）が開始するアクセスを使用するには、ストアまたはStoreFront サーバーグループを個別に定義する必要があります
最適な HDX ルーティング
認証を実行する以外では、StoreFront でゲートウェイを定義できるもう1つの理由は、最適なHDXルーティングです。この設定では、Citrix Virtual Apps and Desktops サイトまたはゾーンごとにGatewayが割り当てられます。この設定の目的は、ユーザーの元の認証ポイントとは異なるゲートウェイ（ユーザーのセッションをホストしているVDAに近いゲートウェイ経由など）を介してICA接続を再ルーティングすることです。この「最適な」ゲートウェイで認証を実行しない場合は、セッションプロキシにバインドされたSTAサーバーのみを必要とし、StoreFront で「HDXルーティングのみ」ゲートウェイの種類として設定できます。これにより、すべての認証設定が排除されます。
以下に示すストア設定でGatewayをサイト（Delivery Controllerの管理経由）またはゾーン（ゾーンの管理経由）に割り当てる場合、オプションの [外部のみ] チェックボックスがあります。
-
- 最適なHDXルーティング
この設定では、「最適」ゲートウェイは、「外部」から発信されるICAセッションにのみ使用されます。つまり、認証タイプとしてゲートウェイパススルーを使用するセッション（StoreFront では、ユーザーが企業ネットワークの外部から発信されていることを意味します）。この設定は、StoreFront で直接認証を行うユーザーには適用されません（StoreFront は、ユーザーが企業ネットワーク内にあることを意味します）。このボックスの選択を解除すると、そのサイトまたはゾーン宛てのICAセッションはすべて、ユーザーが外部か内部かにかかわらず、定義されたゲートウェイを介してルーティングされます。「内部のみ」チェックボックスはありません。つまり、定義されたGateway URL は、すべての可能なユーザロケーションから到達可能である必要があるため、スプリット DNS を使用しなければ困難になる可能性があります。これは、最適なHDXルーティングを使用する複雑なアーキテクチャシナリオで、（これはストアレベルの設定であるため）別々のストアが必要となる別のケースです。
デザインのポイント
要約すると:
- 最適なHDXルーティングに使用されるGatewayでは、STAサーバーのみバインドが必要
- 最適なHDXルーティングに使用されるゲートウェイは、「外部のみ」または「外部と内部」のいずれかになりますが、「内部のみ」にはできません
- 最適なHDXルーティングを実現するために、別々のストアまたはサーバーグループで内部GatewayURLと外部GatewayURLを定義する必要がある
ビーコン
ビーコンはStoreFront 構成のGatewayとは別に定義され、ストアのリモートアクセスを有効にし、最初のGatewayを構成すると自動的に有効になります。ビーコンは、Workspaceアプリ（Receiver）がエンドポイントクライアントが企業ネットワーク内または外部にあるかどうかを識別し、クライアントが「内部」と判断された場合はStoreFront ベースURL、またはデフォルトのゲートウェイアドレス（クライアントは、ユーザーに入力を求めずに「外部」であると判断されます。これを行うには、Workspace アプリ（Receiver）は、まず内部ビーコンアドレス（インターネットに直接接続できる外部のアドレスが常に到達可能であると仮定）をクエリし、内部で障害が発生した場合にのみ外部ビーコンアドレスにフォールバックします。内部URLに到達できる場合（HTTP 200レスポンスを取得）、クライアントは企業ネットワーク上に存在すると見なされ、StoreFront ベースURLに送信されます。
5: ビーコンの管理
ユーザーがWebブラウザを介して接続している場合、ビーコンはまったく使用されません。これは、ユーザーがブラウザバーに URL を入力して入力を提供し、したがって、ブラウザを特定のアドレスに誘導するためです。Workspace アプリ（Receiver）では、初期構成後、ユーザーはどのURLを使用するかについてそれ以上の入力を提供しません。Workspaceアプリ（Receiver）には、構成の一部としてキャッシュされたベースURLと構成済みのゲートウェイURLがあり、ユーザーがアプリケーションを使用しようとしたときに使用するURLをユーザーに代わってインテリジェントに選択できる必要があります。
同じゲートウェイURLとStoreFrontベースURLが使用されていない限り、ビーコンアドレスを変更したり微調整したりする必要はありません。この場合、外部ビーコンと内部ビーコンは同じになり、内部 URL は外部からアクセス可能になり、目的が破られます。したがって、管理者は、内部ビーコンの「ビーコンアドレスの指定」を選択し、企業ネットワークからのみアクセス可能な Web サイトを入力する必要があります。それ以外の場合は、Webブラウザベースのアクセスに関する問題を調査するときにビーコンアドレスがどのように適用されるかを理解して、ビーコンアドレスの適用方法を理解することは単に良いトラブルシューティング方法です。
デザインのポイント
要約すると:
- ビーコンはワークスペースアプリ（Receiver）クライアントのみを使用
- ビーコンは、StoreFront ベースURLがゲートウェイURLと一致する（企業ネットワーク外からアクセス可能）場合にのみ変更されます。