Aruba EdgeConnect Enterprise

В рамках этого руководства интеграция рассматривается на примере сценария с двумя филиалами, у каждого из которых своя подсеть.

Есть 2 филиала, у каждого свои отдельные подсети.

• В восточном филиале есть 10.3.0.0/16 сеть с EdgeConnect, завершающим anycast-туннель GRE.
• У западного филиала есть 10.30.0.0/16 сеть с EdgeConnect, завершающим anycast-туннель GRE.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

В следующем примере демонстрируется east_branch развертывание в Orchestrator.

Снимок экрана Deployment показывает несколько разных IP-адресов и интерфейсов. Слева направо:

• Next Hop 10.3.0.1: В этом примере используется Google Cloud. Этот IP-адрес задаёт IP-адрес шлюза по умолчанию для подсети и встроен в GCP.
• IP/Mask (LAN) 10.3.0.2/24: Задаёт IP-адрес интерфейса LAN0 устройства EdgeConnect.
• IP/Mask (WAN) 10.2.0.2/24: Задаёт IP-адрес интерфейса WAN0 устройства EdgeConnect.
• Next Hop 10.2.0.1: В этом примере используется Google Cloud. Этот IP-адрес задаёт IP-адрес шлюза по умолчанию для подсети и встроен в GCP.

В рамках этого руководства интеграция рассматривается на примере сценария с двумя филиалами, у каждого из которых своя подсеть.

Центральный офис филиала имеет 10.22.0.0/24 сеть с EdgeConnect, завершающим anycast-туннель IPsec.

У западного филиала есть 10.77.0.0/24 сеть с EdgeConnect, завершающим anycast-туннель IPsec.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

В следующем примере демонстрируется central_branch развертывание в Orchestrator.

Снимок экрана Deployment показывает несколько разных IP-адресов и интерфейсов. Слева направо:

• Next Hop 10.22.0.1: В этом примере используется Google Cloud. Этот IP-адрес задаёт IP-адрес шлюза по умолчанию для подсети и встроен в GCP.
• IP/Mask (LAN) 10.22.0.2/24: Задаёт IP-адрес интерфейса LAN0 устройства EdgeConnect.
• IP/Mask (WAN) 10.32.0.2/24: Задаёт IP-адрес интерфейса WAN0 устройства EdgeConnect.
• Next Hop 10.32.0.1: В этом примере используется Google Cloud. Этот IP-адрес задаёт IP-адрес шлюза по умолчанию для подсети и встроен в GCP.

Cloudflare проверки работоспособности туннеля это пакеты ответа ping, инкапсулированные в пакеты GRE. В качестве исходного IP-адреса выступает WAN-интерфейс EdgeConnect, используемый для установления туннеля, а адресом назначения являются серверы Cloudflare. Эти пакеты необходимо отправлять напрямую с WAN-интерфейса, а не через установленные туннели.

Чтобы создать оверлейную политику:

1. Создайте составное приложение, представляющее собой комбинацию всех публичные IP-адреса Cloudflare ↗ и пакеты ICMP.

2. Создайте breakout Business Intent Overlay (BIO), чтобы обойти туннель GRE в качестве первой политики, и используйте это новое приложение в качестве критерия соответствия.

3. Определите хотя бы одну дополнительную оверлейную политику и трафик, который нужно отправлять в Cloudflare через туннели GRE.

Для отправки трафика через туннель, который будет создан на следующем шаге, используется имя службы Cloudflare_GRE. В примере используется Совпадение со всем чтобы направлять весь остальной трафик через установленный туннель (как частный east-west-трафик, так и исходящий в интернет north-south-трафик через Secure Web Gateway от Cloudflare).

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

Cloudflare проверки работоспособности туннеля это пакеты ответа ping, инкапсулированные в пакеты IPsec. В качестве исходного IP-адреса выступает WAN-интерфейс EdgeConnect, используемый для установления туннеля, а адресом назначения являются серверы Cloudflare. Эти пакеты необходимо отправлять напрямую с WAN-интерфейса, а не через установленные туннели.

Чтобы создать оверлейную политику:

1. Создайте составное приложение, представляющее собой комбинацию всех публичные IP-адреса Cloudflare ↗ и пакеты ICMP.

2. Создайте breakout Business Intent Overlay (BIO), чтобы обойти туннель IPsec в качестве первой политики, и используйте это новое приложение в качестве критерия соответствия.

3. Определите хотя бы одну дополнительную оверлейную политику и трафик, который нужно отправлять в Cloudflare через туннели IPsec.

Для отправки трафика через туннель, который будет создан на следующем шаге, используется имя службы Cloudflare_IPsec. В примере используется Совпадение со всем чтобы направлять весь остальной трафик через установленный туннель (как частный east-west-трафик, так и исходящий в интернет north-south-трафик через Secure Web Gateway от Cloudflare).

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

1. Создайте туннель на EdgeConnect, используя публичный anycast IP-адрес, назначенный Cloudflare, и службу, используемую в политике overlay в предыдущий шаг.
2. Создайте Virtual Tunnel Interface (VTI), используя пару частных IP-адресов, общую с конечной точкой туннеля CF GRE, и passthrough-туннель, чтобы он соответствовал псевдониму вновь созданного туннеля (CF_GRE_east в нашем примере).

3. Определите GRE-туннель в панели управления Cloudflare, используя публичный IP-адрес устройства EdgeConnect и пару приватных IP-адресов /31, общую с этим устройством.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

Дополнительную информацию о создании туннелей IPsec см. в Документация API для туннелей IPsec.

• X-Auth-Email: ваш Cloudflare email ID
• X-Auth-Key: Отображается в URL (dash.cloudflare.com/<X-Auth-Key>/....)
• Account key: Глобальный API-токен в панели управления Cloudflare

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. Создать предварительный общий ключ (PSK) для туннеля

Используйте ID туннеля из ответа, полученного на шаге 2. Сохраните предварительный общий ключ (PSK), сгенерированный на этом шаге: он понадобится вам для настройки туннелей на 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": []
}

Создать туннель IPsec на EdgeConnect

Вы можете создать туннель после того, как будут определены политики Business Intent Overlay. Используйте политику или службу, созданную в настроить оверлейную политику. Локальным IP-адресом является локальный интерфейс WAN устройства EdgeConnect, а удалённым IP-адресом является публичный IP-адрес Cloudflare, назначенный в качестве конечной точки туннеля.

Создайте Virtual Tunnel Interface (VTI) на EdgeConnect appliance

1. Определите статические маршруты в панели управления Cloudflare для подсетей LAN, подключённых к устройству EdgeConnect. Используйте пару приватных IP-адресов для конечной точки туннеля EdgeConnect.

   В этом примере трафик к подсети 10.3.0.0/16 прикреплённая к east_branch Устройство EdgeConnect имеет next hop, равный 10.40.8.10.

2. Определите статические маршруты в Orchestrator, чтобы Cloudflare мог направлять трафик между сайтами.

   В этом примере создаётся маршрут для подсети 10.30.0.0/24 на west_branch для маршрутизации через установленный туннель GRE между устройством EdgeConnect и Cloudflare.

Статические маршруты для центрального филиала на EdgeConnect

Статические маршруты для западного филиала на EdgeConnect

Проверить Secure Web Gateway

Чтобы проверить прохождение трафика из локальной подсети через Secure Web Gateway Cloudflare, выполните запрос cURL, как показано в этом примере.

Убедиться, что запрос прошёл через Gateway, можно по наличию Cf-Team заголовок ответа, либо по журналам в панели управления в разделе Журналы > Gateway > HTTP.

Проверить east-west-трафик

Чтобы проверить трафик east-west, выполните traceroute, как показано в примере.

В примере показан клиент в GCP East (10.3.0.3), который может пинговать приватный IP-адрес клиента в GCP West (10.30.0.4).

Трассировка показывает путь от клиента (10.3.0.3) чтобы:

• IP-адрес lan0 GCP East на EdgeConnect (10.3.0.2)
• IP-адрес частной конечной точки GRE Cloudflare (10.4.8.11)
• IP-адрес lan0 GCP West на West EdgeConnect (10.30.0.3)
• клиент GCP West (10.30.0.4)

Это позволяет проверить поток east-west-трафика через Cloudflare WAN.

Проверить Secure Web Gateway

Чтобы проверить прохождение трафика из локальной подсети через Secure Web Gateway Cloudflare, выполните запрос cURL, как показано в этом примере.

Убедиться, что запрос прошёл через Secure Web Gateway, можно по наличию Cf-Team заголовок ответа либо по журналам в панели управления в разделе Журналы > Gateway > HTTP.

Проверить east-west-трафик

Чтобы проверить трафик east-west, выполните traceroute, как показано в примере.

В примере показан клиент в GCP Central (10.22.0.9), который может пинговать приватный IP-адрес клиента в GCP West (10.77.0.10).

Трассировка показывает путь от клиента (10.22.0.9) чтобы:

• IP-адрес lan0 GCP Central на EdgeConnect (10.22.0.2)
• IP-адрес частной конечной точки IPsec Cloudflare (192.168.10.11)
• IP-адрес частной конечной точки IPsec EdgeConnect GCP West (192.168.15.10)
• клиент GCP West (10.77.0.10)

Это позволяет проверить поток east-west-трафика через Cloudflare WAN.