Stan Cloud VPN: najpierw przeczytaj stan zasobu, potem dziennik IKE

Tunel Cloud VPN prowadzi dwa cykle życia naraz i nie są one na tym samym zegarze. Zasób musi zostać przydzielony i skonfigurowany, zanim będzie mógł negocjować, a potem protokół ma własną kolejność komunikatów IKE. Pole stanu może zgłaszać pierwsze, nie mówiąc nic użytecznego o drugim. Czytanie ich jako jednej rzeczy to sposób, w jaki niezgodność klucza zostaje obwiniona o opóźnienie w udostępnianiu.

Zacznij od jednego obiektu tunelu i jednego okna czasowego.

Dwa cykle życia, jeden obiekt tunelu

Cykl życia zasobu to dostawca przygotowujący tunel: adresy, konfiguracja, pojemność. Cykl życia protokołu zaczyna się, gdy obie strony mają dość konfiguracji, by wymienić IKE_SA_INIT, potem IKE_AUTH, potem podrzędne asocjacje bezpieczeństwa. Tunel wciąż w pierwszej fazie nie zawiódł uwierzytelniania, bo uwierzytelniania jeszcze nie próbowano.

Ta różnica to cały problem. Wszystko inne to kwestia tego, jak to obserwować bez scalania niepowiązanych komunikatów.

Czytaj obiekt, nie podsumowanie konsoli

Zapytaj API o dwa pola, które mają znaczenie, i o nic więcej, żeby odpowiedź pozostała dość mała, by przeczytać ją o trzeciej nad ranem: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Pole status nazywa etap cyklu życia, a detailedStatus niesie czytelny powód z nim związany. Pełny zrzut konfiguracji odpowiada na inne pytania i trudniej go wkleić do zgłoszenia. Takie wywołania tylko do odczytu nie mogą zmienić tunelu, co ma znaczenie, dopóki incydent trwa.

Zapisz znacznik czasu wywołania obok wartości, bo oba pola się zmieniają.

ALLOCATING_RESOURCES to nie niezgodność klucza

Gdy tunel zgłasza ALLOCATING_RESOURCES, dostawca wciąż składa obiekt. Niezgodności wstępnie współdzielonego klucza nie da się zaobserwować na tym etapie, a zablokowany port peera jest równie nieudowodniony. Sprawdzić można szczegółowy komunikat, to, czy projekt i usługa wyglądają zdrowo, oraz czy konfiguracja tunelu jest dość kompletna, by w ogóle skontaktować się z peerem. Wymiana sekretu teraz zmienia wartość, która nigdy nie została przetestowana.

Poczekaj, aż stan się zmieni, zanim wyciągniesz wniosek o konfiguracji.

ESTABLISHED to początek kontroli dostępu

Ustanowiony tunel oznacza, że IKE się zakończył, a nie że płynie ruch. Potwierdź trasy, które niesie tunel, a tam, gdzie uczestniczy Cloud Router, potwierdź sesję BGP i nauczone prefiksy. Potem przetestuj dozwoloną wymianę aplikacji, bo reguła zapory lub brakująca trasa mogą zablokować ruch przez całkowicie zdrowy tunel. Każde z tych to osobna obserwacja z osobną poprawką.

Stan mówi, które pytanie zadać następne. Nigdy nie odpowiada za ciebie na pytanie o dostęp.

Skorelowuj jeden obiekt i jedno okno czasowe

Stary błąd uwierzytelniania w dzienniku należy do wcześniejszej próby, chyba że jego znacznik czasu wpada w okno, które badasz. Pobierz dzienniki zasobu tunelu za te same minuty co zarejestrowany stan i trzymaj identyfikatory razem. Późniejsze zdarzenie IKE może pokazać, że negocjacja się zaczęła, podczas gdy komunikat w konsoli, w który się wpatrujesz, jest już nieaktualny.

Jeśli tunel się podniesie, zanim cokolwiek zbierzesz, powiedz to. Nieustalona przyczyna to lepszy zapis niż pewna historia złożona z niepowiązanych linii.

Następny krok zawsze ma ten sam kształt: jeden obiekt, jedno okno, jeden etap. Cokolwiek szerszego to podsumowanie, nie diagnoza.