コンテンツにスキップ

Aruba EdgeConnect Enterprise

Cloudflareは、ArubaのEdgeConnect SD-WANソリューションと提携し、ユーザーに統合ソリューションを提供します。EdgeConnectアプライアンスは、支店や小売店舗に関連するサブネットを管理します。Anycastトンネルは、EdgeConnectアプライアンスとCloudflareの間に設定され、トラフィックを安全にルーティングします。

このチュートリアルでは、EdgeConnectデバイスを東西(支店間)および南北(インターネット向け)のユースケースに設定する方法を説明します。

前提条件

EdgeConnectとCloudflareの間に接続を設定する前に、次のものを用意する必要があります。

  • Magic WANおよびSecure Web Gatewayを含む契約。
  • 2つのCloudflareエンドポイント(anycast IPアドレス)を受け取った。
  • 各トンネルで使用するプライベート静的/31 IPペアを決定した。/31ペアは、各EdgeConnectアプライアンスの背後で使用されるプライベートサブネットとは異なるプライベートサブネットから取得する必要があります。
  • このチュートリアルで使用されるEdgeConnectデバイスは、v9.0であること。

例のシナリオ

GREトンネルの設定

このチュートリアルの目的のために、統合は異なるサブネットを持つ2つの支店のシナリオを参照します。

2つの支店があり、それぞれ異なるサブネットを持っています。

  • 東支店は、anycast GREトンネルを終端するEdgeConnectを持つ10.3.0.0/16ネットワークを持っています。
  • 西支店は、anycast GREトンネルを終端するEdgeConnectを持つ10.30.0.0/16ネットワークを持っています。

支店サブネット情報の表

以下は、Orchestrator上のeast_branchデプロイメントの例です。

GCP Eastデプロイメント設定

デプロイメントのスクリーンショットには、いくつかの異なるIPアドレスとインターフェースが表示されています。左から右へ:

  • Next Hop 10.3.0.1 - この例ではGoogle Cloudを使用しています。このIPはサブネットのデフォルトゲートウェイIPを定義し、GCPに組み込まれています。
  • IP/Mask (LAN) 10.3.0.2/24 - これはEdgeConnectアプライアンスのLAN0インターフェースIPを定義します。
  • IP/Mask (WAN) 10.2.0.2/24 - これはEdgeConnectアプライアンスのWAN0インターフェースIPを定義します。
  • Next Hop 10.2.0.1 - この例ではGoogle Cloudを使用しています。このIPはサブネットのデフォルトゲートウェイIPを定義し、GCPに組み込まれています。

IPsecトンネルの設定

このチュートリアルの目的のために、統合は異なるサブネットを持つ2つの支店のシナリオを参照します。

中央支店は、anycast IPsecトンネルを終端するEdgeConnectを持つ10.22.0.0/24ネットワークを持っています。

西支店は、anycast IPsecトンネルを終端するEdgeConnectを持つ10.77.0.0/24ネットワークを持っています。

東西支店のIPsecトンネル値

以下は、Orchestrator上のcentral_branchデプロイメントの例です。

Orchestrator内の中央支店設定の値

デプロイメントのスクリーンショットには、いくつかの異なるIPアドレスとインターフェースが表示されています。左から右へ:

  • Next Hop 10.22.0.1 - この例ではGoogle Cloudを使用しています。このIPはサブネットのデフォルトゲートウェイIPを定義し、GCPに組み込まれています。
  • IP/Mask (LAN) 10.22.0.2/24 - これはEdgeConnectアプライアンスのLAN0インターフェースIPを定義します。
  • IP/Mask (WAN) 10.32.0.2/24 - これはEdgeConnectアプライアンスのWAN0インターフェースIPを定義します。
  • Next Hop 10.32.0.1 - この例ではGoogle Cloudを使用しています。このIPはサブネットのデフォルトゲートウェイIPを定義し、GCPに組み込まれています。

1. Orchestratorで共通サイトを定義する

Cloudflareを使用するすべてのEdgeConnectデバイスについて、デバイスを同じサイトに配置するように変更します。これにより、使用中のWANインターフェースに同じラベルを持つEdgeConnectデバイス間の自動IPsecトンネルの作成が無効になります。

このステップは、Cloudflareが東西トラフィックルーティングに使用される場合にのみ必要です。

2. オーバーレイポリシーを設定する

Aruba OrchestratorのBusiness Intent Overlaysを使用して、アプリケーショントラフィックをCloudflareに自動的に識別し、誘導する直感的なポリシーを作成します。この例では、2つのBusiness Intent Overlay (BIO)ポリシーが作成されます。

GREトンネルの設定

Cloudflareのtunnel health checksは、GREパケットにカプセル化されたping応答パケットです。ソースIPはトンネルを確立するために使用されるEdgeconnect WANインターフェースで、宛先IPはCloudflareサーバーです。これらのパケットは、確立されたトンネルを介してではなく、WANインターフェースから直接送信する必要があります。

オーバーレイポリシーを作成するには:

  1. すべてのCloudflareのパブリックIPとICMPパケットの組み合わせである複合アプリケーションを作成します。

IP値を持つアプリケーション定義画面

  1. GREトンネルをバイパスするためのブレークアウトBusiness Intent Overlay (BIO)を最初のポリシーとして作成し、この新しく作成したアプリケーションをマッチ基準として使用します。

  2. CloudflareにGREトンネルを介して送信したいトラフィックと少なくとも1つの追加のオーバーレイポリシーを定義します。

次のステップで作成されたトンネルを介してトラフィックを送信するために使用されるサービス名はCloudflare_GREです。この例では、すべての他のトラフィックを確立されたトンネルを介して送信するためにMatch Everythingを使用します(プライベートな東西トラフィックとCloudflareのSecure Web Gatewayを介したインターネット向け南北トラフィックの両方)。

ブレークアウトとCFオーバーレイを持つBusiness Intent Overlay画面

IPsecトンネルの設定

Cloudflareのtunnel health checksは、IPsecパケットにカプセル化されたping応答パケットです。ソースIPはトンネルを確立するために使用されるEdgeconnect WANインターフェースで、宛先IPはCloudflareサーバーです。これらのパケットは、確立されたトンネルを介してではなく、WANインターフェースから直接送信する必要があります。

オーバーレイポリシーを作成するには:

  1. すべてのCloudflareのパブリックIPとICMPパケットの組み合わせである複合アプリケーションを作成します。

IP値を持つアプリケーション定義画面

  1. IPsecトンネルをバイパスするためのブレークアウトBusiness Intent Overlay (BIO)を最初のポリシーとして作成し、この新しく作成したアプリケーションをマッチ基準として使用します。

  2. CloudflareにIPsecトンネルを介して送信したいトラフィックと少なくとも1つの追加のオーバーレイポリシーを定義します。

次のステップで作成されたトンネルを介してトラフィックを送信するために使用されるサービス名はCloudflare_IPsecです。この例では、すべての他のトラフィックを確立されたトンネルを介して送信するためにMatch Everythingを使用します(プライベートな東西トラフィックとCloudflareのSecure Web Gatewayを介したインターネット向け南北トラフィックの両方)。

IPsec用のブレークアウトとCFオーバーレイを持つBusiness Intent Overlay画面

3. CloudflareとEdgeConnectでトンネルを作成する

GREトンネルの設定

GCP、Aruba Orchestrator、Cloudflare製品の図

  1. Cloudflareが割り当てたパブリックanycast IPと、前のステップでのオーバーレイポリシーで使用されるサービスを使用して、EdgeConnectでトンネルを作成します。
  2. CF GREトンネルエンドポイントと共有されたプライベートIPペアを使用して、パススルートンネルに一致する仮想トンネルインターフェース(VTI)を作成します。この新しく作成されたトンネルエイリアス(この例ではCF_GRE_east)に一致させます。

パススルートンネルの変更画面

仮想トンネルインターフェースの編集画面

  1. EdgeConnectアプライアンスのパブリックIPとアプライアンスと共有されたプライベートIPペア/31を使用して、CloudflareダッシュボードでGREトンネルを定義します。

各支店のGREトンネル情報

IPsecトンネルの設定

GCP、Aruba Orchestrator、Cloudflare製品の図(IPsecトンネル用)

IPsecトンネルの作成に関する追加情報は、IPsecトンネルのAPIドキュメントを参照してください。

  • X-Auth-Email: あなたのCloudflareメールID
  • X-Auth-Key: URLに表示される(dash.cloudflare.com/<X-Auth-Key>/....
  • Account key: CloudflareダッシュボードのグローバルAPIトークン
  1. 新しいIPsecトンネルの作成をテストします。
Request
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels?validate_only=true" \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
"ipsec_tunnels": [
{
"name": "EdgeConnect_IPSEC_1",
"customer_endpoint": "35.188.72.56",
"cloudflare_endpoint": "172.64.241.205",
"interface_address": "192.168.10.11/31",
"description": "Tunnel for EdgeConnect - GCP Central"
}
]
}'
  1. 新しいIPsecトンネルを作成します。
Request
curl https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
"ipsec_tunnels": [
{
"name": "EdgeConnect_IPSEC_1",
"customer_endpoint": "35.188.72.56",
"cloudflare_endpoint": "172.64.241.205",
"interface_address": "192.168.10.11/31",
"description": "Tunnel for EdgeConnect - GCP Central"
}
]
}'
Response
{
"result": {
"ipsec_tunnels": [
{
"id": "tunnel_id",
"interface_address": "192.168.10.11/31",
"created_on": "2022-04-14T19:57:43.938376Z",
"modified_on": "2022-04-14T19:57:43.938376Z",
"name": "EdgeConnect_IPSEC_1",
"cloudflare_endpoint": "172.64.241.205",
"customer_endpoint": "35.188.72.56",
"description": "Tunnel for EdgeConnect - GCP Central",
"health_check": {
"enabled": true,
"target": "35.188.72.56",
"type": "reply"
}
}
]
},
"success": true,
"errors": [],
"messages": []
}
  1. トンネルのための事前共有キー(PSK)を生成します。

ステップ2の応答からトンネルIDを使用します。このステップで生成された事前共有キーを保存してください。Orchestratorでトンネルを設定するために必要になります。

Request
curl --request POST \
"https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id}/psk_generate?validate_only=true" \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>"
Response
{
"result": {
"ipsec_id": "<ipsec_id>",
"ipsec_tunnel_id": "<tunnel_id>",
"psk": "XXXXXXXXXXXXXXXXX",
"psk_metadata": {
"last_generated_on": "2022-04-14T20:05:29.756514071Z"
}
},
"success": true,
"errors": [],
"messages": []
}

EdgeConnectでIPsecトンネルを作成する

Business Intent Overlayポリシーが定義された後にトンネルを作成できます。オーバーレイポリシーを設定するで作成された正しいポリシーまたはサービスを使用します。ローカルIPはEdgeConnectデバイスのローカルWANインターフェースで、リモートIPはトンネルエンドポイントとして割り当てられたCloudflareのパブリックIPです。

一般的な値を持つパススルートンネルの変更ダイアログ

IKE値を持つパススルートンネルの変更ダイアログ

IPsec値を持つパススルートンネルの変更ダイアログ

EdgeConnectアプライアンスで仮想トンネルインターフェース(VTI)を作成する

VTIインターフェースの編集値

4. CloudflareとEdgeConnectで静的ルートを作成する

GREトンネルの設定

  1. EdgeConnectアプライアンスに接続されたLANサブネットのために、Cloudflareダッシュボードで静的ルートを定義します。EdgeConnectトンネルエンドポイントのプライベートIPペアを使用します。

    以下の例では、east_branch EdgeConnectアプライアンスに接続されたサブネット10.3.0.0/16へのトラフィックは、次のホップが10.40.8.10です。

各支店の静的ルート情報

  1. Orchestratorで静的ルートを定義し、Cloudflareがサイト間でトラフィックをルーティングできるようにします。

    以下の例では、west_branchのサブネット10.30.0.0/24が、EdgeConnectアプライアンスとCloudflareの間に確立されたGREトンネルを介してルーティングされるようにルートを作成します。

各支店の静的ルート情報

IPsecトンネルの設定

Cloudflareダッシュボードからの静的ルート値

EdgeConnectの中央支店向け静的ルート

EdgeConnectの中央支店向け静的ルート値

EdgeConnectの西支店向け静的ルート

EdgeConnectの西支店向け静的ルート値

5. トラフィックフローの検証

GREトンネル構成

セキュアウェブゲートウェイの検証

ローカルサブネットからCloudflareのセキュアウェブゲートウェイを通じてトラフィックフローを検証するには、以下の例のようにcurlを実行します。

セキュアウェブゲートウェイの検証用curl例

Cf-Teamレスポンスヘッダーの存在を確認することで、リクエストがゲートウェイを通過したことを検証できます。また、ダッシュボードのLogs > Gateway > HTTPのログを確認することでも検証できます。

セキュアウェブゲートウェイの検証用ダッシュボード例

東西トラフィックの検証

東西トラフィックフローを検証するには、以下の例のようにtracerouteを実行します。

東西トラフィックの検証用traceroute例

この例では、GCP Eastのクライアント(10.3.0.3)がGCP Westのクライアント(10.30.0.4)のプライベートIPにpingを送信できることを示しています。

tracerouteは、クライアント(10.3.0.3)からの経路を示しています。
→ EdgeConnectのGCP East lan0 IP(10.3.0.2)へ
→ CloudflareプライベートGREエンドポイントIP(10.4.8.11)へ
→ West EdgeConnectのGCP West lan0 IP(10.30.0.3)へ
→ GCP Westクライアント(10.30.0.4)へ。

これにより、Cloudflare Magic WANを通る東西トラフィックフローが検証されます。

IPsecトンネル構成

セキュアウェブゲートウェイの検証

ローカルサブネットからCloudflareのセキュアウェブゲートウェイを通じてトラフィックフローを検証するには、以下の例のようにcURLを実行します。

トラフィック検証用cURL例

Cf-Teamレスポンスヘッダーの存在を確認することで、リクエストがセキュアウェブゲートウェイを通過したことを検証できます。また、ダッシュボードのLogs > Gateway > HTTPのログを確認することでも検証できます。

セキュアウェブゲートウェイの検証用ダッシュボード例

東西トラフィックの検証

東西トラフィックフローを検証するには、以下の例のようにtracerouteを実行します。

IPsec検証用traceroute例

この例では、GCP Centralのクライアント(10.22.0.9)がGCP Westのクライアント(10.77.0.10)のプライベートIPにpingを送信できることを示しています。

tracerouteは、クライアント(10.22.0.9)からの経路を示しています。
→ EdgeConnectのGCP Central lan0 IP(10.22.0.2)へ
→ CloudflareプライベートIPsecエンドポイントIP(192.168.10.11)へ
→ GCP West EdgeConnectプライベートIPsecエンドポイントIP(192.168.15.10)へ
→ GCP Westクライアント(10.77.0.10)へ。

これにより、Cloudflare Magic WANを通る東西トラフィックフローが検証されます。

6. Cloudflareポリシー

この時点で、GREまたはIPsecトンネルはEdgeConnectアプライアンスからCloudflareのグローバルネットワークに接続されており、トラフィックはEdgeConnectビジネスインテントオーバーレイを使用してトンネルを経由してルーティングされるようにスコープされています。

トラフィックのフィルタリングを開始し、分析を収集するには、Magic Firewallドキュメントを参照して、東西の支店間トラフィックのフィルタを作成する方法を学び、セキュアウェブゲートウェイドキュメントを参照して、ローカルプライベートサブネットからCloudflare Gatewayを通じてインターネットにトラフィックを送信する場合のゲートウェイポリシーの構成方法を学んでください。