このドキュメントでは、インターネット向けネットワークインフラ向けの BGP ベースの DDoS 防御およびトラフィック高速化サービスである Cloudflare Magic Transit の主要なアーキテクチャ、機能、ネットワーク導入オプションを説明します。
このリファレンスアーキテクチャは、自社の既存ネットワークインフラに関する責任や知見がある IT／ネットワーク担当者向けです。ルーター、DNS、ファイアウォールなど、コンテンツ配信に関わる技術と概念の経験があると読みやすくなります。
Cloudflare の基礎を固めるには、次の資料を推奨します。
このリファレンスアーキテクチャでは、次の内容を学べます。
- Cloudflare Magic Transit が、サービス拒否攻撃（DDoS）からネットワークインフラをどう守るか
- 既存のネットワークインフラに Magic Transit をどう組み込むか
ネットワークインフラを DDoS 攻撃から守るには、容量と速度の両立が必要です。ボリュメトリック攻撃は、ハードウェア機器とその帯域が限られたインターネット回線を簡単に飽和させます。多くのクラウド型ソリューションは、トラフィックを集中型のスクラビングセンターへ迂回させるため、ネットワーク性能が大きく落ちます。
Cloudflare Magic Transit は、オンプレミス、クラウド、ハイブリッドネットワーク向けに DDoS 防御とトラフィック高速化を提供します。データセンターは 数百都市 ↗ に広がり、緩和容量は数百 Tbps です。Magic Transit は発生源の近くで攻撃を検知・緩和し、世界平均で 3 秒未満です。そのうえで、パブリックインターネットより速くトラフィックをルーティングします。
Magic Transit の大まかな動作は次のとおりです。
-
接続: Border Gateway Protocol（BGP）でインターネットへ経路を広告し、Cloudflare の Anycast ネットワークを使って、発生源に最も近い Cloudflare データセンターで顧客トラフィックを取り込みます。
-
防御と処理: 顧客トラフィックはすべて攻撃がないか検査されます。攻撃を検知すると、高度で自動化された緩和手法をすぐに適用します。負荷分散、次世代ファイアウォール、コンテンツキャッシュ、サーバーレスコンピューティングなどの追加機能もサービスとして利用できます。
-
高速化: クリーンなトラフィックは、Cloudflare の低遅延リンク経由で最適なスループットになるようルーティングされ、IP トンネル（GRE または IPsec）またはプライベートネットワーク相互接続（PNI）でオリジンネットワークへ引き渡されます。Magic Transit は Cloudflare 側のトンネルエンドポイントに Anycast IP アドレスを使うため、どのデータセンターのどのサーバーでも、同じトンネルのカプセル化とデカプセル化ができます。トンネルとカプセル化の詳細は GRE および IPsec トンネル を参照してください。
Magic Transit は、自側のトンネルエンドポイントに Anycast IP アドレスを使います。そのため、顧客ネットワークから Cloudflare へ設定した 1 本のトンネルが、すべての Cloudflare グローバルデータセンター（China Network を除く）につながります。ルーターへの負荷は増えません。ルーターから見ると、単一 IP エンドポイントへの単一トンネルです。
トンネルエンドポイントは技術的には IP アドレスに紐づきますが、特定デバイスに紐づける必要がないためです。外側ヘッダーを外して内側パケットをルーティングできるデバイスなら、トンネル経由のどのパケットも処理できます。
ネットワーク障害などの問題が起きても、トンネルは自動でフェイルオーバーし、顧客のネットワーク性能には影響しません。
デフォルトでは、Magic Transit はイングレス方向（インターネットから顧客ネットワークへ）のトラフィックだけを処理します。クライアントへ戻るサーバーリターントラフィックは、顧客の DC エッジルーターが、デフォルトのルーティングテーブルに従い、アップリンク経由でインターネット／ISP へ送ります。このリターントラフィックはトンネル経由で Cloudflare を通りません。これを Direct Server Return（DSR）と呼びます。
図 2 のネットワーク図は、この Magic Transit 構成と、Magic Transit で保護されたトラフィックのエンドツーエンドのパケットフローを示します。この構成のトンネルは GRE でカプセル化します。
-
Cloudflare は、トンネルの Cloudflare 側エンドポイント用に IPv4 Anycast アドレスを顧客へ提供します。これは Cloudflare 所有アドレス空間からの、インターネットで経路広報される IP アドレスです。Cloudflare は、世界各地の多数のデータセンターの複数ノードからエンドポイント IP を広告することで、自ネットワーク上の障害を自動で処理します。顧客ネットワーク側の障害に備えるには、別々のルーターから 2 本のトンネルを設定します。追加の Anycast IP アドレスはアカウントチームに依頼できます。上記の構成は単一トンネルで、Cloudflare 側のトンネルエンドポイントアドレスは 192.0.2.1 です。
-
Anycast GRE トンネルの顧客側は、インターネットで経路広報されるアドレスである必要があります。通常は顧客エッジルーターの WAN インターフェースの IP アドレスです。この例では 192.0.2.153 です。
-
トンネルインターフェースの IP アドレスは RFC 1918 のプライベートアドレスです。これらのアドレスは、所属する特定の Magic Transit サービスインスタンス内でのみ「ローカルに意味を持ちます」。そのため、同じ Magic Transit サービスインスタンス内の他トンネルと重ならなければ、顧客は任意の RFC 1918 アドレスを選べます。
-
ベストプラクティスとして、トンネルはポイントツーポイント接続なので、1 本のトンネルに必要な 2 つの IP アドレスの割り当てには /31 サブネットで足ります。上記の例では 10.10.10.0/31 を選び、Cloudflare 側のトンネルインターフェースを 10.10.10.0/31、顧客の DC エッジルーター側を 10.10.10.1/31 としています。
-
トンネルを設定したら、Magic Transit サービスインスタンスにルートを設定し、指定した顧客プレフィックス宛のトラフィックを正しいトンネルへ転送します。
-
顧客プレフィックス 203.0.113.0/24 宛のトラフィックは、トンネルインターフェースの対向側（Cloudflare ネットワークから見た顧客側）が 10.10.10.1 であるトンネルへルーティングされます。
-
これは Direct Server Return（DSR）構成なので、サーバーリターントラフィックは顧客エッジルーターに設定されたデフォルトルート（ip route 0/0）に従い、アップリンクピア（顧客 ISP のルーター）へ送られ、インターネット経由でクライアントへ戻ります。このリターントラフィックは Cloudflare ネットワークを通りません。
注: ほとんどの ISP が互いの BGP 広告で受け入れる最小の IP プレフィックスサイズ（最長のサブネットマスク）は /24 です。例: x.x.x.0/24 や y.y.y.0/23 は問題ありませんが、z.z.z.0/25 は不可です。そのため、Cloudflare Magic Transit が顧客に代わって広告できる最小の IP プレフィックスサイズは /24 です。
エグレスオプションを有効にして Magic Transit を導入すると、顧客ネットワークからのエグレストラフィックも Cloudflare ネットワークを通ります。クライアントからサーバー、サーバーからのリターンの両方が Cloudflare ネットワークを通るため、トラフィックフローが対称になります。この実装では、Cloudflare ネットワークの利点により、サーバーリターントラフィックのセキュリティと信頼性も高まります。
次のネットワーク図は、Magic Transit のエグレスオプションを有効にしたときの、エンドクライアントと顧客ネットワーク間のエンドツーエンドのパケットフローを示します。
-
イングレストラフィックの流れは、上記のデフォルト構成と同じです。
-
Magic Transit がエグレストラフィックを受信して処理するには、トラフィックの送信元 IP アドレスが Magic Transit で保護する IP プレフィックスの範囲にあり、宛先 IP アドレスがインターネットで経路広報されるアドレス（RFC 1918 以外）である必要があります。
クラウド上のサービスに自社のパブリック IP アドレス（BYOIP）を持ち込む顧客にとって、Magic Transit のエグレスオプションは、クラウドプロバイダーの BYOIP サービスを購入・導入する必要をなくし、クラウド費用と運用コストを下げられる点でも価値があります。
これを実現するには、クラウドプロバイダーの VPC と Cloudflare ネットワークの間に、Magic Transit へのオンランプとなる IP トンネルを設定します。Magic Transit のエグレスオプションでは、クライアント／サーバー通信の両方向がこれらのトンネルを通ります。トンネル化されたパケット内の BYOIP アドレスは、外側のトンネルエンドポイント IP とトンネルヘッダーの後ろに隠れるため、VPC と Cloudflare ネットワークの間にある基盤のクラウドプロバイダー機器からは「見えません」。
Cloudflare Network Interconnect（CNI） は、顧客のネットワークインフラをパブリックインターネットを経由せず Cloudflare に直接接続し、より信頼性が高く、高性能で安全な体験を提供します。
-
CNI は相互接続プロバイダーがレイヤー 2 接続のセットとしてプロビジョニングし、Cloudflare は各接続に対して、自社のインターネット経路広報アドレスブロックから IP アドレスのペアを割り当てます。
-
Cloudflare は顧客と連携してこれらのリンクを設定し、CNI オンボーディング中にリンク上で BGP ピアリングセッションを確立します。
-
CNI で接続された Cloudflare ネットワークと顧客エッジルーターの間で BGP セッションが上がると、Cloudflare 所有プレフィックスがこの CNI リンク経由で顧客エッジルーターへ広告されます。
図 4 は、CNI 上の Magic Transit の参考構成と、関連するパケットフローを示します。
注: ここで示す例は、エグレスオプションを有効にしていないデフォルトの Magic Transit サービスです。前述のとおり、Magic Transit の Direct Server Return モード（イングレスのみ）では、サーバーリターントラフィックは顧客エッジルーターが ISP 経由でパブリックインターネットを通じてクライアントへルーティングします。
エグレスオプションを有効にして使う場合、サーバーリターントラフィックは、CNI 接続上に設定した IP トンネル経由で Cloudflare ネットワークを通じてクライアントへ戻せます。図 5 はその一例です。
Magic Transit は、オンプレミスとクラウドの両方でホストするサービスを守ります。このユースケースは、クラウドホスト導入の構成を示します。
-
この例では、ある顧客が 2 つの異なるクラウドプロバイダー、かつ 2 つの異なる地理的リージョンに、2 つのクラウド VPC を展開しています。
-
この例では、顧客の /24 以上のプレフィックスを、より小さい（サブネットマスクが長い）複数のプレフィックス（例: /26）に分割し、異なる場所の各 VPC に割り当てます。Cloudflare ネットワークから各 VPC へトンネルを確立したあと、顧客は Magic Transit の設定でルートを集中管理し、それぞれの VPC へトラフィックをルーティングできます。この設定は API または UI ダッシュボードから行えます。
Magic Transit のエグレスオプションを使うと、顧客は各クラウドプロバイダーの BYOIP サービス、その料金、設定と運用の複雑さを回避し、エグレストラフィック（保護プレフィックスからのサーバーリターン、またはサーバーからインターネットへのトラフィック）を Magic Transit トンネル経由で Cloudflare グローバルネットワークへ送れます。
企業の外部向けサービス（南北方向のインターネット経路広報トラフィック）を Cloudflare Magic Transit で保護・ルーティングするのに加え、顧客は Cloudflare WAN（旧 Magic WAN）を使い、企業内の東西方向の内部トラフィック（例: RFC 1918 プライベートアドレス）を保護し、企業の全サイトを相互接続できます。
Cloudflare WAN は、レガシーな WAN アーキテクチャを Cloudflare ネットワークに置き換え、グローバル接続、クラウドベースのセキュリティ、性能、制御を、シンプルな 1 つのユーザーインターフェースで提供します。
Cloudflare Magic Transit と Cloudflare WAN を組み合わせると、企業全体向けの包括的で安全、信頼性が高く高性能なグローバル network-as-a-service になり、南北方向と東西方向のトラフィックの両方を保護・高速化します。
両サービスは同じサービスインスタンスに導入できます。外部のインターネット向けネットワークと社内ネットワークの管理とトラフィックフローを完全に分けたい場合は、Magic Transit と Cloudflare WAN で別々のサービスインスタンスを導入できます。
図 7 は、Magic Transit と Cloudflare WAN を別々のサービスインスタンスで導入する例です。
注: この画像のラベルは、以前の製品名を反映している場合があります。
-
この例では、GRE トンネルを使い、Cloudflare グローバル Anycast ネットワーク経由で顧客の各サイトを接続します。Magic Transit サービスインスタンスの Cloudflare Anycast IP アドレスは 192.0.2.1、Cloudflare WAN サービスインスタンスは 192.0.2.2 です。Magic Transit サービスはエグレスオプションを有効にしています。
-
Magic Transit サービスは、外部向けのフロントエンドのクライアント／サーバートラフィックを保護・ルーティングします。Cloudflare WAN サービスは、社内アプリケーション、バックエンドのデータベース同期、拠点と DC、拠点間などの企業内部トラフィックを保護・ルーティングします。
Magic Transit は顧客のサービスを DDoS 攻撃から守りますが、多くのネットワーク管理者は、ほかの不要または悪意のあるトラフィックも制御・ブロックしたいと考えます。Cloudflare Network Firewall は、本社、支店、仮想プライベートクラウドを含む顧客 WAN 全体で一貫したネットワークセキュリティポリシーを適用し、共通ダッシュボードから細かいフィルタリングルールを数秒で世界中に展開できます。
Cloudflare Network Firewall は Magic Transit の一部として導入・設定します。Cloudflare エッジデータセンターを通り、宛先プレフィックスが Magic Transit で保護されているイングレストラフィックは、すべて Cloudflare Network Firewall でフィルタリングできます。
注: この画像のラベルは、以前の製品名を反映している場合があります。
Cloudflare Network Firewall のルールでは、管理者は IP パケットヘッダーの典型的な 5 タプル（送信元／宛先 IP、送信元／宛先ポート、プロトコル）だけでなく、IP パケット長、IP ヘッダー長、TTL などのパケット情報でもネットワークトラフィックを照合・フィルタリングできます。さらに、Cloudflare データセンター／colo の名前、リージョン、データセンターがある国などの地理情報も、Network Firewall ルール（ジオブロッキング）の設定に使えます。
Cloudflare Network Firewall とその設定の詳細は、Introducing Magic Firewall ↗ と Cloudflare Network Firewall のドキュメント を参照してください。
クラウド型 DDoS 緩和サービスは、常にトラフィックを監視して脅威を探す（常時オン導入モデル）か、攻撃を検知したときだけトラフィックを迂回させる（オンデマンド）かを選べます。この判断は、応答時間と緩和までの時間に影響します。場合によっては、遅延にも影響します。
オンデマンド導入モデルでは、ネットワークエッジでインバウンドトラフィックを監視・計測し、ボリュメトリック攻撃を検知します。通常運用（「平時」）では、すべてのトラフィックが遅延や迂回なしでアプリケーションとインフラに直接届きます。トラフィックがクラウドスクラビングプロバイダーへ迂回されるのは、進行中の DDoS 攻撃時だけです。多くの場合、顧客はサービスプロバイダーに連絡してトラフィックを迂回させる必要があり、応答時間が長くなります。
常時オンモードは、攻撃時に顧客側の操作を必要としない、手を離した DDoS 緩和です。組織のトラフィックは平時でも、脅威検査のため常にクラウドプロバイダーのデータセンターを通ります。検知から緩和までの時間が最短になり、サービス中断もありません。
アプローチと導入オプションのなかで、最も包括的な防御を提供するのは常時オン方式です。
ただしプロバイダーによっては、すべてのトラフィックを DDoS 緩和プロバイダーのクラウドへ迂回させると、業務重要アプリケーションには適さない遅延が加わることがあります。Cloudflare は、常時オン導入でも、攻撃の結果として遅延ペナルティが発生しないように設計されています。エッジでトラフィックを解析することが、性能を落とさずに大規模に緩和する唯一の方法です。
理由は、Anycast 経由でトラフィックを取り込むと、検査のために最も近い Cloudflare データセンターへしか向かわないためです。データセンターは 世界数百都市 ↗ にあるため、距離は短いことが多いです。これによりトロンボーン効果を避けられます。
多くの場合、Cloudflare 経由のルーティングはパブリックインターネットより速くなります ↗。包括的なセキュリティのために性能を犠牲にする必要はない、というのが Cloudflare の考えです。
Cloudflare は、オンプレミス、クラウドホスト、ハイブリッドの企業ネットワークを接続・保護する包括的なネットワークサービスを提供します。顧客固有のアーキテクチャに合わせて、さまざまな接続・導入オプションがあります。
-
Cloudflare Magic Transit は、Cloudflare グローバルネットワークの力で組織を DDoS 攻撃から守る、クラウドネイティブのネットワークセキュリティソリューションです。
-
Magic Transit にはネットワークファイアウォールが組み込まれており、オンプレミスファイアウォールを段階的に廃止し、スケールする network security as-a-service を導入できます。
-
企業の外部向けサービス（南北方向のインターネット経路広報トラフィック）の保護とルーティングに加え、顧客は Cloudflare WAN で東西方向の「企業内」内部トラフィックを接続・保護できます。
Magic Transit、Cloudflare WAN、Cloudflare Network Firewall の詳細は、デモを依頼 ↗ してください。