Cloud VPN ke Cisco ASA: bina semula selepas percanggahan cadangan

NEGOTIATION_FAILURE pada terowong Cloud VPN dengan Cisco ASA di hujung jauh hampir selalu percanggahan cadangan atau pemilih, dan fakta pertama yang berguna ialah tiada suntingan akan membaikinya. Cloud VPN menetapkan cadangan IKE apabila objek terowong dicipta. Tiada medan untuk menukar algoritma di tempat, jadi pembaikan ialah padam dan bina semula dengan titik permulaan yang direkodkan. Perlakukan sebagai pembinaan semula dan kerja menjadi senarai semak, bukan petang penuh meneka.

Baca kegagalan sebelum memadam apa-apa

Kegagalan rundingan ialah masalah fasa, dan log rakan biasanya menamakan fasa. Kegagalan fasa 1 bermakna hujung tidak dapat bersetuju tentang cadangan atau tidak dapat mengesahkan satu sama lain. Kegagalan fasa 2 bermakna terowong naik tetapi pemilih yang dilindungi tidak sepadan. Itu pembaikan yang berbeza, dan baris log itu wajar diambil sebelum sesiapa menyentuh konfigurasi.

Kegagalan itu juga menolak beberapa perkara. Ia bukan laluan VPC, bukan peraturan firewall pada antara muka terowong, dan bukan kerosakan penyelesaian nama di dalam rangkaian. Mengejarnya menghasilkan perubahan yakin yang tidak boleh mengubah hasil, dan menyukarkan pembaikan akhir dikaitkan.

Tangkap kedua-dua konfigurasi selagi ia masih wujud

Memadam terowong mengambil masa setengah minit dan memusnahkan satu-satunya bukti yang anda ada. Sebelum itu, tuliskan pemilih setempat dan jauh, alamat rakan, siapa memiliki rahsia kongsi, serta crypto map atau profil IKEv2 ASA. ASA menjawab dua soalan berasingan: apa yang dikonfigurasikan 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 sebelah Google, baca objek terowong dan bukan ringkasan konsol, kerana alamat rakan dan medan pemilih ialah nilai yang mesti anda hasilkan semula dengan tepat:

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

Letakkan nilai itu dalam tiket sebelum pemadaman pertama. Pembinaan semula di bawah berfungsi hanya kerana anda boleh mencipta semula objek yang sama dengan satu perbezaan yang disengajakan.

Algoritma yang enggan dirundingkan oleh satu pihak

Cloud VPN tidak memilih daripada julat algoritma IKEv1 seperti rakan tradisional. Tetapan rakan yang dijangkakannya adalah tetap: aes-cbc-128 untuk penyulitan, sha1-96 untuk integriti dan PRF, kumpulan Diffie-Hellman 2, 36,600 saat untuk fasa 1 dan 10,800 saat untuk fasa 2. Dasar ASA mesti menawarkan set tepat itu. Cadangan kedua pada ASA tidak memudaratkan selagi yang sepadan juga ada dalam senarai.

IKEv2 memberi kedua-dua pihak lebih ruang, tetapi peraturannya kekal berbentuk sama: hidupkan PFS, pilih kumpulan DH yang disokong terowong, dan pastikan senarai cadangan cukup pendek supaya percanggahan jelas. Rakan ASA pada Cloud VPN juga bermakna penghalaan statik, jadi awalan yang dilindungi mesti dirancang dan disenaraikan dan bukan diserahkan kepada BGP.

Jangka hayat yang disalin daripada templat vendor lain ialah salah langkah biasa di sini. Google menerbitkan nilai ini sebagai tetapan rakan wajib, jadi tetapkan; nilai yang lebih pendek tidak dirundingkan ke atas sehingga apa yang ASA mahu.

Padam, bina semula dan bersihkan keadaan lama

Padam terowong, bukan gateway, dan catat nama yang diberikan Cloud VPN kepada pengganti, kerana nama diberikan dan tidak digunakan semula. Bina semula dengan nilai yang direkodkan dan alamat rakan yang sama, kemudian tambah cadangan yang sepadan ke senarai dasar ASA.

Bersihkan persatuan keselamatan selepas perubahan pada ASA dan sebelum membaca hasilnya. ASA boleh terus menawarkan dasar lapuk sehingga SA semasa tamat tempoh, jadi konfigurasi yang betul kelihatan rosak sepanjang hayat lama dan pemerhati menyimpulkan pembinaan semula gagal sedangkan ia belum bermula:

clear crypto ikev2 sa
clear crypto ipsec sa

Pastikan fasa 1 naik sebelum melihat fasa 2. Selagi fasa 1 turun, cadangan atau kunci yang dikongsi awal adalah salah, dan kerja pemilih tidak akan mengubahnya.

Pemilih mencerminkan, kemudian pembilang menentukan

Fasa 2 berfungsi hanya apabila kedua-dua hujung bersetuju tentang alamat yang dilindungi, dan persetujuan itu bercermin dan bukan dikongsi. Pemilih setempat Google mesti sepadan dengan pemilih yang dipanggil jauh oleh ASA, dan pemilih jauh Google dengan apa yang dipanggil setempat oleh ASA. Terowong dengan 0.0.0.0/0 di satu pihak dan satu subnet di pihak lain melepasi fasa 1 dan kemudian gagal fasa 2 dengan ralat utama yang sama. Tiada pihak boleh melebarkan senarai pihak lain.

Untuk pemilih berasaskan dasar, senaraikan setiap pasangan awalan dan simpan senarai dalam tiket. Subnet yang ditambah di premis kemudian memerlukan suntingan pada kedua-dua hujung, kerana laluan baharu pada ASA tidak melebarkan pemilih, dan hasilnya ialah terowong yang naik dan hanya melalukan trafik untuk awalan yang wujud pada hari pertama.

Akhiri dengan satu aliran hos ke hos dan baca pembilang bait di kedua-dua pihak. Pembilang yang meningkat pada ASA tetapi rata pada Google biasanya bermaksud balasan keluar melalui antara muka lain, atau pemilih tidak meliputi awalan balik. Catat algoritma, jangka hayat, pemilih dan nama terowong baharu, kerana perubahan cadangan seterusnya mengulangi pembinaan semula ini dan nilai itu menjadikannya kerja pendek.