PoC ガイド:Citrix DaaS による Google Cloud Platform (GCP) 共有 VPC のサポート
概要
CitrixDaaSは、Google Cloud Platform（GCP）共有VPCをサポートしています。このドキュメントでは、次の内容について説明します。
Googleクラウド共有VPCに対するCitrixサポートの概要。
Google クラウド共有 VPC に関連する用語の概要。
共有 VPC の使用をサポートするための Google クラウド環境の設定
ホスト接続およびマシンカタログのプロビジョニングに谷歌共有VPCを使用する。
一般的なエラー状態とその解決方法。
前提条件
このドキュメントは、Google Cloudに関する知識と、Google CloudプロジェクトでマシンカタログをプロビジョニングするためのCitrix DaaSの使用を前提としています。
CitrixDaaS の GCP プロジェクトをセットアップするには、製品ドキュメントを参照してください。
概要
共有VPC に展開されたマシンカタログのプロビジョニングと管理に対するCitrix MCSのサポートは、今日のローカルVPCでサポートされている機能と同等です。
それらが異なっている2つの方法があります。
MCS が共有 VPC リソースにアクセスして使用できるようにするには、ホスト接続の作成に使用するサービスアカウントに、さらにいくつかのアクセス許可を付与する必要があります。
サイト管理者は、イメージのマスタリングプロセスで使用するために、入力と出力用に 1 つずつ 2 つのファイアウォールルールを作成する必要があります。
これらの両方については、このドキュメントの後半で詳しく説明します。
グーグルクラウド共有VPC
GCP 共有 VPC は、共有サブネットが使用可能になるホストプロジェクトと、リソースを使用する 1 つ以上のサービスプロジェクトで構成されます。
共有 VPC を使用すると、企業の共有 Google クラウドリソースをより一元的に管理、使用、管理できるため、大規模なインストールに適しています。グーグルクラウドはこのように説明しています：
「共有 VPC を使用すると、組織は複数のプロジェクトのリソースを共通のVirtual Private Cloud (VPC) ネットワークに接続し、そのネットワークの内部 IP を使用して相互に安全かつ効率的に通信できます。共有 VPC を使用する場合は、プロジェクトをホストプロジェクトとして指定し、1 つ以上の他のサービスプロジェクトをプロジェクトにアタッチします。ホストプロジェクト内の VPC ネットワークは、共有 VPC ネットワークと呼ばれます。サービスプロジェクトの適格なリソースは、共有 VPC ネットワーク内のサブネットを使用できます。」
上記の段落は、Google ドキュメントサイトから引用したものです。
新しい権限が必要です
CitrixDaaS と Google Cloud を使用する場合、ホスト接続を作成するときに、特定の権限を持つ GCP サービスアカウントを提供する必要があります。上記のように、GCP 共有 VPC を使用するには、共有 VPC ベースのホスト接続の作成に使用するサービスアカウントに、追加のアクセス許可を付与する必要があります。
技術的に言えば、必要な権限は「新規」ではありません。これは、Citrix DaaSをGCPおよびローカルVPCで利用するためにすでに必要だからです。変更点として、共有 VPC リソースへのアクセスを許可するために、アクセス許可を付与する必要があります。これは、ホストプロジェクトの IAM ロールにサービスアカウントを追加することで実現されます。詳細については、このドキュメントの「操作方法」セクションで説明します。
注：
現在出荷されているCitrix DaaS製品に必要な権限を確認するには、リソースの場所について説明したCitrixドキュメントサイトを参照してください。
ホスト接続に関連付けられたサービスアカウントには、合計で最大 4 つの追加のアクセス許可を付与する必要があります。
計算.firewalls.list-必須
この権限は、Citrix MCSが共有VPCに存在するファイアウォールルールのリストを取得できるようにするために必要です（詳細は後述）。
計算.networks.list-必須
この権限は,Citrix MCSがサービスアカウントで使用できる共有VPCネットワークを識別できるようにするために必要です。
compute.subnetworks.list —必須かもしれません(下記参照)
この権限は、MCS が可視共有 VPC 内のサブネットを識別できるようにするために必要です。
注：
この権限は、ローカル VPC の使用にはすでに必要ですが、共有 VPC ホストプロジェクトでも割り当てる必要があります。
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 \
Cloud Connector
CitrixDaaSマシンカタログに共有VPCを使用する場合、2つ以上のCloud Connectorを作成して、共有VPC内にあるドメインコントローラーにアクセスします。この場合、ローカルプロジェクトに GCP マシンインスタンスを作成し、追加のネットワークインターフェイスをインスタンスに追加することをお勧めします。最初のインターフェイスは、共有 VPC のサブネットに接続されます。2 番目のネットワークインターフェイスは、ローカル VPC のサブネットに接続して、ローカル VPC 踏み台サーバーを介した管理制御とメンテナンスのためのアクセスを許可します。
残念ながら、GCP インスタンスの作成後にネットワークインターフェイスを追加することはできません。これは簡単なプロセスであり、以下に説明する「方法」エントリの 1 つです。
ハウ・・・セクション
次のセクションには、Citrix DaaSでGoogle共有VPCを使用するために必要な構成変更を実行する手順を理解するのに役立つ一連の説明例が含まれています。
Google コンソールのスクリーンショットに示されている例は、すべて、共有 VPC プロジェクト 1 という名前の仮想 Google プロジェクトで行われます。
方法:新しい IAM ロールを作成する
ホスト接続の作成時に使用されるサービスアカウントには、追加のアクセス許可を付与する必要があります。共有 VPC へのデプロイの目的は、複数のプロジェクトを同じ Shared VPC にデプロイできるようにすることであるため、最も効率的なアプローチは、目的のアクセス許可を持つホストプロジェクトで新しいロールを作成し、そのロールを共有 VPC へのアクセスを必要とするサービスアカウントに割り当てることです。
以下では、Citrix-ProjectLevel-SharedvpCroleという名前のプロジェクトレベルの役割を作成します。サブネットレベルの役割は、割り当てられた最初の 2 つのアクセス許可セットに対して同じ手順に従います。
Google コンソールの IAM と管理者
Google クラウドコンソールでIAM と管理者設定オプションにアクセスします。
役割の作成
[ロールの作成] を選択します。
![[ロールの作成] オプション](http://m.giftsix.com/docs/en-us/tech-zone/learn/media/poc-guides_gcp-shared-vpc_002.png)
ロールの作成画面を空にする
次のような画面が表示されます。
名前を入力し、権限を追加します
ロール名を指定します。[アクセス許可の追加] をクリックして、更新プログラムを適用します。
[権限の追加] ダイアログ
[ADD PERMISSIONS] をクリックすると、以下のような 1 つの画面が表示されます。
この画像では、「フィルタテーブル」テキスト入力フィールドが強調表示されています。
compute.firewalls.list 権限を追加する
[フィルタテーブル] テキスト入力フィールドをクリックすると、コンテキストメニューが表示されます。
以下に示すように、文字列compute.firewalls.listをコピーしてテキストフィールドに貼り付け (または入力) します。
パーミッションテーブルから除外されたcompute.firewalls.listエントリを選択すると、このダイアログが表示されます。
![[権限] ダイアログボックス](http://m.giftsix.com/docs/en-us/tech-zone/learn/media/poc-guides_gcp-shared-vpc_008.png)
トグルボックスをクリックして、権限を有効にします。
[追加] をクリックします。
[ ロールの作成] 画面が再表示されます。ロールに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 つの権限が付与された画面は次のようになります。
［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を選択:
プロジェクト権限画面
指定されたアクセス許可を持つメンバーを追加します。「追加」をクリックして、メンバーのリストを表示します。
[メンバーの追加] パネル
下図に示すように、[追加] をクリックすると、小さなパネルが表示されます。データは、次の手順で入力されます。
![[メンバーの追加] パネル](http://m.giftsix.com/docs/en-us/tech-zone/learn/media/poc-guides_gcp-shared-vpc_018.png)
サービスアカウントの追加
フィールドにサービスアカウントの名前を入力し始めます。入力すると、Google Cloud はアクセス権限のあるプロジェクトを検索し、一致する可能性のあるリストを絞り込みます。この場合、マッチが 1 つ (入力の直下に表示される) ので、そのエントリを選択します。
役割の選択
メンバー名(この場合はサービスアカウント）を指定した後、共有 VPC プロジェクトとして機能するサービスアカウントのロールを選択します。表示されたリストをクリックして、このプロセスを開始します。
ロールの選択
ロールの選択] プロセスは、前の「方法-新しい IAM ロールを作成する」で使用したプロセスと似ています。この場合、さらにいくつかのオプションとフィルインが表示されます。
ロールの指定
適用したいロールがわかっているので、入力を開始できます。目的のロールが表示されたら、ロールを選択します。
選択して保存
ロールを選択したら、[保存] をクリックします。
これで、ホストプロジェクトにサービスアカウントが正常に追加されました。
方法:サブネットレベルのアクセス許可
プロジェクトレベルのアクセスではなくサブネットレベルのアクセスを使用する場合は、共有 VPC で使用するサービスアカウントを、アクセスするリソースを表す各サブネットのメンバーとして追加する必要があります。この [操作方法] セクションでは、共有 VPC 内の 1つのサブネットへのアクセス権を持つsharedvpc-sa\@citrix-mcs-documentation.iam.gserviceaccount.comという名前のサービスアカウントを提供します。
[VPC] > [共有 VPC] に移動します
最初のステップは,谷歌コンソールの[共有VPC]画面に移動することです。
最初の共有 VPC 画面
これは、Google クラウドコンソールの共有 VPC 画面のランディングページです。このプロジェクトでは、5 つのサブネットが表示されます。この例のサービスアカウントには、2番目のサブネットに適切なサブネット(下の一覧の最後のサブネット) へのアクセスが必要です。
2番目のサブネットの正常なサブネットの横にあるチェックボックスをオンにします。
サービスアカウントアクセスのサブネットを選択します
最後のサブネットのチェックボックスが選択されたので、[ADD MEMBER] オプションが画面の右上に表示されます。
この演習では、このサブネットが共有されているユーザーの数を記録しておくと便利です。示されているように、1 人のユーザーがこのサブネットにアクセスできます。
[メンバの追加] をクリックします。
![[メンバの追加] オプション](http://m.giftsix.com/docs/en-us/tech-zone/learn/media/poc-guides_gcp-shared-vpc_026.png)
新しいメンバー名を入力
前述の「操作方法」セクションでサービスアカウントをホストプロジェクトに追加するために必要な手順と同様に、新しいメンバー名をここにも指定する必要があります。名前を入力した後、Google Cloudは（以前のように）関連するすべての項目をリストし、関連するサービスアカウントを選択できるようにします。この場合、それは単一のエントリです。
サービスアカウントをダブルクリックして選択します。
新しいメンバーの役割を選択してください
サービスアカウントを選択したら、新しいメンバーのロールも選択する必要があります。
一覧で、[ロールの選択] をクリックします。
コンピュートネットワークユーザーロールをダブルクリックします。
ロールが選択されました
この図は、サービスアカウントとロールが指定されていることを示しています。残りの手順は、[保存] をクリックして変更をコミットすることです。
サブネットにユーザーが追加されました
変更を保存すると、メイン Shared VPC 画面が表示されます。最後のサブネットにアクセスできるユーザーの数が、予想どおりに 2 つに増加していることを確認します。
方法:プロジェクト CloudBuild サービスアカウントを共有の VPC に追加する
すべての Google クラウドサブスクリプションには、プロジェクトの ID 番号に続いてcloudbuild.gserviceaccount が続くサービスアカウントがあります。フルネームの例 (メイドアッププロジェクト ID を使用) は次のとおりです。
705794712345@ cloudbuild.gserviceaccount。
このcloudbuild サービスアカウントも、ホスト接続の作成に使用するサービスアカウントが「方法:ホストプロジェクトの IAM 役割にサービスアカウントを追加する」のステップ 3 と同じ方法で、共有 VPC のメンバーとして追加する必要があります。
Google Cloud Console メニューで [**ホームとダッシュボード** ] を選択すると、プロジェクトのプロジェクト ID 番号を確認できます。
画面の [**プロジェクト情報] 領域の下にある [プロジェクト番号** ] を探します。
「メンバーの追加」フィールドに、プロジェクト番号と cloudbuild.gserviceAccount の組み合わせを入力します。コンピュータネットワークユーザーの役割を割り当てる:
［保存］を選択します。
方法:ファイアウォールルール
必要なファイアウォールルールの作成は、ロールを作成するよりも少し簡単です。
ホストプロジェクトを選択
このドキュメントで既に説明したように、2 つのファイアウォールルールはホストプロジェクトで作成する必要があります。
ホストプロジェクトを選択していることを確認してください。
VPC ネットワーク > ファイアウォール
Google コンソールメニューから、次に示すように、[VPC] > [ファイアウォール]に移動します。
ファイアウォールルールの作成ボタン
Google コンソールの [ファイアウォール] 画面の上部には、新しいルールを作成するためのボタンがあります。
[ファイアウォールルールの作成] をクリックします。
[新しいファイアウォールの作成] 画面
新しいファイアウォールルールの作成に使用する画面を以下に示します。
入力ルール:データの入力
まず、次のフィールドに値を追加または変更して、必要なDeny-All Ingressルールを作成します。
名前
[すべて拒否] ファイアウォールルールに名前を付けます。たとえば、
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の値を使用します。
プロトコルとポート
[プロトコルとポート] で [すべて拒否] を選択します。
完成した画面は次のようになります。
[作成] をクリックし、新しいルールを生成します。
出力ルール:データの入力
出力ルールは、以前に作成した入力ルールとほぼ同じです。上記で行ったように、ファイアウォールルールの作成を再度使用し、以下に詳述するフィールドに入力します。
名前
Deny-All 出力ファイアウォールルールに名前を付けます。ここでは、それをCitrix 拒否オールエグレスルールと呼びます。
ネットワーク
上記の入力ファイアウォールルールの作成時に使用したのと同じ共有 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 アドレスに[なし]に変更しました。
![[ネットワーク設定] パネル](http://m.giftsix.com/docs/en-us/tech-zone/learn/media/poc-guides_gcp-shared-vpc_040.png)
[完了] をクリックして変更を保存します。[ネットワークインターフェイスの追加] をクリックします。
2 番目のネットワークインターフェイスの追加
これで、最初のインターフェイスが共有 VPC に接続されました（示されているように）。新しいCloud Connectorの作成時に通常使用されるのと同じ手順を使用して、2番目のインターフェイスを設定できます。ネットワーク、サブネットを選択し、外部 IP アドレスを決定し、[完了] をクリックします。
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 DaaS と GCP 共有 VPC を使用するためのセットアップと構成を実行するときに発生する可能性があるいくつかの一般的な問題とエラーを以下に示します。
ファイアウォールルールがないか正しくありません
ファイアウォールルールが見つからない場合、またはルールは検出されたが、ルールまたは優先順位が正しくない場合は、次の形式のメッセージが返されます。
「VPC の有効な INGRESS および EGRESS
このメッセージが表示された場合は、ファイアウォールルール、優先順位、および適用されるネットワークを確認する必要があります。詳細については、「方法- ファイアウォールルール」のセクションを参照してください。
ホスト接続の作成時に共有リソースがない
このような状況が発生する場合にはいくつかの理由があります。
ホスト接続の作成時に誤ったプロジェクトが選択されました
たとえば、プロジェクトの代わりにホスト接続を作成するときに [共有 VPC ホストプロジェクト] が選択された場合、共有 VPCのネットワークリソースは引き続き表示されますが、それらのリソースには(Shared)が付加されません。
共有サブネットがその追加情報なしで表示される場合は、ホスト接続が間違ったサービスアカウントで確立された可能性があります。
ハウツー- ホスト接続とホスティングユニットを作成するを参照してください。
サービスアカウントに間違ったロールが割り当てられました
サービスアカウントに間違ったロールが割り当てられている場合、共有 VPC 内の目的のリソースにアクセスできない可能性があります。「方法-サービスアカウントをホストプロジェクトの IAM ロールに追加する」を参照してください。
ロールに付与された権限が不完全または正しくありません
サービスアカウントに正しいロールを割り当てることはできますが、ロール自体が不完全である可能性があります。「操作方法——新しい我ロールを作成する」を参照してください。
サービスアカウントはサブネットメンバーとして追加されていません
サブネットレベルのアクセスを使用している場合は、サービスアカウントが目的のサブネットリソースのメンバ（ユーザー）として適切に追加されていることを確認します。方法-サブネットレベルの権限を参照してください。
Studio でパスエラーが見つかりません
Studio でカタログを作成する際にエラーが発生した場合は、次のフォームを使用します。
Cannot find path “XDHyp:\\Connections …” because it does not exist
多くの場合、共有 VPC リソースの使用を容易にするために、新しいCloud Connector が作成されていない可能性があります。上記の手順をすべて実行してすべてを構成した後、見過ごすのは簡単です。作成時の重要なポイントについては、Cloud Connectorを参照してください。