Professional Cloud Network Engineer試験対策マニュアル

記事タイトルとURLをコピーする

G-genの杉村です。 Professional Cloud Network Engineer は Google Cloud (旧称 GCP) のプロフェッショナルレベルの認定資格の一つです。 Google Cloud のネットワーク系サービスや専用線・ VPN 等に関する高度な知識を確認する難関試験です。

当記事では合格に役立つ Tips、勉強方法、 出題傾向等をご紹介いたします。

Professional Cloud Network Engineer

Professional Cloud Network Engineer 試験について

概要

Professional Cloud Network Engineer 試験では Google Cloud のネットワーク系サービスや専用線・ VPN 等に関する知識が問われます。

試験問題は50問、試験時間は120分です。

2023年7月現在、当試験は英語版と日本語版が提供されています(従来は英語版しかありませんでしたが、2023年7月に日本語版がリリースされました)。

当試験では問題文が長く、複雑なネットワーク構成が説明されるため、ネットワーク設計に慣れていないと読み解きに時間がかかることが想定されます。構成図で説明してくれるような問題は無く、問題文をしっかり読み解く必要があります。

難易度

Professional Cloud Network Engineer 試験の難易度は、中〜高程度だと言えます。

VPC を中心に、Google Cloud のネットワークの仕様に関する深い知識が問われます。特に、専用線や Cloud VPN を使用したり、VPC Network Peering で複数の VPC Network を接続する際の、ルーティングの仕様が細かく問われます。また、Cloud DNS を複数の VPC から、あるいはオンプレミスから利用するなどの特別なユースケースに関する問題も問われます。

公式の試験要項には「業界経験が 3 年以上(Google Cloud を使用したソリューションの設計と管理の経験 1 年以上を含む)。」という要件が記載されていますが、必ずしもここまでの経験は必要ありません。 Google Cloud に関する Professional Cloud Architect 程度の知見に加えて、一般的なネットワーク技術の知見、特にルーティングやファイアウォールに関する知識を持っていることが望ましいです。とはいえ、Google Cloud の VPC は独特の仕様を持っていますので、一般的な知識に加えて、Google Cloud 特有のネットワーク仕様をしっかりと学んでおく必要があります。

勉強方法

推奨の勉強方法は、以下となります。

  1. 試験ガイド を読む
  2. 試験ガイドで把握した試験範囲について勉強する
  3. この際 Google Cloud に限らない一般的なネットワーク知識についても穴埋めをする
  4. 模擬試験 を受ける
  5. 当記事を読み、出題傾向を把握し、知らない知識を穴埋めする

特に VPC や Cloud VPN などは、Google Cloud の検証環境があれば、実際に構築してみることをお勧めします。コンソールの構築画面や CLI のコマンド構造を見ることで、Google Cloud のリソース構成が直感的に理解できるため、理解が飛躍的に進みます。

ルーティングや Cloud DNS、Cloud Interconnect などについては、以下の書籍が設計要素などについて詳しく解説しており、オススメです。

出題傾向

VPC のルーティングや専用線、 Cloud DNS に関する問題が非常に多く出題されます。「Google Cloud のネットワーク設計の際に、適切なトポロジを選択できるか」「可用性とセキュリティを考慮した設計ができるか」「実運用時のトラブルに対処できるか」といった観点の出題が多いです。

出題範囲は、以下のような Google Cloud サービスです。

  • VPC
    • Routing
    • Firewall
    • Shared VPC
  • Packet Mirroring
  • Cloud Router
  • Cloud NAT
  • Cloud Load Balancing
  • VPC Service Controls
  • Dedicated / Partner Interconnect
  • Cloud VPN
  • Cloud DNS
  • Cloud Armor
  • Network Intelligence Center

本記事ではこれ以降、試験合格のために「具体的に何を知っているべきか」について細かく記述します。試験の利用規約の関係上、具体的な出題内容はご紹介できませんが、当記事が試験合格のための参考になれば幸いです。

VPC

ハブアンドスポーク型トポロジ

カスタムルート広報とピアリング

VPC Peering や Cloud VPN を駆使した複雑なネットワーク構成について問われる問題が多く出題されます。

なかでも Hub-and-Spoke 型 (スター型とも呼ばれる) のネットワークトポロジに関する問題が頻出です。以下に例を挙げます。

Hub-VPC を中心としたネットワーク

このネットワークは VPC (A) をハブとして、オンプレミスサイト、 VPC (B) 、 VPC (C) と接続されています。VPC (A) と オンプレミスは Cloud VPN (IPSec VPN) で接続されており、 VPC 間は VPC Peering で接続されています。

このとき、Cloud Router や VPC Peering がデフォルトの設定のままだと、「オンプレミスから VPC (B) へ」といったハブ VPC を経由した通信はできず、直接接続されているネットワーク間のみでしか通信できません。

しかし、適切に設定しさえすれば、図右下の表のように相互にネットワーク間通信が実現できます。設定内容は、以下のとおりです。

  • Cloud Router にてオンプレミスの対向ルーターに広報するルートを明示的に設定する
    • デフォルトだと Cloud Router が紐づいている VPC (A) のサブネットの CIDR しか広報されない
    • Peering で繋がっている VPC (B) と (C) のルートも追加で広報するよう、明示的に設定
  • VPC (A) 側の 2 つある Peering 設定にてカスタムルートをエクスポートするよう設定する
    • これにより対向である VPC (B) および (C) にカスタムルート (オンプレから受け取った 10.0.0.0/8 のルート) を渡せる
  • VPC (B) および (C) の Peering 設定にて対向である VPC (A) からカスタムルートをインポートするよう設定する
    • これにより対向である VPC (A) からカスタムルート (オンプレから受け取った 10.0.0.0/8 のルート) を受け取れる

1 つ目の設定をしないと、オンプレミスルーターは VPC (B) と (C) への経路を知ることができません。Cloud Router はデフォルトだと、自分が紐付いている VPC のルートのみを、対向ルーターへ広報するからです。VPC (B) と (C) の経路を対向ルーターへ広報するよう、明示的に設定してあげる必要があります。これをカスタムルート広報といいます。

2 つ目と 3 つ目の設定をしないと、 VPC (B) と (C) はオンプレミスへの経路を知ることができません。カスタムルートのインポート・エクスポートの設定をしてあげることで、 VPC (A) がオンプレミスから受け取った 10.0.0.0/8 というルートを VPC (B) と (C) に教えてあげることができます。なおここでいうカスタムルートとは Google Cloud によって自動的に生成されるルート (デフォルトルートやサブネット間のルート) 以外 の動的・静的なルートを指しています。この図でいえば、オンプレミスから BGP で受け取った 10.0.0.0/8 へのルートがカスタムルートになります。

複雑ですが、上記のような一通りの設定を行うと、 VPC (A) をハブとした相互通信が可能になるのです。

VPC 間の推移的ピアリング

VPC (B) と (C) 同士の通信ですが、これは VPC Peering で繋がった VPC を経由して通信をする推移的ピアリングと呼ばれる形になり、 VPC ではこの通信ができない仕様 になっています。これは AWS の VPC Peering でも同様で、「2 ホップ制限」とも呼ばれています。

VPC Peering では直接繋がっている VPC 間でしか通信できないと覚えておきましょう。

VPC (B) と (C) を通信させたい場合は、これらを直接、VPC Peering で繋ぐ必要があります。つまり VPC Peering で複数の VPC 間通信を実現したい場合、接続はフルメッシュになります。フルメッシュ構成ではネットワークの数を n とすると n * (n-1) / 2 の数の Peering を作成することになります。

しかし、そのようなフルメッシュ構成は複雑性を高め、運用性を下げるため、これを避ける方法もあります。それは VPC 間を Peering ではなく、Cloud VPN で接続することです。

Cloud VPN で繋がっていれば、先程の図でオンプレミスと行ったのと同じように経路の交換ができますので、ハブ VPC を中心としたトポロジで VPC 間通信をさせることができます。

Cloud VPN には 利用料金 がかかってしまうため、実際の設計ではコストと運用性のトレードオフを検討することになります。

参考情報

Google Cloud のルーティングに関する詳細は、以下の記事もご参照ください。

medium.com

blog.g-gen.co.jp

VPC Firewall

Firewall の基本とベストプラクティス

VPC Firewall Rules の仕組みを問う問題が出題されます。ステートフルインスペクションや Ingress、 Egress、 ターゲット、ネットワークタグ、サービスアカウントの概念が分かれば解けるものとなっています。

Google Cloud のベストプラクティスとして、 VPC Firewall で VM 間通信を制御する際は、ネットワークタグよりもサービスアカウントを利用することが 推奨 されています。このようなベストプラクティスも押さえておく必要があります。

ネットワークタグは VM に対する管理権限 ( Compute Instance Admin ロール等 ) を持っていれば編集ができてしまうのに対し、サービスアカウントはサービスアカウントごと個別に IAM でアクセス制御ができるため、インスタンス管理者がネットワーク管理者の許可なく、禁止されている通信を可能にしてしまう、ということを抑止することができます。これがポイントとされる問題も出題されます。

gcloud による設定

gcloud compute firewall-rules create コマンド ( Reference ) を使って適切にファイアウォールを設定した経験があるか、問われる問題もあります。

例えば、--direction オプションを省略するとデフォルト値は INGRESS になるなど、ある程度細かい仕様も押さえておく必要があるかもしれません。

Firewall Policy

Firewall Policy の継承、評価順、goto_next などを理解していれば解ける問題も出題されます。

上位リソースにアタッチされた Firewall Policy がどのように下位リソースに渡って評価されるか、 ドキュメント で確認しておきましょう。

Shared VPC

ネットワークを IT 管理者が中央管理し、各ユーザー部門の開発部隊にそれを使わせたい、といったときに Shared VPC が活躍します。

Host project や Service projects といった言葉など、基本的な概念をドキュメントで押さえておきましょう。

細かいところでは、Shared VPC の IAM に関する出題があります。Shared VPC Admin というロールがありますが、これは組織レベルもしくはフォルダレベルにアタッチする必要があることに注意が必要です。

Shared VPC Admin がサブネットリソースに Network User ロール (Service Project Admin として言及されることも) を付与することで、利用者側は自分の VM 等を共有されたサブネットに配置することができるようになります。

このあたりは一度、実際にコンソール等で構築をしてみると分かりやすいでしょう。

Monitoring

Packet Mirroring

例えば「VM から Egress する全てのトラフィックを検査しなければならない」といったセキュリティ要件がある際に活躍するのが Packet Mirroring です。

Packet Mirroring では VM のネットワークインターフェイスからパケットをミラーして、別の VM へ渡す機能です。これにより、パケット解析などを行うことができます。VPC を流れる全てのパケットをミラーできる訳ではなく VM へ出入りするパケットのみです。

また Filter により「プロトコル」「 IP アドレスレンジ」「トラフィックの方向 (VM へ入るパケットのみ / VM から出るパケットのみ / 両方) 」でミラーするパケットを絞ることができます。受け取り手の VM の手前には Internal TCP/UDP Load Balancer が必要です。

Firewall Logging

Firewall Logging の基本も押さえておきましょう。

Firewall Logging はルールごとに有効化します。もちろん、取得できるのはそのルールに評価されたパケットだけです。問題文に書かれている要件に Firewall Logging が本当に合致しているかには注意して回答が必要です。

Cloud NAT

セキュリティ上、VM に Public IP を持たせることはできれば避けたいものです。Cloud NAT を使えば Public IP を持たない VM もインターネットへ出ていくことができます。

Cloud NAT は意外と細かい設定が可能です。とはいえ、全てを覚える必要はありません。

ただし Cloud NAT が VM のパケットを NAT するのはパケットが「0.0.0.0/0 → default internet gateway」のルートを使うときだけである 、といった基本的な内容は押さえておくべきです。ネクストホップが default internet gateway 以外(Cloud VPN 等)であったり、0.0.0.0/0 より狭いターゲットが指定されている場合は、Cloud NAT は使われません。

Cloud Load Balancing

各種用途のために適切な ロードバランサーを選択 できるようにしておきましょう。

ロードバランサーは種類が多く、一見大変に思えますが、軸を覚えてしまえばそこまで大変ではありません。「Internal / External」「Regional / Global」「Proxy / Pass-through」「TCP & UDP / HTTP(S) / SSL」などです。

例えば「一般公開するシステムで、パススルー型の (接続元 IP を書き換えない) ロードバランサーが必要だ」と問われたならば、これだけで選択肢は External TCP/UDP Network load balancer であると定まります。

また「アメリカの西海岸リージョンと東海岸リージョンにそれぞれ AP サーバーがあり、顧客は HTTPS でアクセスする」ならば Global external HTTP(S) load balancer となります。

VPC Service Controls

VPC Service Controls と 限定公開の Google アクセス (Private Google Access) を組み合わせるような問題が頻出です。

オンプレミスと VPC が Cloud Interconnect や VPN で接続されており、オンプレミスのクライアントから Google API を「限定公開の Google アクセス」経由でアクセスするよう構成されているネットワークにおいて、VPC Service Controls を使った API を保護実現したいケースが出題されます。

このようなケースで、限定公開の Google アクセスのためのドメイン名として restricted.googleapis.com を使うのか private.googleapis.com を使うのか、答えられるようにしておきましょう。

また VPC Service Controls に対して直ちに設定を変更すると本番影響が恐ろしいため、どう事前精査するか、といった実用的な内容も問われます。

VPC Service Controls や限定公開の Google アクセスについては、ぜひ以下の記事をご参照ください。

blog.g-gen.co.jp

blog.g-gen.co.jp

これらを読めば、先の問いには答えられるようになります。 「限定公開の Google アクセス」は難解なので、実際に検証環境で構築してみると理解が深まります。

Cloud Interconnect

Dedicated Interconnect

Cloud Interconnect は自ら検証するのが非常に難しいサービスです。ドキュメントを中心に、理解を深めましょう。

例えば Dedicated Interconnect の利用開始手順は ドキュメント に記載されているため、流れを把握しておきます。

Partner Interconnect

トポロジ

Partner Interconnect で Google が推奨するトポロジーはどのようなものか、についても把握しておきましょう。

99.99% の可用性を確保するには このドキュメント の図の構成にする必要があります。

  • 別々の 2つのリージョンにそれぞれ Cloud Router を配置
  • 各 Cloud Router からは違うゾーンに向けた2つずつの VLAN Attachment を作成する
  • Cloud Router の 動的ルーティングモード を Global にする

Cloud Router のルーティングモードを Global にすることで片方の回線が落ちてもルーティングが活きるようになる、という点に注意してください。

L2 と L3

Partner Interconnect には Layer 2 と Layer 3 の 二種類が存在 します。

L2 だと自社ルーターと Cloud Router 間で BGP Session 確立が必須です。
L3 だと Cloud Router とオンプレミスの間で BGP を貼るのは、ネットワーク業者のルーターです。そのルーターから自社への経路をどうするかは、パートナーによります。

適切な Interconnect の選択

Dedicated Interconnect / Partner Interconnect Layer 2 / Partner Interconnect Layer 3 の間で、適切な選択をできるかどうか問う問題もでてきます。

Dedicated Interconnect は Google の PoP (Point of Presence) まで回線が引けることが必須です。それができない場合は Partner Interconnect を選択することになりますが、自社のルーターの BGP 対応可否などで Layer 2 か Layer 3 を選ぶことになります。

Direct Peering / Carrier Peering

Direct Peering / Carrier Peering は Google Workspace 等のパブリックな Google サービスと接続するためのサービスです。深追いする必要はありませんが、その存在と概要は把握しておきましょう。

Cloud VPN

BGP セッション

Cloud VPN については先の VPC 間接続のハブアンドスポーク型トポロジの解説で記載したことをしっかり押さえておきましょう。

これに加え、BGP セッションの設定方法 などは、実際に一度検証してみることが望ましいです。
Google Cloud では VPC 間で VPN 接続を行うことが可能ですため、Google Cloud 検証環境があれば試してみることができます。

BGP IP アドレスは 169.254.x.x (リンクローカルアドレス) であり、また ASN が Private ASN (64512-65535 or 4200000000 - 4294967294) となっている必要があります。

組織のポリシー

組織のポリシーを使うことで、VPN で接続する先のインターフェイスの Public IP を制限することができます。

ドキュメント Restricting peer IP addresses through a Cloud VPN tunnel に記載の constraints/compute.restrictVpnPeerIPs がそれです。

これにより接続可能な IP アドレスのホワイトリストを作ることで不用意な Internet VPN 接続を防ぐことができます。

Cloud DNS

inbound policy

inbound policy を定義することで、オンプレミスのクライアントから Cloud DNS で名前解決クエリを投げたり、オンプレミスの DNS サーバから一部のリクエストを Cloud DNS へフォワーディングすることができます。

inbound policy を作成して VPC に適用すると、オンプレミスのクライアントや DNS サーバから Cloud DNS にリーチするための Private IP アドレス ( inbound forwarder entry points ) が払い出されます。

forwarding zone

逆に forwarding zone は Cloud DNS から一部のドメイン名をオンプレミスや VM 上の DNS にフォワードするための設定です。

特定ドメインの名前解決を Cloud DNS からフォワードして、オンプレの DNS や VM で稼働する DNS へ投げることができるようになります。このCloud DNS からオンプレミス DNS 等へ投げるクエリを Cloud Interconnect や Cloud VPN 経由にすることも可能です。

ただし注意点として、そのとき転送を受ける方の DNS サーバから見たクエリの 接続元 IP は 35.199.192.0/19 となります。プライベートネットワーク経由でクエリが来ているのに、接続元 IP が RFC 1918 のプライベートアドレスではないので若干の気持ち悪さはありますが、こういう仕様です。

Cloud DNS からオンプレミス DNS へのフォワーディングを実現するためには「オンプレミス側ファイアウォール設定で 35.199.192.0/19 からの TCP/UDP 53 番ポートを許可する」「オンプレミス側 DNS の設定でこの IP アドレス帯からの DNS クエリを許可する」「パケットを返せるように経路を設定する ( BGP で Cloud Router から広報する等) 」などの必要がある点、問題でも問われることがあります。

DNS Peering

DNS Peering は、特定ドメインの名前解決を異なるプロジェクト/ VPC の Cloud DNS にフォワードするための設定です。

例えば以下のようなケースで使うことができます。

  • VPC (A) はオンプレミスサイトと Cloud Interconnect で接続されている
  • VPC (A) の Cloud DNS では onpremiss.local のドメイン名をオンプレミスのDNSサーバにフォワードするよう設定されている
  • VPC (B) は VPC (A) と VPC Peering で接続されている
  • VPC (B) で onpremiss.local を名前解決したい

DNS Forwarding と DNS Peering

このようなときに VPC (B) から VPC (A) への DNS Peering を設定することで要件を満たせます。VPC (B) の中にいる VM は Cloud DNS に対して onpremiss.local の名前解決クエリを投げると、 DNS Peering に従い VPC (A) に名前解決をフォワードします。VPC (A) は forwarding zone に従いオンプレミス DNS に名前解決をフォワードします。クエリへの返答は、VPC (B) に返ります。

このような構成を、前述のハブアンドスポーク型トポロジを前提としてルーティングの知識と合わせて問う問題が出題されます。

Cloud Armor

WAF サービスである Cloud Armor も出題範囲です。

概要を理解することに加え、細かいところでは、 Cloud WAF で偽陽性などが発生した際に、どのログを見て調査すれば良いか、などは把握しておきましょう。Cloud Armor の検知に関するログは Cloud Armor の Cloud Audit Log ではなくCloud Load Balancing のアクセスログに出力されます。

その点を含め Cloud Armor でできることについては、当社記事もご参照ください。

blog.g-gen.co.jp

Network Intelligence Center

Connectivity Tests

Shared VPC や オンプレミスとの Cloud VPN / Cloud Interconnect による接続、 VPC Peering などが絡み合った複雑なネットワークでは、ノード間の疎通ができない等のトラブル時の切り分けが複雑化します。

このようなときに Network Intelligence Center の Connectivity Tests が威力を発揮します。

接続元・先 IP を指定してテストを実行することで、疎通の可否を論理的に確認できます。接続元と接続先の間にある VPC Firewall、VPC Route、Cloud Router などの設定が確認され、どこに問題があるかを速やかに特定できます。

ただし、実務で扱うときは各種考慮事項を理解しましょう。Connectivity Tests は Google Cloud 上のリソースの設定情報に基づいて判断するので、オンプレミスのネットワーク機器等の設定を考慮しておらず、実際の通信可否を必ずしも表すものではありません。

Firewall Insights

Network Intelligence Center の Firewall Insights を利用することで 以下のような情報 を得ることができます。

  • VPC ファイアウォールの Deny ルールへのヒットの急増
  • 実質的に使われていないファイアウォールルールの棚卸し

この機能を効率的に使うことで、ネットワーク運用における分析の時間を節約することができます。

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。