ネットワークエンジニアのITブログ

長らくネットワークで仕事をしてきましたが、ここ数年クラウドとサーバー系に触れる機会が増えて、クラウドのネットワークというのが自分の性分にはあっているようです。最近のお気に入りはNSXALBとGoogle Cloud。

オンプレミス環境とGoogle Cloud VMware Engine（GCVE）をHCXで接続しL2延伸を実現する

GCVE ホームラボ HCX

前回の記事でGCVEを構築しましたが、この状態からホームラボとGoogle Cloudを接続し、GCVEと通信可能な状態とします。さらに、ホームラボとGCVE間をHCXによるL2延伸をしていきたいと思います。

HCXを使ったL2延伸の概要

検証環境

オンプレミスのホームラボとGoogle Cloud間のVPN接続については、こちらの記事で詳しく紹介しているため、ここでは割愛します。
hironw.hatenablog.com

Google との接続を表現するために、こちらの構成図ではホームラボを一部省略しています。

ホームラボの構成は、いつもの環境です。

L2延伸のメリットとユースケース

L2延伸を使用すると、オンプレミスのネットワークセグメント（VLANやサブネット）をGCVE上にそのまま拡張できます。この機能により、以下のメリットがあります：

  • 移行中のIPアドレス変更の回避：ネットワーク設定の変更を最小限に抑え、ダウンタイムを防ぐ。
  • シームレスなハイブリッドクラウド環境：オンプレミスとクラウド間のアプリケーション連携を強化。
  • 災害復旧（DR）の強化：既存のネットワーク構成を利用して迅速な切り替えを実現。

HCXの基本構成要素

HCXを利用する際には、以下の主要な構成要素が必要です：

  • HCX Connector：オンプレミス環境にデプロイされ、GCVEとの通信を管理します。
  • HCX Cloud Manager：GCVE内に存在し、クラウド環境での設定と管理を行います。
  • HCX Network Extension：L2延伸を可能にするサービスです。

HCXによるL2延伸の設定手順

HCX Connectorのデプロイ

１．GCVEのHCX Managerにログインし、Support欄を選択します。

２．画面上部の「REQUEST DOWNLOAD LINK」をクリックし表示される「COPY LINK」を選択します。


３．ブラウザにリンクを貼り付けると、自動的にHCXダウンロードがスタートします。
https://hybridity-depot.vmware.com/4.8.0.0/VMware-HCX-Connector-4.8.0.0-22804409.ova?verify=1735629225-cPK3zFy3o%2BLeicNnTIZBpUnpuCSVUFzgPeF%2F8%2FdZO1M%3D

４．vSphere Web ClientからOVAファイルを使用してHCX Connectorをデプロイします。
　　BroadcomサイトからダウンロードしたOVAファイルを指定します。

５．仮想マシン名を「HCX-Connector」として指定します。

６．ターゲットコンピューティングリソースを指定します。


７．使用許諾契約書に同意します。

８．ストレージを選択し、シンプロビジョニングを選択します。

９．管理用ネットワークをVLAN10の「DPortGroup 10」を選択します。

１０．パスワードを設定し、ホスト名とIPアドレスを設定し、「完了」を選択します。
　　ホスト名：hcxconnector
　　IPv4アドレス：192.168.10.89

１１．DNSおよびサービスの構成を設定します。
　　DNSサーバーリスト：192.168.10.32
　　ドメイン検索リスト：home.local
　　NTPサーバリスト：192.168.10.32
　　SSHの有効化：チェック



HCX Managerの設定

１．Google Cloud ConsoleからVMware Engineをクリック後に、プライベートクラウドを表示し、HCXコネクタキー右にある「表示」を選択します。
そうすると、画面右端に、オンプレミス環境にデプロイしたHCX Connectorをアクティベートする際に使用するHCXコネクタキーが表示されるので控えておきます。

２．HCX Manager「https://192.168.10.89:443」に接続します。
　　ユーザー名：admin
　　パスワード：デプロイ時に設定したパスワード

３．Activateの画面で、先ほど控えたHCXコネクタキーを入力し「ACTIVATE」を選択します。

４．Locationは、「Tokyo, Japan」のまま「CONTINUE」を選択します。

５．System Nameで「hcxconnector-enterprise」のまま「CONTINUE」を選択します。

６．設定の最終確認があるので、「YES、CONTINUE」を選択します。

７．続いてvCenter接続設定を行います。
　　vCenter Server：https://vcsa31.home.local/　（ここではオンプレのvCenterを指定します）
　　Username：[email protected]
　　Password：********

８．SSO/PSCでは、以下の情報を入力します。
　　Identity Sources：https://vcsa31.home.local/

９．「RESTART」を選択して設定を完了します。

１０．再起動後に再度ログインすると設定が完了しています。



サイトペアリングの設定

オンプレミスのHCX ConnectorとGCVEのHCX Cloud Manager間でサイトペアリングを構成します。
サイトペアリングが成功すると、双方の環境が認識されます。

Network Profilesの設定

１．サイトペアリングの設定は、vCenter or HCX Managerのどちらからでも可能なので、今回はvCenterのHCX設定画面から操作していきます。
vCenterの画面左上にある、3本線をクリックし、HCXを選択します。

２．Infrastructure→Site Pairing から「CONNECT TO REMOTE SITE」を選択します。

３．設定画面で、GCVE側のHCX情報を入力し、「CONNECT」を選択します。
　　Remote HCX URL：https://hcx-374651.e14f1442.asia-northeast1.gve.goog
　　Username：[email protected]
　　Password：********

４．Site Paringの画面に切り替わるので、「ADD A SITE PAIRING」を選択します。

５．続いて、Interconnect→Network Profilesで、「CREATE NETWORK PROFILE」を選択します。
　　このネットワークは、HCX仮想アプライアンスが、様々な通信で使用するネットワークです。

６．以下の情報を入力して、「CREATE」を選択します。
　　vCenter：vcsa31.home.local
　　Network：Distributed Port Groups
　　Name：DPortGroup3
　　MTU：1500
　　HCX Traffic Type：Management、HCX Uplink



ComputeProfilesの設定

１．Interconnect→Compute Profilesで、「CREATE COMPUTE PROFILE」を選択します。

２．Name Your Compute Profile名を「L2 Extention」とし、「CONTINUE」を選択します。

３．Select Services to be activated画面で、利用する以下のサービスを選択し✅状態にします。
　　Hybrid Interconnect
　　Bulk Migration
　　Network Extention

４．Select Service Resources画面で、リソースのあるCluster「Cluster_Lab」を選択します。

５．Select Deplyment Resources and Reservations画面で、以下を選択します。
　　Select Datastore：datastore_qnap2
　　Select Folder：Discoverd Virtual Machine

６．Select Management Network Profile画面で、先ほど作成したNetwork Profileの情報をそのまま「UPDATE」します。


７．Select Uplink Network Profile画面で、DportGroup3が選択されているのを確認して「CONTINUE」を選択します。

８．Select vSphere Replication Network Profile画面は、そのまま「CONTINUE」を選択します。

９．Select Netwrok Containers Eligible for Network Extention画面は、そのまま「CONTINUE」を選択します。

１０．Review Connection Rules画面は、そのまま「CONTINUE」を選択します。

１１．Ready to Complete画面で、「FINISH」を選択します。



Service Meshの設定

１．Interconnect→Service Meshで、「CREATE SERVICE MESH」を選択します。

２．Select Siteは、そのまま「CONTINUE」を選択します。

３．Select Compute Profilesは、そのまま「CONTINUE」を選択します。

４．Select Services to be activatedは、そのまま「CONTINUE」を選択します。

５．Advanced Configration－ Override Uplink Network Profilesは、以下を選択し「CONTINUE」を選択します。
　　Source：DportGroup3
　　Destination：GCVE MGMT Network Profile

６．Advanced Configration － Network Extension Appliance Scale Outで、「DSwitch」を選択します。

７．Advanced Configration － Traffice Engineeringは、そのまま「CONTINUE」を選択します。

８．Review Topoloty Previewで内容を確認します。

９．Ready to Completeで、Service Meshの名前を、「interconnect-1」として「FINISH」を選択します。



Network Extensionの有効化

１．Services→Network Extensionをクリックし、「CREATE A NETWORK EXTENSITON」を選択します。

２．L2延伸したいVLANである「DPortGroup12」を選択します。

３．Select Source Networks for Extension to remote siteで、以下の設定を行います。
　　Destination First Hop Router：Tier1
　　Gateway IP Address / Prefix Length：192.168.12.1/24

４．Network Extensionの設定が開始すると、Statusの進捗が進み、最終的には✅となり完了します。


動作確認

L2延伸状態の確認

オンプレHCXでの確認

Extension Networkが1つ作成されており、VLAN12のステータスが✅となっています。


GCVE HCXでの確認

こちらも同様にExtension Networkが1つ作成されており、VLAN12のステータスが✅となっています。


GCVEでL2延伸したネットワークの確認

GCVEのNSX Managerにログインし、セグメントにL2延伸したVLAN12のセグメントが作成されていることを確認できます。また、Tier1ゲートウェイには接続していないことも確認できます。


また、ネットワークトポロジーでもL2延伸したネットワークを確認できます。


GCVE上に作成した仮想マシン（winsv_vlan12）での疎通確認

オンプレネットワークのインターネットゲートウェイであるNVR510（192.168.100.1）にTracerouteを実行したところ、デフォルトゲートウェイであるCatalyst2960-L3（192.168.12.1）のネクストホップが、NVR510（192.168.100.1）であることから、GCVEとのL2延伸が正しく接続できていることが確認できました。
また、インターネット接続も確認できました。

C:\>ipconfig
Windows IP 構成
イーサネット アダプター Ethernet0:
   接続固有の DNS サフィックス . . . . .:
   IPv4 アドレス . . . . . . . . . . . .: 192.168.12.121
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: 192.168.12.1

C:\>tracert -d 192.168.100.1
192.168.100.1 へのルートをトレースしています。経由するホップ数は最大 30 です
  1    21 ms    21 ms    23 ms  192.168.12.1
  2    32 ms    27 ms    31 ms  192.168.100.1
トレースを完了しました。

C:\>ping www.google.co.jp
www.google.co.jp [142.250.207.35]に ping を送信しています 32 バイトのデータ:
142.250.207.35 からの応答: バイト数 =32 時間 =30ms TTL=60
142.250.207.35 からの応答: バイト数 =32 時間 =36ms TTL=60
142.250.207.35 からの応答: バイト数 =32 時間 =51ms TTL=60
142.250.207.35 からの応答: バイト数 =32 時間 =45ms TTL=60

142.250.207.35 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 30ms、最大 = 51ms、平均 = 40ms
C:\>

まとめと次のステップ

本記事では、オンプレミス環境とGoogle Cloud VMware EngineをHCXで接続し、L2延伸を実現する方法を解説しました。この設定により、ネットワークの一貫性を保ちながら、オンプレミスのワークロードをシームレスにクラウドへ移行できます。

Google Cloud VMware Engine (GCVE) 入門：クラウドでVMwareワークロードを構築してみた

Google Cloud ホームラボ GCVE vSphere

昨今、vSphereの環境は様々なクラウド環境で利用できるようになりました。今回はその中でもGoogle Cloud上にvSphereの環境を利用することができる「Google Cloud VMware Engine（GCVE）」の概要と導入手順について紹介していきます。

はじめに

Google Cloud VMware Engine（GCVE）は、オンプレミスで運用しているVMwareワークロードをそのままGoogle Cloud上に移行し、実行できるマネージドサービスです。クラウドネイティブなサービスに再設計することなく、既存のVMware環境を活用できるため、クラウド移行のハードルが大きく下がります。

GCVEはVMwareの主要なソリューション（vSphere、vSAN、NSX-Tなど）をサポートし、Google Cloudのスケーラビリティや高可用性を活用できます。本記事ではGCVEの基本的な特徴、アーキテクチャ、ユースケース、導入手順について詳しく説明します。

GCVE のアーキテクチャ

基本構造：Google Cloud と VMware の統合

GCVE は、Google Cloud 上で専用ホストとして稼働する VMware 環境を提供します。この環境はフルマネージドで、Google がハードウェア管理や基盤インフラのメンテナンスを担います。ユーザーはVMwareの管理ツール（vCenterなど）を使用し、従来の運用と同じ方法で管理が可能です。

サポートされる VMware 製品

GCVE では以下の主要な VMware 製品が利用可能です：

  • vSphere: 仮想マシンの管理と運用
  • vSAN: ソフトウェアベースのストレージソリューション
  • NSX-T: ソフトウェア定義ネットワーキング（SDN）
  • HCX: クラウド移行を容易にするツール

ネイティブ Google Cloud サービスとの連携

GCVE は Google Cloud のサービスとシームレスに統合され、ビッグデータ解析、AI/ML、バックアップなどの追加機能を簡単に利用できます。たとえば、VMware ワークロードのデータを Google BigQuery に転送して分析を行うといった活用が可能です。

GCVE のユースケース

データセンターのモダナイゼーション

オンプレミスの老朽化したハードウェアを GCVE に移行することで、データセンターの運用負担を軽減しつつ、最新のインフラにアップグレードできます。

災害復旧とビジネス継続性

GCVE を災害復旧（DR）サイトとして活用することで、オンプレミス環境に障害が発生した場合でも迅速に業務を復旧できます。

クラウド移行とハイブリッドクラウド戦略

GCVE はオンプレミス環境から Google Cloud への段階的な移行を可能にし、必要に応じてハイブリッドクラウドの戦略を展開できます。

GCVE のセットアップ手順

ネットワーク構成

Google Cloud上にプロジェクトとGCVEのネットワーク環境を構築します。
今回は、Google Cloud 内が対象でVPN接続は含まれません。
Cloud VPNについては、こちらの記事を参照ください。
hironw.hatenablog.com



プロジェクトの作成

１．Google Cloud Console から「新しいプロジェクト」を選択します。

２．新しいプロジェクトに以下の項目を入力し、「作成」を選択します。
　　プロジェクト名：gcdev（プロジェクト作成時にIDが自動採番されます）
　　請求先アカウント：Billing Account for gc-sales.fsi.co.jp
　　組織：gc-sales.fsi.co.jp
　　場所：gc-sales.fsi.co.jp

３．プロジェクト作成時の初回のみ Compute Engine API が表示されるので「有効にする」を選択します。

４．プロジェクトが作成されると、Defaultのネットワークも自動的に作成されるので、「default」を選択します。このサブネットは、10.x.x.x台をかなり広い範囲で作成し、今後オンプレミス環境と接続する際にアドレスが重複していますので削除します。

５．画面上部にある「VPCネットワークの削除」を選択します。

６．削除にあたり再度確認が入るので、ネットワーク名である「default」を入力し、「削除」を選択します。


VPCの作成

１．オンプレミス接続専用VPCを作るために「VPCネットワークを作成」を選択します。

２．以下の情報を入力し、「作成」を選択します。
　　なお、サブネットはこの時点で不要なので削除します。
　　名前：vpn01
　　最大伝送単位：1500
　　サブネット作成モード：カスタム
　　新しいサブネット：ゴミ箱をクリックして削除
　　動的ルーティングモード：グローバル


３．同様に共有VPC用にVPCネットワークを作成します。（ここは必須ではありません）
　　名前：shared01
　　最大伝送単位：1500
　　サブネット作成モード：カスタム
　　新しいサブネット：ゴミ箱をクリックして削除
　　動的ルーティングモード：グローバル


GCVEの作成

１．左のメニューから「VMware Engine」を選択します。なお、初回のみ VMware Engine API が表示されるので「有効にする」を選択します。

２．プライベートクラウドで「作成」を選択します。

３．以下の情報を入力し「作成」を選択します。
　　名前：gcvedev
　　プライベートクラウドの種類：単一ノードのプライベートクラウド（検証のため）
　　リージョン：asia-northeast1
　　ゾーン：asia-northeast1-a
　　クラスタ名：gcvecluster
　　HCIノードモデル：ve1-standar-72
　　管理IPアドレス：10.16.0.0/23（最低でも/23が必要）
　　VMware Engine ネットワーク名：gcveconnect
　　VPCネットワークピアリング名：gcvepeering
　　VPCネットワークとのピアリング：現在のプロジェクト内：gcdev-441804（作成したプロジェクト）
　　ピアリングするVPCネットワーク：vpn01（オンプレと接続予定のVPCを選択）


４．約１～２時間ぐらいで作成が完了します。
　　名前「gcvedev」を選択すると詳細を確認できます。



動作確認

接続用GCEのサブネットを作成

VPC「Shared01」にサブネット「shared-net01」を作成します。ここでは、GUIではなく、gcloudのコマンドベースで作成してみたいと思います。

gcloud compute networks subnets create shared-net01 \
--project=gcdev-441804 \
--network=shared01 \
--range=10.16.11.0/24 \
--region=asia-northeast1
Created [https://www.googleapis.com/compute/v1/projects/gcdev-441804/regions/asia-northeast1/subnetworks/shared-net01].
NAME          REGION           NETWORK   RANGE          STACK_TYPE  IPV6_ACCESS_TYPE  INTERNAL_IPV6_PREFIX  EXTERNAL_IPV6_PREFIX
shared-net01  asia-northeast1  shared01  10.16.11.0/24  IPV4_ONLY

C:\>


接続用Compute Engineを作成

作成したサブネットに、Compute Engine（Windows）を作成します。

gcloud compute instances create win01 \
--project=gcdev-441804 \
--zone=asia-northeast1-a \
--machine-type=e2-medium \
--subnet=shared-net01 \
--no-address \
--network-tier=PREMIUM \
--maintenance-policy=MIGRATE \
--image-project=windows-cloud \
--image-family=windows-2022 \
--boot-disk-size=50GB \
--boot-disk-type=pd-balanced \
--boot-disk-device-name=windows-server-2022
Created [https://www.googleapis.com/compute/v1/projects/gcdev-441804/zones/asia-northeast1-a/instances/win01].
NAME   ZONE               MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP  STATUS
win01  asia-northeast1-a  e2-medium                  10.16.11.2                RUNNING


GCEへIAP接続

コマンドプロンプトから以下のコマンドを実行し、Identity-Aware Proxy（IAP）によりwin01（10.16.11.2）にRDP接続します。

C:\>gcloud compute start-iap-tunnel win01 3389 --zone=asia-northeast1-b --project=gcdev-441804
Picking local unused port [62174].
WARNING:

To increase the performance of the tunnel, consider installing NumPy. For instructions,
please see https://cloud.google.com/iap/docs/using-tcp-forwarding#increasing_the_tcp_upload_bandwidth

Testing if tunnel connection works.
Listening on port [62174].

コマンドを実行すると、ポート番号がランダムで表示されるので、リモートデスクトップを起動し、アドレスの部分に「localhost:62174」と入力しRDP接続します。




vCenter、NSX Manager、HCX Managerに接続

仮想アプライアンスのURLをクリックして接続できることを確認できました。
ログイン情報は、URLの右にある「鍵の詳細」から確認できます。



まとめ

Google Cloud VMware Engine（GCVE）は、VMwareワークロードを Google Cloud 上で効率的に運用するための強力なソリューションです。オンプレミスの複雑な運用を簡素化しながら、クラウドのスケーラビリティや先進技術を活用できます。この記事で紹介した基本情報と手順を参考に、実際に GCVE を試してみることをお勧めします。クラウド移行やハイブリッド戦略を進める際に、GCVE は重要な役割を果たすことでしょう。

Google CloudのNetwork Connectivity Centerを活用したネットワーク管理の最適化

ホームラボ Google Cloud Network Connectivity Center

富士ソフトの佐藤です。
現代のビジネス環境において、複雑化するクラウドネットワークとオンプレミス環境の統合管理は、多くの企業にとって重要な課題です。Google Cloudの「Network Connectivity Center」は、ハブとスポークのアーキテクチャを採用し、さまざまな接続オプションを一元的に管理する機能を提供します。
本記事では、Network Connectivity Centerの主要な機能とユースケース、従来のVPCピアリングの限界、そして設定方法やベストプラクティスについて詳しく解説していきます。

Network Connectivity Centerの主要機能

ハブとスポークアーキテクチャの説明

Network Connectivity Centerの中心には「ハブとスポーク」アーキテクチャがあります。ハブは中心となる管理ポイントであり、スポークはクラウドやオンプレミス環境への接続を表します。このアーキテクチャにより、ネットワークの複雑さを減らし、接続の一元管理が可能です。これにより、VPCピアリングが抱える管理負荷の問題を効果的に軽減できます。

クラウドおよびオンプレミス接続の統合

Network Connectivity Centerは、クラウドとオンプレミス環境間の接続を統合し、VPN、Interconnect、パートナー接続を含む多様な接続オプションをサポートしています。これにより、企業は各拠点間のトラフィックを一貫して管理し、最適化できます。これは、VPCピアリングでは不可能なトランジティブルーティング（経路の中継）もサポートしており、複雑なネットワークトポロジーを効率的に設計できる点で大きな優位性があります。


パフォーマンスとセキュリティの強化

Network Connectivity Centerは、高パフォーマンスのトラフィックルーティングと強化されたセキュリティ機能を提供します。これにより、データの転送速度を最大化しつつ、不正アクセスやデータ漏洩からネットワークを保護することができます。VPCピアリングの帯域幅制限や管理の複雑さに対して、Network Connectivity Centerはより効率的な接続管理を可能にします。

VPCピアリングの限界と課題

従来のVPCピアリングは、異なるVPCネットワーク間を直接接続するための有効な方法ですが、いくつかの制限と課題があります。これらの限界を理解することで、Network Connectivity Centerの価値がより明確になります。

スケーラビリティの制限

VPCピアリングは、特に大規模なネットワーク環境では、1つのVPCあたり最大25のピアリング接続までという制限があり、スケーラビリティに限界があります。多くのネットワーク接続が必要なシステムでは、これが大きな制約となります。

推移的ピアリングの制限

VPCピアリングの最も大きな制約は、VPCピアリングによる推移的ルーティングをサポートしていないことです。このため、ピアリングされたVPCを経由して、さらにその先へVPCピアリングしたVPCへルーティングすることができず、複雑なネットワークトポロジーには適していません。

ネットワークの分離とセキュリティ

VPCピアリングを用いると、個々のネットワークは分離されていますが、セキュリティ管理が煩雑になる可能性があります。各VPC間の通信に対するアクセス制御やファイアウォール設定が個別に必要になるため、管理が難しくなります。

帯域幅とパフォーマンスの制限

ピアリングされたVPC間のデータトラフィックはGoogleの内部バックボーンを使用しますが、大規模データ転送には向いておらず、パフォーマンスが制約されることがあります。

Network Connectivity Centerのユースケース

ハイブリッドクラウド環境の統合

Network Connectivity Centerを使用することで、VPCピアリングでは難しかったハイブリッドクラウド環境のシームレスな統合が可能になります。これにより、クラウドとオンプレミスのリソースを効率的に一元管理できます。

多拠点間接続の最適化

多拠点間でのネットワーク接続を最適化する際に、Network Connectivity Centerはハブとスポーク構造を活かして、接続の冗長性とパフォーマンスを高めることができます。

ベストプラクティスと設計の考慮点

セキュリティ対策とアクセス制御

ネットワークセキュリティを強化するためには、各スポークに対して適切なアクセス制御リスト（ACL）を設定し、データ転送の暗号化を有効化することが重要です。

ネットワークパフォーマンスの最適化

トラフィックの効率的なルーティングを確保するために、最も近い接続ポイントを利用し、冗長性と可用性を高める設計を採用することが推奨されます。

トラフィック管理とルーティングの設定

カスタムルーティングポリシーを設定し、異なるトラフィックタイプごとに優先度を設定することで、ネットワーク全体のパフォーマンスを最適化できます。

Network Connectivity Centerの設定手順

ネットワーク構成

オンプレミス環境からNCC経由でmainvpcのWebサーバーに接続できることを確認します。

前提条件

  • SpokeBのWebサーバー接続については、PSCエンドポイントを経由となります。設定手順については、こちらの記事をご覧ください。

NCCハブの作成

１．JITHUBプロジェクトで[ネットワーク接続]-[Network Connectivity Center]のハブから、「+ハブを作成」を選択します。

２．ハブの作成で、以下の情報を入力し、「次のステップ」を選択します。

３．スポークを追加するで、「スポークを追加」を選択します。

４．VPNスポークの情報を入力し、「作成」を選択します。
　　スポークタイプ：VPNトンネル
　　スポーク名：spoke-vpnvpc
　　リージョン：asia-northeast1（東京）
　　サイト間データ転送：無効
　　VPCネットワーク：vpnvpc
　　VPNトンネル1：hometunnel01

５．続いてVLANアタッチメントの情報を入力し、「完了」を選択します。
　　スポークタイプ：VPCネットワーク
　　スポーク名：spoke-mainvpc
　　VPCネットワーク：mainvpc


動作確認

オンプレ環境からmainvpcのCompute Engineへ接続

オンプレ環境の仮想マシン（192.168.10.91）から、mainvpcのCompute Engine（10.24.1.3）への接続を確認します。
pingとcurlコマンドを使用して、接続性とWebサーバーの応答を確認しました。

[root@cent91 ~]#
[root@cent91 ~]# ping 10.24.1.3 -c 3
PING 10.24.1.3 (10.24.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.24.1.3: icmp_seq=1 ttl=61 時間=49.8ミリ秒
64 バイト応答 送信元 10.24.1.3: icmp_seq=2 ttl=61 時間=54.4ミリ秒
64 バイト応答 送信元 10.24.1.3: icmp_seq=3 ttl=61 時間=54.4ミリ秒
--- 10.24.1.3 ping 統計 ---
送信パケット数 3, 受信パケット数 3, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 49.844/52.885/54.408/2.150 ms
[root@cent91 ~]#
[root@cent91 ~]#
[root@cent91 ~]# curl -v http://10.24.1.3
*   Trying 10.24.1.3:80...
* Connected to 10.24.1.3 (10.24.1.3) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.24.1.3
> User-Agent: curl/7.76.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sun, 06 Oct 2024 12:39:04 GMT
< Server: Apache/2.4.62 (CentOS Stream)
< Last-Modified: Sun, 06 Oct 2024 10:44:04 GMT
< ETag: "69f-623cc95439ba1"
< Accept-Ranges: bytes
< Content-Length: 1695
< Content-Type: text/html; charset=UTF-8
<

まとめ

Network Connectivity Centerは、クラウドとオンプレミス環境を効率的に接続し、VPCピアリングの制限を克服するための強力なツールです。これにより、よりスケーラブルで柔軟なネットワーク管理を実現できます。

Google Cloudとオンプレミス環境をVPN接続する方法

Google Cloud ホームラボ Cloud VPN

富士ソフトの佐藤です。
Google Cloudに環境を構築した後、既存の社内環境と接続する必要が出てくることがあります。セキュアかつ高速で安定した経路としてInterConnectがおすすめですが、コストをかけずに迅速に接続したい場合は、VPN接続が適しています。
今回は、Google Cloudと社内環境に見立てた自宅のホームラボ環境をVPN接続し、自宅からGoogle Cloudに接続する方法をご紹介します。

構成

ホームラボのゲートウェイであるFortigate60DとGoogle CloudのCloud VPNでVPN接続を行い、さらにCloud RouterとBGPによるルート情報の交換を行うことで、通信を可能にします。
Compute Engineはすでに構築済みで、Webサーバーとして起動しています。


Cloud VPNの概要

Cloud VPNは、IPsec VPN接続を使用してピアネットワークをVPCネットワークに安全に拡張するサービスです。
ネットワーク間のトラフィックを暗号化し、VPNゲートウェイ間で暗号化と復号を行うことで、送信中のデータを保護します。
主なVPN接続サービスには以下の2種類があります。

HA VPN（高可用性VPN）

  • 2つのインターフェースと2つの外部IPアドレスを持ち、冗長構成が可能
  • 動的ルーティング(BGP)をサポート
  • 99.99%のサービス可用性SLAを提供
  • IPv6をサポート
  • 最新かつ推奨されるVPNサービス

Classic VPN

  • 従来型のVPNサービス

利用シーン

Cloud VPNは以下のような場合に利用されます

  • オンプレミス環境とGoogle Cloud環境の接続
  • 異なるVPCネットワーク間の接続
  • リモートワーク環境からの安全なアクセス確保
  • クラウド間接続（例：AWSã‚„Azureとの接続）

設計時の考慮ポイント

Cloud VPNを設計する際は、以下の点を考慮することが重要です。

プロジェクト構成

Cloud VPNリソースとCloud Routerリソースを他のGoogle Cloudリソースとは別のプロジェクトに配置することで、IAMのロールと権限の構成が簡素化されます。

ルーティングとフェイルオーバー

動的ルーティングとBGPを使用するCloud VPNゲートウェイを選択し、可能な限りHA VPNを使用します。

トンネル構成

HA VPNトンネルが2つある場合はアクティブ/パッシブ構成、3つ以上ある場合はアクティブ/アクティブ構成を使用します。

セキュリティ対策

  • VPNトンネル内のトラフィックを暗号化し、データの機密性を確保します。
  • ファイアウォールルールを適切に設定し、不要なトラフィックをブロックします。
  • ログ記録と監視を行い、異常なアクティビティを検出できるようにします。

パフォーマンス最適化

コンプライアンス要件

業界標準や法規制に準拠したVPN設定を行い、必要に応じて暗号化アルゴリズムや鍵長を調整します。

テストと検証

本番環境に展開する前に、テスト環境でVPN接続の動作を確認します。

設定手順概要

Cloud VPNの設定手順
１．VPN設定ウィザードの起動
２．VPNオプションの選択
３．Cloud HA VPNゲートウェイの作成
４．VPNトンネルの追加
５．Cloud Routerの設定
６．BGPセッションの構成
７．設定の確認とサンプル構成ファイルのダウンロード

ホームラボのFortigate60Dの設定手順
１．サンプル構成ファイルの修正
２．CLIからの設定の適用
３．VPNトンネルの確認
４．BGPルーティングの確認

Cloud VPNの設定手順

１．JITHUBプロジェクトで、 [ネットワーク接続]-[VPN]を選択し、[+VPN設定ウィザード]を選択する。
２．VPNオプションで、「高可用性（HA）VPN」選択し、「続行」をクリックする。

３．「①Cloud HA VPNゲートウェイの作成」で以下の情報を入力し、「作成して続行」を選択する。
　　VPNゲートウェイの名前：gcvpngw
　　ネットワーク：mainvpc
　　リージョン：asia-northeast1（東京）
　　VPNゲートウェイのIPバージョン：IPv4
　　VPNゲートウェイのIPスタックタイプ：IPv4（シングルスタック）

４．「②VPNトンネルの追加」で以下の情報を入力し、「作成して続行」を選択する。
　　ピアVPNゲートウェイ：オンプレミス、または Google Cloud 以外
　　ピアVPNゲートウェイの名前：「新しいピアVPNゲートウェイを作成する」を選択
　　名前：fgt60d
　　インタフェース：1つのインターフェース
　　インタフェース0のIPアドレス：183.180.20.137　←Fortigate60DのグロバールIPを入力する
　　高可用性：VPNトンネルを1つ作成する

５．引き続き以下の情報を入力する。
　　Cloud Router：「新しいルーターを作成」を選択する。
　　名前：vpnrouter
　　Google ASN：64640
　　ルート：Cloud Routerに表示されるすべてのサブネットにアドバタイズ（デフォルト）

６．引き続き以下の情報を入力する。
　　Cloud Router：vpnrouter
　　名前：vpntunnel01
　　IKE事前共有鍵キー：xxxxxxxx

７．「+VPNTUNNEL01用のBPGセッションを構成」を選択する。

８．「BGPセッションの作成」で以下の情報を入力し、「保存して次へ」を選択する。
　　BGPセッションの種類：IPv4 BGPセッション
　　名前：bgpsession01
　　ピアASN：65000　←Fortigateでは、65000でBGPのASNを設定している
　　BGP IPv4アドレスを割り当てる：自動

９．BGPの設定が反映されたことを確認して、「BGP構成を保存」を選択する。

１０．「リマインダー」の下にある「構成をダウンロード」を押下すると、オンプレ環境用のサンプル構成ファイルをダウンロードできるので、該当するベンダー、プラットフォーム、ソフトウェアを選択してください。
なお、Fortigateは1つしか設定ファイルがなかったので、これをダウンロードします。

サンプル構成ファイルは以下となります。

# Google Cloud
# Configuration generated for fgt60d, project: jithub-414902.
#
# This configuration contains _SNAKE_CASE_ variables which are required to be
# replaced by the network engineer setting up the GCP <-> Prem VPN tunnels.
#
# These values are as follows:
#   > _IKE_SHARED_SECRET_PLACEHOLDER_ if configuration is downloaded after creation in GCP, this is where pre-shared secret is replaced.
#   > _CUSTOMER_ONPREM_IP_ ip component of on-premise IP range e.g. 172.10.11.0/24 => 172.10.11.0
#   > _CUSTOMER_ONPREM_NETMASK_ netmask component of GCP on-premise IP range e.g. 172.10.11.0/24 => 24 => 255.255.255.0
# Other
#   > Port assignment assumes no prior set up for virtual port assignments
#   > aes256-sha1 algorithms are chosen as a sensible default; if modified, pay
#     mind to MTU differences
config system interface
    edit port1
        set vdom root
        set mode static
        set ip 169.254.76.222 255.255.255.252
        set allowaccess ping https ssh
        set description wan1
    next
    edit port2
        set vdom root
        set mode static
        set ip _CUSTOMER_ONPREM_IP_ _CUSTOMER_ONPREM_NETMASK_
        set allowaccess ping
        set description lan1
    next
end

# phase1
config vpn ipsec phase1-interface
    edit GCP-HA-VPN-INT0
        set interface port1
                set ike-version 2
                set keylife 36000
        set peertype any
        set proposal aes256-sha1
        set remote-gw 34.157.78.15
        set local-gw 183.180.20.137
        set psksecret VMwarevmware1! 
    next
end

# phase2
config vpn ipsec phase2-interface
    edit GCP-HA-VPN-INT0
        set phase1name GCP-HA-VPN-INT0
        set proposal aes256-sha1
        set dhgrp 15
        set keylifeseconds 10800
    next
end

# tunnel interfaces
config system interface
    edit GCP-HA-VPN-INT0
        set ip 169.254.76.222 _CUSTOMER_ONPREM_NETMASK_TUNNEL0_
        set remote-ip 169.254.76.221 255.255.255.252
    next
end

# Configure BGP settings
config router bgp
    set as 65000
    set router-id 169.254.76.222
    config neighbor
        edit 169.254.76.221
            set soft-reconfiguration enable
            set remote-as 64640
        next
    end
    config redistribute connected
        set status enable
    end
end

# Configure the firewall policy to allow traffic
config firewall policy
    edit 1
        set name allow-gcp-to-lan
        set srcintf  GCP-HA-VPN-INT0
        set dstintf port2
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
    next
    edit 2
        set name allow-lan-to-gcp
        set srcintf port2
        set dstintf  GCP-HA-VPN-INT0
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
    end
end

ホームラボのFortigate60Dの設定手順

VPN設定の実施

サンプル構成ファイルの情報をもとに、インタフェースの設定を書き換えて、CLIから流し込みを行います。
以下、変更した箇所です。
port1 → wan1
port2 → internal1
psksecret → マスクしています
_CUSTOMER_ONPREM_NETMASK_TUNNEL0_ → 255.255.255.255

# phase1
config vpn ipsec phase1-interface
   edit GCP-HA-VPN-INT0
       set interface "wan1"
       set ike-version 2
       set keylife 36000
       set peertype any
       set proposal aes256-sha1
       set dhgrp 5 2
       set nattraversal disable
       set remote-gw 34.157.78.15
       set psksecret xxxxxxxx
   next
end

# phase2
config vpn ipsec phase2-interface
   edit GCP-HA-VPN-INT0
       set phase1name GCP-HA-VPN-INT0
       set proposal aes256-sha1
       set dhgrp 15
       set auto-negotiate enable
       set keylifeseconds 10800
   next
end

# tunnel interfaces
config system interface
    edit GCP-HA-VPN-INT0
        set ip 169.254.76.222 255.255.255.255
        set remote-ip 169.254.76.221 255.255.255.252
        set allowaccess ping
        set type tunnel
        set interface "wan1"
    next
end

# Configure BGP settings
config router bgp
    config neighbor
        edit 169.254.76.221
            set remote-as 64640
        next
    end
end

# Configure the firewall policy to allow traffic
config firewall policy
    edit 151
        set name allow-gcp-to-lan
        set srcintf "GCP-HA-VPN-INT0"
        set dstintf "internal1"
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
    next
    edit 152
        set name allow-lan-to-gcp
        set srcintf "internal1"
        set dstintf "GCP-HA-VPN-INT0"
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
    end
end
VPNトンネルの確認

設定が完了すると、VPNトンネルがアップし接続していることを確認できました。

BGPルーティングの確認

また、VPN経由でGoogle Cloudのネットワーク情報をBGPで受信していることを確認できました。

動作確認

オンプレ環境の仮想マシン（192.168.10.91）から、Google CloudのCompute Engine（10.24.1.3）への接続を確認します。
pingとcurlコマンドを使用して、接続性とWebサーバーの応答を確認しました。

[root@cent91 ~]#
[root@cent91 ~]# ping 10.24.1.3 -c 3
PING 10.24.1.3 (10.24.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.24.1.3: icmp_seq=1 ttl=61 時間=49.8ミリ秒
64 バイト応答 送信元 10.24.1.3: icmp_seq=2 ttl=61 時間=54.4ミリ秒
64 バイト応答 送信元 10.24.1.3: icmp_seq=3 ttl=61 時間=54.4ミリ秒

--- 10.24.1.3 ping 統計 ---
送信パケット数 3, 受信パケット数 3, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 49.844/52.885/54.408/2.150 ms
[root@cent91 ~]#
[root@cent91 ~]#
[root@cent91 ~]# curl -v http://10.24.1.3
*   Trying 10.24.1.3:80...
* Connected to 10.24.1.3 (10.24.1.3) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.24.1.3
> User-Agent: curl/7.76.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sun, 06 Oct 2024 12:39:04 GMT
< Server: Apache/2.4.62 (CentOS Stream)
< Last-Modified: Sun, 06 Oct 2024 10:44:04 GMT
< ETag: "69f-623cc95439ba1"
< Accept-Ranges: bytes
< Content-Length: 1695
< Content-Type: text/html; charset=UTF-8
<

まとめ

以上で、Google CloudとオンプレミスのVPN接続の設定と確認が完了しました。
今回の検証では、VPNトンネルを1つしか設定していませんが、Cloud Routerは、2つのインターフェースを持っているので、設定することで耐障害性を高めたり、負荷分散したりすることも可能です。
この方法を使用することで、セキュアかつ効率的なネットワーク接続を実現してみてください。

Google Cloud ファイアウォールポリシーの基本とファイアウォールルールとの違い

Google Cloud ホームラボ ファイアウォール

富士ソフトの佐藤です。
Google Cloudでは、クラウド環境のセキュリティを強化するために、ファイアウォールポリシーとファイアウォールルールが重要な役割を果たしています。これらの機能を理解し、適切に利用することで、ネットワーク全体のアクセス制御を効果的に管理できます。本記事では、ファイアウォールポリシーとファイアウォールルールの違いや、それぞれの利用シナリオについて詳しく解説し、最新の設定項目やアクションについても触れます。

ファイアウォールルールとは？

ファイアウォールルールの定義

ファイアウォールルールは、Google Cloud内の特定のインスタンスやネットワークに対してアクセスを許可または拒否するための設定です。これらはVPCレベルで適用され、インバウンドおよびアウトバウンドトラフィックを制御します。

ファイアウォールルールの主要な特徴

利用シナリオ

ファイアウォールルールは、以下の状況でよく使われます。

ファイアウォールポリシーとは？

ファイアウォールポリシーの定義

ファイアウォールポリシーは、Google Cloudのネットワーク全体に対して一貫したセキュリティルールを適用するための仕組みです。複数のVPC（Virtual Private Cloud）間で同じセキュリティ基準を共有したい場合に、統一されたルールセットを提供します。

ファイアウォールポリシーの主要な特徴

  • 一元管理: 複数のVPC間で一貫したポリシーを管理できるため、設定や管理が簡素化されます。
  • 階層構造: ポリシーの優先順位を設定でき、特定のルールを上位または下位に配置することで、適用の順序を柔軟に制御できます。
  • アクションの多様性: Allow、Deny、Go to next、Proceed to L7 inspectionといった多彩なアクションが選択でき、複雑なセキュリティ要件にも対応可能です。
  • 送信元の指定オプション: FQDN、位置情報、アドレスグループ、Google Cloud Threat Intelligenceを利用して、よりインテリジェントな制御が可能です。

利用シナリオ

ファイアウォールポリシーは、以下のようなケースで効果的に利用できます。

  • 一貫したセキュリティルールの適用: 全てのVPCに共通するセキュリティルールを設定する場合。
  • 組織全体のコンプライアンス管理: 法規制に準拠するために、統一されたセキュリティポリシーを適用する場合。
  • FQDNや位置情報を活用した高度な制御を行いたい場合。

ファイアウォールルールとファイアウォールポリシーの違い

両者の比較

設定項目 ファイアウォールルール ファイアウォールポリシー
適用範囲（スコープ） 単一のVPCネットワークに適用 複数のVPCやプロジェクト、組織全体に適用可能
優先順位と制御 数値が小さいほど高い優先度で適用（VPC内でのみ影響） 優先順位が高いが、ファイアウォールルールよりも常に優先される
アクションの種類 Allow（許可）または Deny（拒否）の2種類 Allow、Deny、Go to next（次に移動）、Proceed to L7 inspection（L7の検査に進む）
送信元の指定方法 インスタンスタグ、サブネット、IPアドレス範囲で指定 FQDN、位置情報、アドレスグループ、Google Cloud Threat Intelligenceの利用可
ターゲットの指定方法 インスタンスタグ、サブネット、IPアドレス範囲で指定 階層タグを使用して複数VPCやプロジェクトに対して指定可能
ログ記録のオプション トラフィックログの有効化が可能 組織全体のトラフィックログを包括的に記録・監視可能
適用条件とフィルタリング プロトコル、ポート、IPアドレスなどのシンプルな条件でフィルタリング サービスアカウントベースのフィルタリング、L7インスペクションなどの高度な条件が設定可能

優先順位と制御の仕組みについて

ファイアウォールポリシーは、ファイアウォールルールよりも常に優先されます。これにより、組織全体で一貫したセキュリティポリシーを設定しつつ、ローカルな環境での個別調整も可能です。この特性を利用して、大枠のセキュリティはポリシーで制御し、細かな調整をルールで行うのが推奨される運用方法です。

ポリシーとルールの使い分け

ファイアウォールポリシーは、組織全体のセキュリティルールを一元管理したいときや、複数のVPCに共通する設定を適用するのに最適です。
ファイアウォールルールは、より細かいアクセス制御が必要な場合や、特定のアプリケーションやインスタンスに対して制限を設定する際に使います。

ファイアウォールポリシーの設定方法

ネットワーク構成

FQDNによる通信制御を行い、楽天市場は表示できるが、Amazonは表示できないように制御します。


Google Cloud コンソールを使用した設定手順

１．JITHUBプロジェクトを収容している「if-innovation」フォルダを選択し、 [ネットワークセキュリティ]-[Cloud NGFW]-[ファイアウォールポリシー]で、[+ファイアウォールポリシーを作成]を選択します。

２．①ポリシーの構成で、ポリシー名を「my-firewall-policy」とし、「続行」を選択します。

３．②ルールの追加で、「ルールを追加」を選択します。

４．ファイアウォールルールの作成で以下の情報を入力し、作成を選択します。
　　優先度：3001
　　トラフィックの方向：下り（外向き）
　　一致したときのアクション：許可
　　ターゲットネットワーク
　　　プロジェクト：JITHUB
　　　ネットワーク：labvpc
　　宛先
　　　FQDN：www.yahoo.co.jp
　　送信元
　　　IP範囲：10.24.11.0/24
　　プロトコルとポート：すべて許可

５．同様に上記以外の下り通信は拒否するルールを作成します。
　　優先度：9000
　　トラフィックの方向：下り（外向き）
　　一致したときのアクション：拒否
　　ターゲットネットワーク
　　　プロジェクト：JITHUB
　　　ネットワーク：labvpc
　　宛先
　　　FQDN：www.rakuten.co.jp
　　送信元
　　　IP範囲：10.24.11.0/24
　　プロトコルとポート：すべて許可

６．ルールの作成を確認したら、「続行」を選択します。

７．③ポリシーとリソースの関連付け（省略可）で、「追加」を選択します。

８．ポリシーとリソースの関連付けで「if-inonovation」フォルダにチェックを入れ、「追加」を選択します。

９．関連付けがされたことを確認し、「作成」を選択します。

１０．ファイウォールポリシーの作成完了したことを確認します。


動作確認

labvpcのファイアウォール設定確認

labvpcのファイアウォール設定を確認すると、ポリシーとルールの両方が表示されていて、ポリシーの優先度が高いことが確認できます。


10.24.11.0/24サブネットからのインターネット向け通信確認

www.yahoo.co.jpに接続できることを確認できました。

★接続成功
[hisato@vm-tokyo-01 ~]$ curl -v https://www.yahoo.co.jp
*   Trying 182.22.24.252:443...
* Connected to www.yahoo.co.jp (182.22.24.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1

～途中省略～

> GET / HTTP/2
> Host: www.yahoo.co.jp
> user-agent: curl/7.76.1
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
< HTTP/2 200 
< server: nginx
< date: Fri, 12 Jul 2024 07:49:23 GMT
< content-type: text/html; charset=UTF-8

～以下省略～

www.yahoo.co.jp以外には接続できないことを確認できました。

★接続失敗
[hisato@vm-tokyo-01 ~]$ curl -v https://www.rakuten.co.jp
*   Trying 23.201.17.168:443...
* connect to 23.201.17.168 port 443 failed: Connection timed out
* Failed to connect to www.rakuten.co.jp port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to www.rakuten.co.jp port 443: Connection timed out

10.24.12.0/24サブネットからのインターネット向け通信確認

www.yahoo.co.jp以外から接続できることを確認できました。

★接続成功
[hisato@vm-tokyo-02 ~]$ curl -v https:/www.rakuten.co.jp
*   Trying 23.201.17.168:443...
* Connected to www.rakuten.co.jp (23.201.17.168) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1

～途中省略～

> GET / HTTP/2
> Host: www.rakuten.co.jp
> user-agent: curl/7.76.1
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
< HTTP/2 200 
< server: Apache
< pragma: no-cache

～以下省略～

まとめ

Google Cloudのファイアウォールルールとファイアウォールポリシーは、それぞれ異なるレベルでネットワークのセキュリティを制御するために設計されています。ポリシーは大規模な設定の一元管理に適しており、ルールは細かなアクセス制御に役立ちます。これらを効果的に使い分けることで、よりセキュアで効率的なクラウド環境を構築できるでしょう。

Google Cloudのセキュリティを最大限に活用するためには、定期的な見直しと最適化が欠かせません。ぜひ、この記事の内容を参考に、最適なセキュリティ設定を実現してください。

Google Cloud DNSの基礎から実践まで - 設定方法と動作確認のステップバイステップガイド

Google Cloud ホームラボ Cloud DNS

富士ソフトの佐藤です。
Google Cloud DNSは、高性能で信頼性の高いDNSサービスであり、Googleのグローバルネットワークを活用しています。これにより、低レイテンシーで安定したドメイン名解決を実現します。
本記事では、Cloud DNSの特徴や利点、設定手順を詳しく解説し、実践的なスキルを身につける手助けをしていきます。

はじめに

1.1 Cloud DNSとは

Google Cloud DNSは、Google Cloud（GC）の一部として提供されるスケーラブルで高可用性のDNSサービスです。このサービスは、ユーザーがドメイン名をIPアドレスに変換するためのDNSレコードを管理できるように設計されています。Cloud DNSは、Googleのインフラストラクチャを活用して、高速かつ信頼性の高いDNS解決を提供します。

1.2 Cloud DNSの主な特徴と利点

高可用性：Googleのグローバルネットワークを使用して、常に利用可能なDNSサービスを提供します。
スケーラビリティ：大規模なトラフィックにも対応可能で、急激なトラフィック増加にも柔軟に対応します。
セキュリティ：DNSSEC（DNS Security Extensions）をサポートし、DNSデータの整合性と認証を確保します。
簡単な管理：GCコンソールやAPIを通じて簡単にゾーンやレコードを管理できます。


Cloud DNSの基本概念

2.1 ゾーンとレコードタイプ

Cloud DNSでは、DNS情報は「ゾーン」と呼ばれる単位で管理されます。ゾーンは特定のドメイン名に関連するDNSレコードの集合です。主要なレコードタイプには以下があります。
Aレコード：ドメイン名をIPv4アドレスにマッピングします。
AAAAレコード：ドメイン名をIPv6アドレスにマッピングします。
CNAMEレコード：別のドメイン名へのエイリアスを作成します。
MXレコード：メールサーバーの優先順位とアドレスを指定します。


2.2 ネームサーバーとDNS解決の仕組み

DNS解決は、クライアントがドメイン名を入力した際に、その名前に関連するIPアドレスを取得するプロセスです。ネームサーバーは、このプロセスを担うサーバーであり、Cloud DNSではGoogleが提供するネームサーバーが使用されます。


Cloud DNSの設定手順

それでは、実際にGoogleの環境にCloud DNSをデプロイしていきたいと思います。

構成

今回は、一般に公開しないプライベートなDNS環境を構築し、Google Cloud内のインスタンスからFQDN「www.googlelab.local」でWebサーバーに接続してみます。

プライベートDNSゾーンの作成

１．JITHUBプロジェクトから、[ネットワークサービス]-[Cloud DNS]-[ゾーン]をクリックし、「+ゾーンを作成」を選択します。

２．DNSゾーンの作成で以下の情報を入力し、「作成」を選択して、一般には公開しないプライベートなゾーンを作成していきます。
　　ゾーンのタイプ：プライベート
　　ゾーン名：googlelab-local
　　DNS名：googlelab.local
　　オプション：デフォルト（限定公開）
　　プロジェクト：JITHUB
　　ネットワーク：mainvpc

３．ゾーンの作成が完了したら、レコードセットから、「+標準を追加」を選択します。

４．レコードの作成で、以下の情報を入力し、「作成」を選択します。

５．レコードが作成できたことを確認します。表示されるリストに新しいレコードが含まれていることを確認してください。


動作確認とトラブルシューティング

Google Cloud内で名前解決確認

Subnet03のインスタンス（10.24.3.7）からブラウザに「http://www.googlelab.local/」と入力し、Subnet01のインスタンス（10.24.1.3）のWebページが表示されることを確認します。


Cloud DNSの応用と高度な機能

今回の検証では実施しませんが、以下を実現することで、セキュリティ対策や高度な運用が可能です。

6.1 DNSセキュリティ（DNSSEC）

Cloud DNSはDNSSECによるセキュリティ機能も提供しています。これにより、不正なDNSデータから保護されます。DNSSECの設定はゾーン設定画面から行えます。

6.2 ルーティングポリシーの活用

Cloud DNSではルーティングポリシーも利用可能です。これにより、地理的な位置やトラフィック負荷に応じて異なるIPアドレスへルーティングできます。この機能は特定のビジネスニーズに応じた柔軟な対応が可能です。

まとめと次のステップ

この記事ではGoogle Cloud DNSについて基本的な概念から実際の設定方法まで詳しく解説しました。これからは実際に自分自身でCloud DNSを試してみて、その利点や機能について深く理解することが重要です。また、さらに高度な機能やセキュリティ対策についても学び、自身のプロジェクトに役立ててください。今後もGoogle Cloud Platformについて学び続け、新たな技術やサービスへの理解を深めていきましょう。

Private Service Connectインターフェース機能ガイドと設定方法を紹介

Google Cloud Private Serivce Connect ホームラボ

富士ソフトの佐藤です。
前回ご紹介したPrivate Service Connect（PSC）エンドポイントは、公開サービスに接続するための機能でしたが、公開サービス側のサーバーからは、VPCピアリングやNetwork Connectivity Centerで接続していないVPCへは接続できません。
今回は、Private Serivce Connectインターフェースを利用して、公開サービス側から他のVPCへ接続する方法について紹介します。

Private Service Connect と 3 種類のタイプについて

Google Cloud ネットワーキング機能の一つで、外部IPを持たない仮想マシンやオンプレミスのクライアントが、 VPC ネットワーク内からプライベートIPを経由して、次のタイプのマネージド サービスへのアクセスをサポートしています。


Google Cloud ドキュメントから引用


Private Service Connect（以下、PSC）には、以下の 3 つのタイプがあります。

１．Endpoint

PSC エンドポイントは、コンシューマー VPC ネットワーク内のクライアントが、アクセスできる内部 IP アドレスです。エンドポイントは、接続したいサービスがあるプロジェクトのサービス アタッチメントまたは Google API のバンドルを参照する転送ルールをデプロイすることで作成されます。
以下は、組織内で開発した公開サービスにアクセスする例です。


以下は、Cloud Storage や BigQuery などの Google API にアクセスする例です。

２．Backend

コンシューマーロードバランサ経由で バックエンドへトラフィックを送信し、公開サービスまたは Google API にアクセスできます。PSC バックエンドは、プロデューサー サービス アタッチメントまたはサポートされている Google API を参照する、PSC ネットワーク エンドポイント グループ（NEG）を使用してデプロイされます。
マネージド サービスの前面にロードバランサを配置すると、同じ接続先を通じて移行元と移行先のサービスを同時に提供でき、移行プロセスを簡素化することができます。また、エンドポイントを介した場合よりもコンシューマーの可視性が高まり制御しやすくなります。

３．Interface

PSC インターフェースは、プロデューサーの仮想マシンに、2 つ目の標準ネットワークインターフェースを提供し、コンシューマー VPC ネットワーク内のサブネットの IP アドレスを割り当てます。
これにより、プロデューサーの仮想マシンは、コンシューマー VPC経由で、Google Cloud 内およびオンプレミスネットワークと通信することが可能です。
今回は、この機能についての紹介です。


どのようなときに Private Service Connect インターフェースを使うのか

VPCがネットワーク的に孤立している

プロデューサー VPC を作成した際に、VPC ピアリングや Network Connectivity Center により、Google Cloud 内または、InterConnect や VPN 経由でオンプレミス環境と接続しますが、ネットワークアドレスの重複などにより、コンシューマー VPC が接続できない場合があります。このような時に、PSCエンドポイントで開発したサービスを公開したり、PSCインターフェースにより社内システムへの接続を実現することが可能です。

設計時のポイント

デフォルトルートは1つ目のネットワークインターフェースとなる

PSCインターフェースを利用すると、Compute Engineに2つ目のネットワークインターフェース（NIC）ができますが、デフォルトルートは1つ目のNICとなっています。PSCインターフェースのNICのみにすることや、1つ目をPSCインターフェースにすることはできないため、インターネットへの接続がどちらのNICを経由した先にあるのかをあらかじめ確認しておき、ネットワーク構成を決定する必要があります。

Compute EngineへのアクセスはPSCエンドポイントのみである。

一般的に、VPCピアリングやNetwork Connectivity CenterなどでVPCが接続していて、ファイアウォールで上り（内向き）の通信許可を行っていれば、Compute Engineへ接続することは可能ですが、PSCエンドポイントやPSCインターフェースの構成を採用していると、直接接続することはできないため、必ずPSCエンドポイント経由での接続が必要となります。
様々なポートを使用して頻繁に接続するようなCompute Engineに適用してしまうと、運用が煩雑となってしまいます。

PSCインターフェース設定手順

今回は、3 種類ある PSC タイプの中から、PSCインターフェースを使用した 公開サービスへのアクセス手順について紹介します。

ネットワーク構成図

ホームラボとGoogle Cloudの環境を接続して、SpokeBに新規作成したCompute Engineからオンプレ環境の仮想マシンへ接続する検証を行います。


提供側のプロジェクトでネットワークアタッチメントを作成

１．JITHUBプロジェクトで、 [ネットワークサービス]-[Private Service Connect ]-[ネットワークアタッチメント]を選択し、[+ネットワークアタッチメントを作成]を選択する。

２． ネットワーク アタッチメントの作成で、以下の情報を入力し、「ネットワーク アタッチメントの作成」を選択する。なお、ネットワークアタッチメントは、リージョンごとに作成する必要があるので、大阪リージョンにもネットワークがある場合は、PSC用のサブネットを作成し、同様の設定を行ってください。
　　名前：attatch-tokyo01
　　ネットワーク：mainvpc
　　リージョン：asia-northeast1（東京）
　　サブネットワーク：subnet-psc
　　接続の設定：すべてのプロジェクトの接続を自動的に受け入れる

３．作成したネットワークアタッチメントの「attatch-tokyo01」を選択し、ネットワーク アタッチメントの接続情報を控えておきます。
　　ネットワークアタッチメント：projects/jithub-414902/regions/asia-northeast1/networkAttachments/attatch-tokyo01


利用側のCompute Engineを作成しPSCインターフェースを設定する。

１．SpokeBプロジェクトで、 [Compute Engine]-[VMインスタンス]を選択し、[+インスタンスを作成]を選択する。

２．「VMの基本」で、エンドポイントを接続の画面で、以下の情報を入力する。
　　名前：instance-win01
　　リージョン：asia-northeast1（東京）

３．「マシンの構成」で、マシンタイプを「e2-standard-2」に変更する。

４．「OSとストレージ」で、イメージを「Windows Server 2022 Datacenter」に変更する。

５．「ネットワーキング」で、1つ目のネットワークインターフェースの情報を入力し、「完了」を選択後、「ネットワーク インターフェースを追加」をクリックする。
　　ネットワーク：vpc-b
　　サブネットワーク：subnet-b01 IPv4（10.168.10.0/24）
　　外部 IPv4 アドレス：なし

６．2つ目のネットワークインターフェースの情報を入力し、「完了」を選択後、「作成」をクリックしインスタンスを作成する。
　　インターフェース タイプ：Private Serivce Connect
　　ネットワーク アタッチメントのURL：projects/jithub-414902/regions/asia-northeast1/networkAttachments/attatch-tokyo01
　　IP スタックタイプ：IPv4（シングル スタック）

７．作成したインスタンスに2つのNICがあることを確認する。


インスタンスのルート情報確認とスタティックルートの設定

１．インスタンス名の「instance-win01」をクリックし、「WINDOWS パスワードを設定」からアカウントの作成を行う。

２．Google Consoleの操作をしている端末でコマンドプロンプトを開き、IAP接続のためのトンネル設定を行う。

C:\>gcloud compute start-iap-tunnel instance-win01 3389 --local-host-port=localhost:0 --zone=asia-northeast1-c
Picking local unused port [58146].
WARNING:

To increase the performance of the tunnel, consider installing NumPy. For instructions,
please see https://cloud.google.com/iap/docs/using-tcp-forwarding#increasing_the_tcp_upload_bandwidth

Testing if tunnel connection works.
Listening on port [58146].

３．リモートデスクトップアプリを開き、コンピュータ名に、「localhost:58146」と入力し接続する。

４．IPアドレスとルート情報を確認し、デフォルトルートが10.168.10.13となっていることを確認する。

C:\>ipconfig

Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : asia-northeast1-c.c.spokeb-430504.internal.
   Link-local IPv6 Address . . . . . : fe80::1745:2100:ee54:8873%5
   IPv4 Address. . . . . . . . . . . : 10.168.10.13
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.168.10.1

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . : asia-northeast1-c.c.spokeb-430504.internal.
   Link-local IPv6 Address . . . . . : fe80::fa8:8240:edb6:f402%4
   IPv4 Address. . . . . . . . . . . : 10.24.6.6
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

C:\>
C:\>route print
===========================================================================
Interface List
  5...42 01 0a a8 0a 0d ......Google VirtIO Ethernet Adapter
  4...42 01 0a 18 06 06 ......Google VirtIO Ethernet Adapter #2
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.168.10.1     10.168.10.13      5
        10.24.6.0    255.255.255.0        10.24.6.1        10.24.6.6      6
        10.24.6.1  255.255.255.255         On-link         10.24.6.6      6
        10.24.6.6  255.255.255.255         On-link         10.24.6.6    261
      10.168.10.0    255.255.255.0      10.168.10.1     10.168.10.13      6
      10.168.10.1  255.255.255.255         On-link      10.168.10.13      6
     10.168.10.13  255.255.255.255         On-link      10.168.10.13    261
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  169.254.169.254  255.255.255.255         On-link      10.168.10.13      6
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link         10.24.6.6    261
        224.0.0.0        240.0.0.0         On-link      10.168.10.13    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link         10.24.6.6    261
  255.255.255.255  255.255.255.255         On-link      10.168.10.13    261
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
  169.254.169.254  255.255.255.255         On-link        1
===========================================================================

５．このままでは、オンプレ環境へ接続できないため、以下のスティックルートを設定し、ルート情報が反映されていることを確認する。

html >

C:\>route add 192.168.0.0 mask 255.255.0.0 10.24.6.1 -p
OK!

C:\>
C:\>
C:\>route print
===========================================================================
Interface List
5...42 01 0a a8 0a 0d ......Google VirtIO Ethernet Adapter
4...42 01 0a 18 06 06 ......Google VirtIO Ethernet Adapter #2
1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.168.10.1 10.168.10.13 5
10.24.6.0 255.255.255.0 10.24.6.1 10.24.6.6 6
10.24.6.1 255.255.255.255 On-link 10.24.6.6 6
10.24.6.6 255.255.255.255 On-link 10.24.6.6 261
10.168.10.0 255.255.255.0 10.168.10.1 10.168.10.13 6
10.168.10.1 255.255.255.255 On-link 10.168.10.13 6
10.168.10.13 255.255.255.255 On-link 10.168.10.13 261
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
169.254.169.254 255.255.255.255 On-link 10.168.10.13 6
192.168.0.0 255.255.0.0 10.24.6.1 10.24.6.6 6
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.24.6.6 261
224.0.0.0 240.0.0.0 On-link 10.168.10.13 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.24.6.6 261
255.255.255.255 255.255.255.255 On-link 10.168.10.13 261
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
169.254.169.254 255.255.255.255 On-link 1
192.168.0.0 255.255.0.0 10.24.6.1 1
===========================================================================
|

動作確認

オンプレ環境にある仮想マシン（192.168.10.91）へICMP、およびHTTP接続できることを確認する。

C:\>ipconfig

Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : asia-northeast1-c.c.spokeb-430504.internal.
   Link-local IPv6 Address . . . . . : fe80::1745:2100:ee54:8873%5
   IPv4 Address. . . . . . . . . . . : 10.168.10.13
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.168.10.1

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . : asia-northeast1-c.c.spokeb-430504.internal.
   Link-local IPv6 Address . . . . . : fe80::fa8:8240:edb6:f402%4
   IPv4 Address. . . . . . . . . . . : 10.24.6.6
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

C:\>ping 192.168.10.91

Pinging 192.168.10.91 with 32 bytes of data:
Reply from 192.168.10.91: bytes=32 time=53ms TTL=61
Reply from 192.168.10.91: bytes=32 time=51ms TTL=61
Reply from 192.168.10.91: bytes=32 time=40ms TTL=61
Reply from 192.168.10.91: bytes=32 time=52ms TTL=61

Ping statistics for 192.168.10.91:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 40ms, Maximum = 53ms, Average = 49ms

C:\>


まとめ

本記事では、Private Service Connectインターフェースを使用して、どのVPCにも接続していないプロジェクトからオンプレミス環境へ接続する方法について解説しました。本機能を利用することで、プロジェクトで自由なサブネット設計を行いながら、既存の社内ネットワークに接続できるようになります。
このようにプロジェクト開発者に自身のプロジェクトのネットワーク管理を任せることができ、管理者側の運用負担を軽減することが可能になりますので、今後プロジェクトを払い出す際には、PSCを利用した接続の検討をしてみてはいかがでしょうか。