Siapkan Jalur Pemulihan Serial Sebelum Mengubah VPN di GCE

Jendela SSH kedua pada antarmuka yang sama bukanlah jalur pemulihan. Jendela itu berbagi rute, aturan firewall, dan daemon yang akan Anda ubah, sehingga gagal tepat pada saat Anda membutuhkannya. Sebelum mengedit rute VPN pada VM Compute Engine, buktikan tiga hal terpisah: bahwa Anda boleh memakai konsol serial, bahwa Anda dapat membaca output-nya, dan bahwa tamu benar-benar akan memberi Anda login. Pemeriksaan di bawah berjalan dalam urutan itu, termurah lebih dulu, agar izin yang hilang ditemukan sebelum menjadi penting.

Langkah 1: pastikan izin di sisi cloud

Sebutkan VM, proyek, dan zona yang tepat, lalu periksa kebijakan akses serial yang disetujui organisasi. Administrator memerlukan izin yang relevan, dan akses serial interaktif harus diaktifkan untuk instans itu di bawah kontrol proyek dan organisasi yang berlaku.

Jangan melemahkan kebijakan organisasi atau menyalakan akses konsol untuk seluruh proyek hanya untuk menyiapkan satu mesin. Mintalah pemilik mengatur mekanisme yang diizinkan sebelum eksperimen, bukan selama gangguan.

Langkah 2: buktikan Anda dapat membaca output

Membaca output serial adalah pemeriksaan termurah, dan itu melatih transport tanpa menyentuh login tamu:

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

Ganti pengenal dan gunakan port yang diizinkan. Pesan boot dan obrolan konsol memberi tahu Anda bahwa kanal berfungsi. Itu tidak membuktikan Anda bisa mendapatkan shell. Itulah sebabnya langkah ini terpisah dari langkah berikutnya.

Langkah 3: buktikan Anda bisa mendapatkan login interaktif

Perintah koneksi membuka sesi nyata, bukan pratinjau:

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

Perlakukan sebagai konsol langsung. Konfirmasi endpoint sebelum mengetik kredensial, karena setiap ketikan mendarat di instans.

Di sinilah rencana yang tampak lengkap berantakan. Izin cloud adalah satu batas dan prompt login Linux adalah batas lain, dan melewati yang pertama tidak memberi tahu apa pun tentang yang kedua.

Langkah 4: siapkan kredensial yang akan diterima tamu

Image Linux yang disediakan Google tidak mengaktifkan login lokal berbasis kata sandi secara default. Karena itu sesi serial bisa mencapai prompt login dan berhenti di sana, menunggu kredensial yang tidak pernah diatur siapa pun.

Akun pemulihan yang disetujui, atau metode login tamu terdokumentasi apa pun yang dipakai penerapan Anda, harus ada dan diuji. Kunci SSH yang berfungsi melalui jaringan tidak otomatis memenuhi prompt kata sandi konsol, jadi periksa pengaturan OS Login dan kunci yang sebenarnya alih-alih menganggapnya mencakup kasus ini.

Jaga kredensial pemulihan tetap privat. Kata sandi root yang ditempel ke contoh startup-script publik adalah insiden kedua yang menunggu terjadi.

Langkah 5: catat pemilik dan rollback

Sebelum mengubah apa pun, pertahankan konfigurasi jaringan yang berfungsi dan tuliskan siapa yang mengelolanya, layanan VPN mana yang terlibat, dan bagaimana rollback dilakukan. Dari sesi yang berfungsi, tangkap rute, aturan, dan status layanan saat ini.

Catatan itulah yang mengubah kanal pemulihan menjadi perbaikan, karena konsol hanya memberi Anda prompt. Tulis sebelum perubahan, bukan dari ingatan sesudahnya. Rollback yang disalin dari wiki bukan rollback. Itu tebakan dengan nomor versi.

Langkah 6: verifikasi setelah perubahan

Sesi SSH yang ada dapat bertahan dari kebijakan yang memblokir sesi baru, jadi uji dengan sesi administrasi normal yang baru. Lalu uji perilaku VPN yang Anda ubah secara terpisah.

Biarkan kanal pemulihan terbuka sampai kedua pemeriksaan lolos, lalu tutup sesuai kebijakan akses. Jika SSH sudah hilang dan tidak ada login konsol yang disiapkan, berhentilah memperlakukan akses serial sebagai jaring pengaman dan mulai alur pemulihan akun atau perbaikan instans yang resmi. Menyiapkan VM lain sebagai jump host tidak memperbaiki jalur tamu maupun kredensial yang hilang.