Състояние на 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 може да покаже, че преговорите са започнали, докато съобщението в конзолата, в което се взирате, вече е остаряло.

Ако тунелът се възстанови, преди да съберете каквото и да е, кажете го. Неопределената причина е по-добър запис от уверена история, сглобена от несвързани редове.

Следващата стъпка винаги е с една и съща форма: един обект, един прозорец, един етап. Всичко по-широко е обобщение, не диагноза.