Пределы Cloud VPN, которые нельзя настроить: время жизни IKE и NAT пира

Cloud VPN согласует время жизни IKE в фиксированных границах и требует NAT один-к-одному на стороне пира. Планируйте удалённое устройство исходя из этого, а не из стороны Google.

Задайте удалённому устройству время жизни фазы 1 в 24 часа, и туннель Cloud VPN останется лежать, хотя на стороне Google всё настроено правильно. Пир предлагает значение, которое ответчик не примет, поэтому согласование либо полностью проваливается, либо перезапускается бесконечно. Cloud VPN ограничивает фазу 1 значением 36,000 секунд, то есть десятью часами, и этот предел нельзя поднять настройкой. Изменение относится к удалённому устройству.

Пир спрашивает, ответчик решает

IKE — это упражнение по сопоставлению двух наборов предложений. Туннель образуется только там, где наборы пересекаются в границах, которые принимает ответчик, поэтому время жизни вне диапазона не даёт даже частичного туннеля. Обычная ошибка — считать конфигурацию пира списком пожеланий, а не предложением. Пустое пересечение оставляет туннель лежать, какими бы правильными ни были маршрутизация и селекторы.

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

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Сравните возвращённое с поддерживаемым набором для вашего типа шлюза и версии IKE и запишите оба селектора трафика, пока вы там. Несовпадение селектора даёт тот же симптом лежащего туннеля, что и несовпадение алгоритма, и, в отличие от алгоритма, это вам исправлять.

36,000 секунд — это потолок

Фаза 1 останавливается на 36,000 секундах. Устройство, выставленное на 86,400, просит то, с чем ответчик никогда не согласится, и повторные попытки не меняют его решения. Верните удалённое предложение в диапазон, и та же конфигурация установится; асимметрия — это весь урок, потому что своё значение можно понизить, а значение Google поднять нельзя.

Запишите выбранное значение в проектные заметки. Иначе следующий инженер повторит эксперимент с 24 часами и упрётся в ту же стену.

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

Туннель, который падает по расписанию

Фаза 2 ведёт себя иначе: когда два конца не договариваются, пересогласование ключей идёт по более короткому интервалу. Пир, который считает несовпадение фатальным, вместо этого роняет туннель, поэтому одно несовпадение может выглядеть как две несвязанные неисправности. Следите за ритмом пересогласования ключей, а не только за первым подключением. Туннель, который поднимается и затем падает в регулярном такте, чаще оказывается несовпадением времени жизни, чем дефектом маршрутизации.

Сопоставьте эти метки времени падений с собственными журналами пира, прежде чем что-либо менять, потому что изменение селектора или маршрута может имитировать тот же ритм. Если такт совпадает с таймером фазы 2, причина найдена без вмешательства в предложение.

Наборы происходят от типа шлюза

Наборы шифрования и целостности — это не профиль для каждого туннеля, который вы редактируете, как позволяет strongSwan. Вы выбираете их по типу шлюза и версии IKE, а поиск несуществующего профиля тратит полдня.

Старое устройство, которое ничего не предлагает в пределах поддерживаемого набора, оставляет два честных пути: заменить устройство или завершить на программном шлюзе, которым вы управляете, и оттуда маршрутизировать в VPC. Всё остальное — обходной путь, который провалится на следующем обзоре.

Один внешний адрес на устройство

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

Держите и этот внешний адрес стабильным. Перенесите устройство за другой NAT, и связь рвётся, хотя каждое предложение всё ещё совпадает. Стоит записать, какие значения принадлежат Google, а какие вам: времена жизни, наборы и NAT один-к-одному фиксированы на их стороне, а предложения, селекторы, маршрутизация и приоритеты BGP — ваши.

Похожие статьи