1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

GCP スキルバッジをもらおう!Advent Calendar 2021

Day 21

GCP スキルバッジをもらおう ~6. VPC ネットワーク ピアリング〜Security & Identity Fundamentals

Posted at

実際にラボを実施した際の記録を載せていきます。
学習の助けになったリンクや、後に見るための学習メモ、ちょっと迷った手順を書いていきます。
あと、コマンドも忘れたくないのでログしていきます。

  • 学習の助けになったリンクは、「学習に役立つリンク」にまとめて書いてあります。
  • 学習メモは:writing_hand:アイコンをつけてます。
  • 迷った手順は箇条書きでつらつら書いてます。
    実際の手順については、Google Cloud Skills Boostのラボの手順を参照してください。

クエスト「Security & Identity Fundamentals」の4つめのラボです。
SkillBoostの始め方は記事「GCP スキルバッジをもらおう 1Google Cloud Skill Boostをはじめよう」をどうぞ。

この記事は「GCP スキルバッジをもらおう! 〜Security & Identity Fundamentals Advent Calendar 2021」の一部として公開しています。
25日にスキルバッジが獲得できるペースで公開していきます。

##ラボの情報
ラボの名前:VPC ネットワーク ピアリング
所要時間:45分 レベル:Advanced 必要なクレジット:7
概要:
2つの異なるプロジェクトでそれぞれVPCネットワークを作成して、2つのVPCの間でピアリングを設定し、セッションを設定して接続テストを行う。

たとえば、組織が project-A の network-A と project-B の network-B の間で VPC ネットワーク ピアリングを確立する必要があるとします。この場合は、network-A と network-B の管理者がそれぞれのネットワークでピアリングを設定する必要があります。
(ラボより抜粋:このラボで作成するNWの最終イメージ)
スクリーンショット 2021-12-19 22.38.15.png

学習メモ:writing_hand::VPCネットワークピアリングって?
同じまたは異なる組織のGCPプロジェクト間で プライベート通信を構成する手段
ここは共有VPCとの違いです。共有VPCは異なるGCPプロジェクト間でのみ有効です。

VPC ネットワーク ピアリングは、次のような場合に役立ちます。
・組織に複数のネットワーク管理ドメインがある場合
・他の組織とピアリングを行う場合

分散型のマルチプロジェクト ネットワーキング手法です
個別の管理グループ下で制御でき 固有のグローバルファイアウォールと ルーティングテーブルを維持する。
ここが、共有VPCとの違いでもあります。共有VPCはファイアウォールルールとルーティングテーブルを1つのホストプロジェクトで管理する集中型の手法です。

VMインスタンス同士が 内部IPアドレスでプライベートに通信できる
外部IPアドレスやVPNの使用に伴う レイテンシ、セキュリティ、費用の 問題がありません

##学習に役立つリンク
参考URL:
VPC ネットワークの概要
VPC ネットワーク ピアリングの概要
関連SDK:
https://cloud.google.com/sdk/gcloud/reference/compute/networks
https://cloud.google.com/sdk/gcloud/reference/compute/instances
https://cloud.google.com/sdk/gcloud/reference/compute/firewall-rules

##ラボの実施記録
このラボはプロジェクトを2つ使う。
ラボの起動画面の情報をチェックしておく。
Project 1を「Project-A」、Project 2を「Project-B」として操作していいきます。


最初は「Project A」がCloudConsoleに表示されている状態のはず。
CloudShellを起動し、を押して、2つ目のCloudShellを起動して、「Project-B」に接続するようにしておく。

$gcloud config set project <PROJECT_ID2>

###VPC ネットワーク ピアリングを設定する
####プロジェクトでカスタム ネットワークを作成する
1つめのCloudShellで、「Project-A」にカスタムネットワークを作成します。

gcloud compute networks create network-a --subnet-mode custom
Created [https://www.googleapis.com/compute/v1/projects/[Project-AのID]/global/networks/network-a].
NAME: network-a
SUBNET_MODE: CUSTOM
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:

Instances on this network will not be reachable until firewall rules
are created. As an example, you can allow all internal traffic between
instances as well as SSH, RDP, and ICMP by running:
$

VPC内にサブネットを作成して、リージョンとIPレンジを指定する。

$ gcloud compute networks subnets create network-a-central --network network-a \
>     --range 10.0.0.0/16 --region us-central1
Created [https://www.googleapis.com/compute/v1/projects/[Project-AのID]/regions/us-central1/subnetworks/network-a-central].
NAME: network-a-central
REGION: us-central1
NETWORK: network-a
RANGE: 10.0.0.0/16
STACK_TYPE: IPV4_ONLY
IPV6_ACCESS_TYPE:
IPV6_CIDR_RANGE:
EXTERNAL_IPV6_CIDR_RANGE:
$

VMインスタンスを作成する

$ gcloud compute instances create vm-a --zone us-central1-a --network network-a --subnet network-a-central
Created [https://www.googleapis.com/compute/v1/projects/[Project-AのID]/zones/us-central1-a/instances/vm-a].
NAME: vm-a
ZONE: us-central1-a
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
INTERNAL_IP: 10.0.0.2
EXTERNAL_IP: 35.223.175.40
STATUS: RUNNING
$

ファイアウォールルールを編集して、icmptcp/22 sshallowするようにする。
ラボの最後で疎通確認のためにsshとPingを使うからです。

$ gcloud compute firewall-rules create network-a-fw --network network-a --allow tcp:22,icmp
Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/[Project-AのID]/global/firewalls/network-a-fw].
Creating firewall...done.
NAME: network-a-fw
NETWORK: network-a
DIRECTION: INGRESS
PRIORITY: 1000
ALLOW: tcp:22,icmp
DENY:
DISABLED: False

2つめのCloudShellで、「Project-B」にカスタムネットワークを作成します。
こちらは割愛します。

###VPC ネットワーク ピアリング セッションを設定する
ここはCloudConsoleで操作します。
まずは、「Project-A」のコンソールでnetwork-aから「Project-B」のnetworc-bへのピアリングを作成します。
次に逆方向、「Project-B」のコンソールでnetworc-bから「Project-A」のnetwork-aへのピアリングを作成します。

:writing_hand:ピアリングの作成操作

  1. ハンバーガー>VPC Network>VPC network peering>に移動
  2. 右側パンで「CREATE PEERING CONNECTION」をクリック
  3. そのまま、「Continue」を押す
  4. [Name]を入力する「peer-ab」
  5. [Your VPC network] でピアリング元のNWを選択する。「network-a」
  6. [Peerd VPC Network] で [別のプロジェクト] を選択
  7. [Project ID] は、2 番目のプロジェクトの ID で置き換え
  8. [VPC Network name] には「network-b」を入力
  9. [Create]をクリック

設定後の表示例。
この状態では1方向しかセッションを作っていないので、StatusがInactive
VPC network peering.png

もう一つブラウザタブを開いてコンソールを表示して、プロジェクトを「Project-B」に切り替えて、逆方向のピアリングを作成します。
設定値:
 [Name]:peer-ab
 [Your VPC network] :network-b
 [Peerd VPC Network] :[別のプロジェクト] を選択
 [Project ID] :2 番目のプロジェクトの ID で置き換え
 [VPC Network name]:network-b

結果表示の例。今度は、双方向でセッションを作ったので、StatusがActiveになった。

VPC network peering.png

CloudShellで確認のため、「project-A」のすべての VPC ネットワークのルートを一覧表示する。

$ gcloud compute routes list --project [Project-AのID]
…
NAME: default-route-730b4154fcca58f5
NETWORK: network-a
DEST_RANGE: 0.0.0.0/0
NEXT_HOP: default-internet-gateway
PRIORITY: 1000
…
NAME: peering-route-1ff76c14819d0fd6
NETWORK: network-a
DEST_RANGE: 10.8.0.0/16
NEXT_HOP: peer-ab
PRIORITY: 0

###接続テスト
(Project-A)のタブで実施
ハンバーガー>Compute Engine>VM Instanceを表示する。
VMのリストが表示されているので、「vm-a」のInternal-IPをコピーする。

(Project-B)のタブで実施
ハンバーガー>Compute Engine>VM Instanceを表示する。
VMのリストが表示されているので、「vm-b」のSSHボタンを押して接続する。
そこで、コピーしておいた「Project-A」の「vm-a」のInternal-IPにPingする。
うまくいけば、成功です。

##お疲れさまでした
これでラボの手順は終了。
右上のスコア表示が「100/100」になっていることを確認して、「ラボを終了」を押します。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?