Aruba EdgeConnect Enterprise

このチュートリアルでは、それぞれ異なるサブネットを持つ 2 つの拠点がある構成を例にします。

拠点は 2 つあり、それぞれサブネットが異なります。

• 東拠点は 10.3.0.0/16 ネットワークです。EdgeConnect が anycast GRE トンネルを終端します。
• 西拠点は 10.30.0.0/16 ネットワークです。EdgeConnect が anycast GRE トンネルを終端します。

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

次の例は、Orchestrator 上の east_branch のデプロイです。

Deployment の画面には、複数の 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 に組み込まれています。

このチュートリアルでは、それぞれ異なるサブネットを持つ 2 つの拠点がある構成を例にします。

中央拠点は 10.22.0.0/24 ネットワークです。EdgeConnect が anycast IPsec トンネルを終端します。

西拠点は 10.77.0.0/24 ネットワークです。EdgeConnect が anycast IPsec トンネルを終端します。

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

次の例は、Orchestrator 上の central_branch のデプロイです。

Deployment の画面には、複数の 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 に組み込まれています。

Cloudflare の トンネルヘルスチェック は、GRE パケットにカプセル化した ping 応答パケットです。送信元 IP はトンネル確立に使う EdgeConnect の WAN インターフェース、宛先 IP は Cloudflare のサーバーです。これらのパケットは、確立済みトンネル経由ではなく、WAN インターフェースから直接送る必要があります。

オーバーレイポリシーを作成する手順は次のとおりです。

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

2. GRE トンネルをバイパスする breakout Business Intent Overlay（BIO）を最初のポリシーとして作成し、いま作成したアプリケーションを一致条件に使います。

3. 追加のオーバーレイポリシーを少なくとも 1 つ定義し、GRE トンネル経由で Cloudflare へ送るトラフィックを指定します。

次の手順で作成するトンネルへトラフィックを送るサービス名は Cloudflare_GRE です。この例では Match Everything を使い、それ以外のトラフィック（プライベートな東西トラフィックと、Cloudflare の Secure Web Gateway 経由のインターネット向け南北トラフィックの両方）を確立済みトンネルへ送ります。

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

Cloudflare の トンネルヘルスチェック は、IPsec パケットにカプセル化した ping 応答パケットです。送信元 IP はトンネル確立に使う EdgeConnect の WAN インターフェース、宛先 IP は Cloudflare のサーバーです。これらのパケットは、確立済みトンネル経由ではなく、WAN インターフェースから直接送る必要があります。

オーバーレイポリシーを作成する手順は次のとおりです。

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

2. IPsec トンネルをバイパスする breakout Business Intent Overlay（BIO）を最初のポリシーとして作成し、いま作成したアプリケーションを一致条件に使います。

3. 追加のオーバーレイポリシーを少なくとも 1 つ定義し、IPsec トンネル経由で Cloudflare へ送るトラフィックを指定します。

次の手順で作成するトンネルへトラフィックを送るサービス名は Cloudflare_IPsec です。この例では Match Everything を使い、それ以外のトラフィック（プライベートな東西トラフィックと、Cloudflare の Secure Web Gateway 経由のインターネット向け南北トラフィックの両方）を確立済みトンネルへ送ります。

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

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

1. 前の手順 のオーバーレイポリシーで使ったサービスと、Cloudflare が割り当てたパブリック anycast IP を使い、EdgeConnect 上にトンネルを作成します。
2. CF GRE トンネルエンドポイントと共有したプライベート IP ペアと、新しく作成したトンネルエイリアス（この例では CF_GRE_east）に一致する passthrough トンネルを使い、Virtual Tunnel Interface（VTI）を作成します。

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

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

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

• X-Auth-Email: Cloudflare のメール ID
• X-Auth-Key: URL に表示されます（dash.cloudflare.com/<X-Auth-Key>/....）
• Account key: Cloudflare ダッシュボードの Global API token

1. 新しい IPsec トンネル作成をテストする

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"
    }
  ]
}'

2. 新しい IPsec トンネルを作成する

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"
    }
  ]
}'

{
	"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": []
}

3. トンネルの Pre Shared Key（PSK）を生成する

手順 2 の応答にあるトンネル ID を使います。この手順で生成した事前共有鍵は保存してください。Orchestrator でトンネルを設定するときに必要です。

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>"

{
	"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 です。

EdgeConnect アプライアンスで Virtual Tunnel Interface（VTI）を作成する

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

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

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

   この例では、west_branch のサブネット 10.30.0.0/24 向けに、EdgeConnect アプライアンスと Cloudflare のあいだで確立した GRE トンネル経由のルートを作成します。

EdgeConnect 上の中央拠点向け静的ルート

EdgeConnect 上の西拠点向け静的ルート

Secure Web Gateway を確認する

ローカルサブネットから Cloudflare の Secure Web Gateway 経由のトラフィックフローを確認するには、この例のように cURL を実行します。

リクエストが Gateway を通過したことは、Cf-Team 応答ヘッダーの有無、またはダッシュボードの Logs > Gateway > HTTP のログで確認できます。

東西トラフィックを確認する

東西トラフィックフローを確認するには、この例のように traceroute を実行します。

この例では、GCP East のクライアント（10.3.0.3）が、GCP West のクライアントのプライベート IP（10.30.0.4）へ 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 WAN 経由の東西トラフィックフローを確認できます。

Secure Web Gateway を確認する

ローカルサブネットから Cloudflare の Secure Web Gateway 経由のトラフィックフローを確認するには、この例のように cURL を実行します。

リクエストが Secure Web Gateway を通過したことは、Cf-Team 応答ヘッダーの有無、またはダッシュボードの Logs > Gateway > HTTP のログで確認できます。

東西トラフィックを確認する

東西トラフィックフローを確認するには、この例のように traceroute を実行します。

この例では、GCP Central のクライアント（10.22.0.9）が、GCP West のクライアントのプライベート IP（10.77.0.10）へ 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 WAN 経由の東西トラフィックフローを確認できます。