Из локального Linux я попытался проверить статус vpn.
Почему не продолжить работу с подробным статусом? Почему статус по-прежнему "FIRST_HANDSHAKE"?
Общий ключ и TargetIP не ошиблись.
$ gcloud compute vpn-tunnels describe gvis-vpn-tunnel
И здесь было эхо.
creationTimestamp: '2020-07-28T15:05:44.541-07:00'
description: ''
detailedStatus: Allocating resources. VPN tunnel will start soon.
id:'2892217179569987543'
ikeVersion: 2
kind: compute#vpnTunnel
:
region: https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-east1
:
sharedSecret: '*************'
:
status: FIRST_HANDSHAKE
targetVpnGateway: https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-east1/targetVpnGateways/gvis-vpn
ОБНОВИТЬ
На прошлой неделе мне удалось подключить vpn туннель. С этого понедельника не удалось подключиться, и я увидел следующие записи:
2020-07-28T22:45:04.831987016Z initiating IKE_SA vpn_58.xxx.xxx.xxx[779] to 58.xxx.xxx.xxx
2020-07-28T22:45:04.758749637Z creating acquire job for policy with reqid {1}
2020-07-28T22:45:02.148478373Z sending packet: from 35.xxx.xxx.xxx[4500] to 58.xxx.xxx.xxx[4500] (80 bytes)
2020-07-28T22:45:02.148478373Z generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
2020-07-28T22:45:02.148478373Z tried 1 shared key for '35.xxx.xxx.xxx' - '58.xxx.xxx.xxx', but MAC mismatched
2020-07-28T22:45:02.148478373Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
2020-07-28T22:45:02.105535147Z received packet: from 58.xxx.xxx.xxx[4500] to 35.xxx.xxx.xxx[4500] (256 bytes)
2020-07-28T22:45:02.029020541Z sending packet: from 35.xxx.xxx.xxx[4500] to 58.xxx.xxx.xxx[4500] (336 bytes)
2020-07-28T22:45:02.029020541Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ]
2020-07-28T22:45:02.029020541Z establishing CHILD_SA vpn_58.xxx.xxx.xxx{1}
2020-07-28T22:45:02.029020541Z authentication of '35.xxx.xxx.xxx' (myself) with pre-shared key
2020-07-28T22:45:02.029020541Z remote host is behind NAT
2020-07-28T22:45:02.029020541Z parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
2020-07-28T22:45:01.933846400Z received packet: from 58.xxx.xxx.xxx[500] to 35.xxx.xxx.xxx[500] (464 bytes)
2020-07-28T22:45:01.819625244Z sending packet: from 35.xxx.xxx.xxx[500] to 58.xxx.xxx.xxx[500] (892 bytes)
2020-07-28T22:45:01.819625244Z generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
Предварительный общий ключ такой же с декабря 2019 года. Каждый день, когда я хочу подключиться, создавал vpn-туннель вот так,
gcloud compute vpn-tunnels create [my-vpn-tunnel] \
--peer-address 58.xxx.xxx.xxx \
--ike-version 2 \
--shared-secret [Pre-shared key] \
--local-traffic-selector=192.xxx.100.0/24 \
--remote-traffic-selector=172.xx.xx.0/24,192.xxx.10.0/24 \
--target-vpn-gateway [my-vpn] \
--region us-east1 \
--project [project-id]
И когда я отключаюсь, удаляю vpn-tunnel вот так,
gcloud compute vpn-tunnels delete [my-vpn-tunnel] --region=us-east1
Я всегда использую gcloud в своем сценарии оболочки Linux.
Поскольку ваша проблема разрешилась сама по себе, мы можем только догадываться, чем была вызвана эта проблема раньше.
Как я писал в комментариях, лучше следить руководство по устранению неполадок и начать с Журналы Cloud VPN.
2020-07-28T22:45:02.148478373Z tried 1 shared key for '35.xxx.xxx.xxx' - '58.xxx.xxx.xxx', but MAC mismatched
Коды аутентификации сообщений (MAC) вычисляются на основе предварительно общего ключа и сообщения, и если предварительно общие ключи не совпадают, соответствующие MAC также не будут совпадать. Между тем, это не похоже на ваш случай, потому что вы утверждаете, что «предварительный общий ключ остается неизменным с декабря 2019 года».
2020-07-28T22:45:02.029020541Z remote host is behind NAT
Поскольку вы используете NAT, я бы порекомендовал вам взглянуть на руководство по устранению неполадок раздел Локальные шлюзы за NAT:
Cloud VPN может работать с локальными или одноранговыми VPN-шлюзами, которые находятся за NAT. Это стало возможным благодаря инкапсуляции UDP и NAT-T, и поддерживается только NAT один к одному.
более подробную информацию вы можете найти в эта секция:
Cloud VPN поддерживает только NAT-трансляцию один-к-одному через инкапсуляцию UDP для NAT-Traversal (NAT-T). NAT «один ко многим» и преобразование адресов на основе портов не поддерживаются. Другими словами, Cloud VPN не может подключаться к нескольким одноранговым VPN-шлюзам, использующим один внешний IP-адрес.
При использовании NAT «один-к-одному» одноранговый шлюз VPN должен быть настроен для идентификации себя с использованием внешнего IP-адреса, а не его внутреннего (частного) адреса. При настройке туннеля Cloud VPN для подключения к одноранговому шлюзу VPN вы указываете внешний IP-адрес. Cloud VPN ожидает, что локальный VPN-шлюз будет использовать внешний IP-адрес для идентификации.
Возможно, эта проблема может быть связана с вашим локальным маршрутизатором, но без журналов сложно сказать.
Кроме того, в следующий раз вы можете проверить, есть ли эта проблема на стороне Google на Панель состояния Google Cloud и подать отчет о проблеме на Отслеживание проблем Google.