Przygotuj ścieżkę odzyskiwania przez konsolę szeregową przed zmianą VPN w GCE

Drugie okno SSH na tym samym interfejsie nie jest ścieżką odzyskiwania. Dzieli trasę, regułę zapory i demona, które zamierzasz zmienić, więc zawodzi dokładnie w chwili, gdy go potrzebujesz. Przed edycją tras VPN na maszynie Compute Engine udowodnij trzy osobne rzeczy: że możesz używać konsoli szeregowej, że umiesz czytać jej wyjście i że gość naprawdę da ci logowanie. Poniższe kontrole idą w tej kolejności, od najtańszej, aby brakujące uprawnienie wykryto, zanim zacznie mieć znaczenie.

Krok 1: potwierdź uprawnienie po stronie chmury

Wskaż dokładną maszynę, projekt i strefę, a następnie sprawdź zatwierdzoną przez organizację politykę dostępu szeregowego. Administrator potrzebuje odpowiedniego uprawnienia, a interaktywny dostęp szeregowy musi być włączony dla tej instancji w ramach obowiązujących kontroli projektu i organizacji.

Nie osłabiaj polityki organizacji i nie włączaj dostępu do konsoli dla całego projektu, aby przygotować jedną maszynę. Poproś właściciela o ustalenie dozwolonego mechanizmu przed eksperymentem, a nie w trakcie awarii.

Krok 2: udowodnij, że umiesz czytać wyjście

Czytanie wyjścia szeregowego to najtańsza kontrola i ćwiczy transport bez dotykania logowania gościa:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

Zastąp identyfikatory i użyj dozwolonego portu. Komunikaty rozruchowe i gadanina konsoli mówią, że kanał działa. Nie dowodzą, że możesz uzyskać powłokę. Dlatego ten krok jest oddzielony od następnego.

Krok 3: udowodnij, że możesz uzyskać interaktywne logowanie

Polecenie połączenia otwiera prawdziwą sesję, a nie podgląd:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

Traktuj ją jak żywą konsolę. Potwierdź punkt końcowy, zanim wpiszesz dane logowania, ponieważ każde naciśnięcie klawisza trafia na instancję.

Tu właśnie rozsypuje się plan, który wyglądał na kompletny. Uprawnienie w chmurze to jedna granica, a monit logowania Linux to druga, i przejście pierwszej nic nie mówi o drugiej.

Krok 4: przygotuj dane logowania, które gość zaakceptuje

Obrazy Linux od Google domyślnie nie włączają lokalnego logowania hasłem. Sesja szeregowa może więc dotrzeć do monitu logowania i zatrzymać się tam, czekając na dane logowania, których nikt nie ustawił.

Zatwierdzone konto odzyskiwania lub dowolna udokumentowana metoda logowania gościa używana w twoim wdrożeniu musi istnieć i zostać przetestowana. Klucz SSH działający przez sieć nie spełnia automatycznie monitu hasła konsoli, więc sprawdź faktyczny układ OS Login i kluczy, zamiast zakładać, że obejmuje ten przypadek.

Trzymaj dane odzyskiwania w tajemnicy. Hasło root wklejone do publicznego przykładu startup-script to drugi incydent czekający na wybuch.

Krok 5: zapisz właściciela i wycofanie

Zanim cokolwiek zmienisz, zachowaj działającą konfigurację sieci i zapisz, kto nią zarządza, która usługa VPN jest zaangażowana i jak przebiega wycofanie. Z działającej sesji przechwyć bieżące trasy, reguły i stan usługi.

Właśnie ten zapis zamienia kanał odzyskiwania w naprawę, bo konsola daje ci tylko monit. Zapisz go przed zmianą, a nie później z pamięci. Wycofanie skopiowane z wiki nie jest wycofaniem. To domysł z numerem wersji.

Krok 6: zweryfikuj po zmianie

Istniejąca sesja SSH może przetrwać politykę blokującą nowe, więc testuj świeżą zwykłą sesją administracyjną. Następnie przetestuj osobno zmienione zachowanie VPN.

Trzymaj kanał odzyskiwania otwarty, dopóki obie kontrole nie przejdą, a potem zamknij go zgodnie z polityką dostępu. Jeśli SSH już przepadło i nie przygotowano logowania przez konsolę, przestań traktować dostęp szeregowy jako siatkę bezpieczeństwa i rozpocznij zatwierdzony proces odzyskiwania konta lub naprawy instancji. Postawienie kolejnej maszyny jako jump hosta nie naprawia ani ścieżki gościa, ani brakujących danych logowania.