GCE VPN değişikliğinden önce seri kurtarma yolu hazırlayın

Aynı arabirimdeki ikinci bir SSH penceresi kurtarma yolu değildir. Değiştirmek üzere olduğunuz yolu, güvenlik duvarı kuralını ve daemonu paylaşır, bu yüzden tam da ona ihtiyaç duyduğunuz anda başarısız olur. Bir Compute Engine VM’inde VPN yollarını düzenlemeden önce üç ayrı şeyi kanıtlayın: seri konsolu kullanabildiğinizi, çıktısını okuyabildiğinizi ve konuğun size gerçekten oturum açma izni vereceğini. Aşağıdaki kontroller bu sırayla, en ucuzdan başlayarak ilerler; böylece eksik bir izin önemli hale gelmeden keşfedilir.

Adım 1: bulut tarafındaki izni doğrulayın

Tam VM’i, projeyi ve bölgeyi belirtin, ardından kuruluşun onayladığı seri erişim politikasını kontrol edin. Yöneticinin ilgili izne ihtiyacı vardır ve etkileşimli seri erişim, yürürlükteki proje ve kuruluş kontrolleri altında o örnek için etkinleştirilmelidir.

Tek bir makine hazırlamak için kuruluş politikasını zayıflatmayın veya tüm proje genelinde konsol erişimini açmayın. Sahibinden izin verilen mekanizmayı deneyden önce ayarlamasını isteyin, kesinti sırasında değil.

Adım 2: çıktıyı okuyabildiğinizi kanıtlayın

Seri çıktıyı okumak en ucuz kontroldür ve konuğun oturum açmasına dokunmadan taşımayı çalıştırır:

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

Tanımlayıcıları değiştirin ve izin verilen bağlantı noktasını kullanın. Önyükleme mesajları ve konsol sohbeti kanalın çalıştığını söyler. Bir shell alabileceğinizi kanıtlamazlar. Bu yüzden bu adım bir sonrakinden ayrıdır.

Adım 3: etkileşimli bir oturum açma alabildiğinizi kanıtlayın

Bağlantı komutu önizleme değil, gerçek bir oturum açar:

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

Ona canlı bir konsol gibi davranın. Kimlik bilgilerini yazmadan önce uç noktayı doğrulayın, çünkü her tuş vuruşu örneğe iner.

Tam görünen bir plan tam burada dağılır. Bulut izni bir sınır, Linux oturum açma istemi ise başka bir sınırdır ve ilkini geçmek ikincisi hakkında hiçbir şey söylemez.

Adım 4: konuğun kabul edeceği kimlik bilgilerini hazırlayın

Google’ın sağladığı Linux imajları varsayılan olarak yerel parola tabanlı oturum açmayı etkinleştirmez. Bu nedenle bir seri oturum, oturum açma istemine ulaşıp orada durabilir ve kimsenin ayarlamadığı bir kimlik bilgisini bekleyebilir.

Onaylanmış bir kurtarma hesabı veya dağıtımınızın kullandığı belgelenmiş herhangi bir konuk oturum açma yöntemi mevcut olmalı ve test edilmelidir. Ağ üzerinden çalışan bir SSH anahtarı, konsol parola istemini otomatik olarak karşılamaz; bu durumu kapsadığını varsaymak yerine gerçek OS Login ve anahtar düzenini kontrol edin.

Kurtarma kimlik bilgilerini gizli tutun. Herkese açık bir startup-script örneğine yapıştırılan root parolası, olmayı bekleyen ikinci bir olaydır.

Adım 5: sahibi ve geri almayı kaydedin

Herhangi bir şeyi değiştirmeden önce çalışan ağ yapılandırmasını koruyun ve onu kimin yönettiğini, hangi VPN hizmetinin dahil olduğunu ve geri almanın nasıl yapıldığını yazın. Çalışan bir oturumdan mevcut yolları, kuralları ve hizmet durumunu kaydedin.

Kurtarma kanalını onarıma dönüştüren şey tam olarak bu kayıttır, çünkü konsol size yalnızca bir istem verir. Onu değişiklikten önce yazın, sonra ezberden değil. Bir wiki’den kopyalanan geri alma geri alma değildir. Sürüm numarası olan bir tahmindir.

Adım 6: değişiklikten sonra doğrulayın

Mevcut bir SSH oturumu yenileri engelleyen bir politikadan sağ çıkabilir, bu yüzden yeni normal bir yönetim oturumuyla test edin. Ardından değiştirdiğiniz VPN davranışını ayrı ayrı test edin.

Her iki kontrol de geçene kadar kurtarma kanalını açık tutun ve sonra erişim politikasına göre kapatın. SSH zaten kaybolduysa ve konsol oturumu hazırlanmadıysa, seri erişimi güvenlik ağı olarak görmeyi bırakın ve yetkili hesap kurtarma veya örnek onarma iş akışını başlatın. Başka bir VM’i jump host olarak ayağa kaldırmak ne konuğun yolunu ne de eksik kimlik bilgilerini onarır.