クラウド環境への移行検討の際、「IP アドレス変更」による影響に頭を悩ませている方も多いのではないでしょうか。

IP アドレス変更によって、ミドルウェアが起動しなくなったり、業務アプリケーションの外部連携に支障がでたりと、直接的な対応もさることながら、一通りの動作検証を実施する費用や期間がビジネスのスピードとマッチしない、というお話を聞くことが多くあります。

技術的には「L2 延伸」という方式で「IP アドレス」を変更せずにネットワークの延伸が可能ですが、オンプレミス環境にそれなりの設備が必要となりますので、敷居としては少し高いかなと。

※ Google Cloud VMware Engine (GCVE) 等の VMware サービスを用いることで、HCX による L2 延伸構成が可能です。

そんな中、Google Cloud にてオンプレミス環境サブネットと クラウド環境サブネットを 1 つの論理サブネットに結合できる機能がリリースされたとのこと。

ずばり「ハイブリッド サブネット」という機能です。

まだプレビュー段階とのことですが、可能性を検証していきたいと思います。

今回は、オンプレミス環境のネットワーク延伸を検証するために、同一 IP アドレス体系のネットワークをクラウド環境(Google Cloud 環境)上にも準備します。
※ 下図では「192.168.64.0/24」のサブネットが該当します。

つまり、実現できれば両方の環境で「同じ IP アドレス体系を利用できる！」ということですね。

ネットワークを延伸するために、環境を準備します。

① オンプレミス環境とGoogle Cloud 環境を接続

オンプレミス環境と Google Cloud 環境を接続するため、公式ドキュメントを参考に Cloud VPN を準備します。

後程、動的ルーティング（BGP）を利用するため、VPN オプションは「高可用性（HA）VPN」を選択してください。

② オンプレミス環境 ルーターのプロキシ ARP を有効にする

今回はオンプレミス環境のエッジルータとして、YAMAHA 社製の VPN ルータ「RTX 1210」を利用しました。

LAN1 に接続しているサブネットを延伸したかったので、下記コマンドでプロキシ ARP を有効にします。

ip lan1 proxyarp on

save

以上でオンプレミス環境の作業は終了です。

以降は Google Cloud コンソールより操作を行います。

③ IAM ロールの確認

ハイブリッド サブネットの作成にあたっては、下記ロールの付与が必要となります。

ご利用される IAM に権限が不足している場合は、ナビゲーションメニューの「IAM と管理」から付与してください。

• Compute ネットワーク管理者（roles/compute.networkAdmin）

④ VPC サブネットを作成する
「VPC ネットワーク」から「サブネットの追加」を選択し、延伸したいサブネットを作成します。
!！重要 !！ ここでは、オンプレミス環境と同じ IP アドレス範囲 (192.168.64.0/24) を指定します。
※ IP アドレス範囲以外は標準設定で構いません。

⑤ ハイブリッド サブネット ルーティングを有効にする
サブネットを作成後、ハイブリッド サブネット ルーティングを有効にします。
※ Google Cloud コンソール内の「Cloud Shell」 から実行すると簡単です！

gcloud beta compute networks subnets update (拡張したいサブネット)\

--region=(リージョン)\

--allow-cidr-routes-overlap

⑥ ルート アドバタイズを構成する
Cloud VPN で作成した Cloud Router のアドバタイズ設定を変更します。
ナビゲーションメニューの「ネットワーク接続」から、アドバタイズ設定を以下のように変更します。

ポイントは４つ

• アドバタイズモード：デフォルト → カスタムルートの作成
• 「Cloud Router に表示されるすべてのサブネットにアドバタイズする」のチェックを外す。
• カスタム範囲に、オンプレミス環境と通信させたいサブネットを追加
• !！重要 !！ カスタム範囲に、オンプレミス環境とネットワーク延伸させたいサーバを個別に追加

(ネットワークマスクは「/32」)

※今回は疎通確認として「検証用インスタンス」を作成しますので、あらかじめ使用予定のIP アドレス　(192.168.64.101/32) を追加します。

設定変更前：

↓
設定変更後：

以上で設定は終了です。

それでは、疎通確認してみましょう！

オンプレミス環境とGoogle Cloud環境にて疎通確認用の Windows インスタンスを作成して、ネットワーク疎通の確認を行います。
また、事前にファイヤウォールにて必要な通信も許可しておきます。

＜ 検証用インスタンスのおもな設定＞

• オンプレミス環境：

• Google Cloud 環境：

さっそく、オンプレミス環境から Ping ！

繋がった！！！！！
Google Cloud  環境からも Ping！

さっくりと繋がりました。
もちろん、リモートデスクトップも接続できました。

でも、インターネットをまたいでいるのに、同じサブネットとしてお互い疎通ができるって、いったいどうなってるんでしょう？？

実は、ARP というプロトコルの仕様と、前述の設定変更がカギとなっています。

• ②オンプレミス環境 ルーターのプロキシ ARP を有効にする
• ⑤ハイブリッド サブネット ルーティングを有効にする

ARP (Address Resolution Protocol）自体の詳細についてはここでは割愛しますが、大事な要素を大雑把にまとめると以下４点になります。

• ARP は IPアドレスからMAC アドレスを取得するプロトコル。
• IP アドレスの通信は、実は、MAC アドレスを宛先として通信を行っている。
• ARP で MAC アドレスが取得できない場合は、IP アドレスでネットワーク通信ができない。
• ARP は、OSI 参照モデルにて「データリンク層(Layer 2)」と「ネットワーク層(Layer 3)」を橋渡しするプロトコルであり、別のサブネットと直接疎通はできない。

オンプレミス環境：
「プロキシ ARP」設定により、オンプレミス環境で下記の条件を満たした場合は、クライアントからのARP 要求に対して、自身(「プロキシ ARP」が有効になっているオンプレミス環境 ルータのインターフェース)の MAC アドレス(HWaddress)を代理で応答( ARP 応答）するようになります。

• プロキシ ARP を有効にしている。
• 通信先 IP アドレスのルートを知っていること← Cloud Router より受領(BGP経由)。

下図は オンプレミス環境検証サーバのARPテーブルです。

Google Cloud 環境の検証サーバ(192.168.64.101/24)のMACアドレスと、オンプレミス環境ルータ(192.168.64.254/24)の MAC アドレスが同一であることが確認できます。

そのため、Google Cloud 環境の検証サーバ向けのIPアドレス通信は、オンプレミス環境ルータへ向かい、BGPで受信したルーティングを経由してGoogle Cloud 環境の検証サーバへ到達すると考えられます。

Google Cloud 環境：
サブネットに対して「allowSubnetCidrRoutesOverlap」フラグを有効にすることで、サブネット内の IP アドレス宛てのパケット が仮想ネットワーク(VPC）から外部に出ることができるようになります。

下図は Google Cloud 環境検証サーバのARPテーブルです。

※ Google Cloud 環境のデフォルトルータは「192.168.64.1/24」となります。

内部構造まではわかりませんが、こちらもデフォルトルータにてオンプレミス環境へルーティングしてくれているようですね。

(ここら辺はまだお勉強が必要です >_<)

ということで、まったく別のサブネットにある MAC アドレスを代理／橋渡しにて解決し、あたかも同じサブネットの通信として IP アドレスでの通信ができているんですね。

では、ハイブリッド サブネット構成での移行を検討してみます。

ユースケースとして、データセンタ上のWebサーバをIPを変えずに移行するケースを考えてみます。

これまでの検証より、上図の「WEBサーバ」をオンプレミス環境からGoogle Cloud 環境に移行しても、これまでと同様に同じIPアドレスを利用して接続することができます。

しかしながら、ネットワーク経路としてはデータセンタを必ず中継するため、下記の点について懸念が想定されます。

• 通信が迂回するため、ネットワークスループットはあまり期待できない。
• データセンタが単一障害点(SPOF：Single Point of Failure)となってしまう。

その場合は、上図「Webサーバ」のIPアドレスを変更し、オフィス環境と直接接続(上図のオレンジ線）するような構成を検討されることとなるかと思います。

つまり、「ネットワーク延伸」の解除ですね。
上記から、ネットワーク延伸は「クラウド環境への移行に際し、IPアドレス変更の影響を緩和することで移行ハードルを下げ、段階的に環境の移行を進めていく一時的な構成」として利用できるのではないでしょうか。

いかがでしたでしょうか。
今回の検証では、IPアドレス体系を変えずクラウド環境にネットワークを延伸できることが確認できました。

まとめると、

• IP アドレスを変えずにクラウドへ移行できるのは便利！
• とはいえ、延伸先の対象を１台づつ手動で設定するのはちょっと手間。。。
• 環境面でいくつか制約あり

延伸されたGoogle Cloud側 サブネット内のVM インスタンス最大数は 130台まで

レイヤ 3 Partner Interconnect 接続では利用できない

オンプレミス環境とのブロードキャスト通信／マルチキャスト通信は利用できない

• 当面の移行ハードルは低減できるが、いずれはネットワーク延伸解除について検討も併せて考慮したい。

現時点では、運用面での負荷も考慮すると大規模な環境や継続的な運用には向かないかもしれませんが、今後の発展に期待しています。

最後まで読んでいただき、ありがとうございました！

当社システムサポートは、Google Cloudの導入・移行・運営支援を行っています。
クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします！