Magic Transit

解決する課題

• 自社データセンターやクラウド上のネットワークが大規模なDDoS攻撃（帯域消費型・プロトコル型）にさらされ、自前のスクラビング設備では吸収しきれない
• IPレンジ単位でネットワーク全体を守りたいが、Webアプリケーション単位のWAFやCDNだけではIP・TCP・UDPレイヤーの攻撃をカバーできない
• 複数の拠点・クラウド・オンプレミスが混在し、経路とセキュリティポリシーの一元管理が難しい
• 攻撃の有無にかかわらず正規トラフィックの遅延を増やしたくない（スクラビングセンター経由の迂回を避けたい）
• DDoS対策とWAF、DNS、Zero Trustなどのセキュリティ機能を別々の仕組みで運用するコストと複雑さを減らしたい

主要概念と用語

• Magic Transit: 顧客が保有するIPプレフィックスをCloudflareのエニーキャストネットワークからアナウンスし、IP・TCP・UDPレイヤーのトラフィック全体をエッジで受け止めてDDoS防御・ルーティングを行うサービス
• BGPアナウンス: 顧客が自社で保有・管理するIPアドレス範囲（プレフィックス）を、Cloudflareのネットワークから世界中のインターネットへ広報する仕組み。これによりそのIP宛のトラフィックが最寄りのCloudflareエッジへ引き寄せられる
• エニーキャスト: 同一のIPアドレスを世界中の拠点から同時にアナウンスする技術。攻撃トラフィックも正規トラフィックも最寄りの拠点で吸収・処理されるため、特定拠点への集中を避けられる
• GRE トンネル / Anycast GRE: クリーントラフィック（攻撃を除去した後の通信）をCloudflareのエッジから顧客のネットワークへ戻すためのトンネリング方式。オンプレミスのルーターやファイアウォールとの間に張る
• Magic IPsec: GREの代替として使えるIPsecベースの接続方式。トンネルの暗号化を重視する構成で利用する
• Magic Firewall: Magic Transitに組み込まれたネットワークレイヤーのファイアウォール。IP・ポート・プロトコル単位でルールを定義し、L3/L4の許可・拒否を制御する
• オンランプ（on-ramp）: 顧客ネットワークからCloudflareへトラフィックを送り込む経路（GRE、IPsec、専用接続など）の総称
• スクラビング: 受信したトラフィックから攻撃性の通信を検知・除去し、正規のトラフィックだけを抽出する処理

仕様・制限・クォータ

• 対象になるのは顧客が自ら保有・管理するIPプレフィックス（BGPで広報可能なブロック）であり、個別の単一IPだけを保護する用途には向かない
• BGPアナウンスの開始には、プレフィックスの所有権確認や既存アナウンス元との調整など事前のオンボーディング作業が必要
• クリーントラフィックの戻し経路（GRE・IPsec・専用接続）は冗長構成での契約が前提になり、単一トンネルのみの構成は可用性上のリスクが残る
• Magic Firewallのルール数やログ保持期間、GREトンネルの本数などは契約内容によって上限が異なる
• 対応できるプロトコルはIP・TCP・UDPを中心としたネットワークレイヤーであり、HTTP/HTTPSレベルのアプリケーション攻撃対策は別途WAF等と組み合わせる

内部の仕組み

Magic Transitを導入すると、顧客のIPプレフィックスはCloudflareのエニーキャストネットワークからBGPアナウンスされるようになります。そのプレフィックス宛の全トラフィックは、インターネットの経路制御の仕組みにより最寄りのCloudflareエッジへ自然に引き寄せられます。

• エッジに到達したトラフィックは、まずネットワークレイヤーの自動DDoS検知にかけられ、異常なパターン（フラッド攻撃、増幅攻撃など）が自動的に検知・遮断される
• Magic Firewallのルールに従って、許可されたIP・ポート・プロトコルの通信だけが後段へ通過する
• 攻撃性のトラフィックが除去された後のクリーントラフィックは、GREトンネルやIPsecトンネルを通じて顧客のオンプレミス環境やクラウド上のネットワークへ転送される
• 同じCloudflareのネットワーク上でWAFやDNS、Zero Trust関連の機能も動作しているため、Magic Transit経由のトラフィックに対してもこれらの機能を重ねて適用できる
• 攻撃検知やトラフィックの傾向は可視化ダッシュボードに集約され、アナウンスしているプレフィックス単位で状況を確認できる

設計パターン / ベストプラクティス

• 戻し経路（GRE/IPsec）は複数拠点・複数トンネルで冗長化し、単一の接続点に依存しない構成にする
• Magic Firewallのルールは最小権限の原則で設計し、必要なプロトコル・ポートだけを明示的に許可する
• WAFやDNSなど他のCloudflare製品と組み合わせて多層防御にし、ネットワークレイヤーとアプリケーションレイヤーの両方をカバーする
• BGPアナウンスの切り替えは段階的な移行計画を立て、既存のISPやアップストリームとのアナウンスとの競合や優先度を事前に調整する
• オンプレミス側のルーターやファイアウォールの設定は、GRE/IPsecトンネルのキープアライブとフェイルオーバーを明示的に検証しておく

運用・監視

• ダッシュボードで攻撃の検知状況とトラフィック量の推移をプレフィックス単位・時系列で確認する
• GRE/IPsecトンネルの**接続状態（up/down）**を継続的に監視し、戻し経路の障害を早期に検知する
• Magic Firewallのルールごとのヒット数を確認し、意図しない遮断や想定外の通過がないかを定期的に点検する
• BGPアナウンスの状態（アナウンスされているプレフィックスと経路）を外部の経路観測ツールと突き合わせて異常がないか確認する
• インシデント発生時は、攻撃の種類・規模・遮断状況をログから追跡し、Magic Firewallのルール改善につなげる

コスト

Magic Transitは保護対象のIPプレフィックス規模や契約内容に応じた費用体系になっており、一般的な従量課金のサービスとは異なる契約形態を取ることが多いサービスです。自前でスクラビング設備やDDoS対策専用機器を保有・運用するコストと比較して、エッジネットワークを共有利用することで初期投資を抑えられる点が特徴です。具体的な料金は契約内容によって変動するため、公式情報での確認が前提になります。

セキュリティ

• IP・TCP・UDPレイヤーの大規模なDDoS攻撃（フラッド攻撃、増幅攻撃など）を自動検知・自動緩和する
• Magic Firewallによって、ネットワークレイヤーでのアクセス制御ルールを一元管理できる
• 戻し経路にIPsecを選択すれば、Cloudflareと顧客ネットワークの間の通信を暗号化できる
• 同じアカウント内でWAFやZero Trust関連の機能と組み合わせることで、ネットワークからアプリケーションまでの多層防御を構築できる
• BGPアナウンスの切り替え自体がネットワーク構成の変更を伴うため、権限管理と変更手順の統制が重要になる

関連サービス・比較

Magic Transitはネットワークレイヤー（L3/L4）全体を守るのに対し、CloudflareのWAFはアプリケーションレイヤー（L7）のHTTP/HTTPSトラフィックを守ります。対象レイヤーと保護範囲の違いを整理します。

ハンズオン / CLI例

# wranglerでログイン（アカウント認証）
wrangler login

# アカウントIDやトークンを確認（Magic Transitの設定はダッシュボード/APIが中心のため
# wranglerは主に周辺のWorkers連携やログ確認補助として利用する）
wrangler whoami

# アカウントに紐づくログ設定（Logpush等)の一覧を確認する例
wrangler tail --format=pretty