Вот потребность:
Подключите устройство Fortigate за статическим NAT 1:1 к Интернету через VPN-шлюз Google Cloud Platform (GCP).
Упрощенная диаграмма ASCII:
LOCAL_LAN ---- Fortigate ----- Оптоволоконный модем ---- Интернет ---- Шлюз GCP VPN ----- 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-адрес, чтобы туннель был поднят.
Что странно, так это то, что я определил в параметре локального идентификатора FortiGate Phase 1 общедоступный IP-адрес, и он правильно отправлен на шлюз GCP VPN.
Это событие подтверждено в журналах GCP, как показано ниже!
{
Идентификатор вставки: "5abgbbg2313tdw"
метки: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
получитьTimestamp: "2021-09-01T21:14:46.610751733Z"
ресурс: {2}
серьезность: "ОТЛАДКА"
**textPayload: "IDir '201.110.XXX.240' не соответствует '201.110.XXX.240'"**
отметка времени: "2021-09-01T21:14:46.592461252Z"
}
Но проблема в том, что Фаза 2 никогда не согласовывается на стороне GCP, и туннель удаляется.
В целях документации вот вывод журнала отладки Fortigate ike:
ike 0:gcp00-0:10752: обработано НАЧАЛЬНЫЙ КОНТАКТ
ike 0:gcp00-0: автоматическое согласование расписания
ike 0:gcp00-0:10752: нет ожидающих переговоров в Quick-Mode
[...]
ike 0:gcp00-0:10751: recv ISAKMP SA удалить 14cb5d60541aaaaa/d405bbbbf6d06acb
Затем отключение ISAKMP сопоставляется с журналами GCP:
{
Идентификатор вставки: "5abgbbg2313tdx"
метки: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
получитьTimestamp: "2021-09-01T21:14:46.610751733Z"
ресурс: {2}
серьезность: "ВНИМАНИЕ"
textPayload: "удаление IKE_SA vpn_201.110.XXX.240[2662] между 35.242.XXX.165[35.242.XXX.165]...201.110.XXX.240[%any]"
отметка времени: "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-адресом IP-адреса, определенного локальным GW. Поскольку этот IP-адрес не является действительным для модема, пакет никогда не отправляется.
Важно отметить, что я сделал 2 туннеля, один на ike v1, а другой на ike v2 для проверки. Из-за этого IP-адреса в следующем туннеле отличаются:
Вот журналы доказательств из консоли GCP:
{
Идентификатор вставки: "134hqnjg23gnfib"
метки: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
ReceiveTimestamp: "2021-09-01T21:52:39.566968571Z"
ресурс: {2}
серьезность: "ОТЛАДКА"
textPayload: "ищем одноранговые конфигурации, соответствующие 35.220.XXX.31[%any]...201.110.XXX.240[201.110.XXX.240]"
отметка времени: "2021-09-01T21:52:39.552310603Z"
}
{
InsertId: "134hqnjg23gnfia"
метки: {1}
logName: "projects/my-project-xxxxxx/logs/cloud.googleapis.com%2Fipsec_events"
ReceiveTimestamp: "2021-09-01T21:52:39.566968571Z"
ресурс: {2}
серьезность: "ОТЛАДКА"
textPayload: "проанализирован запрос IKE_AUTH 1 [IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr]"
отметка времени: "2021-09-01T21:52:39.552287263Z"
}
ВОПРОСЫ
Кто-нибудь знает, почему на ike v1, даже если IP-адреса правильные, VPN-шлюз GCP отказывается настраивать туннель (фаза 2)?
Кто-нибудь знает способ установить IKE v2 IDi или IDr в определении фазы 1 на Fortigate?
Кто-нибудь видел эту проблему раньше? Какие-либо предложения?
