Citrix Virtual Apps and Desktops を使用したGoogle Cloud Platform(GCP)の共有 VPC サポート

概要

Citrix Virtual Apps and Desktops サービスは、Google Cloud Platform(GCP)共有VPCをサポートしています。このドキュメントでは、次の内容について説明します。

  • Googleクラウド共有VPCに対するCitrixサポートの概要。

  • Google クラウド共有 VPC に関連する用語の概要。

  • 共有 VPC の使用をサポートするための Google クラウド環境の設定

  • ホスト接続およびマシンカタログのプロビジョニングにGoogle共有VPCを使用する。

  • 一般的なエラー状態とその解決方法。

前提条件

このドキュメントでは、Google Cloudに関する知識と、GoogleクラウドプロジェクトでマシンカタログをプロビジョニングするためのCitrix Virtual Apps and Desktops サービスの使用を前提としています。

Citrix Virtual Apps and Desktops Service用のGCPプロジェクトを設定するには、製品ドキュメントを参照してください。

結果

共有VPC に展開されたマシンカタログのプロビジョニングと管理に対するCitrix MCSのサポートは、今日のローカルVPCでサポートされている機能と同等です。

それらが異なっている2つの方法があります。

  • MCS が共有 VPC リソースにアクセスして使用できるようにするには、ホスト接続の作成に使用するサービスアカウントに、さらにいくつかのアクセス許可を付与する必要があります。

  • サイト管理者は、イメージのマスタリングプロセスで使用するために、入力と出力用に 1 つずつ 2 つのファイアウォールルールを作成する必要があります。

これらの両方については、このドキュメントの後半で詳しく説明します。

グーグルクラウド共有VPC

GCP 共有 VPC は、共有サブネットが使用可能になるホストプロジェクトと、リソースを使用する 1 つ以上のサービスプロジェクトで構成されます。

共有 VPC を使用すると、企業の共有 Google クラウドリソースをより一元的に管理、使用、管理できるため、大規模なインストールに適しています。グーグルクラウドはこのように説明しています:

「共有 VPC を使用すると、会社は複数のプロジェクトから共通仮想プライベートクラウド(VPC)ネットワークにリソースを接続できるため、ネットワーク内の内部 IP を使用して、相互に安全かつ効率的に通信できます。共有 VPC を使用する場合は、プロジェクトをホストプロジェクトとして指定し、1 つ以上の他のサービスプロジェクトをプロジェクトにアタッチします。ホストプロジェクト内の VPC ネットワークは、共有 VPC ネットワークと呼ばれます。対象リソースは、共有 VPC ネットワーク内のサブネットを使用できます。

上記の段落は、Googleドキュメントサイトの一部です。

新しい権限が必要です

Citrix Virtual Apps and Desktops、およびGoogle Cloudで作業する場合は、ホスト接続の作成時に特定の権限を持つGCPサービスアカウントを指定する必要があります。上記のように、GCP 共有 VPC を使用するには、共有 VPC ベースのホスト接続の作成に使用するサービスアカウントに、追加のアクセス許可を付与する必要があります。

技術的に言えば、必要な権限は「新規」ではありません。なぜなら、GCPとローカルVPCでCitrix Virtual Apps and Desktops topsを利用するためにすでに必要であるため、必要な権限は「新規」ではありません。変更点として、共有 VPC リソースへのアクセスを許可するために、アクセス許可を付与する必要があります。これは、ホストプロジェクトの IAM ロールにサービスアカウントを追加することで実現されます。詳細については、このドキュメントの「操作方法」セクションで説明します。

注:

現在出荷されているCitrix Virtual Apps and Desktops tops製品に必要な権限を確認するには、Citrixドキュメントサイトリソースの場所の説明を参照してください。

ホスト接続に関連付けられたサービスアカウントには、合計で最大 4 つの追加のアクセス許可を付与する必要があります。

  1. 計算.firewalls.list-必須

    この権限は、Citrix MCSが共有VPCに存在するファイアウォールルールのリストを取得できるようにするために必要です(詳細は後述)。

  2. 計算.networks.list-必須

    この権限は、Citrix MCSがサービスアカウントで使用できる共有VPCネットワークを識別できるようにするために必要です。

  3. compute.subnetworks.list — 必須かもしれません (下記参照)

    この権限は、MCS が可視共有 VPC 内のサブネットを識別できるようにするために必要です。

    注:

    この権限は、ローカル VPC の使用にはすでに必要ですが、共有 VPC ホストプロジェクトでも割り当てる必要があります。

  4. compute.subnetworks.use- 必須かもしれません (下記参照)

    この権限は、プロビジョニングされたマシンカタログのサブネットリソースを利用するために必要です。

    注:

    この権限は、ローカル VPC の使用にはすでに必要ですが、共有 VPC ホストプロジェクトでも割り当てる必要があります。

最後の 2 つの項目は「必須である可能性があります 」と記載されています。これらのアクセス許可を扱う際には、次の 2 つのアプローチを考慮する必要があります。

  • プロジェクトレベルの権限

    • ホストプロジェクト内のすべての共有VPCへのアクセスを許可します。

    • アクセス許可 #3 と #4 をサービスアカウントに割り当てる必要があります。

  • サブネットレベルの権限

    • 共有VPC内の特定のサブネットへのアクセスを許可します。

    • アクセス許可 #3 と #4 はサブネットレベルの割り当てに固有であるため、サービスアカウントに直接割り当てる必要はありません。

このマニュアルの「操作方法」セクションで、両方のアプローチの例を以下に示します。

どちらのアプローチも同様に機能します。組織のニーズやセキュリティ基準に合わせてモデルを選択します。プロジェクトレベルの権限とサブネットレベルの権限の違いに関する詳細については、Google Cloudドキュメントを参照してください。

プロジェクトをホストする

Google クラウドで共有 VPC を使用するには、まず 1 つの Google クラウドプロジェクトをホストプロジェクトに指定して有効にします。このホストプロジェクトには、組織内の他の Google クラウドプロジェクトによって利用される 1 つまたは複数の共有 VPC ネットワークが含まれています。

共有 VPC ホストプロジェクトの設定、サブネットの作成、プロジェクト全体または特定のサブネットの他の Google クラウドプロジェクトとの共有は、純粋に Google Cloud 関連のアクティビティであり、このドキュメントの対象には含まれません。共有 VPC の作成と操作に関連する Google Cloud ドキュメントを 参照してください。ここ

ファイアウォール規則

マシンカタログのプロビジョニングまたは更新時に発生するバックグラウンド処理における重要なステップは、 マスタリングと呼ばれます。これは、選択したマシンイメージがコピーされ、カタログのマスターイメージシステムディスクとして準備される場合です。マスタリング中、このディスクは一時仮想マシン( 準備マシン )に接続され、準備スクリプトを実行できるように起動されます。この仮想マシンは、 すべてのインバウンドおよびアウトバウンドネットワークトラフィックを防止する分離された環境で実行する必要があります 。これは、入力用と出力用の Deny-All ファイアウォールルールのペアによって実現されます。

GCP ローカル VPC を使用する場合、MCS はローカルネットワーク内でこのファイアウォールルールペアをその場で作成し、マスタリングのためにマシンに適用し、マスタリングの完了時に削除します。

共有VPC は企業リソースレベルが高く、通常、より厳格なセキュリティプロトコルが設定されているため、共有VPC を利用するために必要な新しいアクセス許可の数を最小限に抑えるすることをお勧めします。このため、サイト管理者は、優先順位が最も高い各共有 VPC でファイアウォールルールのペア(入力と 1 つの出力)を作成し、 各ルールに新しいターゲットタグを適用する必要があります 。[ターゲットタグ] の値は次のとおりです。

citrix-provisioning-quarantine-firewall

MCSはマシンカタログを作成または更新するときに、このターゲットタグを含むファイアウォールルールを検索し、ルールが正しいかどうかを調べて、 準備マシンに適用します

ファイアウォールルールが見つからない場合、またはルールが検出されたが、ルールまたは優先順位が正しくない場合は、次の形式のメッセージが返されます。

Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC \<name\> in project \<project\>. Please ensure you have created deny all firewall rules with the network tagcitrix-provisioning-quarantine-firewall and proper priority. Refer to Citrix Documentation for details.

Cloud Connector

Citrix Virtual Apps and Desktopsマシンカタログ用の共有VPCを使用する場合は、共有VPC内に存在するドメインコントローラーにアクセスするためのクラウドコネクタを2つ以上作成します。この場合、ローカルプロジェクトに GCP マシンインスタンスを作成し、追加のネットワークインターフェイスをインスタンスに追加することをお勧めします。最初のインターフェイスは、共有 VPC のサブネットに接続されます。2 番目のネットワークインターフェイスは、ローカル VPC のサブネットに接続して、ローカル VPC 踏み台サーバーを介した管理制御とメンテナンスのためのアクセスを許可します。

残念ながら、GCP インスタンスの作成後にネットワークインターフェイスを追加することはできません。これは簡単なプロセスであり、以下に説明する「方法」エントリの 1 つです。

ハウ・・・セクション

以下のセクションでは、Citrix Virtual Apps and Desktops でGoogle共有VPCを使用するために必要な構成変更を実行する手順を理解するのに役立つ一連の手順について説明します。

Google コンソールのスクリーンショットに示されている例は、すべて、 共有 VPC プロジェクト 1 という名前の仮想 Google プロジェクトで行われます

方法:新しい IAM ロールを作成する

ホスト接続の作成時に使用されるサービスアカウントには、追加のアクセス許可を付与する必要があります。共有 VPC へのデプロイの目的は、複数のプロジェクトを同じ Shared VPC にデプロイできるようにすることであるため、最も効率的なアプローチは、目的のアクセス許可を持つホストプロジェクトで新しいロールを作成し、そのロールを共有 VPC へのアクセスを必要とするサービスアカウントに割り当てることです。

以下では、 Citrix-ProjectLevel-SharedvpCroleという名前のプロジェクトレベルの役割を作成します。サブネットレベルの役割は、割り当てられた最初の 2 つのアクセス許可セットに対して同じ手順に従います。

Google コンソールの IAM と管理者

Google クラウドコンソールで IAM と管理者設定オプションにアクセスします

IAM および管理者設定オプション

役割の作成

[ ロールの作成] を選択します。

[ロールの作成] オプション

ロールの作成画面を空にする

次のような画面が表示されます。

ロールの作成画面を空にする

名前を入力し、権限を追加します

ロール名を指定します。[ アクセス許可の追加 ] をクリックして、更新プログラムを適用します。

ロール名の指定

[権限の追加] ダイアログ

[ ADD PERMISSIONS] をクリックすると、以下のような 1 つの画面が表示されます。

この画像では、「フィルタテーブル」 テキスト入力フィールドが強調表示されています。

ハイライト表示されたフィルタテーブルのテキストエントリ

compute.firewalls.list 権限を追加する

[ フィルタテーブル ] テキスト入力フィールドをクリックすると、コンテキストメニューが表示されます。

コンテキストメニュー

以下に示すように、文字列 compute.firewalls.list をコピーしてテキストフィールドに貼り付け (または入力) します。

テキストフィールドに文字列を追加する

パーミッションテーブルから除外された compute.firewalls.list エントリを選択すると、このダイアログが表示されます。

[権限] ダイアログボックス

トグルボックスをクリックして、権限を有効にします。

権限を有効にする

[ 追加] をクリックします。

[ ロールの作成 ] 画面が再表示されます。ロールに compute.firewalls.list 権限が追加されていることに注意してください。

ロールの作成画面

計算.networks.list 権限を追加する

上記と同じ手順を使用して、 compute.networks.list アクセス許可を追加します。ただし、適切なルールを選択するようにしてください。以下に示すように、 フィルタテーブルのフィールドに権限テキストを入力すると 、2 つの権限が表示されます。compute.networks.list エントリを選択します。

正しい権限を選択する

権限のエントリを修正

[ 追加] をクリックします。

ロールに追加された 2 つの必須のアクセス許可:

必須権限ロール

プロジェクトレベルまたはサブネットレベル

プロジェクトレベルのアクセスや、サブネットレベルのアクセスを使用して、より制限されたモデルなど、ロールが持つアクセスのレベルを決定します。このドキュメントでは、Citrix-ProjectLevel-SharedVpc Roleという名前のロールを作成しています。したがって、上記と同じ手順を使用して、 compute.subnetworks.list および compute.subnetworks.use パーミッションを追加します。[ Create] をクリックする直前に、4 つの権限が付与された画面は次のようになります。

4 つの権限が付与されました

[CREATE] をクリックします。

注:

サブネットレベルのロールをここで作成した場合は、2 つの追加の *compute.subnetworks.list および *compute.subnetworks.use アクセス許可を追加するのではなく、[ 作成 ] をクリックします。

Citrix-プロジェクトレベル-共有DVPCロールが作成されました

サブネットレベルの役割

方法:プロジェクトの IAM ロールをホストするサービスアカウントを追加する

新しいCitrix-ProjectLevel-SharedVpc Roleを作成したので、ホストプロジェクト内でサービスアカウントを追加する必要があります。この例では、citrix-shared-vpc-service-accountという名前のサービスアカウントを使用します 。

IAM と管理者に移動します

最初のステップは、 プロジェクトの [IAM とロール ] 画面に移動することです。コンソールで、[ IAM] と [Admin] を選択します。IAMを選択:

IAM の選択

プロジェクト権限画面

指定されたアクセス許可を持つメンバーを追加します。「 追加 」をクリックして、メンバーのリストを表示します。

メンバーのリストの表示

[メンバーの追加] パネル

下図に示すように、[ 追加 ] をクリックすると、小さなパネルが表示されます。データは、次の手順で入力されます。

[メンバーの追加] パネル

サービスアカウントの追加

フィールドにサービスアカウントの名前を入力し始めます。入力すると、Google Cloud はアクセス権限のあるプロジェクトを検索し、一致する可能性のあるリストを絞り込みます。この場合、マッチが 1 つ (入力の直下に表示される) ので、そのエントリを選択します。

サービスアカウントのエントリ

役割の選択

メンバー名 (この場合はサービスアカウント)を指定した後、共有 VPC プロジェクトとして機能するサービスアカウントのロールを選択します。表示されたリストをクリックして、このプロセスを開始します。

サービスアカウントの役割を選択

ロールの選択

ロールの選択] プロセスは、 前の「方法-新しい IAM ロールを作成する」で使用したプロセスと似ています。この場合、さらにいくつかのオプションとフィルインが表示されます。

その他の役割の選択オプション

ロールの指定

適用したいロールがわかっているので、入力を開始できます。目的のロールが表示されたら、ロールを選択します。

役割の選択

選択して保存

ロールを選択したら、[ 保存] をクリックします。

ロールを保存する

これで、ホストプロジェクトにサービスアカウントが正常に追加されました。

方法:サブネットレベルのアクセス許可

プロジェクトレベルのアクセスではなくサブネットレベルのアクセスを使用する場合は、共有 VPC で使用するサービスアカウントを、アクセスするリソースを表す各サブネットのメンバーとして追加する必要があります。この [操作方法] セクションでは、共有 VPC 内の 1つのサブネットへのアクセス権を持つsharedvpc-sa\@citrix-mcs-documentation.iam.gserviceaccount.comという名前のサービスアカウントを提供します。

[VPC] > [共有 VPC] に移動します

最初のステップは、Google コンソールの [共有 VPC] 画面に移動することです。

共有 VPC 画面

最初の共有 VPC 画面

これは、Google クラウドコンソールの共有 VPC 画面のランディングページです。このプロジェクトでは、5 つのサブネットが表示されます。この例のサービスアカウントには、2 番目のサブネットに適切なサブネット (下の一覧の最後のサブネット) へのアクセスが必要です。

2 番目のサブネットの正常なサブネットの横にあるチェックボックスをオンにします

サブネット

サービスアカウントアクセスのサブネットを選択します

最後のサブネットのチェックボックスが選択されたので、[ ADD MEMBER ] オプションが画面の右上に表示されます。

この演習では、このサブネットが共有されているユーザーの数を記録しておくと便利です。示されているように、1 人のユーザーがこのサブネットにアクセスできます。

[ メンバの追加] をクリックします。

[メンバの追加] オプション

新しいメンバー名を入力

前述の「操作方法」セクションでサービスアカウントをホストプロジェクトに追加するために必要な手順と同様に、新しいメンバー名をここにも指定する必要があります。名前を入力した後、Google Cloudは(以前のように)関連するすべての項目をリストし、関連するサービスアカウントを選択できるようにします。この場合、それは単一のエントリです。

サービスアカウントをダブルクリックして選択します

サービスアカウントオプション

新しいメンバーの役割を選択してください

サービスアカウントを選択したら、新しいメンバーのロールも選択する必要があります。

  1. 一覧で、[ ロールの選択] をクリックします。

  2. コンピュートネットワークユーザーロールをダブルクリックします

コンピュータネットワークユーザーの役割

ロールが選択されました

この図は、サービスアカウントとロールが指定されていることを示しています。残りの手順は、[ 保存 ] をクリックして変更をコミットすることです。

役割の選択

サブネットにユーザーが追加されました

変更を保存すると、メイン Shared VPC 画面が表示されます。最後のサブネットにアクセスできるユーザーの数が、予想どおりに 2 つに増加していることを確認します。

追加されたメンバー

方法:プロジェクト CloudBuild サービスアカウントを共有の VPC に追加する

すべての Google クラウドサブスクリプションには、プロジェクトの ID 番号に続いて cloudbuild.gserviceaccount が続くサービスアカウントがあります。フルネームの例 (メイドアッププロジェクト ID を使用) は次のとおりです。

705794712345@ cloudbuild.gserviceaccount。

この cloudbuild サービスアカウントは方法:プロジェクトの IAM ロールをホストするサービスアカウントを追加するのステップ 3 でホスト接続の作成に使用するサービスアカウントと同じ方法で、共有 VPC のメンバーとして追加する必要があります。

Google Cloud Console メニューで [ **ホームとダッシュボード** ] を選択すると、プロジェクトのプロジェクト ID 番号を確認できます。

プロジェクト ID 番号

画面の [ **プロジェクト情報] 領域の下にある [プロジェクト番号** ] を探します。

メンバーの追加 」フィールドに、プロジェクト番号と cloudbuild.gserviceAccount の組み合わせを入力します。コンピュータネットワークユーザーの役割を割り当てる:

ロールを割り当てる

[保存] を選択します。

方法:ファイアウォールルール

必要なファイアウォールルールの作成は、ロールを作成するよりも少し簡単です。

ホストプロジェクトを選択

このドキュメントで既に説明したように、2 つのファイアウォールルールはホストプロジェクトで作成する必要があります。

ホストプロジェクトを選択していることを確認してください

VPC ネットワーク > ファイアウォール

Google コンソールメニューから、次に示すように、[ VPC] > [ファイアウォール]に移動します。

ファイアウォールオプション

ファイアウォールルールの作成ボタン

Google コンソールの [ファイアウォール] 画面の上部には、新しいルールを作成するためのボタンがあります。

[ ファイアウォールルールの作成] をクリックします。

ファイアウォールルールの作成

[新しいファイアウォールの作成] 画面

新しいファイアウォールルールの作成に使用する画面を以下に示します。

新しいファイアウォールルールの作成

入力ルール:データの入力

まず、次のフィールドに値を追加または変更して、必要な Deny-All Ingress ルールを作成します。

  • Name

    [すべて拒否] ファイアウォールルールに名前を付けます。たとえば、 citrix-deny-all-ingress-ruleのようにします。

  • ネットワーク

    この入力ファイアウォールルールが適用される共有 VPC ネットワークを選択します。たとえば、gcp-test-vpcなどです。

  • 優先度

    このフィールドの値は重要です。ファイアウォールルールの世界では、 プライオリティ値が低いほどルールの優先順位が高くなります 。このため、すべての既定のルールの値が 66536 であるため、65536 より小さい値を持つカスタムルールは、既定のルールよりも優先されます。

    これら 2 つのルールでは、ネットワーク上で最も優先順位の高いルールが必要です。私たちは、10の値を使用します。

  • 交通の方向

    新しいルールを作成するためのデフォルトは [ Ingress] です。これはすでに選択されています。

  • マッチ時にアクション

    この値はデフォルトで [ 許可] に設定されます。Deny ( 拒否) に変更する必要があります。

  • ターゲット

    これはもう1つの非常に重要なフィールドです。ターゲットのデフォルトのタイプは、 指定されたターゲットタグです。これは正確には必要なものです。[ Target Tags ] というラベルのテキストボックスに、 citrix-Provisioning-Quarantine-firewall という値を入力します。

  • ソースフィルタ

    ソースフィルタについては、 IP 範囲のデフォルトのフィルタタイプを保持しすべてのトラフィックに一致する範囲を入力します 。そのために、0.0.0.0/0の値を使用します。

  • プロトコルとポート

    [プロトコルとポート] で、[ すべて拒否] を選択します。

完成した画面は次のようになります。

最終画面

[ 作成 ] をクリックし、新しいルールを生成します。

出力ルール:データの入力

出力ルールは、以前に作成した入力ルールとほぼ同じです。上記で行ったように、 ファイアウォールルールの作成を再度使用し 、以下に詳述するフィールドに入力します。

  • Name

    Deny-All 出力ファイアウォールルールに名前を付けます。ここでは、 それをシトリックス拒否オールエグレスルールと呼びます。

  • ネットワーク

    上記の入力ファイアウォールルールの作成時に使用したのと同じ共有 VPC ネットワークをここで選択します。たとえば、gcp-test-vpcなどです。

  • 優先度

    上記のように、我々は、10の値を使用します。

  • 交通の方向

    このルールでは、デフォルトから変更して Egressを選択する必要があります。

  • マッチ時にアクション

    この値はデフォルトで [ 許可] に設定されます。Deny ( 拒否) に変更する必要があります。

  • ターゲット

    [ Target Tags ] フィールドに、 citrix プロビジョニング検疫ファイアウォールの値を入力します

  • ソースフィルタ

    ソースフィルタの場合IP 範囲のデフォルトのフィルタタイプを保持しすべてのトラフィックに一致する範囲を入力します 。そのために、0.0.0.0/0の値を使用します。

  • プロトコルとポート

    [ プロトコルとポート] で、[ すべて拒否] を選択します。

完成した画面は次のようになります。

完了したルール画面

[ 作成 ] をクリックして、新しいルールを生成します。

必要なファイアウォールルールは両方とも作成されています。マシンカタログを展開するときに複数の共有VPCを使用する場合は、上記の手順を繰り返します。それぞれのホストプロジェクトで、識別された共有 VPC ごとに 2 つのルールを作成します。

方法:Cloud Connector インスタンスにネットワークインターフェイスを追加する

共有 VPC で使用する Cloud Connectors を作成する場合、 インスタンスを作成するときに、追加のネットワークインターフェイスをインスタンスに追加する必要があります。

インスタンスが存在すると、追加のネットワークインターフェースを追加することはできません。2 番目のネットワークインターフェイスを追加するには、次の手順を実行します。

GCP インスタンスの初期ネットワーク設定パネル

これは、ネットワークインスタンスの初回作成時に表示されるネットワーク設定の初期パネルです。

ネットワーク設定パネル

共有 VPC の最初のネットワークインスタンスを使用するので、[ 鉛筆 ] アイコンをクリックして [ Edit ] モードに入ります。

拡張されたネットワーク設定画面は以下の通りです。注意すべき重要な項目は、[ ネットワークインタフェース ] バナーの真下に、 私と共有されているネットワーク (ホストプロジェクトから:citrix-shared-vpc-project-1) のオプションが表示されることです。

自分と共有するネットワークのオプション

共有 VPC を選択した [ネットワーク設定] パネルには、次の情報が表示されます。

  • 共有 VPC ネットワークを選択しました。

  • サブネットの正常なサブネットを選択

  • 設定を外部 IP アドレスに [なし]に変更しました。

[ネットワーク設定] パネル

[ 完了 ] をクリックして変更を保存します。[ ネットワークインターフェイスの追加] をクリックします。

2 番目のネットワークインターフェイスの追加

これで、最初のインターフェイスが共有 VPC に接続されました(示されているように)。新しいCloud Connectorの作成時に通常使用されるのと同じ手順を使用して、2番目のインターフェイスを設定できます。ネットワーク、サブネットを選択し、外部 IP アドレスを決定し、[ 完了] をクリックします。

2 番目のネットワークインターフェイス

How: ホスト接続とホストユニットの作成

共有 VPC で使用するホスト接続の作成は、ローカル VPC で使用するためのホスト接続の作成と大差ありません。違いは、ホスト接続に関連づけるリソースを選択することにあります。ホスト接続を作成して共有 VPC リソースにアクセスする場合は、プロビジョニングされたマシンが存在するプロジェクトに関連するサービスアカウント JSON ファイルを使用します。

クレデンシャルと接続名

共有 VPC リソースを使用するためのホスト接続の作成は、他の GCP 関連のホスト接続の作成に似ています。

ホスト接続

プロジェクトと地域を選択

次の図の「 開発者プロジェクト 」として表示されているプロジェクトが、共有 VPC にアクセスできるリストに追加されると、Studio にプロジェクトと共有 VPC プロジェクトの両方が表示されます。共有VPCではなく 、デプロイされたマシンカタログが存在するプロジェクトを選択することが重要です。

プロジェクトと地域の選択

リソースを選択

ホスト接続に関連づけられているリソースを選択します。

以下に注意してください:

  • リソースに与えられた名前は sharedvpcreSources です。

  • 選択する仮想ネットワークのリストには、ネットワーク名に (Shared) が付加されているように、ローカルプロジェクトの仮想ネットワークと、共有 VPC からのネットワークが含まれます。

注:

名前に Shared が付加されたネットワークが表示されない場合は、[ 戻る ] ボタンをクリックして、正しいプロジェクトを選択していることを確認します。選択したプロジェクトが正しいことを確認しても、共有 VPC が表示されない場合は、Google Cloud Console で何かが誤って構成されます。このドキュメントの後半の「一般的に発生する問題とエラー」を参照してください。

可能性のあるエラー

リソースが選択されました

次の図は、前のステップで gcp-test-vpc(共有) 仮想ネットワークが選択されたことを示しています。また、 subnet-good という名前のサブネットが選択されていることも示されます。[次へ] をクリックします:

選択されたリソース

概要画面

[ 次へ] をクリックすると、[ 概要] 画面が表示されます 。この画面では、次の点を考慮してください。

  • プロジェクトは開発者プロジェクトです

  • 仮想ネットワークは gcp-test-vpcで、共有 VPC の 1 つです。

  • サブネットは良好です

[概要]画面

方法:カタログを作成する

この時点から、カタログの作成、マシンの起動/停止、マシンの更新など、すべては、ローカル VPC を使用する場合とまったく同じように実行されます。

一般的に発生する問題とエラー

相互依存関係を持つ複雑なシステムを操作すると、予期しない状況が発生する可能性があります。Citrix Virtual Apps and Desktops、およびGCP共有VPCを使用するセットアップと構成を実行する際に発生する可能性のある一般的な問題とエラーは、以下に記載されています。

ファイアウォールルールがないか正しくありません

ファイアウォールルールが見つからない場合、またはルールは検出されたが、ルールまたは優先順位が正しくない場合は、次の形式のメッセージが返されます。

“Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC <name> in project <project>. “Please ensure you have created ‘deny all’ firewall rules with the network tag ‘citrix-provisioning-quarantine-firewall’ and proper priority.” “Refer to Citrix Documentation for details.”);

このメッセージが表示された場合は、ファイアウォールルール、優先順位、および適用されるネットワークを確認する必要があります。詳細については、「方法- ファイアウォールルール」セクションを参照してください。

ホスト接続の作成時に共有リソースがない

このような状況が発生する場合にはいくつかの理由があります。

ホスト接続の作成時に誤ったプロジェクトが選択されました

たとえば、プロジェクトの代わりにホスト接続を作成するときに [共有 VPC ホストプロジェクト] が選択された場合、共有 VPC のネットワークリソースは引き続き表示されますが 、それらのリソースには (Shared) が付加されません。

共有サブネットがその追加情報なしで表示される場合は、ホスト接続が間違ったサービスアカウントで確立された可能性があります。

ホスト接続とホストユニットの作成方法」を参照してください。

サービスアカウントに間違ったロールが割り当てられました

サービスアカウントに間違ったロールが割り当てられている場合、共有 VPC 内の目的のリソースにアクセスできない可能性があります。「方法-プロジェクトの IAM ロールをホストするサービスアカウントを追加する」を参照してください。

ロールに付与された権限が不完全または正しくありません

サービスアカウントに正しいロールを割り当てることはできますが、ロール自体が不完全である可能性があります。「手順 — 新しい IAM ロールを作成する」を参照してください。

サービスアカウントはサブネットメンバーとして追加されていません

サブネットレベルのアクセスを使用している場合は、サービスアカウントが目的のサブネットリソースのメンバ(ユーザー)として適切に追加されていることを確認します。「サブネットレベルの権限の使用方法」を参照してください。

Studio でパスエラーが見つかりません

Studio でカタログを作成する際にエラーが発生した場合は、次のフォームを使用します。

Cannot find path “XDHyp:\\Connections …” because it does not exist

多くの場合、共有 VPC リソースの使用を容易にするために、新しいCloud Connector が作成されていない可能性があります。上記の手順をすべて実行してすべてを構成した後、見過ごすのは簡単です。これらの作成に関する重要なポイントについては、Cloud Connectorを参照してください。