Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

Cloudflare Magic Transit でハイブリッドクラウドネットワークを保護する

最終更新 Markdown で表示Agent セットアップ

はじめに

ネットワークインフラを DDoS 攻撃から守るには、容量と速度の両立が必要です。ボリュメトリック攻撃は、オンプレミスのハードウェア型 DDoS 防御機器と、帯域が限られたインターネット回線を簡単に飽和させます。

クラウド型の DDoS 防御は、より機敏で効率的かつスケーラブルです。ただし市場の多くのソリューションは、良好なネットワーク性能を保つために必要なグローバルな拠点とスクラビングセンターの密度を欠いています。こうした弱点がある DDoS 防御では、顧客トラフィックを疎らなスクラビングセンターへ迂回させる必要があり、取り込み地点から数千マイル離れることも珍しくありません。その結果、遅延が大きく増え、エンドツーエンドのネットワーク性能とスループットに必ず影響します。

Cloudflare Magic Transit は、インターネットからの受信ユーザートラフィックを扱うインターネット向けネットワーク全体に、クラウドネイティブのインライン DDoS 防御とトラフィック高速化を提供します。導入場所はオンプレミス、クラウド、その組み合わせ(ハイブリッドアーキテクチャ)を問いません。データセンターは数百都市に広がり、DDoS 緩和容量は数百 Tbps です。Magic Transit は発生源の近くで攻撃を検知・緩和し、世界平均で 3 秒未満です。

Magic Transit の動作と、各種ユースケース向けのアーキテクチャは、このドキュメント末尾の関連リソース(Cloudflare Magic TransitMagic Transit リファレンスアーキテクチャ)に記載しています。

このドキュメントでは、ハイブリッドクラウドのネットワークインフラを Magic Transit で保護する、よくあるシナリオのリファレンスアーキテクチャに絞って説明します。

シナリオ 1 - オンプレミスとクラウドの両方で顧客 BYOIP を使う

このシナリオでは、/24 以上のネットワークプレフィックスを複数、Magic Transit で保護します。これらのネットワークはオンプレミスと、複数のクラウドプロバイダーのリージョンにまたがって導入されています。

説明のため、インターネット向けネットワークの場所と、それぞれの IP プレフィックスの例を次に示します。

AWS VPC: 192.0.2.0/24
GCP VPC: 198.51.100.0/24
Azure vNet: 203.0.113.0/26
On-premise data center 1: 203.0.113.64/26
On-premise data center 2: 203.0.113.128/25
図 1: クラウドとオンプレミスのすべてのネットワークで顧客 BYOIP を使う
図 1: クラウドとオンプレミスのすべてのネットワークで顧客 BYOIP を使う

注: この画像のラベルは、以前の製品名を反映している場合があります。

  1. Border Gateway Protocol(BGP)を使い、Cloudflare は保護対象の顧客 IP プレフィックスを、世界中の Cloudflare データセンターからインターネットへ広告します。これにより IP Anycast が有効になり、保護対象プレフィックス宛てのインターネットトラフィックは、常に発生源に最も近い Cloudflare データセンターへルーティングされます。

同時に、オンプレミスネットワークとクラウドプロバイダーネットワークは、それぞれの境界ルーターから同一プレフィックスの広告を止めます。これにより、Magic Transit で保護する IP プレフィックス宛てのインターネットトラフィックは、すべて Cloudflare ネットワーク経由になります。

代わりに、境界ルーターからより広い(less-specific)IP プレフィックスをインターネットへ広告することもできます。こうしておくと、ごくまれに Magic Transit に障害が起きた場合でも、トラフィックをインターネットから各ネットワーク拠点へすばやく直接戻せます。

  1. インターネットから保護対象 IP プレフィックス宛てに発生したトラフィックは、世界中の Cloudflare ネットワークへ取り込まれます。
  2. すべてのトラフィックはスクラビングされます。つまり、高度で自動化された DDoS 緩和 技術により、各 Cloudflare データセンターでインラインに DDoS 攻撃トラフィックを除去・緩和します。
  3. DDoS 緩和を通過したトラフィックは、付属の Cloudflare Network Firewall で追加のネットワークファイアウォールフィルタリングを受けます。
  4. クリーンでフィルタ済みのトラフィックは、Cloudflare Network Interconnect(CNI)と呼ばれるプライベート接続、または GRE や IPsec などの標準 IP トンネルを使ったパブリックインターネット経由で、保護対象ネットワークへルーティングされます。Magic Transit の IP トンネルの詳細は、Magic Transit のトンネルとカプセル化 を参照してください。
  5. 保護対象 IP プレフィックスからインターネットユーザーへのサーバー返送トラフィックは、ハイブリッドクラウド拠点からインターネットへ直接ルーティングされ、Cloudflare ネットワークを経由しません。これをダイレクトサーバーリターン(DSR)と呼びます。DSR を使うには、クラウドサービスプロバイダー側で BYOIP が必要です。

Magic Transit が、Cloudflare ネットワーク上で世界規模に動く単一のクラウドネイティブなネットワーク保護ソリューションになるため、グローバルなハイブリッドクラウドのインターネット向けネットワークは、導入環境を問わず DDoS やその他の悪意ある攻撃から保護されます。

こうした統合されたクラウドネイティブなネットワーク保護のもう 1 つの利点は、インターネット向けネットワークをハイブリッドクラウド環境間で移行・再配置しても、保護が切れないことです。Magic Transit の設定で、新しい場所へトラフィックをルーティングする経路を変えるだけで済みます。

シナリオ 2 - オンプレミスとクラウドの両方で Cloudflare から IP をリースする

/24 以上のネットワークプレフィックスを所有していない場合でも、Cloudflare から IP をリース して、より小さなネットワークに割り当てれば、Magic Transit で保護できます。次の図は、こうした導入のアーキテクチャです。前のシナリオと同様に、顧客ネットワークはオンプレミスと、複数のクラウドプロバイダーのリージョンにまたがって導入されています。

説明のため、インターネット向けネットワークの場所と、それぞれの IP プレフィックスの例を次に示します。

AWS VPC: 192.0.2.0/28
GCP VPC: 192.0.2.16/28
Azure vNet: 192.0.2.32/28
On-premise data center 1: 192.0.2.48/28
On-premise data center 2: 192.0.2.64/28
図 2: オンプレミスとクラウドの両方で Cloudflare から IP をリースする
図 2: オンプレミスとクラウドの両方で Cloudflare から IP をリースする

注: この画像のラベルは、以前の製品名を反映している場合があります。

  1. Border Gateway Protocol(BGP)を使い、Cloudflare は自社所有の IP プレフィックス(リースした IP アドレスを含む)をインターネットへ広告します。

[手順 2 から 5 は、上記シナリオ 1 と同じです]

  1. リースした Cloudflare IP アドレスを送信元とするサーバー返送トラフィックは、各拠点の境界ルーターからインターネットへ直接ルーティングできません。このトラフィックは、Magic Transit Egress を使い、Cloudflare ネットワーク経由でインターネットへ到達させる必要があります。Ingress トラフィックと同じ CNI または IP トンネル経由で Cloudflare ネットワークへ戻せます。拠点ではポリシーベースルーティング(PBR)などのルーティング技術を使います。
  2. Magic Transit Egress トラフィックは、ユーザー向けにインターネットへ出る前に、Network Firewall のフィルタリングを受けます。

シナリオ 3 - オンプレミスは顧客 BYOIP、クラウドは Cloudflare から IP をリースする

このシナリオでは、より大きなオンプレミスネットワークと、より小さなクラウドベースネットワークを導入します。オンプレミスには自社の /24 IP プレフィックスを割り当て、クラウドベースネットワークには Cloudflare から IP をリースします。

説明のため、インターネット向けネットワークの場所と、それぞれの IP プレフィックスの例を次に示します。

AWS VPC: 192.0.2.0/28
GCP VPC: 192.0.2.16/28
Azure vNet: 192.0.2.32/28
On-premise data center 1: 198.51.100.0/24
On-premise data center 2: 203.0.113.0/24
図 3: オンプレミスは顧客 BYOIP、クラウドは Cloudflare から IP をリースする
図 3: オンプレミスは顧客 BYOIP、クラウドは Cloudflare から IP をリースする

注: この画像のラベルは、以前の製品名を反映している場合があります。

  1. Border Gateway Protocol(BGP)を使い、Cloudflare は顧客所有と Cloudflare 所有の両方の IP プレフィックスをインターネットへ広告します。

[手順 2 から 5 は、上記シナリオ 1 と同じです]

  1. クラウドベースネットワークからのサーバー返送トラフィックは、Magic Transit Egress を使い、Cloudflare ネットワーク経由でインターネットへ到達させます。Ingress トラフィックと同じ CNI または IP トンネル経由で Cloudflare ネットワークへ戻せます。物理拠点ではポリシーベースルーティング(PBR)などのルーティング技術を使います。
  2. この Magic Transit Egress トラフィックは、ユーザー向けにインターネットへ出る前に、Network Firewall のフィルタリングを受けます。
  3. オンプレミスネットワークからインターネットユーザーへのサーバー返送トラフィックは、ダイレクトサーバーリターン(DSR)であり、Cloudflare ネットワークを経由しません。

: 代わりに、オンプレミスネットワークのサーバー返送トラフィックも、ポリシーベースルーティングと Magic Transit Egress で Cloudflare 経由にできます。これにより、Egress トラフィックに Network Firewall のフィルタリングという追加のセキュリティと制御が加わります。たとえば、疑わしい IP アドレスやサイト、禁止された宛先、特定の国宛てトラフィックをブロックできます。

関連リソース

役に立ちましたか?