本日当社は、インターネット上のIPトラフィックでのCloudflareのネットワークの利用を可能にする、Cloudflare Magic Transitを発表いたしました。従来、Cloudflareでは主にプロキシサービスを運営してきました。これは、当社のサーバーがインターネットユーザーのHTTP、TCP、UDPの各セッションを中断し、サーバーがオリジンサーバーとの間に作成する新規セッションを介してデータを渡す仕組みです。Magic Transitでは、CloudflareがIP層の運用にも関与します。セッションを中断するほか、当社サーバーがパケット単位でネットワーク機能一式（DoS軽減、ファイアウォール、ルーティングなど）を適用します。
過去9年間にわたってCloudflareが構築してきた堅牢でスケーラブルなグローバルネットワークは現在、90か国以上の193都市におよび、さらに成長を続けています。すべてのCloudflareのお客様は、2つの重要な手法によって、このスケールの恩恵を受けることができます。1つ目が、エニーキャストネットワーキングです。Cloudflareは、エニーキャストを早期に採用し、このルーティング技術を使ってインターネットトラフィックを当社データーセンターに分散しています。これにより、任意のデータセンターが任意のお客様のトラフィックを処理できることで、新規データセンターの導入時に新規IPアドレスを取得しプロビジョニングする手間を省くことができます。2つ目の手法は、同種のサーバーアーキテクチャの使用です。各エッジデータセンター内のすべてのサーバーに、すべてのタスクを実行する機能を持たせています。コモディティハードウェア上にサーバーを構築することにより、既存のデータセンターに新しいサーバーを追加して処理能力の増強をすることが、迅速かつ容易です。当社はこのように、特別なハードウェアに依存することなく、最新のLinuxカーネルの手法を用いて、ネットワークの可能性や限界を押し広げるノウハウの開発を行っています。
Magic Transitは同じ手法を使用して同じネットワーク上に構築されており、お客様はCloudflareと同じスケールでネットワーク機能を実行することができます。当社の高速で、安全、信頼性の高いグローバルエッジが、お客様のエッジになるのです。では、パケットがインターネット上のユーザーからMagic Transitのお客様のネットワークに到達するまでの流れを説明していきましょう。
DoS攻撃の軽減機能...お客様のために
発表に関するブログ記事では、AcmeCorpの展開を例にとって説明しています。この展開例について話を続けます。AcmeのIPプレフィックス 203.0.113.0/24がCloudflareに送られると、Cloudflareの世界中のデータセンターにあるトランジットプロバイダー、ピア、およびインターネットエクスチェンジへのこのプレフィックスのアナウンスが開始されます。加えて、Acmeは自身のISPへのプレフィックスのアナウンスを停止します。つまり、Acmeのプレフィックス内に宛先アドレスを持つインターネット上のIPパケットは、Acmeのルーターではなく、近くのCloudflareデータセンターに配信されます。
たとえば、イリノイ州シャンペーンにあるCloudflareのオフィスにあるコンピューターから、203.0.113.100にあるAcmeのFTPサーバーにアクセスしたいとします。私のコンピューターが宛先アドレス203.0.113.100の TCP SYNパケットを生成し、インターネットに送信します。エニーキャストのおかげで、このパケットは、シャンペーンに（インターネットルーティング距離の観点で）最も近い、シカゴのCloudflareのデータセンターで終端します。パケットはデータセンターのルーターに到着し、ECMP（等価マルチパス）ルーティングを使用してこのパケットを処理するサーバーを選択し、このパケットを選択したサーバーにディスパッチします。
サーバーで、パケットはいったんCloudflareのXDPおおよびiptablesベースのDoS検出と軽減機能を通過します。もし、このTCP SYNパケットが攻撃の一部であると判断された場合、そのパケットはドロップされてそこで終わりになります。幸い、パケットは通過を許可されています。
ここまでは、Cloudflareのネットワーク上の他のトラフィックとまったく同じように見えます。Cloudflareでは、グローバルなエニーキャストネットワークの運用に用いている専門知識を活用し、Magic Transitのお客様のトラフィックをすべてのデータセンターに引き付け、トラフィックに対して、Cloudflareを保護してきたものと同じDoS攻撃軽減ソリューションを適用することができます。CloudflareのDoS攻撃軽減ソリューションは、記録されている中では最大規模の、2018年の942Gbps SYNフラッドをはじめとする攻撃を処理してきました。最近の、1秒あたり3億パケットというSYNフラッド攻撃のスクリーンショットを示します。当社はアーキテクチャにより拡張性を確保し大規模な攻撃を阻止しています。
ネットワーク名前空間による分離と制御
ここまでのところは、Cloudflareの他のトラフィックの処理方法と同じようにに見えますが、この先は違ってきます。Cloudflareの他のサービスでは、TCP SYNパケットはローカルプロキシプロセス（nginxベースのHTTP/Sスタックなど）にディスパッチされます。Magic Transitでは、他のサービスとは異なり、ファイアウォールやルーティングなどのお客様定義のネットワーク機能を動的にプロビジョニングして適用したいと考えました。それには、ネットワーク間の分離を提供しながら、これらのネットワーク機能を迅速にスピンアップして構成する方法が必要でした。そのため当社では、ネットワーク名前空間に目をつけました。
名前空間は、プロセス群同士の間で共有できるシステムリソースからなる軽量な仮想インスタンスを作成するための、Linuxカーネル機能の集合です。名前空間は、Linuxのコンテナ型仮想化のための基本的な構成要素です。特にDockerは、Linux名前空間上に構築されています。_ネットワーク名前空間_とはLinuxネットワークスタックの分離インスタンスで、自身のネットワークインタフェース（固有のeBPFフック付き）、ルーティングテーブル、ネットフィルタ構成などを含みます。ネットワーク名前空間は、分離において、お客様定義によるネットワーク設定を迅速に適用するための低コストのメカニズムを、すべて内蔵のLinuxカーネル機能で提供するため、ユーザー空間パケットの転送やプロキシによるパフォーマンス低下は生じません。
新規のお客様がMagic Transitの使用を開始する際、Cloudflareのエッジネットワーク上のすべてのサーバーに新しいネットワーク名前空間を作成します（すべてのサーバーがすべてのタスクを実行可能という点については、説明しましたっけ？）。当社では、当社サーバー上で実行され、このネットワーク名前空間とその設定の管理を担うデーモンを構築しました。このデーモンは、グローバルに分散する当社のキーバリューストアであるQuicksilverから、構成の更新を常に読み取り、ファイアウォールやルーティングなどの顧客定義の構成を_お客様の名前空間内で_適用しています。たとえば、Acmeがファイアウォール規則をプロビジョニングしてFTPトラフィック（TCPポート20および 21）から 203.0.113.100へのアクセスを許可する場合には、Quicksilverを介してグローバルに伝播され、Magic Transitがnftablesルールを付加してお客様の名前空間にファイアウォールルールを適用します。
# Apply nftables rule inside Acme’s namespace
$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 acceptお客様のトラフィックをネットワーク名前空間へ送るためには、デフォルトのネットワーク名前空間にルーティングを少々設定する必要があります。ネットワーク名前空間が作成されると、仮想イーサネット（veth）インタフェースのペアも作成されます（デフォルトの名前空間に1つ、新規作成された名前空間に1つ）。このインタフェースのペアは、ネットワークトラフィックを新しいネットワーク名前空間との間で出し入れするための「仮想ワイヤ」を作成します。既定のネットワーク名前空間では、Magic Transitのお客様IPのプレフィックスをこのお客様の名前空間に対応するvethに転送するルーティングテーブルを維持します。Cloudflareでは、iptablesを使用して、Magic Transitの顧客プレフィックス向けられたパケットをマーキングし、さらにこのような特にマーキングされたパケットにはMagit Transitのルーティングテーブルを使用しなければならないとするルーティングルールを設定しています。
（なぜ、わざわざ、iptablesでパケットをマーキングして別のルーティングテーブルを維持するのか？分離のためです。Magit Transitのルーティング設定を分離したままにすることで、既定のルーティングテーブルが、Magit Transit以外のトラフィックのCloudflareのエッジを経由する流れに影響する方向に、誤って変更されるリスクを低減するのです。
ネットワーク名前空間は、Magit Transitのお客様がネットワーク機能を分離した状態で実行、管理できる軽量な環境を提供し、お客様側での完全な制御が可能となります。
GRE＋エニーキャスト＝マジック
エッジネットワーク機能を通過後、TCP SYNパケットは最終的にお客様のネットワークインフラストラクチャに返される状態になります。AcmeCorpはCloudflare内のコロケーション設備にネットワークフットプリントを持たないため、Cloudflare側から、AcmeCorpのネットワークトラフィックをパブリックインターネットを介して配信する必要があります。
ここで問題が生じます。TCP SYNパケットの宛先アドレスは203.0.113.100ですが、IPプレフィックス203.0.113.0/24をアナウンスしている唯一のネットワークはCloudflareです。つまり、Cloudflareから単純にこのパケットを転送することはできません。パケットはブーメランのように戻ってきてしまいます。このパケットをAcmeに配信するには、トンネリングと呼ばれる技術を使用する必要があります。
トンネリングは、1つのネットワークからのトラフィックを別のネットワーク経由で運ぶ方法です。今回の例では、AcmeのIPパケットを、インターネット経由でAcmeのルーターに配信できるIPパケット内にカプセル化します。多数ある一般的なトンネリングプロトコルの中でも、シンプルでベンダーのサポートも行き届いているという理由で、Generic Routing Encapsulation（GRE）がよく用いられています。
GREトンネルのエンドポイントは、Cloudflareのサーバー（Acmeのネットワーク名前空間内）とAcmeのルータの両方に設定されています。Cloudflareのサーバーは、パブリックにルーティング可能なAcmeのルーターのIPアドレスに向けられたIPパケット内の、203.0.113.0/24宛てのIPパケットをカプセル化し、ルーター経過後にこのパケットのカプセル化を解除して、Acmeの社内ネットワークに送り出します。
さて、上の図では、重要な情報を省略していました。GREトンネルのCloudflare側のIPアドレスです。GREトンネルを設定するには、各サイドにIPアドレスを指定する必要があり、トンネル経由で送信されるパケットの外側のIPヘッダーは、特定のアドレスを使用する必要があります。しかし、Cloudflareには何千台ものサーバーがあり、それぞれがトンネル経由でお客様にパケットを配信することが必要となる場合があります。では、お客様は通信のために、何個のCloudflare IPアドレス（およびGREトンネル）が必要になるでしょうか？答えは、1個です。これがエニーキャストのマジックです。
Cloudflareは、自社のGREトンネルのエンドポイントにエニーキャストIPアドレスを使用、つまり、当社データセンターの任意のサーバーが、同一のGREトンネルを経由するパケットのカプセル化と解除の両方を実行することが可能です。なぜ、このようなことが可能なのでしょう？トンネルはポイントツーポイントリンクではなかったのでしょうか？ GREプロトコル自体はステートレスで、各パケットは個別に処理され、トンネルのエンドポイント間でのネゴシエーションや調整は必要としません。トンネルは技術的には_IPアドレス_にバインドされているものの、_特定のデバイス_へのバインドは不要です。外側のヘッダーを取り除いて内側のパケットをルーティングできるデバイスであれば、トンネル経由で送信されるGREパケットを処理できます。実際のところ、エニーキャストの文脈では、「トンネル」は、2つの固定したポイントがリンクされた状態を想像させることから誤解を招く用語かです。CloudflareのエニーキャストGREでは、単一の「トンネル」が、Cloudflareの世界規模のエッジ上にある、すべてのデータセンターのすべてのサーバーへの、導管のように機能しています。
エニーキャストGREを使用することによる、最大の強みは、単一障害点の排除です。従来は、2つのGREエンドポイント間でインターネットが停止すると、「トンネル」が完全に遮断されるため、GRE-over-Internet（インターネット上でのGREの使用）には問題がありました。つまり、これまで、信頼性の高いデータ配信には、異なる物理的サイトで終端する冗長なGREトンネルのセットアップおよびメンテナンスと、いずれかのトンネルが壊れた時には再ルーティングが必要という、頭の痛い作業を伴うものでした。しかし、Cloudflareはすべてのデータセンター内のすべてのサーバからお客様のトラフィックをカプセル化して配信しているため、1つの「トンネル」が壊れて困るというような問題はありません。つまり、Magit Transitのお客様は、トンネルを複数の物理サイトで終端させるという冗長性と信頼性を両立しながら、セットアップと管理は1つのGREエンドポイントで済むという簡便さも得ることができるのです。
Cloudflareの規模を共有できる
Magic Transitは、ネットワーク機能を大規模に展開することのできる、パワフルな新しい方法です。Cloudflareは仮想インスタンスのみでなく、_グローバルな仮想エッジ_を提供しています。Magic Transitは、一般的にユーザーの施設内のネットワークに設定されているハードウェアアプライアンスを活用し、ユーザーのネットワークをCloudflareのネットワークのすべてのデータセンターにあるすべてのサーバーの規模にまで拡大、分散します。これにより、Cloudflareのグローバルなエニーキャストネットワークへのアクセスが可能となり、Cloudflareのサーバー群で_顧客の_タスクの実行も可能になり、Cloudflareのノウハウによって高速で信頼性の高い、セキュアなネットワークを構築することができるようになります。Cloudflareが持つ規模を、お客様も共有できるようになるのです。