Вот необходимость:

Подключите устройство Fortigate за статическим NAT 1:1 к Интернету через 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-адрес на Fortigatehttps://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4

Совместимость с Fortinet. У меня нет двух статических IP-адресов, по одному на каждый интерфейс Fortigatehttps://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

Говорит: надо определить Peer ID как публичный IP, чтобы туннель поднялся.

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

Это событие подтверждено в журналах 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, и туннель удаляется. Для целей документации вот вывод журнала отладки Fortigate ike:

      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, само согласование вообще не может быть завершено. Причина: при установке этого параметра на интерфейсе gw фазы 1 FGT Fortigate будет отправлять пакеты с ИСТОЧНЫМ IP-адресом, определенным локальным 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?

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