Cloudflare One Appliance のデプロイオプション

Cloudflare は、オンプレミスネットワーク、仮想クラウドネットワーク、SaaS アプリケーションへのアクセスに対して、安全で高性能な接続を提供し、組織のネットワーク変革を支援します。アプリケーションがクラウドへ移るなか、Cloudflare の SASE ↗ プラットフォームは、従来のオンプレミス製品の置き換えを可能にします。分散した環境でも安全なアクセス、低遅延、自動スケーリングを確保できます。レガシーハードウェアへの依存を減らし、IT 運用を簡素化し、クラウドサービスのユーザー体験も向上します。

Cloudflare One Appliance（旧称 Magic WAN Connector）は、物理アプライアンス、またはハイパーバイザー上の VM としてデプロイする仮想アプライアンスです。Zero Touch Provisioning ↗ を使い、ローカルネットワークのトラフィックを自動で Cloudflare へオンランプし、管理の難しい既存のエッジハードウェアを置き換えます。

組織もネットワークもそれぞれ違うため、Cloudflare One Appliance の置き方に万能な答えはありません。このドキュメントでは、多くの環境で妥当なデプロイオプションを概観し、いくつかの高度なユースケースも説明します。

Cloudflare One Appliance をデプロイするときの最初の判断は、ネットワーク上の設置場所です。既存の顧客構内設備（CPE。拠点のエッジルーターやファイアウォール）を残すか、残すなら何のためか、に関わります。実務では、この判断は次の 3 つの構成に分かれることが多いです。

• Connector で CPE を置き換える（図 1a）: 回線が Internet 接続で、既存機器に実質的な用途がない場合です。Connector は DHCP、DNS、NAT、トランキング（801.1Q）、IP アクセスリスト、ブレークアウトトラフィックなど、必要なネットワーク機能を備えています。例は次のとおりです。

  • MPLS から Internet ベースの接続へ移行するとき。MPLS ルーターは、その構成では価値を足さないことが多いです。
  • Internet 向け CPE が寿命に近づいている、またはすでに超えているとき。
  • Internet 向け CPE が Cloudflare One Appliance と冗長になっており、構成を単純にするために外せるとき。

• CPE の北側に Connector を置く（図 1b）: 既存 CPE がファイアウォールで、次の理由で残したい場合に選ばれます。

  • 多層防御として、LAN をさらに保護したい。
  • 高度なセグメンテーションが必要。たとえばセグメント間の許可 / 遮断を Layer 3 から Layer 7 のルールで制御したい場合です。Cloudflare One Appliance のセグメンテーションは OSI モデルの Layer 3 と Layer 4 のみです。

• CPE の南側に Connector を置く（図 1c）: 既存の Internet 向け CPE の南側に Cloudflare One Appliance を置く理由は、次のようなものです。

  • CPE を置き換えられない。ブロードバンド回線の物理インタフェース（例: RJ-11）やプロトコル（例: PPPoE）に、Cloudflare One Appliance が対応していない。
  • CPE を置き換えられない。その機器だけで動く光ファイバーサービス（ISP 提供の ONT など）の一部である。
  • CPE を（まだ）置き換えられない。稼働中のマネージドサービスの一部である。
  • CPE を置き換えられない。技術面または契約面の理由で残したいファイアウォールである。

注: この画像のラベルは、以前の製品名のままのことがあります。

広域ネットワーク（WAN）では、リモートオフィス、データセンター、クラウドサービスが相互接続されています。停止すると、重要アプリケーションへのアクセス喪失、通信の途絶、生産性の低下につながります。こうした停止を避けるため、WAN は高可用性（HA）を前提に設計されることがほとんどです。冗長なハードウェアと上り回線、フェイルオーバー機構を置くと、1 つの部品が壊れてもすぐ別の部品が引き継ぎます。分散ネットワークで接続、信頼性、サービスの継続を保つうえで、この耐障害性が重要です。

Cloudflare One Appliance は、上り回線用の WAN ポートを 2 つ以上使えます。そのため、複数の ISP に接続して回線の耐障害性を確保できます。基本的な HA として、Cloudflare One Appliance 1 台に上り回線を 2 本使い、トラフィックを負荷分散する方法があります（下の図 2）。重要度の低いブランチ、小規模オフィス、同種の拠点向け、またはフル HA へ進む途中段階として使えます。

この構成では、プライマリ機器の障害時に冗長機器が引き継ぎ、トラフィックを途切れなくフェイルオーバーします。アプリケーション、データ、サービスへのアクセスを維持できます。単一障害点を減らし、ネットワークの耐障害性とサービスの信頼性を高め、生産性の維持にもつながります。

下の図 3 は、Cloudflare One Appliance がフル HA を取る構成です。選挙プロセスにより、1 台がアクティブ、もう 1 台がパッシブになります。これを実現するには、2 台の Connector を同じ Layer 2 ドメイン（VLAN など）の LAN スイッチへ接続し、ハートビートをやり取りします。アクティブ / パッシブでは、ある時点でトラフィックを転送するのはアクティブな Connector だけです。

各 Cloudflare One Appliance は、同じ 2 つの ISP にデュアル上り回線で接続し、WAN ポートごとに IPsec トンネルを自動作成します。そのため、各 ISP はオンサイトの Network Termination Unit（または CPE がある場合は CPE）で複数ポートに対応する必要があります。この HA 構成ではトンネルは合計 4 本（Connector あたり 2 本）です。アクティブ機器上の 2 本のトンネル間でトラフィックを負荷分散できます。アクティブな Connector、またはその IPsec トンネルが落ちると、もう一方の Connector が引き継いでトラフィックを転送し、自身が障害になるまでアクティブ役割を維持します（不要なフェイルオーバー遅延を避けるため、プリエンプションは使いません）。

この節では、Cloudflare One Appliance を、単なる CPE としてサイト間またはサイトから Internet への接続と保護のためにオンランプする、といった典型的な用途を超えて使う構成を説明します。

この構成の主な用途は、多くの組織が Cloud / SaaS アプリケーションの性能向上のためにローカル Internet breakout を必要とする一方、セルフホストアプリケーションやサイト間接続には、アーキテクチャの近代化を後回しにするまで、既存のプライベート MPLS を使い続ける、という状況です。その判断の背景は次のようなものです。

• MPLS 契約はまだ残っているが、満了後はすべての拠点を Internet 接続へ置き換える予定
• セルフホストアプリケーションに低遅延と合意済み SLA が必要で、MPLS と Internet のハイブリッド構成が要る

このハイブリッド構成では、MPLS Customer Edge ルーター（CE）、または LAN 内の別の L3 機器が、宛先に応じて異なるインタフェースへルーティングする必要があります。トラフィックの流れは次のとおりです。

1. ローカルネットワーク上の機器は、MPLS CE（または別のローカル L3 機器）をデフォルトゲートウェイにします
2. プライベートトラフィックは MPLS ネットワークへ送られます。たとえば MPLS CE は、MPLS ネットワークから BGP で受け取った RFC1918 レンジを使ってこの経路を知ります
3. LAN からの Internet トラフィックは Cloudflare One Appliance へ転送されます（MPLS CE / L3 ゲートウェイが Connector 向けに静的デフォルトルートを持ちます）

内部拠点とセルフホストアプリケーション向けのトラフィックは MPLS 経路を通り、クラウドおよび SaaS アプリケーション向けのトラフィックは、Cloudflare のセキュリティサービスで保護されたローカル Internet breakout 経路を通ります。

一部の構成では、secure web gateway などの Cloudflare セキュリティサービスで特定プロトコルだけを保護し、残りのトラフィックは既存のエッジ機器（ルーターまたはファイアウォール）経由にしたいことがあります。図 5 はその例です。

この例では、組織は Internet の Web トラフィック（HTTP/HTTPS）を Cloudflare で保護し、それ以外は既存ファイアウォール経由で出します。後者には、既存 VPN 向けのトラフィックや、サイトから出る非 Web トラフィック（オンプレミスファイアウォールで保護）が含まれます。この方法では、ローカル機器のポリシーベースルーティング（PBR）を活用できます。例は次のとおりです。

1. ローカル機器はオンプレミスファイアウォールをデフォルトゲートウェイにします
2. ファイアウォールは PBR で、適切なトラフィックを正しい宛先へ送ります
3. Web トラフィック（TCP 80/443）は Cloudflare One Appliance 経由で Cloudflare へ送られます
4. その他のトラフィックはオンプレミスファイアウォールから出ます

ローカルに PBR があり、ISP が組織へパブリック IP を少なくとも 2 つ提供していれば、Cloudflare One Appliance へ振り分ける方法はいくらでもあります。振り分け方は、各組織の環境とユースケースに依存します。

Cloudflare One Appliance が支えられるもう一つの高度な用途は、ローカルセグメンテーションと、特定のローカルネットワークの保護です。現在のアーキテクチャ、事業内容、セキュリティポリシー、コンプライアンス要件に応じて、サイトのエッジ機器より南側の任意の位置に設置し、より細かいネットワークセキュリティを提供できます。図 6 とその後の説明を参照してください。

この例では、Cloudflare One Appliance はオンプレミスファイアウォールとローカル Internet 接続を通して、Cloudflare への IPsec トンネルを作ります。Subnet A と B はどちらも Cloudflare One Appliance に接続しますが、互いに直接はつながりません。これにより、次のユースケースが可能になります。

• Internet セキュリティ: Segment 1 は Cloudflare のセキュリティポリシーに従い、ローカルファイアウォールのポリシーをバイパスします。
• サイト間接続: Segment 1 は、組織のポリシーに応じて、他拠点のローカルセグメント（または Site 2 のようなサイト全体）へ接続できます。

この例では、Cloudflare One Appliance による 2 種類のローカルネットワークセグメンテーションも示しています。

• セグメント内: 同じ Connector の LAN ポート間のトラフィックは、デフォルトで遮断されます。そのため Segment 1 の Subnet A と Subnet B は互いに通信できません。管理者は、IP アクセスリストに近い設定で、この通信を明示的に許可する必要があります。Connector の LAN ポート経由でローカルトラフィックをヘアピンさせると、Cloudflare プラットフォーム経由のトロンボーニング（IPsec/GRE トンネルで出て戻る経路）を避けられます。Internet 回線障害時に、それらのセグメント同士の接続が切れることを防げます。そのため、Internet アクセスを必ずしも必要としないローカルノード（プリンター、ファイルサーバー、NAS、各種 IoT 機器など）は、Internet 障害中も、別セグメントのローカルホストから到達し続けられます。
• セグメント間: Cloudflare One Appliance は WAN ポートでの受信トラフィックを許可しません。そのため Segment 1 と Segment 2 は互いに通信できません。

まとめると、Cloudflare One Appliance は Zero-Touch Provisioning（ZTP）機器です。組織は Cloudflare へ接続して高度なセキュリティと接続サービスを利用しつつ、運用コストを抑えられます。

• Cloudflare WAN - Cloud-delivered enterprise networking ↗
• Announcing the Cloudflare One Appliance: the easiest on-ramp to your next generation network ↗
• Cloudflare One Appliance の設定