こんにちは、クラウドエース株式会社 第一開発部のダッフィです。
近年、Web アプリケーションや業務システムを支える サーバー側のインフラ を、自社の機械室ではなくクラウドプロバイダ上に構築する事例が増えました。一方で、執務するオフィスの LAN や自宅の回線・Wi-Fi ルーターなど、足元のネットワークは今もオンプレミス（または契約プロバイダの設備）に依存しています。クラウド化されているのは主に「クラウド側に置く計算・ストレージ・仮想ネットワーク（VPC ネットワークなど）」をどう設計・運用するか の領域であり、コンソールからマルチリージョンの経路やファイアウォールを組める点は、その文脈での大きな利点です。
しかし、その利便性の高さゆえに、「ネットワークの裏側で実際に何が起きているのか」を意識する機会が少なくなっているようにも感じます。
「VPC ネットワーク作成」の操作を行った時、パケットはどう流れ、どこで制御されているのか。ここを理解しておくことは、トラブルシューティングや設計の品質向上において非常に重要です。
そこで今回は、あえてネットワークの基礎である 「オンプレミス（物理）環境での LAN の挙動」を実験で確かめながら、現代の「Google Cloud VPC ネットワーク」（以下、VPC） がどのような仕組みで通信を実現しているのか、比較検証を行いながら解説します。
前提知識：LAN と VPC
本題に入る前に、今回比較する2つのネットワーク用語について整理しておきます。
つまり、「物理的なケーブルで繋ぐ（LAN）」 か、「クラウド上で論理的にプライベート空間を作って繋ぐ（VPC ネットワーク）」 かという違いはありますが、「独立したプライベートなネットワークを作る」 という目的は同じです。
また、本記事で登場する L2／L3 などのレイヤ番号は、OSI 参照モデル における階層を指します。OSI 参照モデルの概要（各層が何を担当するか）は理解済みである前提で進めます（本文ではデータリンク層・ネットワーク層といった呼び方も併記します）。
検証の概要と環境構築
クラウドの挙動を正しく理解するために、まずは物理環境での基本的な通信を確認します。
本記事では、以下の3つのステップで検証を進め、オンプレミスとクラウドの違いを浮き彫りにします。
検証項目
- L2（データリンク層）の確認（ARP と MAC アドレス）
Ping実行時のパケットをキャプチャし、ARPリクエスト（ブロードキャスト）が送信されていることを確認します。
- 観点：Google Cloud ではこの「ブロードキャスト」がどう処理されているのか？
- L3（ネットワーク層）の確認（サブネットとルーティング）
片方の PC のサブネットを変更して通信断を再現し、論理ネットワークの境界を確認します。
- 観点：物理的に接続されていても通信できない理由は何か？Google Cloud の「グローバルVPC」との違いは？
- セキュリティの確認（ファイアウォール）
OS のファイアウォールを有効化し、通信拒否の状態を再現します。
- 観点：ネットワーク層（L3）まで到達していても通信が拒否される挙動と、Google Cloud の「ゼロトラスト」思想との比較。
検証環境
- PC 2台（以下、PC-A、PC-B）
- Wi-Fi ルーター1台（ルーターの LAN ポートを使用し、レイヤ2（データリンク層）スイッチとして機能させます）
- Wireshark（パケットキャプチャツール。PC-A に導入し、通信内容を可視化します）
この環境は、Google Cloud に例えると「同一 VPC 内の同じサブネットに配置された2つのVM インスタンス」と同じ状況です。
LAN ネットワークの構成図
検証
L2（データリンク層）の確認（ARP と MAC アドレス）
まずは、L2（データリンク層）の挙動を確認します。普段意識することは少ないですが、通信の根本を支える重要な仕組みです。
【実験内容】 ARP リクエストの観測
PC-A から PC-B へ通信（Ping）を行う際、L3（ネットワーク層）では IP アドレスを使って通信先を指定します。しかし、実際にデータを送信する L2（データリンク層）では「MAC アドレス（物理アドレス）」が必要になります。そのため、IP アドレスから MAC アドレスを解決するために ARP（Address Resolution Protocol） が使用されます。
「指定された IP アドレスを持つ機器はどれか？その MAC アドレスは何か？」を確認する動作を見てみましょう。
一度やり取りがあると、PC は結果を ARP テーブル（キャッシュ） に記録します。キャッシュが残っている状態では、同じ相手へ再度通信するときに ARP クエリが省略されることがあるため、Wireshark にブロードキャストが現れません。そこで、本実験では先にテーブルを空にし、Ping に合わせて ARP が発生するところから確実に観測できる状態を作ります。
- PC-A で
arp -d *コマンドを実行し、MAC アドレスの学習履歴（ARP テーブル）を消去。 - Wireshark を起動し、パケットのキャプチャを開始。
- PC-A から PC-B へ Ping を実行。
【観測結果】
Wireshark の画面を確認すると、Ping（ICMP）が送信される直前に、ARP Request というパケットが記録されています。
内容を確認すると、「Who has 192.168.x.x? Tell 192.168.x.y」 というメッセージが確認できます。
これは PC-A が、まだ該当機器が分からないため 個別の MAC アドレス宛には送らず、同一ネットワーク内の機器へ無差別に、全体に向けて、「この IP アドレスを使っている機器は誰ですか？MAC アドレスを教えてください」と問い合わせを送っている状態です。これが ブロードキャスト と呼ばれる動きです。
Wiresharkのブロードキャスト結果
【考察】Google Cloud の VPC との違い
物理環境では、相手を特定するためにこの 無差別な全体向けの送信（ブロードキャスト） が必要不可欠ですが、接続台数が増えるとネットワーク全体の負荷を高める要因です。
Google Cloud では、この 無差別な全体向けの送信 は行われません。
オンプレの LAN のようにスイッチの動きに任せて同報させるのではなく、転送のやり方をソフトウェア側で決める という設計が VPC の背後にあります。これが SDN（ソフトウェア定義ネットワーク） の考え方で、Google Cloud では Andromeda というネットワーク基盤がそれを実現しています。
VM が ARP リクエストを送信しようとすると、Google の基盤システムがそれを検知し、ネットワーク全体には流さずに該当 IP アドレスの MAC アドレスを代理で即座に応答（ユニキャスト） します。
これにより、Google Cloud の VPC は大規模な環境であっても、不要な通信が発生せず、安定したパフォーマンスを維持できる仕組みになっています。
L3（ネットワーク層）の確認（サブネットとルーティング）
次に、IP（Internet Protocol／インターネットプロトコル） に関する L3（ネットワーク層）の設定（この実験では主に IP アドレスとサブネット）を変更した場合の挙動を確認します。
【実験内容】 サブネットの不一致による通信断
- PC-A の IP 設定は変更しません。
- PC-B の IP アドレス設定を変更し、意図的に別のサブネット（例：192.168.50.5/24）に設定します。
- 物理ケーブルは接続されたままの状態で、PC-A から PC-B へ Ping を実行します。
【観測結果】
結果は「Request Timed Out（要求がタイムアウトしました）」となり、通信できません。
物理的には同じルーター（ハブ）に接続されていても、論理的なネットワーク（サブネット）が異なると、PC は「相手は別のネットワークに存在している」と判断します。
通常、異なるネットワークへの通信はゲートウェイ（ルーター）へ転送されますが、今回のルーターは該当のネットワークへの経路情報（ルート）を持っていないため、通信は破棄されます。
Wiresharkの通信失敗
【考察】 Google Cloud の VPC との違い
Google Cloud の VPC には、物理環境とは異なる大きな特徴があります。
-
グローバル VPC
Google Cloud では、例えば東京リージョンのサブネット（10.1.0.0/24）と、アメリカのサブネット（10.2.0.0/24）のように、物理的な場所やサブネットが異なっていても、同じ VPC 内であれば標準で通信が可能です。
これは VPC がグローバルなリソースとして定義されており、リージョンを跨いだ経路情報（ルート）をシステムが自動的に学習・管理しているためです。 -
VPC ネットワークピアリング
一方で、VPC そのものが異なる場合（例：本番環境 VPC と開発環境 VPC）は、今回の実験と同様に通信できません。この場合、「VPC ネットワークピアリング」などの設定を行い、明示的に経路情報を交換することで通信が可能になります。
セキュリティの確認（ファイアウォール）
最後に、通信制御の要であるファイアウォールの挙動を確認します。
【実験内容】 OS ファイアウォールによる遮断
- PC-B の IP 設定を元に戻し、Ping が通る状態にします。
- PC-B の OS 設定（Windows Defender ファイアウォールなど）で、ICMP（Ping）の受信を拒否する設定にします。
- PC-A から Ping を実行します。
【観測結果】
結果は「Request Timed Out」になっています
データリンク層（L2）で MAC アドレスも解決し、ネットワーク層（L3）のルーティングも正しく、物理的にも接続されていますが、通信は成立しません。これは「データは届いているが、受け取りを拒否された」状態です。
Wiresharkの通信失敗
【考察】 Google Cloud の VPC との違い
オンプレミスの社内 LAN などでは、PC 個別のファイアウォール管理は最小限にし、ネットワークの出入り口（境界ルーター）でセキュリティを確保する構成も見られます。
対して、クラウドでは 「ゼロトラスト」 の考え方が基本です。
Google Cloud のファイアウォールは、ネットワークの境界だけでなく、各 VM インスタンスごとの仮想インターフェースに対して適用される「分散ファイアウォール」として実装されています。
VPC を作成した直後は、セキュリティの観点から「暗黙の拒否」ルールが適用されています。そのため、同じサブネット内の隣接した VM であっても、明示的に「許可」ルールを作成しない限り通信はできません。この厳格な制御により、高いセキュリティレベルが保たれています。
まとめ
今回の実験結果と Google Cloud の仕様比較をまとめます。
| 項目 | オンプレミス（実験環境） | Google Cloud VPC |
|---|---|---|
| L2・データリンク層（宛先解決） | 同一ネットワーク内へ無差別に届く送信（ARP ブロードキャスト） | SDN による代理応答（ブロードキャストの抑制） |
| L3・ネットワーク層（経路制御） | 物理的な配線とルーター設定に依存 | グローバル VPC（リージョンを跨ぎ自動で接続）。 ※経路には Cloud Router なども関係するが、本記事では Cloud Router の紹介は割愛する |
| ファイアウォール（通信の許可／拒否） | 境界防御が一般的 | 分散ファイアウォール（VM 単位のゼロトラスト） |
「VPC ネットワーク」というサービスは、Google の高度な技術（Andromeda SDN）によって、物理ネットワークにおける制約（ブロードキャストの負荷や、物理的な距離、煩雑なルーティング管理）をソフトウェア的に解決し、利用者に使いやすい形で提供されています。
しかし、その基盤にあるのは TCP/IP という標準的な技術です。
もしクラウド環境で「繋がらない」というトラブルに直面した際は、コンソールの設定画面だけでなく、今回の実験のように「パケットがどこまで届き、どこで止まっているのか」をネットワークの階層ごとにイメージしてみてください。解決への糸口がより早く見つかるはずです。
Google Cloud 上で経路や到達性を確認するときに便利なツールとして、Network Intelligence Center の Connectivity Tests（接続テスト） があります。次回はこちらをテーマに解説する予定です。事前に公式ドキュメントで全体像を把握したい場合は、下記を参照してください。
Discussion