FortiGate Azure kunci semula: cadangan peer SA tidak sepadan dengan dasar setempat

Tunnel naik, trafik mengalir, dan kemudian log berkata peer SA proposal not match local policy. Kebanyakan orang membaca baris itu sebagai bukti bahawa kedua-dua konfigurasi tidak pernah sepadan. Biasanya ia bermaksud sesuatu yang lebih sempit: kedua-duanya sepadan untuk CHILD SA pertama dan berhenti sepadan pada pembaharuan pertama, kerana persatuan pertama tidak pernah memerlukan pertukaran yang dilakukan oleh yang kemudian. Perbezaan itulah yang menentukan ke mana anda melihat.

CHILD SA pertama mewarisi, yang kemudian berunding

Dalam IKEv2, CHILD SA awal dicipta semasa IKE_AUTH, dan kuncinya diterbitkan daripada bahan kunci IKE SA. Tiada pertukaran Diffie-Hellman berasingan pada ketika itu, jadi kumpulan PFS yang tidak dapat diterima oleh satu peer belum diuji lagi. Tunnel kelihatan sihat kerana keperluan yang anda akan gagal kemudian tidak pernah diuji.

Kunci semula CHILD_SA ialah urutan mesej yang berbeza. Apabila PFS dikonfigurasikan, peer menjalankan pertukaran kunci baharu dan mesti bersetuju tentang kumpulan yang diterima oleh kedua-dua pihak, serta cadangan ESP untuk persatuan baharu. Ketika itulah ketidakpadanan menjadi kelihatan, dan sebab itulah ralat menamakan cadangan dan bukan laluan.

Jadi “semalam ia berfungsi” tidak memberitahu anda apa-apa tentang cadangan itu. Ia memberitahu anda bahawa pertukaran awal berjaya, yang anda sudah tahu.

Baca pertukaran yang gagal, bukan ping pertama

Kumpulkan pengesahan IKE yang berjaya, CHILD SA awal dan penggantian yang gagal daripada kedua-dua hujung sebelum mengubah apa-apa. Kemudian namakan operasi dengan tepat: kunci semula IKE SA, pengesahan semula IKE dan kunci semula CHILD SA ialah tiga peristiwa berbeza, dan “fasa 2” merangkumi kesemuanya dalam perbualan biasa.

Bandingkan medan di bawah untuk sambungan yang gagal, bukan untuk tunnel secara umum.

Pada FortiGate, buka cadangan fasa-2, tetapan PFS dan kumpulan DH yang diterima untuk tunnel itu. Baca nilai yang dimuatkan dan bukannya menyimpulkannya daripada sambungan yang terbentuk lebih awal. Tangkapan skrin halaman GUI ialah bukti yang lebih lemah daripada konfigurasi yang berjalan, kerana kedua-duanya boleh berbeza selepas peningkatan. Eksport bahagian yang anda ubah dan simpan bersama tiket.

Dasar lalai Azure tetap satu dasar

Tiada dasar tersuai yang dilampirkan pada sambungan tidak bermakna Azure tidak menggunakan apa-apa. Sambungan kembali kepada set cadangan lalai gateway, yang mungkin lebih luas atau lebih sempit daripada apa yang ditawarkan oleh FortiGate anda. Jika kedua-dua set bertindih untuk IKE tetapi tidak untuk ESP dengan PFS, anda mendapat corak kegagalan yang tepat ini.

Paparan baca sahaja ini menunjukkan dasar yang benar-benar dilampirkan, tanpa mendedahkan rahsia:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Gunakan nama sumber sebenar anda. Apabila dasar eksplisit diperlukan, tetapkan pada sumber sambungan. Ia bukan suis seluruh gateway, dan ia tidak terpakai secara senyap kepada tunnel lain pada gateway yang sama.

Dalam portal, halaman Configuration sambungan itu ialah tempat dasar IPsec/IKE tersuai diletakkan. Panduan Microsoft tentang dasar tersuai menyenaraikan parameter yang disokong dan keperluan SKU. Azure mengambil satu kombinasi lengkap bagi setiap sambungan, jadi anda menetapkan medan IKE dan medan IPsec bersama-sama, bukan satu demi satu.

PFS ialah keperluan, bukan suis untuk ditukar

Jika garis dasar keselamatan anda memerlukan PFS, penyelesaiannya ialah kumpulan yang diterima oleh kedua-dua peer di kedua-dua belah, dinyatakan melalui dasar yang sepadan. Mematikan PFS supaya ralat hilang mengubah sifat keselamatan yang anda cuba kekalkan, dan ia biasanya muncul semula kemudian sebagai ketidakpadanan lain.

Satu perangkap khusus Azure: apabila anda memilih GCM untuk ESP, pilihan penyulitan dan integriti mesti menamakan algoritma GCM dan panjang kunci yang sama. Mencampurkan sifer GCM dengan algoritma integriti berasingan menghasilkan kombinasi yang ditolak oleh perkhidmatan, dan ia kelihatan seperti ketidakpadanan peer sehingga anda membaca dasar dengan teliti.

Pilih kombinasi terkuat yang disokong oleh kedua-dua hujung dan dibenarkan oleh keperluan anda, kemudian catatkannya dalam rekod perubahan. Orang seterusnya akan membandingkan dengan rekod itu, bukan dengan ingatan tentang tunnel yang berfungsi. Masukkan kumpulan PFS dan cadangan ESP di dalamnya, bukan hanya nama dasar. Apabila seseorang bertanya kemudian mengapa audit gagal atau mengapa kunci semula lambat, baris itu menjawab kedua-dua soalan.

Sahkan pertukaran yang gagal

Jadualkan perubahan dengan laluan pemulihan, kerana menyunting dasar boleh mengganggu tunnel yang anda cuba baiki. Selepas trafik kembali, tunggu atau cetuskan pembaharuan CHILD_SA dan sahkan bahawa persatuan baharu ditubuhkan dengan kumpulan PFS yang dimaksudkan. Kemudian sahkan bahawa trafik aplikasi terus melaluinya.

Dua petunjuk palsu wajar dinamakan. Jangka hayat SA ialah spesifikasi setempat, jadi nilai yang tidak sama adalah normal dan mengubahnya hanya mengalihkan bila masalah muncul. DPD mengesan sama ada peer hidup; menaikkan had masanya tidak menyelaraskan pilihan ESP atau PFS.

Rekodkan hasil yang dirundingkan dan peristiwa berikutnya selepas perubahan. Jika sambungan kini gagal sebelum pengesahan IKE selesai, anda sedang melihat tetapan IKE yang baru anda sunting, bukan kegagalan pembaharuan CHILD yang asal.