Назад | Перейти на главную страницу

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

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

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

  1. Я настроил VPN с высокой доступностью (HA) и использую динамическую маршрутизацию.
  2. IP-адрес моего VPN-шлюза gcloud - 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

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

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

При использовании NAT «один к одному» ваш локальный шлюз VPN должен идентифицировать себя, используя тот же внешний IP-адрес, что и устройство NAT:

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

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

Для устройств Juniper вы можете установить идентификатор устройства с помощью set security gateway [NAME] local-identity 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.