Cloudflareは、Zero Trustプラットフォームを構築し、私たちのネットワークを利用している企業が、パフォーマンスを向上させ、運用面の負荷を軽減しながら、プライベートネットワークを安全に接続できるようにしました。これにより、お客様は単一の仮想プライベートネットワークを構築することができます。従来は、接続されたすべてのプライベートネットワークを一意に識別する必要がありました。
本日より、Cloudflare WARPおよびCloudflare Tunnelのコネクタの仮想化接続を皮切りに、Cloudflare Zero Trust上で多くの分離された仮想プライベートネットワークの構築を開始できることを発表します。
Cloudflareでお客様のプライベートネットワークを接続
異なるプライベートネットワークでホストされる様々なサービスと、それらのリソースにアクセスするお客様の従業員について考えてみてください。ローミング、リモート、実際の会社のオフィスなど、従業員はこれまで以上に分散して仕事をしている可能性があります。いずれにせよ、そのような従業員のみがプライベートサービスにアクセスできるようにしなければなりません。その場合でも、各ユーザーがネットワーク内でアクセス可能な内容をきめ細かく制御できるようにする必要があります。
そこで、Cloudflareがお役に立ちます。グローバルでパフォーマンスの高いネットワークをお客様に提供し、お客様の従業員とプライベートサービスの間の仮想ブリッジとして機能します。Cloudflare WARPを実行している従業員のデバイスでは、Cloudflareのネットワークを通じてトラフィックがエグレスされます。一方、お客様のプライベートサービスはCloudflare Tunnelの背後にあり、Cloudflareのネットワークを通じてのみアクセス可能です。これらのコネクタは、お客様の仮想プライベートネットワークをエンドツーエンドで保護します。
この構成が優れている点は、お客様のトラフィックが直ちに高速化されると同時により安全になることです。さらに、プライベートネットワークのルーティングトラフィック向けの監査、きめ細かいフィルタリング、データ損失防止、マルウェア検出、セーフブラウジングなど、多くのCloudflareサービスの恩恵を受けることができます。
私たちのお客様は、すでにCloudflareのZero Trustプライベートネットワークルーティングソリューションを気に入ってくださっています。しかし、Cloudflareが愛するすべてのものがそうであるように、お客様側にもまだ改善の余地があります。
重複するネットワークの問題
上の画像では、ユーザーはあたかも物理的にそのプライベートサービスのネットワーク内にいるかのように、どのプライベートサービスにもアクセスできます。つまり、ブラウザで_jira.intra_と入力したり、プライベートIP_10.1.2.3_にSSH接続したりしても、いずれのプライベートサービスもインターネットに公開されていないにかかわらず、シームレスに動作します。
ただし、これには大きな前提条件があります。それらの基盤となるプライベートIPが、お客様のアカウントでCloudflareに接続されているプライベートネットワークで一意であることです。
現在、お客様のチームに、通常CIDRと呼ばれる同じIP空間（10.1.0.0/16など）を使用する2つかそれ以上のデータセンターがあるとします。1つが現在のプライマリ、もう1つがセカンダリで、相互に複製し合っています。このような例では、これら2つのデータセンターのそれぞれに、同じIP_10.1.2.3_を持つマシンが存在することになります。
今日まで、Cloudflareを経由してそのように設定することはできませんでした。データセンター1を、10.1.0.0/16へのトラフィックを担当するCloudflare Tunnelと接続します。データセンター2で同じことをすると、曖昧なIPルートの作成を禁じるエラーが表示されます。
理想的な世界では、チームにこのような問題が起きることはありません。すべてのプライベートネットワークに一意のIP空間があるためです。しかし、これは実際には実現が難しく、特に大企業ではなおさらです。2つの会社が合併した場合を考えてみてください。IPアドレスの一意性を保つために、プライベートネットワークの配置を変更することは、不可能に近いことです。
$ cloudflared tunnel route ip add 10.1.0.0/16 dc-2-tunnel
API error: Failed to add route: code: 1014, reason: You already have a route defined for this exact IP subnet新しい仮想ネットワークを導入する
今では、重複するIPルートを論理的に分離する独自の仮想ネットワークを作成することで、上記の問題を克服できるようになりました。仮想ネットワークは、IPサブ空間のグループと考えることができます。これにより、お客様のインフラストラクチャ全体を独立した（仮想化された）プライベートネットワークに構成し、お客様のCloudflare Zero Trust組織からCloudflare WARPを通じてアクセスするようにできます。
このシナリオを設定してみましょう。
まず、2つの仮想ネットワークを作成し、1つをデフォルトとします。
次にTunnelsを作成し、CIDRをそれらにルーティングします。
$ cloudflared tunnel vnet add —-default vnet-frankfurt "For London and Munich employees primarily"
Successfully added virtual network vnet-frankfurt with ID: 8a6ea860-cd41-45eb-b057-bb6e88a71692 (as the new default for this account)
$ cloudflared tunnel vnet add vnet-sydney "For APAC employees primarily"
Successfully added virtual network vnet-sydney with ID: e436a40f-46c4-496e-80a2-b8c9401feac7以上で終わりです。これで両方のTunnelsを実行することができ、IPが重複しているにもかかわらず、各プライベートデータセンターをCloudflareに接続できます。
$ cloudflared tunnel create tunnel-fra
Created tunnel tunnel-fra with id 79c5ba59-ce90-4e91-8c16-047e07751b42
$ cloudflared tunnel create tunnel-syd
Created tunnel tunnel-syd with id 150ef29f-2fb0-43f8-b56f-de0baa7ab9d8
$ cloudflared tunnel route ip add --vnet vnet-frankfurt 10.1.0.0/16 tunnel-fra
Successfully added route for 10.1.0.0/16 over tunnel 79c5ba59-ce90-4e91-8c16-047e07751b42
$ cloudflared tunnel route ip add --vnet vnet-sydney 10.1.0.0/16 tunnel-syd
Successfully added route for 10.1.0.0/16 over tunnel 150ef29f-2fb0-43f8-b56f-de0baa7ab9d8これで、ユーザーはデフォルトで仮想ネットワーク _vnet-frankfurt_を経由してルーティングされるようになりました。ユーザーが希望する場合は、WARPクライアントインターフェースの設定で、_vnet-sydney_などを経由するように選択できます。
ユーザーが選択した仮想ネットワークを変更すると、Cloudflareのネットワークにそのルーティングの決定が通知されます。これにより、その内容がQuicksilverを通じて、数秒のうちに当社のすべてのデータセンターに伝達されます。WARPクライアントはその後、以前選択していた仮想ネットワークにルーティングされている既存のTCP接続を切断して、当社のネットワークへの接続を再開します。これは、あたかもWARPクライアントを切断して再接続しているように認識される可能性があります。
プライベートネットワークルーティングを使用している現在のCloudflare Zero Trust組織はすべて、Cloudflare TunnelsへのIPルートを包含するデフォルトの仮想ネットワークを持つことになります。これより、上記のコマンドを使用して、重複するIPを持つようにプライベートネットワークを拡張し、必要に応じてデフォルトの仮想ネットワークを再割り当てすることができます。
プライベートインフラストラクチャでIPが重複していない場合は、何もする必要はありません。
今後の展開は？
これは、Cloudflareにおける個別の仮想ネットワークへのサポート提供の始まりに過ぎません。先週、Zero Trustダッシュボードから直接Cloudflare Tunnelsを作成、デプロイ、管理する機能を発表しましたので、ご確認ください。現在、仮想ネットワークはcloudflared CLIでのみサポートされていますが、仮想ネットワークの管理もダッシュボードに統合することを視野に入れています。
次のステップでは、Cloudflare Gatewayがこれらの仮想ネットワークを認識できるようにして、Zero Trustポリシーを重複するIP領域に適用できるようにします。Gatewayがこれらの仮想ネットワークを認識できるようになれば、ネットワークロギングにもこの概念を導入し、監査可能性とトラブルシューティングを改善する予定です。