StoreFront とゲートウェイの統合の設計

寄稿者

著者: Sarah Steinhoff

この記事の目的は、Citrix Gateway とStoreFront との統合について少し詳しく説明することです。設定の意味と、設定の構成方法に関する設計上の考慮事項です。

Gateway URL、コールバック URL、および GSLB URL

StoreFront では、管理者は、1つのストアでGatewayパススルー認証に使用できる複数のGatewayを定義できます。これは、大規模なグローバル展開で構成する必要があるストアの数を最小限に抑えるため、非常に有益です。この統合が正常に機能するためには、Citrix Gateway URL、vServerのIPアドレス、コールバックURL、GSLBのURLという4つの主要なパラメータがあることがわかります。これらについては、以下のセクションで説明します。

Gateway URL

Gatewayの設定の最初の設定画面では、管理者にわかりやすい表示名と、次に示すように、ユーザーが入力した URL であるGateway URL を入力するように求められます。

全般設定 図1:一般設定

StoreFront では、構成で定義されているGatewayからのGatewayパススルーのみを許可します。Citrix Gateway では、ユーザーのWebブラウザまたはWorkspaceアプリ(Receiver)クライアントに入力されたURLが取得され、HTTPヘッダー(XCITRIXVIA)に挿入され、StoreFront に返されます。その後、StoreFront は定義されたGatewayURLの1つに対してこの値を照合しようとします。したがって、StoreFront へのGatewayパススルーが機能するには、「GatewayURL」フィールドは必須であり、ユーザーのWebブラウザまたはWorkspaceアプリ(Receiver)クライアントに入力された内容と一致する必要があります。

コールバック URL および vServer IP アドレス

次に、いくつかのオプションのフィールドについて説明します。vServerのIPアドレスとコールバックURL、その使用方法が関連しているため、一緒にカバーされます。これらのフィールドは、次に示すように、Gateway構成ウィザードの [認証設定] 画面に表示されます。

全般設定 図2:認証の設定

コールバックURL は、StoreFront でユーザーのGatewayセッションに関する追加情報を収集するために使用されます。認証には厳密には使用されません。代わりに、ユーザーのセッションに適用されたGatewayセッションポリシーの名前などのものを照会します。これらの追加情報は、CVAD Access Controlベース (SmartAccess) ポリシーフィルタの一部として使用できます。また、ユーザーのGatewayセッションで追加の検証を実行するためにスマートカードと SAML が使用されている場合など、「パスワードなし」の認証シナリオでも必要です。これらのシナリオのいずれかが実行されない場合、[コールバック URL] フィールドと [vServer IP アドレス] フィールドは必須ではなく、空白のままにしておくことができます。

コールバックURLが必要で、複数のGatewayが1つのストアにリンクされている場合、StoreFront では、トラフィックがGatewayを通過しているかどうかだけでなく、どのGateway vServerからトラフィックが発信されているかを正しく識別する方法が必要です。これは、ユーザーのセッション。StoreFront は、まず、前述のXCITRIXVIA HTTPヘッダーを介して受信するGatewayURLを照合することによってこれを行います。同じGateway URLが指定されている複数のGateway(同じURLが複数の個別のGateway vServerに解決されるGSLBアーキテクチャで発生する)がある場合、StoreFront はIPアドレスを使用してGatewayを識別します。これは一意の値である必要があります。StoreFront は、別のHTTPヘッダー(XCITRIXVIAVIP)を介してGatewayからvServerのVIPアドレスを受け取り、割り当てられたGatewayの1つにある vServerのIPアドレス フィールドの値との照合を試みます。StoreFront がvServerのIPアドレス一致に基づいて1つのGatewayを識別できると仮定すると、コールバックは正常に完了します。したがって、vServer IP アドレスが必要になるのは、コールバック URL が指定され、同じGateway URL が定義されているストアに複数のGatewayがバインドされている場合だけです。

GSLB URLs

最後に、GUIに表示されていないパラメータ: GSLB URL。StoreFront バージョン3.9では、 PowerShell 経由でのみ GSLB URLパラメータを指定する機能が導入されました。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の問題が発生した場合に、各Gatewayで個別に認証をテストし、定義されるGatewayごとに別の一意の名前を作成できるようにしたいと考えています。つまり、次のように合計 6 つのGatewayをストア用に構成する必要があります。

表示名 Gateway 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.2 https://callback-eu.nsg.com
GSLB AP https://www.nsg.com 3.3.3.3 https://callback-ap.nsg.com
US Gateway https://us.nsg.com 1.1.1.1 https://callback-us.nsg.com
EU Gateway https://eu.nsg.com 2.2.2.2 https://callback-eu.nsg.com
AP Gateway https://ap.nsg.com 3.3.3.3 https://callback-ap.nsg.com

表1:完全なGatewayリスト

代わりに、GSLB URLパラメータを利用することで、定義されたGatewayの数を半分に減らすことができ、ユーザーはすべてのGSLBおよび一意のGatewayアドレスを介して次のように接続できます。

表示名 Gateway URL 仮想サーバの IP アドレス コールバック URL GSLBのURL
US Gateway https://us.nsg.com 1.1.1.1 https://callback-us.nsg.com https://www.nsg.com
EU Gateway https://eu.nsg.com 2.2.2.2 https://callback-eu.nsg.com https://www.nsg.com
AP Gateway https://ap.nsg.com 3.3.3.3 https://callback-ap.nsg.com https://www.nsg.com

表 2: GSLB URL を使用した統合Gatewayリスト

さらに、パラメータは「GslbUrl」と呼ばれていても、Gateway定義の代替ホスト名として機能します。したがって、GSLB アドレスである 必要はありません 。同じGateway vServer にアクセスできる別の名前だけです。もう 1 つのユースケースは、同じ vServer にルーティングされる外部/内部Gatewayアドレスを使用して DNS を分割する場合です。

このパラメーターはWorkspaceアプリ(Receiver)では認識されないため、ほとんどの場合、Workspaceアプリ(Receiver)クライアントは引き続きGSLBアドレスを使用し、Webブラウザーを介して接続するときにGatewayごとのURLを使用できます。

表示名 Gateway URL 仮想サーバの IP アドレス コールバック URL GSLB URL
US Gateway https://www.nsg.com 1.1.1.1 https://callback-us.nsg.com https://us.nsg.com
EU Gateway https://www.nsg.com 2.2.2.2 https://callback-eu.nsg.com https://eu.nsg.com
AP Gateway https://www.nsg.com 3.3.3.3 https://callback-ap.nsg.com https://ap.nsg.com

表 3: 受信機およびWorkspaceアプリで調整された GSLB URL

デザインのポイント

前のセクションを要約すると、次のようになります。

  • Gateway URLは常に必要であり、WebブラウザまたはWorkspaceアプリ(Receiver)クライアントに入力するものと一致する必要があります。
  • コールバックURLは、SmartAccess CVADポリシーまたはパスワードなしの認証方法(スマートカード、SAMLなど)が使用されている場合にのみ必要です。
  • vServer IP アドレスは、コールバック URL が指定され、同じGateway URL が指定されているストアに複数のGatewayがバインドされている場合にのみ必要です。
  • GSLB URLは、StoreFront 3.9で追加された新しいパラメータで、複数のURLを介して単一のGateway vServerにアクセスできる場合に、StoreFrontとのGateway統合を簡素化します。
  • Workspaceアプリ(Receiver)はGSLB URLパラメータを読み取らないため、Gateway URLは常にこれらのクライアントが使用するURLであり、GSLB URLはWebブラウザベースの接続で使用できる代替URLである必要があります

「デフォルト・アプライアンス」の選択

管理者がストアのリモートアクセスを有効にする場合、以下のスクリーンショットに示すように「デフォルトアプライアンス」を定義する必要があります。

デフォルトアプライアンス 図3:デフォルトのアプライアンス

Webブラウザ・ベースのアクセスでは、「デフォルトのアプライアンス」設定に影響はありません。Workspaceアプリ(Receiver)ベースのアクセスでは、この設定はストア構成の一部としてストアに接続するとReceiverにダウンロードされ、その後はGatewayがデフォルトで使用されます。定義されたすべてのGatewayが同じGateway URLを共有している場合、これは影響しません(Receiverは認証のためにURLをプルするためにそのGateway定義を使用するだけです。したがって、GSLB構成では、そのクエリは引き続きGSLBルーティングされます)。前述のように、Workspaceアプリ(Receiver)は「GSLB URL」パラメータを読み取らないため、前のセクションの「表3:ReceiverおよびWorkspaceアプリ用に調整されたGSLB URL」に示すように、デフォルトアプライアンスとして定義されたGatewayに適切なGateway URLを定義する必要があります。

ストアにバインドされたGatewayに異なるGateway URLがある場合、デフォルトとして定義されているもののいずれかが、すべてのReceiverクライアントで使用されます。これは、異なるユーザーセットによって使用される異なるゲートウェイを定義している場合に問題になります。たとえば、トークンを使用するユーザーに対して LDAP+RADIUS 認証が設定されたGatewayと、スマートカード認証が設定されたGatewayが 1 つあるとします。ユーザーがスマートカードGatewayのURLをWorkspaceアプリ(Receiver)に入力しても、StoreFront でデフォルトのLDAP+RADIUS Gatewayが定義されている場合、Workspaceアプリ(Receiver)がStoreFrontに接続して構成をキャッシュした後、以降のすべての認証リクエストがLDAP+RADIUS Gatewayに送信されます。ユーザーが最初に入力したものにもかかわらず。これを回避する唯一の方法は、別のストアまたはサーバーグループです。

デザインのポイント

要約すると、次のようになります。

  • リモートアクセスが有効になっているストアには、Workspaceアプリ(Receiver)クライアントを使用するGateway URLを定義するデフォルトのGatewayがあります。
  • 複数のGateway URLとWorkspaceアプリ(Receiver)が開始するアクセスを利用するには、個別のストアまたはStoreFront サーバーグループを定義する必要があります。

最適な HDX ルーティング

認証の実行以外に、StoreFront でゲートウェイが定義されるもう1つの理由は、最適なHDXルーティングです。この設定では、Citrix Virtual Apps and Desktops サイトまたはゾーンごとにGatewayが割り当てられます。この設定の目的は、ユーザーの元の認証ポイントとは異なる可能性があるGateway(ユーザーのセッションをホストするVDAに近いGatewayなど)を介してICA接続を再ルーティングすることです。この「最適」Gatewayが認証を実行しない場合は、セッションプロキシにバインドされたSTAサーバーのみが必要で、StoreFront で「HDXルーティングのみ」Gatewayタイプとして設定できるため、すべての認証設定が排除されます。

以下に示すストア設定でGatewayをサイト(Delivery Controllerの管理経由)またはゾーン(ゾーンの管理経由)に割り当てる場合、オプションの 外部のみチェックボックスがあります。

最適な HDX ルーティング 図4:最適なHDXルーティング

この設定は、「最適な」Gatewayが「外部から」発信されたICAセッションにのみ使用されることを意味します。つまり、認証タイプとしてGatewayパススルーを使用するセッション(StoreFront では、ユーザーが企業ネットワークの外部から発信されているものと見なされます)。この設定は、StoreFront で直接認証を行うユーザーには適用されません(StoreFrontでは、ユーザーが企業ネットワーク内にあると見なされます)。このチェックボックスをオフにすると、そのサイトまたはゾーン宛てのICAセッションはすべて、ユーザーが外部か内部かにかかわらず、定義されたGatewayを介してルーティングされます。[内部のみ] チェックボックスはありません。つまり、定義されたGateway URL は、すべての可能なユーザロケーションから到達可能である必要があるため、スプリット DNS を使用しなければ困難になる可能性があります。これは、Optimal HDXルーティングを使用した複雑なアーキテクチャシナリオで、個別のストア(ストアレベルの設定であるため)が必要になる場合もあります。

デザインのポイント

要約すると、次のようになります。

  • 最適なHDXルーティングに使用されるGatewayでは、STAサーバーのみバインドが必要
  • 最適なHDXルーティングに使用されるGatewayは、「外部のみ」または「外部と内部」のいずれかですが、「内部のみ」ではありません。
  • 最適なHDXルーティングを実現するために、別々のストアまたはサーバーグループで内部GatewayURLと外部GatewayURLを定義する必要がある

ビーコン

ビーコンはStoreFront 構成のGatewayとは別に定義され、ストアのリモートアクセスを有効にし、最初のGatewayを構成すると自動的に有効になります。ビーコンは、Workspace app(Receiver)がエンドポイントクライアントが企業ネットワークの内部または外部にあるかどうかを識別し、クライアントが「内部」であると判断された場合はStoreFront ベースURL、またはデフォルトのGatewayアドレス(クライアントはユーザーに追加の入力を求めることなく、「外部」であると判断されます。これを行うために、Workspace app(Receiver)はまず内部ビーコンアドレスを照会し(インターネットに直接接続する外部のアドレスが常に到達可能であると仮定して)、内部ビーコンアドレスにフォールバックします。内部URLに到達できる(HTTP 200レスポンスを取得する)場合、クライアントは企業ネットワーク上にあると見なされ、StoreFront ベースURLに転送されます。

ビーコンの管理 図5:ビーコンの管理

ユーザーがWebブラウザを介して接続している場合、ビーコンはまったく使用されません。これは、ユーザーがブラウザバーにURLを入力して入力を提供し、したがって、特定のアドレスにブラウザを指示するためです。Workspaceアプリ(Receiver)では、初期構成後、ユーザーは使用するURLについてそれ以上の入力を提供しません。Workspaceアプリ(Receiver)には、ベースURLと構成の一部としてキャッシュされたGateway URLがあり、ユーザーがアプリケーションを使用しようとしたときに使用するURLをユーザーに代わってインテリジェントに選択できる必要があります。

同じGateway URLとStoreFront ベースURLを使用しない限り、ビーコンアドレスを変更したり微調整したりする必要はありません。この場合、外部ビーコンと内部ビーコンは同じになり、内部URLは外部からアクセス可能になり、目的は破られます。そのため、管理者は内部ビーコンの「ビーコンアドレスの指定」を選択し、企業ネットワークからのみアクセス可能な Web サイトを入力する必要があります。それ以外の場合、ビーコンアドレスがどのように活用されているかを理解して、Web ブラウザベースのアクセスに関する問題を調査する際にビーコンアドレスが調査されないようにすることは、単にトラブルシューティングの方法です。

デザインのポイント

要約すると、次のようになります。

  • ビーコンはWorkspaceアプリ(Receiver)クライアントのみを使用
  • ビーコンは、StoreFront ベースURLがGateway URLと一致する(企業ネットワークの外部からアクセスできる)場合にのみ変更する必要があります。

参照ドキュメント

ゲートウェイとStoreFront の統合

最適なHDXルーティングの構成

StoreFront の新機能