Статус Cloud VPN: сначала состояние ресурса, потом журнал IKE

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

Начните с одного объекта туннеля и одного временного окна.

Два жизненных цикла, один объект туннеля

Жизненный цикл ресурса — это подготовка туннеля поставщиком: адреса, конфигурация, ёмкость. Жизненный цикл протокола начинается, когда у обеих сторон достаточно конфигурации, чтобы обменяться IKE_SA_INIT, затем IKE_AUTH, затем дочерними ассоциациями безопасности. Туннель, всё ещё находящийся в первой фазе, не провалил аутентификацию, потому что аутентификацию ещё не пытались выполнить.

Это различие и есть вся проблема. Всё остальное — о том, как наблюдать его, не смешивая несвязанные сообщения.

Читайте объект, а не сводку консоли

Запросите у API только те два поля, которые важны, и ничего больше, чтобы ответ оставался достаточно малым для чтения в три часа ночи: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Поле status называет этап жизненного цикла, а detailedStatus несёт читаемую причину, привязанную к нему. Полный дамп конфигурации отвечает на другие вопросы, и его труднее вставить в заявку. Такие запросы только на чтение не могут изменить туннель, что важно, пока инцидент ещё активен.

Запишите отметку времени вызова рядом со значениями, потому что оба поля меняются.

ALLOCATING_RESOURCES — это не несовпадение ключа

Когда туннель сообщает ALLOCATING_RESOURCES, поставщик ещё собирает объект. Несовпадение предварительно общего ключа на этом этапе наблюдать нельзя, а заблокированный порт партнёра столь же недоказан. Проверить можно подробное сообщение, выглядят ли проект и служба здоровыми и достаточно ли полна конфигурация туннеля, чтобы с партнёром вообще можно было связаться. Замена секрета сейчас меняет значение, которое никогда не проверялось.

Дождитесь изменения состояния, прежде чем делать вывод о конфигурации.

ESTABLISHED — это начало проверок доступа

Установленный туннель означает, что IKE завершился, а не что трафик идёт. Подтвердите маршруты, которые несёт туннель, и там, где участвует Cloud Router, подтвердите сеанс BGP и изученные префиксы. Затем проверьте разрешённый обмен приложения, потому что правило брандмауэра или отсутствующий маршрут могут блокировать трафик через полностью здоровый туннель. Каждое из этого — отдельное наблюдение с отдельным исправлением.

Состояние говорит, какой вопрос задать следующим. Оно никогда не отвечает за вас на вопрос о доступе.

Сопоставьте один объект и одно временное окно

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

Если туннель восстановился до того, как вы что-либо собрали, скажите об этом. Неустановленная причина — лучшая запись, чем уверенная история, собранная из несвязанных строк.

Следующий шаг всегда одной формы: один объект, одно окно, один этап. Всё более широкое — это сводка, а не диагноз.