☰

ВОПРОСЫ

tag-icon • tag-icon vpn google-cloud-platform fortigate ikev2 ikev1
ВОПРОСЫ

Вот что нужно:

Подключите устройство Fortigate за статическим 1:1 NAT к Интернету через VPN-шлюз Google Cloud Platform (GCP).

Упрощенная схема ASCII:

LOCAL_LAN ---- Fortigate ----- Fiber modem ---- Internet ---- GCP VPN Gateway ----- GCP_VPC

Волоконно-оптический модем выполняет NAT 1:1 для Fortigate, на этом модеме активен режим DMZ.

Я следовал нескольким инструкциям:

Как создать VPN для внешнего шлюза на GCP — я использую вариант №3, поскольку у меня есть только один публичный IP-адрес на Fortigate https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4

Взаимодействие с Fortinet - у меня нет 2 статических IP-адресов, по одному на интерфейс Fortigate https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate

Результаты с IKE v1:

Фаза 1 согласована, проблема в том, что Фаза 2 никогда не поднимается. Руководство по устранению неполадок в Google:

https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting

Говорит: для создания туннеля необходимо указать идентификатор однорангового узла как публичный IP-адрес.

Странно то, что я определил в параметре localid FortiGate Phase 1 публичный IP-адрес, и он корректно отправляется на шлюз GCP VPN.

Это событие подтверждено в журналах GCP, как показано ниже!

{
insertId: "5abgbbg2313tdw"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "DEBUG"
**textPayload: "IDir '201.110.XXX.240' does not match to '201.110.XXX.240'"**
timestamp: "2021-09-01T21:14:46.592461252Z"
}

Но проблема в том, что Фаза 2 никогда не согласовывается на стороне GCP, и туннель удаляется. Для целей документирования вот вывод в журнале отладки ike Fortigate:

ike 0:gcp00-0:10752: processed INITIAL-CONTACT
ike 0:gcp00-0: schedule auto-negotiate
ike 0:gcp00-0:10752: no pending Quick-Mode negotiations
[...]
ike 0:gcp00-0:10751: recv ISAKMP SA delete 14cb5d60541aaaaa/d405bbbbf6d06acb

Затем отключение ISAKMP сопоставляется с журналами GCP:

{
insertId: "5abgbbg2313tdx"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "NOTICE"
textPayload: "deleting IKE_SA vpn_201.110.XXX.240[2662] between 35.242.XXX.165[35.242.XXX.165]...201.110.XXX.240[%any]"
timestamp: "2021-09-01T21:14:46.592502955Z"
}

Переговоры остаются в этом состоянии в бесконечном цикле.

Тесты с IKE v2.

Я также попробовал на IKE v2, результаты довольно похожи. Туннель никогда не поднимается, единственное отличие в том, что на стороне FGT я не могу отправить публичный IP на шлюз GCP VPN. Я пробовал изменять параметры localid, local-gw и eap на IKEv2, но безуспешно. Журнал с точки зрения GPC - AUTHENTICATION_FAILED. Аутентификация PSK завершена, но поскольку пиры никогда не идентифицируются должным образом, она никогда не поднимается. Если я определяю параметр local-gw на FGT как публичный IP модема перед Fortigate, само согласование вообще не может быть завершено. Причина: при установке этого параметра на интерфейсе FGT phase1-interface gw Fortigate будет отправлять пакеты с IP-адресом SOURCE IP, определенным local-gw. Поскольку этот IP не является допустимым для модема, пакет никогда не отправляется.

Важно отметить, что я сделал 2 туннеля, один на ike v1 и другой на ike v2 для тестирования. Из-за этого IP-адреса в следующем туннеле отличаются: Вот логи доказательств из консоли GCP:

{
insertId: "134hqnjg23gnfib"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "looking for peer configs matching 35.220.XXX.31[%any]...201.110.XXX.240[201.110.XXX.240]"
timestamp: "2021-09-01T21:52:39.552310603Z"
}

{
insertId: "134hqnjg23gnfia"
labels: {1}
logName: "projects/my-project-xxxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]"
timestamp: "2021-09-01T21:52:39.552287263Z"
}

ВОПРОСЫ

Кто-нибудь знает, почему на Ike v1, даже если IP-адреса правильные, шлюз GCP VPN отказывается настраивать туннель (фаза 2)?

Кто-нибудь знает, как установить IKE v2 IDi или IDr в определении фазы 1 на Fortigate?

Кто-нибудь сталкивался с этой проблемой раньше? Есть предложения?

решение1

Ну, отвечая на свой собственный вопрос. Вот он:

В FortiOS 7.0.1, когда ForiGate находится за устройством NAT, выполняющим NAT 1:1, не существует документированного или явного способа определить IDi или IDr определения первой фазы на FortiGate таким образом, чтобы GCP принял его для настройки туннеля.

Единственный способ настроить VPN-туннель между FGT и шлюзом GCP VPN — это назначить FortiGate публичный IP-адрес напрямую интерфейсу, подключающемуся к GCP VPN.

Таким образом, вы можете определить IP-адрес «локального gw» для интерфейса, публичный IP-адрес в определении FGT Phase 1. На этом согласование туннеля завершается, и VPN работает.

Подводя итог, НЕ ПЫТАЙТЕСЬ настроить туннель FGT-GCP VPN, когда FGT находится за устройством NAT. Это вообще не сработает!

Тестирование проводилось с использованием FortiOS 7.0.1, подключенного к резервным шлюзам GCP VPN с одним публичным IP-адресом на FortiGate и ДВУМЯ IP-адресами на стороне GCP VPN с использованием IKE v2. IKE v1 не тестировался.

Связанный контент