VPNだけじゃない — さくらのクラウドVPNルータで作る境界ネットワーク

はじめに

クラウド環境では、「どこまで公開するか」「どこで通信を止めるか」というネットワーク設計により、障害時の影響範囲やセキュリティリスクが大きく変わります。可用性と信頼性を確保するため、役割に応じてネットワーク領域を分割して、適切にアクセス権を割り当てる必要があります。

本記事では、さくらのクラウドが提供するVPNルータを題材に、VPN接続だけにとどまらない「境界ネットワーク」の設計を解説します。想定している読者は、ネットワークの知識があるエンジニアです。TCP/IP・ルーティング・ファイアウォールなどについて、ある程度理解している人を想定しています。

名前からVPN専用のサービスに見えるかもしれませんが、本記事で扱うVPNルータは、VPN接続を提供する装置というよりも、NAT・ファイアウォール・ルーティングを集約した「境界装置」として理解する方が実態に近いサービスです。ここではコントロールパネル上の詳細な設定手順は扱わず、設計の考え方と構成例を中心に進めます。読了後には、VPNルータのマニュアルから具体的な構築に着手できる状態を目指します。

通信の入口と経路をまとめて扱えるVPNルータ

さくらのクラウドのVPNルータは、クラウド上にVPN（Virtual Private Network）環境を構築できる仮想ルータアプライアンスです。

VPNルータが提供するのは、VPN接続だけではありません。ざっくり言うと、次のような機能を1台に集約したネットワークの入口です。普段使っているネットワーク機器で例えると、UTM（ネットワークセキュリティアプライアンス）に近い役割をクラウド上で担うイメージです。

NAT — プライベート側からインターネットへの外向き通信や、特定ポートの転送など
ファイアウォール — インターフェースごとの受信・送信フィルタ
リモートアクセスVPN — L2TP/IPsecやWireGuardなど、端末からの接続
サイト間VPN — IPsecによる拠点間接続
L3ルーティング(Static Route) — 複数セグメント間の経路制御

いわゆるネットワークの境界装置として、通信の入口と経路をまとめて扱えるのが特徴です。お客様が独自にVPN用ルータを構築・維持する専門知識は不要で、コントロールパネル（GUI）からアプライアンスの作成から設定まで行えます。

さくらのクラウドでは、VPNルータとスイッチ（必要に応じてルータ＋スイッチ）を組み合わせてセグメントを分ける構成を取りやすい点も特徴です。構造を意識しながらネットワークを設計できます。どこが入口で、どのスイッチ配下にどの役割のサーバがあるかが構成から読み取れるため、チーム内で設計を共有しやすくなります。

なお2025年9月18日より、旧称「VPCルータ」から改称されました。名称のみの変更で、機能・仕様・APIに変更はありません（詳細は名称変更のお知らせを参照）。

ネットワーク図を描くように直感的に使えるVPNルータ

では、VPNルータの特長である構造でネットワークを組み立てできる点を説明します。

クラウドのネットワークを設計するとき、大きく2つの考え方があります。本記事では、説明の便宜上、前者をSDN型（ルール定義型）、後者をVPNルータ型と呼びます。

型	考え方
SDN型（ルール定義型）	仮想ネットワーク、サブネット、ルート、ゲートウェイ、セキュリティポリシーなどの論理部品をルールで組み合わせ、通信の挙動を定義する
VPNルータ型	VPNルータとスイッチで構造（形）を作り、境界とセグメントを組み立てる

SDN型でつまずきやすい点

SDNとは、Software Defined Networkingの略で、ネットワーク仮想化とも呼ばれます。仮想ネットワーク、サブネット、ルート、ゲートウェイ、セキュリティポリシーなどの論理部品をルールで組み合わせ、通信の挙動を定義します。AWSのVPC、AzureのVNetなどが、これに当たります。

SDN型は柔軟で強力ですが、抽象度が高い分だけ、慣れないと設定ポイントが分散しやすい側面があります。たとえば、設定がルートテーブル、ゲートウェイ、Security Group、NACLなど複数の論理要素に分散しているため、「出口がない」「途中で遮断される」「戻り道がない」といったミスで通信の停止が発生します。

VPNルータ型が直感的な理由

VPNルータ型は、VPNルータとスイッチを組み合わせて、境界とセグメントを構成します。入口・内部・制御点が構造として見えるのが特徴です。

さくらのクラウドのネットワークでは、サブネットを論理的に定義するのではなく、スイッチに接続することでセグメントを構成します。VPNルータを境界に置き、スイッチごとに「ここがDMZ」「ここが内部」と役割を分けていくのです。

オンプレミスでトポロジー図を描く感覚に近く、VPNルータとスイッチを順に接続しながら構成できます。チーム内で「どこが公開系で、どこが内部資産か」を図で共有しやすい点も、設計の入口として有用です。

構成例1：Web — DMZ / internal / mgmt によるセグメント分離

では、VPNルータによるネットワーク構成の例を紹介します。

Webシステムをクラウド上で運用する場合、信頼境界ごとにネットワークを分ける構成がよくあります。ここでは、DMZ / internal / mgmtの3区分を軸に、設計の考え方を整理します。

セグメント	種類	置くもの
DMZ	外部セグメント	Webサーバ、外部向けAPI
internal	内部セグメント	DB、バックアップ（NFS等）、内部向けAPI
mgmt	管理用セグメント	管理用入口（リモートアクセス）

このネットワーク構成では、VPNルータを境界装置として配置して、そこに外部用・内部用のスイッチを接続します。そして、公開系のWebサーバやAPIはDMZ側のスイッチへ、DBやバックアップなど内部資産はinternal側のスイッチへ接続します。これにより、ネットワークの基本構成が完成します。

internalには、アプリケーション系（内部向けAPI）とデータ系（DB、バックアップ）が同居します。アプリの三層構造とネットワーク区分が1対1で対応するわけではないので注意してください。

スイッチとインターフェースの接続方法など、具体的な構築手順はインターフェース設定を参照してください。

DMZの考え方

DMZ（DeMilitarized Zone、非武装地帯）とは、インターネット側と内部ネットワークのあいだに置く公開用の領域です。Webサーバや外部向けAPIなど、外部からアクセスが必要なシステムを置き、DBや管理系は置きません。

DMZの目的は、侵入そのものを防ぐことではなく、侵害時の影響範囲を限定することです。そのため、WebやAPIをインターネットへ直接公開せず、公開入口を1か所に集約します。

公開入口を一本化する

では、具体的にどのようにして公開する入口を一本化するのでしょうか。

これには、次のように2つの方法があります。

NATで入口を限定する — VPNルータのNAT機能で、グローバル側からの通信を特定のサーバ・ポートに転送します。入口そのものをVPNルータに集約し、必要な通信だけ内部へ届ける方式です。
ロードバランサの背後に置く — エンハンスドロードバランサ（L7 ELB）を追加し、HTTP/HTTPSの入口を集約し、裏側のWebサーバは非公開にします。一般ユーザーからの流れは、インターネット → ELB → Webサーバ（DMZ）です（図の緑色の線）。外部から直接触れるのはELBだけ、というイメージです。

ロードバランサの背後に置く方式の例では、公開HTTP/HTTPSの入口をELBが担い、VPNルータのNATやファイアウォールをセグメント間の制御などに組み合わせて使う、という分担になっています。

さらに、DMZからinternalへの通信をファイアウォールで絞ります。たとえば、外部向けAPIからDBへの通信のみを許可し、DBへの直接アクセスは拒否する、という具合です。先ほどの図の場合、Webサーバからデータベースにはスイッチ(外部用) → VPNルータ → スイッチ(内部用) → データベースという経路でアクセスします。

このようにAny to Any（送信元・宛先を問わず許可）のルールは設けない、つまり必要な通信だけを明示的に許可し、通信経路を固定化しておくと、後から例外が増えにくくなります。

なお、実際のVPNルータの設定では、プライベート側インターフェースが、次のように受信方向と送信方向の定義がグローバル側と逆に見えるので注意してください。

受信：スイッチ側から入る通信
送信：スイッチ側へ出る通信

詳細はファイアウォール設定の設定例を参照してください。

そして、管理用セグメントへのアクセスのために、SSHなどの管理ポートをインターネットへ直接公開するのは避けます。WireGuardなどのリモートアクセスVPNでinternalへ入り、管理系を閉域で運用する構成が推奨されます（WireGuardサーバ機能）。

構成例2：ハイブリッド — オンプレとクラウドをサイト間VPNで接続

続いて、オンプレミス環境とさくらのクラウドを接続する構成例について説明します。移行期の並行運用や、既存環境を活かしたクラウド拡張で使われます。

VPNルータのサイト間VPN（site-to-site IPsec VPN）を使い、オンプレミス側のIPsec対応アプライアンスと暗号化トンネルで接続します。IPsecに対応した機器であれば接続可能です。動作確認済みの機器一覧や仕様はサイト間VPN設定を参照してください。

なお、サイト間VPNでトンネルが張れたからといって、通信をすべて許可する必要はありません。先ほどのDMZ→internalと同様、到達範囲は必要最小限にしましょう。

サイト間VPN アプライアンス側設定例では、クラウド側のVPNルータと対向拠点のアプライアンスをIPsecトンネルで結ぶ構成例を解説しています。

「VPNだから安全」ではない

サイト間VPNやリモートアクセスVPNで接続できたとき、「安全性を確保できた」と考えがちです。しかし、VPNは通信経路を暗号化する仕組みであり、接続先のすべてを自動的に保護するわけではありません。

VPNで繋がった安心感から通信を全開放してしまうと、オンプレミス側で起きた事故や侵害の影響が、クラウド側へそのまま波及する可能性があります。

安全な境界ネットワークを組むうえで、次の原則を押さえておきましょう。

セグメントを分ける — DMZ / internal / mgmt のように、役割ごとにネットワークを分離する。拠点間接続でも、必要に応じて到達範囲を分ける
境界で制御する — VPNルータのNATやファイアウォールで、入口とセグメント間の通信を制御する
最小権限で許可する — 必要な通信だけを明示的に許可し、Any to Anyは作らない

「VPNルータを置いた」「VPNでつながった」こと自体が設計の完成ではありません。どこまで到達させるかを決めることが、境界ネットワーク設計の本質です。先ほど紹介した二つの構成例も、同じ考え方で設計しています。

まとめ

本記事では、さくらのクラウドのVPNルータを題材に、境界ネットワークの設計の考え方を整理しました。

VPNルータはVPN・NAT・ファイアウォール・Static Routeによるルーティングを集約した仮想ルータです。クラウド上でもオンプレミスのネットワーク機器に近い考え方でネットワークを構成できます。

ぜひ、自社のネットワークに近い構成で、さくらのクラウド上でネットワーク設計を実施してみてください。

VPNだけじゃない — さくらのクラウドVPNルータで作る境界ネットワーク

はじめに

通信の入口と経路をまとめて扱えるVPNルータ