Tunnel Cloud VPN menjalankan dua kitaran hayat serentak, dan kedua-duanya bukan pada jam yang sama. Sumber mesti diperuntukkan dan dikonfigurasikan sebelum ia boleh berunding, dan selepas itu protokol mempunyai urutan mesej IKE sendiri. Medan status boleh melaporkan yang pertama tanpa mengatakan apa-apa yang berguna tentang yang kedua. Membacanya sebagai satu perkara ialah cara ketidakpadanan kunci dipersalahkan atas kelewatan peruntukan.

Mulakan dengan satu objek tunnel dan satu tetingkap masa.

Dua kitaran hayat, satu objek tunnel

Kitaran hayat sumber ialah penyedia menyediakan tunnel: alamat, konfigurasi, kapasiti. Kitaran hayat protokol bermula apabila kedua-dua rakan sebaya mempunyai konfigurasi yang cukup untuk bertukar IKE_SA_INIT, kemudian IKE_AUTH, kemudian persatuan keselamatan anak. Tunnel yang masih dalam fasa pertama belum gagal pengesahan, kerana pengesahan belum dicuba.

Perbezaan itulah keseluruhan masalahnya. Selebihnya ialah cara memerhatikannya tanpa menggabungkan mesej yang tidak berkaitan.

Baca objek, bukan ringkasan konsol

Minta API dua medan yang penting dan tiada yang lain, supaya jawapannya kekal cukup kecil untuk dibaca pada pukul tiga pagi: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Medan status menamakan peringkat kitaran hayat, dan detailedStatus membawa sebab yang boleh dibaca yang terikat padanya. Dump konfigurasi penuh menjawab soalan lain dan lebih sukar ditampal ke dalam tiket. Panggilan baca sahaja seperti ini tidak boleh mengubah tunnel, yang penting selagi insiden masih aktif.

Catat cap masa panggilan di sebelah nilai, kerana kedua-dua medan bergerak.

ALLOCATING_RESOURCES bukan ketidakpadanan kunci

Apabila tunnel melaporkan ALLOCATING_RESOURCES, penyedia masih memasang objek itu. Ketidakpadanan kunci yang dikongsi terlebih dahulu tidak dapat diperhatikan pada peringkat itu, dan port rakan sebaya yang tersekat juga sama tidak terbukti. Apa yang boleh anda semak ialah mesej terperinci, sama ada projek dan perkhidmatan kelihatan sihat, dan sama ada konfigurasi tunnel cukup lengkap untuk menghubungi rakan sebaya langsung. Menggantikan rahsia sekarang mengubah nilai yang tidak pernah diuji.

Tunggu sehingga status bergerak sebelum membuat kesimpulan tentang konfigurasi.

ESTABLISHED ialah permulaan pemeriksaan akses

Tunnel yang terbentuk bermakna IKE selesai, bukan trafik mengalir. Sahkan laluan yang dibawa tunnel dan, di mana Cloud Router terlibat, sahkan sesi BGP dan awalan yang dipelajarinya. Kemudian uji pertukaran aplikasi yang dibenarkan, kerana peraturan firewall atau laluan yang hilang boleh menyekat trafik melalui tunnel yang benar-benar sihat. Setiap satu daripadanya ialah pemerhatian berasingan dengan pembetulan berasingan.

Status memberitahu anda soalan mana yang perlu ditanya seterusnya. Ia tidak pernah menjawab soalan akses bagi pihak anda.

Hubungkan satu objek dan satu tetingkap masa

Kegagalan pengesahan lama dalam log adalah milik cubaan terdahulu, melainkan cap masanya jatuh dalam tetingkap yang anda siasat. Tarik log untuk sumber tunnel bagi minit yang sama dengan status yang anda catat, dan simpan pengecam bersama. Peristiwa IKE yang lebih lewat boleh menunjukkan rundingan telah bermula sementara mesej konsol yang anda tatap sudah lapuk.

Jika tunnel pulih sebelum anda mengumpul apa-apa, katakan begitu. Punca yang tidak ditentukan ialah rekod yang lebih baik daripada kisah yakin yang dipasang daripada baris yang tidak berkaitan.

Langkah seterusnya sentiasa berbentuk sama: satu objek, satu tetingkap, satu peringkat. Apa-apa yang lebih luas ialah ringkasan, bukan diagnosis.

Artikel berkaitan