Вопросы Теги

Журнал туннеля gcloud vpn жалуется, что «MAC несоответствующий». Как исправить?

Я пытаюсь подключить свое приложение, развернутое в облачном VPC Google, к локальной сети моего клиента (через VPN по запросу клиента), чтобы я и мой клиент могли передавать файлы между моим сервером в Gcloud и их сервером.

Однако у нас возникают проблемы с настройкой VPN-туннеля. Ниже приведены спецификации:

  1. Я установил VPN с высокой доступностью (HA) и использую динамическую маршрутизацию.
  2. IP-адрес моего шлюза gcloud VPN: 78.211.79.182; IP-адрес однорангового шлюза (он же клиентский) - 41.233.612.86. (Это, конечно, не настоящие IP-адреса. Просто для удобства чтения журнала ниже.)
  3. Я создал общий ключ IKEv2 и поделился им со своими клиентами, чтобы они использовали его для настройки своего шлюза. .

Из журнала моего шлюза Gcloud я вижу, что возникает ошибка: 

D 2020-07-26T13:46:23.854055402Z remote host is behind NAT 
D 2020-07-26T13:46:23.854099553Z authentication of '78.211.79.182' (myself) with pre-shared key 
I 2020-07-26T13:46:23.854167373Z establishing CHILD_SA vpn_41.233.612.86{1} 
D 2020-07-26T13:46:23.854285679Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ] 
D 2020-07-26T13:46:23.854821679Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (320 bytes) 
D 2020-07-26T13:46:23.865825884Z received packet: from 41.233.612.86[4500] to 78.211.79.182[4500] (240 bytes) 
D 2020-07-26T13:46:23.866158710Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ] 
D 2020-07-26T13:46:23.866219472Z tried 1 shared key for '78.211.79.182' - '41.233.612.86', but MAC mismatched 
D 2020-07-26T13:46:23.866341774Z generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ] 
D 2020-07-26T13:46:23.866434696Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (80 bytes) 
D 2020-07-26T13:46:26.830704780Z creating acquire job for policy with reqid {1} 
I 2020-07-26T13:46:26.830879885Z initiating IKE_SA vpn_41.233.612.86[38] to 41.233.612.86 
D 2020-07-26T13:46:26.835746125Z generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ] 
D 2020-07-26T13:46:26.836731673Z sending packet: from 78.211.79.182[500] to 41.233.612.86[500] (892 bytes) 
D 2020-07-26T13:46:26.847907232Z received packet: from 41.233.612.86[500] to 78.211.79.182[500] (464 bytes) 
D 2020-07-26T13:46:26.848248731Z parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] 
D 2020-07-26T13:46:26.853647299Z local host is behind NAT, sending keep alives 
D 2020-07-26T13:46:26.853693084Z remote host is behind NAT 
D 2020-07-26T13:46:26.853740121Z authentication of '78.211.79.182' (myself) with pre-shared key 
I 2020-07-26T13:46:26.853804324Z establishing CHILD_SA vpn_41.233.612.86{1} 
D 2020-07-26T13:46:26.853950401Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ] 
D 2020-07-26T13:46:26.854595024Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (320 bytes) 
D 2020-07-26T13:46:26.865979158Z received packet: from 41.233.612.86[4500] to 78.211.79.182[4500] (240 bytes) 
D 2020-07-26T13:46:26.866316701Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ] 
D 2020-07-26T13:46:26.866381716Z tried 1 shared key for '78.211.79.182' - '41.233.612.86', but MAC mismatched 
D 2020-07-26T13:46:26.866505332Z generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ] 
D 2020-07-26T13:46:26.866615565Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (80 bytes) 
D 2020-07-26T13:46:29.830755043Z creating acquire job for policy with reqid {1} 
I 2020-07-26T13:46:29.830930845Z initiating IKE_SA vpn_41.233.612.86[39] to 41.233.612.86 
D 2020-07-26T13:46:29.835922517Z generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ] 
D 2020-07-26T13:46:29.836919895Z sending packet: from 78.211.79.182[500] to 41.233.612.86[500] (892 bytes) 
D 2020-07-26T13:46:29.848359165Z received packet: from 41.233.612.86[500] to 78.211.79.182[500] (464 bytes) 
D 2020-07-26T13:46:29.848683121Z parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] 
D 2020-07-26T13:46:29.853828481Z local host is behind NAT, sending keep alives 
D 2020-07-26T13:46:29.853841851Z remote host is behind NAT

Туннель VPN не удалось настроить. У меня 2 вопроса:

  1. В журнале написано: 
D 2020-07-26T13:46:26.853647299Z local host is behind NAT, sending keep alives
D 2020-07-26T13:46:26.853693084Z remote host is behind NAT

Это вообще проблема? или это нормальное поведение, о котором мне не нужно беспокоиться?

  1. В журнале написано: 
    D 2020-07-26T13:46:23.866219472Z tried 1 shared key for '78.211.79.182' - '41.233.612.86', but MAC mismatched

Что это означает? Как я могу настроить, чтобы исправить эту проблему? Это что-то, что я должен изменить в моей конфигурации vpn gcloud, или что-то, что я должен посоветовать своему клиенту сделать с его настройками?

0
задан 26 July 2020 в 18:27
2 ответа

Cloud VPN поддерживает только NAT «один к одному» через инкапсуляцию UDP для NAT-Traversal (NAT-T). NAT «один ко многим» и преобразование адресов на основе портов не поддерживаются. Другими словами, Cloud VPN не может подключаться к нескольким одноранговым VPN-шлюзам, которые используют один внешний IP-адрес. Подробности можно найти в UDP-инкапсуляции

. использует тот же внешний IP-адрес, что и устройство NAT:

Тип удостоверения должен быть ID_IPV4_ADDR (RFC 7815).

Не все устройства Cisco поддерживают установку идентификатора устройства на IP-адрес. адрес, отличный от того, который использует устройство (его внутренний адрес). Например, устройства Cisco ASA не поддерживают назначение разные (внешние) IP-адреса для своих идентификаторов. Таким образом, Циско Устройства ASA нельзя настроить для использования NAT «один к одному» с Cloud VPN.

Для устройств Juniper вы можете установить идентификатор устройства, используя set безопасность ike gateway [ИМЯ] локальный идентификатор inet [PUBLIC_IP], где [NAME] — это имя вашего VPN-шлюза, а [PUBLIC_IP] — ваш внешний IP-адрес. адрес. Дополнительные сведения см. в этой статье Juniper TechLibrary.

Кроме того, я заметил следующее в журнале, которым вы поделились.

D 2020-07-26T13:46:23.854285679Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ]
D 2020-07-26T13:46:23.866158710Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]

Согласно информации, рассмотренной выше, решение этой проблемы состоит в том, чтобы настроить локальный VPN-шлюз так, чтобы он идентифицировал себя с помощью общедоступного IP-адреса, а не с внутренний или любой другой адрес. Поскольку конец GCP будет ожидать ответа только от равноправного IP-адреса, настроенного в конфигурации GCP Cloud VPN.

3
ответ дан 28 July 2020 в 20:25

Получил ту же ошибку при попытке подключить два GCP VPC через туннели HA VPN. Причина заключалась в том, что я не предоставил один и тот же общий ключ в мастере.

При создании туннелей мастер предлагает общий секрет, и вместо того, чтобы добавить один и тот же в оба, я получил ту же ошибку, что и вы. Предоставление согласованного секрета заставило ошибку исчезнуть.

2
ответ дан 31 March 2021 в 10:31

Теги

Похожие вопросы