Cloud VPN ke Cisco ASA: bangun ulang setelah ketidakcocokan proposal

NEGOTIATION_FAILURE pada tunnel Cloud VPN dengan Cisco ASA di ujung seberang hampir selalu berarti ketidakcocokan proposal atau selector, dan fakta pertama yang berguna adalah tidak ada penyuntingan yang bisa memperbaikinya. Cloud VPN mengunci proposal IKE saat objek tunnel dibuat. Tidak ada kolom untuk mengganti algoritme di tempat, jadi perbaikannya adalah menghapus lalu membuat ulang dengan titik awal yang tercatat. Perlakukan sebagai pembangunan ulang dan pekerjaannya berubah menjadi daftar periksa, bukan sore penuh dugaan.

Baca kegagalan sebelum menghapus apa pun

Kegagalan negosiasi adalah masalah fase, dan log peer biasanya menyebut fasenya. Fase 1 gagal berarti kedua ujung tidak bisa menyepakati proposal atau tidak bisa saling mengautentikasi. Fase 2 gagal berarti tunnel sudah naik tetapi selector yang dilindungi tidak cocok. Itu perbaikan yang berbeda, dan baris log itu layak diambil sebelum siapa pun menyentuh konfigurasi.

Kegagalan itu juga menyingkirkan beberapa kemungkinan. Ini bukan rute VPC, bukan aturan firewall pada antarmuka tunnel, dan bukan kesalahan resolusi nama di dalam jaringan. Mengejar hal-hal itu menghasilkan perubahan yang percaya diri tetapi tidak bisa mengubah hasil, dan membuat perbaikan akhirnya lebih sulit diatribusikan.

Rekam kedua konfigurasi selagi masih ada

Menghapus tunnel hanya butuh setengah menit dan menghancurkan satu-satunya bukti yang Anda punya. Sebelum itu, tuliskan selector lokal dan jarak jauh, alamat peer, siapa yang memegang shared secret, serta crypto map atau profil IKEv2 milik ASA. ASA menjawab dua pertanyaan terpisah: apa yang dikonfigurasi dan apa yang sedang naik:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Di sisi Google, baca objek tunnel alih-alih ringkasan konsol, karena alamat peer dan kolom selector adalah nilai yang harus Anda reproduksi dengan tepat:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Masukkan nilai itu ke tiket sebelum penghapusan pertama. Pembangunan ulang di bawah hanya berhasil karena Anda bisa membuat objek yang sama dengan satu perbedaan yang disengaja.

Algoritme yang ditolak dinegosiasikan oleh salah satu pihak

Cloud VPN tidak memilih dari rentang algoritme IKEv1 seperti peer tradisional. Setelan peer yang diharapkannya bersifat tetap: aes-cbc-128 untuk enkripsi, sha1-96 untuk integritas dan PRF, grup Diffie-Hellman 2, 36,600 detik untuk fase 1 dan 10,800 detik untuk fase 2. Kebijakan ASA harus menawarkan kumpulan yang persis itu. Proposal kedua di ASA tidak merugikan selama yang cocok juga ada di daftar.

IKEv2 memberi kedua pihak lebih banyak ruang, tetapi aturannya tetap berbentuk sama: aktifkan PFS, pilih grup DH yang didukung tunnel, dan jaga daftar proposal cukup pendek agar ketidakcocokan terlihat jelas. Peer ASA pada Cloud VPN juga berarti perutean statis, jadi prefiks yang dilindungi harus direncanakan dan dicantumkan, bukan diserahkan ke BGP.

Masa hidup yang disalin dari templat vendor lain adalah kesalahan arah yang biasa di sini. Google menerbitkan nilai ini sebagai setelan peer yang wajib, jadi pasanglah; nilai yang lebih pendek tidak dinegosiasikan naik sampai ke apa yang diinginkan ASA.

Hapus, buat ulang, dan bersihkan keadaan lama

Hapus tunnel, bukan gateway, dan catat nama yang diberikan Cloud VPN untuk penggantinya, karena nama diberikan dan tidak dipakai ulang. Buat ulang dengan nilai yang tercatat dan alamat peer yang sama, lalu tambahkan proposal yang cocok ke daftar kebijakan ASA.

Bersihkan security association setelah perubahan di ASA dan sebelum membaca hasilnya. ASA bisa terus menawarkan kebijakan lama sampai SA saat ini kedaluwarsa, jadi konfigurasi yang benar terlihat rusak sepanjang masa hidup lama dan pengamat menyimpulkan pembangunan ulang gagal padahal belum dimulai:

clear crypto ikev2 sa
clear crypto ipsec sa

Pastikan fase 1 naik sebelum melihat fase 2. Selama fase 1 turun, proposal atau kunci yang dibagikan sebelumnya salah, dan pekerjaan selector tidak akan mengubahnya.

Selector saling mencerminkan, lalu penghitung yang memutuskan

Fase 2 hanya berfungsi ketika kedua ujung sepakat soal alamat yang dilindungi, dan kesepakatannya bersifat cermin, bukan dibagi. Selector lokal Google harus cocok dengan selector yang disebut ASA sebagai jarak jauh, dan selector jarak jauh Google harus cocok dengan yang disebut ASA sebagai lokal. Tunnel dengan 0.0.0.0/0 di satu sisi dan satu subnet di sisi lain melewati fase 1 lalu gagal di fase 2 dengan kesalahan utama yang sama. Tidak ada pihak yang bisa memperlebar daftar pihak lain.

Untuk selector berbasis kebijakan, daftarkan setiap pasangan prefiks dan simpan daftarnya di tiket. Subnet yang ditambahkan di lokasi nanti membutuhkan penyuntingan di kedua ujung, karena rute baru di ASA tidak memperlebar selector, dan hasilnya adalah tunnel yang naik dan hanya melewatkan lalu lintas untuk prefiks yang ada pada hari pertama.

Akhiri dengan satu alur host-ke-host dan baca penghitung byte di kedua sisi. Penghitung yang naik di ASA tetapi datar di Google biasanya berarti balasannya keluar melalui antarmuka lain, atau selector tidak mencakup prefiks balik. Catat algoritme, masa hidup, selector, dan nama tunnel yang baru, karena perubahan proposal berikutnya mengulang pembangunan ulang ini dan nilai-nilai itu membuatnya menjadi pekerjaan singkat.