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分です。

2022 年 3 月現在、当試験は 英語版のみ の提供となります。
英語版試験の申込み方法は日本語版試験と異なります。
以前の Looker LookML Developer試験対策 記事において説明していますのでご参照ください。

当試験では問題文が長く、複雑なネットワーク構成が英文で説明されるため、読み解きに時間がかかることが想定されます。
構成図で説明してくれるような問題は無く、英文をしっかり読み解く必要があります。
普段から 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 のネットワーク設計の際に適切なトポロジを選択できるか、可用性とセキュリティを考慮した設計ができるか、また実運用時のトラブルに対処できるか、といった観点で出題されます。

以下のようなサービスが出題範囲です。

  • 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 を経由した通信は できず 、直接接続されているネットワーク間のみでしか通信できません。

しかし、適切に設定しさえすれば、図右下の表のように相互にネットワーク間通信が実現できます。
(ただし VPC (B) ⇔ VPC (C) 間の通信は実現 できません 。後述。)

設定内容は、以下のとおりです。

  • 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 の仕組みを問う問題が出題されます。

ステートフルインスペクションや 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 のルートを使うとき だけである 、といった基本的な内容は押さえておくべきです。

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 Acess) を組み合わせるような問題が頻出です。
オンプレミスサイトと VPC が Cloud Interconnect や VPN で接続されており、オンプレミスのクライアントから Google API を 限定公開の Google アクセス 経由で利用するケースです。
このときに VPC Service Controls で API を保護したいケースが出題されます。

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

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

VPC Service Controls については、ぜひ以下のブログをご参照ください。

blog.g-gen.co.jp

限定公開の Google アクセスについては、以下のブログをご参照ください。

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 が RFP 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 ルールへのヒットの急増
  • 実質的に使われていないファイアウォールルールの棚卸し

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

杉村 勇馬 (記事一覧) (Facebook)

クラウドソリューション部 部長

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格10冠。

2022年5月現在、ハマっているものはモンスターエナジーウルトラ。