FortiGate Azure rekey: proposal peer SA tidak cocok dengan kebijakan lokal
Tunnel IKEv2 yang berfungsi tetap bisa menolak CHILD SA pengganti. Bandingkan proposal yang benar-benar dinegosiasikan pembaruan, bukan yang dipakai ping pertama.
Tunnel naik, lalu lintas mengalir, dan kemudian log berkata peer SA proposal not match local policy. Sebagian besar orang membaca baris itu sebagai bukti bahwa kedua konfigurasi tidak pernah cocok. Biasanya artinya lebih sempit: keduanya cocok untuk CHILD SA pertama dan berhenti cocok pada pembaruan pertama, karena asosiasi pertama tidak pernah memerlukan pertukaran yang dilakukan asosiasi berikutnya. Perbedaan itulah yang menentukan ke mana Anda mencari.
CHILD SA pertama mewarisi, yang berikutnya menegosiasikan
Dalam IKEv2, CHILD SA awal dibuat selama IKE_AUTH, dan kuncinya diturunkan dari materi kunci IKE SA. Tidak ada pertukaran Diffie-Hellman terpisah pada titik itu, jadi grup PFS yang tidak dapat diterima salah satu peer belum diuji. Tunnel tampak sehat karena persyaratan yang nanti akan Anda gagalkan belum pernah diuji.
Rekey CHILD_SA adalah urutan pesan yang berbeda. Saat PFS dikonfigurasi, para peer menjalankan pertukaran kunci baru dan harus menyepakati grup yang diterima kedua sisi, ditambah proposal ESP untuk asosiasi baru. Saat itulah ketidakcocokan menjadi terlihat, dan karena itu kesalahan menyebut proposal, bukan rute.
Jadi “kemarin berhasil” tidak memberi tahu Anda apa pun tentang proposal. Itu memberi tahu bahwa pertukaran awal berhasil, yang sudah Anda ketahui.
Baca pertukaran yang gagal, bukan ping pertama
Kumpulkan autentikasi IKE yang berhasil, CHILD SA awal, dan penggantian yang gagal dari kedua ujung sebelum mengubah apa pun. Lalu sebut operasinya dengan tepat: rekey IKE SA, autentikasi ulang IKE, dan rekey CHILD SA adalah tiga peristiwa berbeda, dan “fase 2” mencakup semuanya dalam percakapan sehari-hari.
Bandingkan bidang di bawah ini untuk koneksi yang gagal, bukan untuk tunnel secara umum.
| Lapisan | Nilai yang dibandingkan |
|---|---|
| IKE | Versi, enkripsi dan integritas atau susunan PRF, grup DH |
| IPsec / CHILD | Enkripsi dan integritas ESP, grup PFS atau pertukaran kunci yang dimaksud |
| Lalu lintas terlindungi | Selektor lokal dan jarak jauh, plus pengaturan selektor berbasis kebijakan apa pun |
Di FortiGate, buka proposal fase-2, pengaturan PFS, dan grup DH yang diterima untuk tunnel itu. Baca nilai yang dimuat, bukan menyimpulkannya dari koneksi yang terbentuk sebelumnya. Tangkapan layar halaman GUI adalah bukti yang lebih lemah daripada konfigurasi yang berjalan, karena keduanya bisa berbeda setelah peningkatan. Ekspor bagian yang Anda ubah dan simpan bersama tiket.
Kebijakan default Azure tetap sebuah kebijakan
Tidak adanya kebijakan khusus yang dilampirkan pada koneksi bukan berarti Azure tidak menerapkan apa pun. Koneksi kembali ke kumpulan proposal default gateway, yang bisa lebih luas atau lebih sempit daripada yang ditawarkan FortiGate Anda. Jika kedua kumpulan tumpang tindih untuk IKE tetapi tidak untuk ESP dengan PFS, Anda mendapatkan pola kegagalan persis seperti ini.
Tampilan hanya-baca ini menunjukkan kebijakan yang benar-benar dilampirkan, tanpa membocorkan rahasia:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesGunakan nama sumber daya Anda yang sebenarnya. Saat kebijakan eksplisit diperlukan, setel pada sumber daya koneksi. Itu bukan sakelar seluruh gateway, dan tidak berlaku diam-diam pada tunnel lain di gateway yang sama.
Di portal, halaman Configuration koneksi itu adalah tempat kebijakan IPsec/IKE khusus berada. Panduan Microsoft tentang kebijakan khusus mencantumkan parameter yang didukung dan persyaratan SKU. Azure mengambil satu kombinasi lengkap per koneksi, jadi Anda menentukan bidang IKE dan bidang IPsec sekaligus, bukan satu per satu.
PFS adalah persyaratan, bukan sakelar untuk dibalik
Jika garis dasar keamanan Anda mensyaratkan PFS, solusinya adalah grup yang diterima kedua peer di kedua sisi, dinyatakan melalui kebijakan yang cocok. Mematikan PFS agar kesalahan hilang mengubah properti keamanan yang ingin Anda pertahankan, dan biasanya muncul lagi nanti sebagai ketidakcocokan lain.
Satu jebakan khusus Azure: saat Anda memilih GCM untuk ESP, pilihan enkripsi dan integritas harus menyebutkan algoritme GCM dan panjang kunci yang sama. Mencampur cipher GCM dengan algoritme integritas terpisah menghasilkan kombinasi yang ditolak layanan, dan itu tampak seperti ketidakcocokan peer sampai Anda membaca kebijakan dengan cermat.
Pilih kombinasi terkuat yang didukung kedua ujung dan diizinkan persyaratan Anda, lalu tuliskan di catatan perubahan. Orang berikutnya akan membandingkan dengan catatan itu, bukan dengan ingatan tentang tunnel yang berfungsi. Masukkan grup PFS dan proposal ESP di dalamnya, bukan hanya nama kebijakan. Saat seseorang nanti bertanya mengapa audit gagal atau mengapa rekey lambat, baris itu menjawab kedua pertanyaan.
Verifikasi pertukaran yang gagal
Jadwalkan perubahan dengan jalur pemulihan, karena mengedit kebijakan dapat mengganggu tunnel yang sedang Anda perbaiki. Setelah lalu lintas kembali, tunggu atau picu pembaruan CHILD_SA dan pastikan asosiasi baru terbentuk dengan grup PFS yang dimaksud. Lalu pastikan lalu lintas aplikasi terus melewatinya.
Dua jalan buntu palsu layak disebut. Masa hidup SA adalah spesifikasi lokal, jadi nilai yang tidak sama itu normal dan mengubahnya hanya menggeser kapan masalah muncul. DPD mendeteksi apakah peer hidup; menaikkan batas waktunya tidak menyelaraskan pilihan ESP atau PFS.
Catat hasil yang dinegosiasikan dan peristiwa berikutnya setelah perubahan. Jika koneksi sekarang gagal sebelum autentikasi IKE selesai, Anda sedang melihat pengaturan IKE yang baru saja Anda edit, bukan kegagalan pembaruan CHILD yang asli.