Google Cloud Classic VPN периодически отключается

Пару недель назад мы создали классическую VPN Google Cloud и создали туннель с другой локальной сетью, соединение было установлено успешно, и мы можем получить доступ к их приложениям, но через пару часов VPN начал периодически отключаться. я заметилestablishing IKE_SA failed, peer not respondingошибка в логах.

Когда VPN отключается, состояние VPN-туннеля иногда былоNO INCOMING PACKETSи иногдаFIRST HANDSHAKE. Я не знаю, что происходит.

Детали конфигурации VPN:

  1. Область, край:us-east1
  2. Тип маршрутизации:Policy-based
  3. Версия ИКЕ:IKEv2

Журналы:

      1.  creating acquire job for policy with reqid {1}
2.  initiating IKE_SA vpn_BB.BBB.BBB.BBB[21328] to BB.BBB.BBB.BBB
3.  generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
4.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
5.  retransmit 1 of request with message ID 0 
6.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
7.  retransmit 2 of request with message ID 0
8.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
9.  creating acquire job for policy with reqid {1}
10. ignoring acquire, connection attempt pending
11. retransmit 3 of request with message ID 0
12. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
13. retransmit 4 of request with message ID 0 
14. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
15. retransmit 5 of request with message ID 0 
16. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
17. creating acquire job for policy with reqid {1}
18. ignoring acquire, connection attempt pending
19. giving up after 5 retransmits
20. establishing IKE_SA failed, peer not responding

Может кто-нибудь объяснить, что происходит?

Пожалуйста, проверьте последние журналы моего GCP VPN.

      1.  peer didn't accept DH group MODP_2048, it requested MODP_1024
2.  remote host is behind NAT
3.  authentication of 'AA.AAA.AAA.AAA' (myself) with pre-shared key
4.  establishing CHILD_SA vpn_ BB.BBB.BBB.BBB
5.  generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(EAP_ONLY) ]
6.  parsed IKE_AUTH response 1 [ IDr AUTH N(CRASH_DET) SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) N(ADD_TS_POSS) ]
7.  authentication of ' BB.BBB.BBB.BBB' with pre-shared key successful
8.  IKE_SA vpn_ BB.BBB.BBB.BBB [21588] established between AA.AAA.AAA.AAA [AA.AAA.AAA.AAA]... BB.BBB.BBB.BBB [BB.BBB.BBB.BBB]
9.  scheduling rekeying in 35937s
10. maximum IKE_SA lifetime 36537s
11. received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
12. Remote traffic selectors narrowed for Child SA: vpn_ BB.BBB.BBB.BBB. Configured TS: [XX.XXX.X.X/24 YYY.YY.YYY.Y/24 ], negotiated TS:[XX.XXX.X.X/24 ]. Please verify configuration on the remote side
13. handling HA CHILD_SA vpn_ BB.BBB.BBB.BBB{66} ZZ.ZZZ.Z.Z/24 === XX.XXX.X.X/24 (segment in: 1, out: 1)
14. CHILD_SA vpn_68.112.246.185{66} established with SPIs 07ab7fec_i de049161_o and TS ZZ.ZZZ.Z.Z/24 === XX.XXX.X.X/24
15. sending DPD request
Источник

1 ответ

Было ли когда-нибудь найдено решение этой проблемы? Я столкнулся с аналогичной проблемой, когда GCP VPN и клиент отключаются через несколько дней после первоначального подключения. Единственный способ, который я нашел, чтобы вернуть VPN в сеть, — это попросить клиента сбросить соединение на своей стороне.

Журналы приблизительного времени отключения VPN показывают:

проанализирован запрос CREATE_CHILD_SA 51 [SA No KE TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG)]

получен ESP_TFC_PADDING_NOT_SUPPORTED, без использования заполнения ESPv3 TFC

Предупреждение: селекторы локального трафика сужены для дочернего SA: vpn_###.###.### Настроенный TS: [###.###.###/32], согласованный TS:[###.###.###/32[tcp/65001] ###.###.###/32 ]. Пожалуйста, проверьте конфигурацию на удаленной стороне.

Предупреждение: селекторы удаленного трафика сужены для дочернего SA: vpn_###.###.###.###. Настроенное TS: [###.###.###.###/32 ], согласованное TS:[###.###.###.###/32[tcp/60394] ###.###.###.###/32 ]. Пожалуйста, проверьте конфигурацию на удаленной стороне.

обработка HA CHILD_SA vpn_###.###.###.###{4302} ###.###.###.###/32 === ###.###.###.###/32 (входной сегмент: 1*, исходящий: 1*)

создание ответа CREATE_CHILD_SA 51 [SA No KE TSi TSr]

Примечание. После регистрации приведенных выше сообщений следующие 5 сообщений повторяются снова и снова, пока VPN-соединение не будет сброшено на стороне клиента.

отправка пакета: от ###.###.###.###[500] до ###.###.###.###[500] (476 байт)

отправка запроса DPD

создание запроса INFORMATIONAL_V1 3569313833 [HASH N(DPD)]

проанализирован запрос INFORMATIONAL_V1 1654888155 [HASH N(DPD_ACK)]

отправка пакета: от ###.###.###.###[500] до ###.###.###.###[500] (92 байта)

полученный пакет: от ###.###.###.###[500] до ###.###.###.###[500] (92 байта)

Редактирование для добавления: эта проблема существовала около 3 лет, пока клиент не выполнил обновление (я полагаю, встроенное ПО) на своих брандмауэрах. Теперь проблема возникает еженедельно, и VPN не будет повторно подключаться, пока клиент не отключит свой конец VPN.

Источник
Другие вопросы по тегам