この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第36回です。
第4章では、クラウド上の仮想ネットワーク、サブネット、ルートテーブル、 NAT Gatewayなどを学んできました。 今回は、社内やデータセンターにあるオンプレミスネットワークとクラウドを接続する方法を学びます。
NETWORK ADVANCED｜CHAPTER 4 CLOUD NETWORK
オンプレミスとクラウドをVPNで接続する｜ハイブリッドクラウドVPNの設計
社内ネットワークからクラウド上のサーバーへ安全に通信したい場合、 インターネット上にSite-to-Site VPNを構成する方法があります。 しかし、VPNトンネルが確立すれば設計完了ではありません。 IPアドレス、ルーティング、冗長化、MTU、セキュリティ、監視まで含めて考える必要があります。
「オンプレミスとクラウドをVPNでつなぐ」という要件だけを見ると、 VPN装置とクラウド側ゲートウェイを用意すればよいように見えます。
実際の設計では、 「どのネットワーク同士を通信させるのか」 「どの経路を優先するのか」 「トンネル障害時にどう切り替えるのか」 まで決めなければなりません。
この記事を読み終えるとできること
- オンプレミスとクラウドをVPNで接続する仕組みを説明できる
- Site-to-Site VPNとリモートアクセスVPNを区別できる
- ハイブリッドVPNに必要な構成要素を整理できる
- スタティックルートとBGPを比較できる
- IPアドレス重複が問題になる理由を説明できる
- VPNの冗長化構成を検討できる
- MTU・MSSを確認する理由を説明できる
- VPNと専用線を要件に応じて比較できる
オンプレミスとクラウドをVPNで接続するとは
オンプレミスとクラウドのVPN接続とは、 インターネットなどのネットワーク上に暗号化されたトンネルを作り、 社内ネットワークとクラウドネットワークを相互接続する構成です。
企業では、すべてのシステムを一度にクラウドへ移行するとは限りません。
たとえば、次のような構成があります。
- 認証サーバーはオンプレミスに残す
- Webサーバーだけクラウドへ移行する
- バックアップ環境をクラウドへ配置する
- クラウド上の業務システムを社内PCから利用する
- オンプレミスのデータベースとクラウドアプリケーションを連携する
このようにオンプレミスとクラウドを組み合わせる環境を、 一般にハイブリッドクラウドと呼びます。
Site-to-Site VPNを利用する
オンプレミスのネットワーク全体とクラウドネットワークを接続する場合は、 拠点間を接続するSite-to-Site VPNを利用します。
中級編で学んだ IPsec VPNの基本動作 や、上級編の VPN設計 が前提知識になります。
リモートアクセスVPNとは目的が違います。
リモートアクセスVPNは主に利用者のPCなどをネットワークへ接続します。 Site-to-Site VPNは、ネットワークとネットワークを接続するために使います。
基本構成を1枚の図で理解する
オンプレミス－クラウド間VPNの基本構成
オンプレミス ⇄ クラウド間の通信を暗号化
オンプレミス側では、ルーターやファイアウォールなどがVPNを終端します。 クラウド側では、クラウドサービス側のVPNゲートウェイがVPNを終端します。
その間にあるインターネットを通過するパケットは、 VPNによって暗号化されます。
VPNは「安全な専用道路を作る」のではなく、公共の道路を通る荷物を暗号化して運ぶイメージです。
インターネット自体を専用化するわけではない点が、 後で学ぶ専用線接続との大きな違いです。
VPN接続に必要な構成要素
オンプレミスネットワーク
社内LANやデータセンターなど、 クラウドと通信させるネットワークです。
VPN装置
ルーターやファイアウォールなど、 オンプレミス側でVPNを終端する装置です。
インターネット回線
VPNトンネルを通す物理的な通信経路です。 回線品質もVPN通信へ影響します。
クラウドVPN Gateway
クラウド側でVPNトンネルを終端し、 仮想ネットワークへ通信を中継します。
ルートテーブル
オンプレミス宛て・クラウド宛て通信を VPNへ転送する経路情報です。
通信制御
ファイアウォールやクラウド側セキュリティ機能で、 許可する通信を制御します。
VPNトンネルがUPしていることと、業務通信ができることは別です。
VPNが確立していても、ルートテーブルやファイアウォール設定が不足していれば通信できません。
オンプレミスからクラウドへ通信する流れ
次の構成を例にします。
- オンプレミス：10.10.0.0/16
- クラウド：10.20.0.0/16
- クラウドサーバー：10.20.1.10
- PCがクラウドサーバーへパケットを送る オンプレミスのPCから10.20.1.10宛ての通信を開始します。
- オンプレミスルーターが経路を確認する 10.20.0.0/16への経路としてVPN側を選択します。
- VPN装置がパケットを暗号化する 元のIPパケットをIPsecで保護し、インターネットへ送信します。
- クラウド側VPN Gatewayが復号する VPNトンネルを通過したパケットを復号します。
- クラウドのルートテーブルを確認する 宛先サブネットへパケットを転送します。
- セキュリティ設定を確認する ファイアウォール等で通信が許可されていれば、サーバーへ到達します。
- 戻り通信もVPNへ返す クラウド側には10.10.0.0/16宛ての戻り経路が必要です。
VPN通信では「往路」だけでなく「復路」を必ず確認します。
行きのルートだけ設定されていても、 クラウドからオンプレミスへの戻り経路がなければ通信は成立しません。
ハイブリッドVPNではルーティング設計が重要
VPN接続で障害になりやすいポイントの一つがルーティングです。
最低限、次の2方向の経路が必要です。
オンプレミス → クラウド
クラウドネットワーク宛ての通信をVPNトンネルへ転送します。
例：10.20.0.0/16 → VPN
クラウド → オンプレミス
オンプレミスネットワーク宛ての通信をVPN Gatewayへ転送します。
例：10.10.0.0/16 → VPN Gateway
スタティックルートとBGP
| 項目 | スタティックルート | BGP |
|---|---|---|
| 経路登録 | 管理者が手動で設定 | ルーター間で経路を交換 |
| 構成 | 比較的シンプル | BGPの設計が必要 |
| 経路数が少ない環境 | 使いやすい | やや複雑になる場合がある |
| ネットワーク追加 | 設定追加が必要 | 経路広告により反映しやすい |
| 冗長化 | 経路切り替え設計が必要 | 経路状態と連動させやすい |
| 向いている環境 | 小規模・固定的な構成 | 複数経路・将来拡張・冗長構成 |
BGPについては、 BGPの基本 と BGPの経路選択 もあわせて確認してください。
「BGPの方が高度だからBGPを使う」という判断は適切ではありません。
経路数、冗長化、将来拡張、運用スキルなどをもとに方式を選びます。
オンプレミスとクラウドのIPアドレス重複を避ける
ハイブリッドクラウド設計では、 VPNを作る前に必ずIPアドレス体系を確認します。
正常な例
オンプレミス
10.10.0.0/16
クラウド
10.20.0.0/16
アドレス空間が重複していないため、 宛先ネットワークをルーティングで明確に区別できます。
問題になる例
オンプレミス
10.0.0.0/16
クラウド
10.0.0.0/16
両方に同じネットワークが存在すると、 「10.0.1.10はオンプレミスなのかクラウドなのか」を 通常のルーティングだけでは区別できません。
クラウドを作ってからIPアドレス重複に気付くと、修正コストが大きくなります。
クラウドネットワークを新規設計する段階で、 オンプレミスや他クラウド、将来接続する可能性のあるネットワークまで確認してください。
IPアドレス設計については IPアドレス設計 も確認してください。
VPNを冗長化する
業務システムでクラウドを利用する場合、 VPNトンネル1本だけでは単一障害点が残る可能性があります。
VPN冗長化の考え方
冗長化で確認する範囲
VPNトンネル
1本が停止しても別トンネルへ切り替えられるか確認します。
VPN装置
オンプレミス側装置自体が単一障害点になっていないか確認します。
インターネット回線
トンネルを2本作っても同じ1本の物理回線を使っていれば、 回線障害には耐えられません。
ルーティング
障害時にバックアップ経路へ正しく切り替わるか確認します。
監視
トンネルが片系停止した状態を検知できるようにします。
試験
本番前に意図的に障害を発生させ、切り替え動作を確認します。
冗長化では「トンネルの本数」ではなく、障害点を確認します。
VPNトンネルが2本でも、その2本が同じルーター・同じ回線を利用していれば、 そのルーターや回線は単一障害点として残ります。
冗長構成を考える際は、 冗長化設計 も参考にしてください。
VPNだけでセキュリティ設計は完了しない
VPNによって通信経路を暗号化しても、 オンプレミスとクラウド間ですべての通信を許可してよいわけではありません。
通信許可を最小限にする
たとえば、オンプレミスの利用者PCからクラウド上のWebサーバーへ HTTPS通信だけが必要であれば、 必要な送信元・宛先・プロトコル・ポートを明確にします。
| 項目 | 設定例 |
|---|---|
| 送信元 | 10.10.10.0/24 |
| 宛先 | 10.20.10.10 |
| プロトコル | TCP |
| ポート | 443 |
| 方向 | オンプレミス → クラウド |
VPN設計で確認するセキュリティ項目
- 使用するVPN・暗号化方式
- 認証方式
- 共有鍵や証明書の管理方法
- 鍵を変更する運用方法
- 許可する送信元・宛先
- 許可するプロトコル・ポート
- 管理アクセス経路
- VPN接続ログの保存
- 設定変更履歴の管理
「VPNなので安全」という説明だけでは不十分です。
暗号化とアクセス制御は別の役割です。 VPNで経路を保護し、そのうえで必要な通信だけを許可します。
VPNではMTU・MSSも確認する
IPsec VPNでは、元のパケットへVPN用の情報が追加されます。 そのため、VPNを利用しない通信と比べて、 実際に運べるデータサイズが小さくなることがあります。
この点を考慮せずに設計すると、 次のような現象が発生することがあります。
- pingは通るのにWebサイトが正常に開かない
- 小さなパケットは通るが大きな通信で止まる
- ファイル転送だけ異常に遅い
- 特定のアプリケーションだけタイムアウトする
VPN障害で「経路もFWも正しいのに一部通信だけ失敗する」場合、MTUも確認候補になります。
設計時に確認すること
- 物理インターフェースのMTU
- VPNによるオーバーヘッド
- 経路上でフラグメントが発生しないか
- Path MTU Discoveryが正常に機能するか
- 必要に応じたTCP MSS調整
MTUはVPN製品やクラウドサービス、暗号化方式、 通信経路によって条件が変わるため、 実際に利用するサービスの仕様を確認して設計します。
インターネットVPNと専用線接続を比較する
オンプレミスとクラウドを接続する方法はVPNだけではありません。
要件によっては、次の記事で学ぶ専用線接続が適している場合があります。
| 比較項目 | インターネットVPN | 専用線接続 |
|---|---|---|
| 通信経路 | インターネットを利用 | 専用・閉域系の接続サービスを利用 |
| 導入のしやすさ | 比較的導入しやすい | 回線・事業者との調整が必要 |
| コスト | 比較的抑えやすい | 高くなる傾向 |
| 通信品質 | インターネット品質の影響を受ける | より安定した設計を行いやすい |
| 大容量通信 | 要件によって制約になりやすい | 大容量用途を検討しやすい |
| 主な用途 | 小～中規模、検証、バックアップ等 | 重要システム、大容量、安定性重視等 |
VPNか専用線かは「どちらが優れているか」ではなく、要件に合っているかで判断します。
通信量、遅延、可用性、予算、導入期間、運用体制を整理して方式を選択します。
ハイブリッドVPN設計で確認する項目
要件定義から設計へ進む際は、 最低でも次の項目を整理します。
1．接続対象
- オンプレミス側の対象ネットワーク
- クラウド側の対象ネットワーク
- 対象システム
- 通信方向
2．IPアドレス
- オンプレミスCIDR
- クラウドCIDR
- IPアドレス重複の有無
- 将来追加するネットワーク
3．VPN
- VPN終端装置
- 接続先IPアドレス
- 認証方式
- 暗号化方式
- トンネル数
- 鍵更新方法
4．ルーティング
- スタティック／BGP
- 広告する経路
- 受信する経路
- デフォルトルートの扱い
- 経路優先順位
- 障害時の切り替え
5．可用性
- VPNトンネル冗長化
- VPN装置冗長化
- インターネット回線冗長化
- 切り替え時間
- 片系障害時の監視
6．通信制御
- 送信元
- 宛先
- プロトコル
- ポート番号
- オンプレミスFW
- クラウド側セキュリティ制御
7．性能
- 平均通信量
- ピーク通信量
- 必要帯域
- 許容遅延
- MTU・MSS
- 将来の通信量増加
8．運用・監視
- VPNトンネル状態
- BGP状態
- 通信量
- パケットロス
- ログ保存
- 障害通知
第1回の ネットワーク要件定義 で整理した「可用性・性能・セキュリティ・運用」の条件が、 ここで具体的なVPN設計へつながります。
ハイブリッドVPNでよくある設計ミス
IPアドレスが重複している
オンプレミスとクラウドで同じアドレス範囲を利用しており、 正しく経路制御できません。
戻り経路がない
オンプレミスからクラウドへの経路だけ設定し、 クラウド側にオンプレミス宛て経路がありません。
FW通信許可が不足
VPNはUPしていますが、 必要な業務通信がファイアウォールで拒否されています。
VPNだけ二重化する
トンネルは2本ありますが、 オンプレミスのVPN装置や回線が1つしかありません。
MTUを考慮していない
小さい通信は成功するのに、 大きなパケットを使う通信だけ失敗します。
監視していない
冗長VPNの片系が停止していても気付かず、 次の障害で全面停止します。
特に危険なのは「VPNがUPだから正常」と判断することです。
VPN、ルーティング、通信制御、DNS、サーバー側設定まで含めて End-to-Endで通信確認する必要があります。
顧客・上司へVPN構成をどう説明するか
技術者同士であれば、 IPsec、IKE、BGP、SAといった言葉を使って説明できます。
一方、顧客へ説明する場合は、 技術そのものではなく目的・メリット・制約に変換します。
技術中心の説明
「オンプレミスのファイアウォールとクラウドVPN Gateway間で IPsec Site-to-Site VPNを構成します。」
間違いではありませんが、 非エンジニアには「それによって何ができるのか」が分かりません。
顧客向けの説明
「現在の社内ネットワークとクラウドを暗号化した通信経路で接続します。 これにより、利用者はクラウド上の業務システムを 社内ネットワーク上のシステムと同じように利用できます。」
「一方で通信経路にはインターネットを利用するため、 大容量通信やより安定した通信品質が必要な場合は、 専用線方式との比較が必要です。」
設計レビューでの説明例
冗長化構成を採用した理由も要件へ結びつけます。
「クラウド上に主要業務システムを配置するため、 単一VPN障害で業務停止しないことが可用性要件となっています。 そのため、VPN経路を冗長化し、 片系障害時にバックアップ経路へ切り替えられる構成としています。」
「一般的に冗長化した方がよいから」ではなく、 要件 → 設計判断の順番で説明することが重要です。
ハイブリッドVPNで使う英語表現
海外ベンダーやクラウドの公式ドキュメントを読む際は、 次の表現を覚えておくと便利です。
| 英語 | 意味 | 実務での使われ方 |
|---|---|---|
| Site-to-Site VPN | 拠点間VPN | オンプレミスとクラウドなど、ネットワーク同士を接続するVPN |
| Customer Gateway | 顧客側ゲートウェイ | オンプレミス側VPN装置を表す文脈で使われる |
| VPN Gateway | VPNゲートウェイ | VPNを終端するゲートウェイ |
| Pre-Shared Key | 事前共有鍵 | VPNピア間の認証に使用する共有秘密情報 |
| Tunnel | トンネル | VPNによって作られる論理的な通信経路 |
| Route Propagation | 経路伝播 | 経路情報をルートテーブルへ反映する文脈で使用 |
| Static Routing | スタティックルーティング | 経路を手動で登録する方式 |
| Dynamic Routing | 動的ルーティング | BGPなどを利用して経路を交換する方式 |
| Redundant Tunnel | 冗長トンネル | 障害対策として複数トンネルを構成する場合 |
| Overlapping CIDR | 重複するCIDR | オンプレミスとクラウドのアドレス重複を調査するときに使用 |
ベンダー問い合わせで使える表現
The VPN tunnel is up, but traffic cannot reach the cloud network.
VPNトンネルはUPしていますが、クラウドネットワークへ通信できません。
Could you confirm whether the route to 10.10.0.0/16 is being advertised?
10.10.0.0/16への経路が広告されているか確認していただけますか。
Only one of the redundant VPN tunnels is currently active.
現在、冗長VPNトンネルのうち1本だけが稼働しています。
理解度チェック
記事の内容を確認するため、次の5問に答えてください。
問題1．Site-to-Site VPNの主な目的として適切なものはどれですか。
- 1台のPCだけをクラウドへ接続する
- ネットワークとネットワークを接続する
- クラウドサーバーへパブリックIPを付与する
- DNS名をIPアドレスへ変換する
解答を見る
Site-to-Site VPNは、オンプレミスLANとクラウドネットワークのように、 ネットワーク同士を接続する用途で利用します。
問題2．オンプレミスが10.0.0.0/16、 クラウドも10.0.0.0/16を利用しています。 最も大きな設計上の問題は何ですか。
解答を見る
同じ宛先ネットワークが両側に存在するため、 通常のルーティングでは通信先を正しく区別できません。
問題3．VPNトンネルがUPしていますが、 オンプレミスからクラウドサーバーへ通信できません。 確認すべき項目を3つ挙げてください。
解答を見る
例：
- オンプレミス側ルーティング
- クラウド側ルーティング
- オンプレミス側ファイアウォール
- クラウド側通信制御
- 戻り経路
- サーバー側ファイアウォール
問題4．VPNトンネルを2本構成しました。 これだけで完全な冗長化と言えない理由を説明してください。
解答を見る
2本のトンネルが同じVPN装置や同じインターネット回線を利用している場合、 装置や回線が単一障害点として残るためです。
問題5．高帯域・安定した通信品質が重要なクラウド接続で、 VPN以外に比較すべき方式は何ですか。
解答を見る
性能、可用性、コスト、導入期間などを比較して方式を選択します。
実践演習：オンプレミス－クラウドVPNを設計する
あなたは、顧客企業のクラウド移行案件でネットワーク設計を担当しています。
顧客要件
- オンプレミス：10.10.0.0/16
- クラウド：10.20.0.0/16
- クラウド上に新しい業務システムを構築する
- 社内PCからクラウド業務システムへ接続する
- 通信は暗号化する
- VPN障害1回で業務停止しないこと
- 今後クラウド側ネットワークが増える予定
- インターネット回線は現在1回線
課題1．基本構成を考える
必要になる主な構成要素を挙げてください。
解答例を見る
オンプレミスLAN → VPNルーター／ファイアウォール → インターネット → クラウドVPN Gateway → クラウドネットワーク
課題2．ルーティング方式を考える
将来クラウド側ネットワークが増える予定です。 スタティックルーティングとBGPのどちらを候補とするか、 理由とともに考えてください。
解答例を見る
候補：BGP
今後ネットワークが増える予定があり、 冗長経路も考慮するため、 動的に経路を交換できるBGPを候補とします。
ただし、実際には運用チームのBGPスキルやクラウドサービスの仕様も確認して最終判断します。
課題3．可用性の問題を見つける
VPNトンネルを2本作る予定ですが、 インターネット回線は1回線しかありません。 どのようなリスクがありますか。
解答例を見る
インターネット回線自体が障害になると、 2本のVPNトンネルが同時に利用できなくなる可能性があります。
「VPN障害1回で業務停止しない」という要件を満たすためには、 VPNトンネルだけでなく、VPN装置やインターネット回線を含めた End-to-Endの冗長化を検討する必要があります。
課題4．試験項目を考える
本番導入前に実施したい試験を5つ以上挙げてください。
解答例を見る
- VPNトンネル確立確認
- オンプレミスからクラウドへの疎通確認
- クラウドからオンプレミスへの疎通確認
- 業務ポートを使用した通信確認
- 不要通信が拒否されることの確認
- VPN片系停止時の切り替え確認
- VPN復旧時の動作確認
- BGP経路切り替え確認
- 大きなパケットを使用した通信確認
- 監視・障害通知確認
自分の言葉で説明する課題
顧客から次の質問を受けました。
「オンプレミスとクラウドをVPNで接続するとは、 具体的にどういうことですか？」
技術に詳しくない人へ30～60秒程度で説明してください。
説明例を見る
オンプレミスとクラウドのVPN接続とは、 会社のネットワークとクラウドのネットワークを インターネット経由で安全につなぐ仕組みです。
通信内容はVPNによって暗号化されるため、 社内からクラウド上の業務システムへ プライベートなネットワーク同士を接続するような形で通信できます。
実際の設計では、VPNだけでなく、 IPアドレス、ルーティング、通信制御、冗長化、監視まで含めて設計します。
まとめ
- オンプレミスとクラウドはSite-to-Site VPNを利用して接続できる
- VPNではインターネット上に暗号化された通信経路を作る
- VPNトンネルがUPしていても、ルーティングやFW設定が不足すれば通信できない
- オンプレミスとクラウドのIPアドレス範囲は重複させないことが基本
- 小規模・固定的な経路ではスタティック、拡張性や冗長化を考慮する場合はBGPも候補になる
- VPN冗長化ではトンネルだけでなく、装置・回線・ルーティングまで確認する
- IPsecのオーバーヘッドを考慮し、MTU・MSSも確認する
- VPNによる暗号化とファイアウォールによる通信制御は別に設計する
- 高帯域・安定した通信品質が重要な場合は専用線接続との比較が必要
ハイブリッドクラウドVPN設計で重要なのは、 「VPNを張ること」ではなく、 オンプレミスからクラウドまでEnd-to-Endで安定して業務通信できる構成を作ることです。
コメント