MAC tidak cocok di IKE berarti pemeriksaan kunci bersama gagal

Log Cloud VPN Anda menunjukkan upaya kunci bersama yang diikuti MAC mismatched, dan dorongan pertama sering kali mencari masalah alamat. Pada cabang ini MAC adalah kode autentikasi pesan: nilai yang dihitung atas pertukaran dengan kunci yang dinegosiasikan. Rekan membandingkan perhitungannya sendiri dengan nilai yang diterimanya, dan keduanya berbeda. Tidak ada kartu jaringan yang terlibat, dan tidak ada pengaturan antarmuka yang mengubah perbandingan itu.

Dalam praktiknya dua kondisi menghasilkannya: rahasia di kedua ujung bukan nilai yang sama, atau identitas yang digunakan untuk memilih rahasia tidak bersesuaian. Tentukan yang mana dengan membaca pasangannya, bukan satu tunnel.

Apa yang dibuktikan tahap ini

Pemeriksaan berjalan setelah kedua pihak bertukar parameter awal dan mengidentifikasi diri. Pemeriksaan memilih kandidat kunci bersama untuk identitas lokal dan jarak jauh lalu mencoba memvalidasi data autentikasi yang diterima; bila tidak ada yang valid, diagnostik dikeluarkan. Itu pernyataan kuat tentang autentikasi dan lemah tentang penyebab, karena tidak menyebut pihak mana yang salah.

Keberhasilan sebelumnya tidak terbawa ke pemeriksaan ini. IKE_SA_INIT yang selesai, atau muatan deteksi NAT yang mengembalikan nilai yang diharapkan, membuktikan kedua rekan dapat berbicara. Itu tidak membuktikan apa pun tentang apakah mereka berbagi rahasia.

Dua kesalahan konfigurasi, satu pesan

Yang pertama adalah ketidakcocokan rahasia sungguhan, dan biasanya kecelakaan penyediaan: nilai yang dibuat dipasang di satu konsol dan diketik ulang di konsol lain, karakter di akhir yang bertahan di satu sisi, atau tanda kutip yang ikut saat menempel. Yang kedua adalah ketidakcocokan identitas, ketika rahasianya benar tetapi identitas yang disajikan rekan memilih entri berbeda, sehingga rahasia yang tepat tidak pernah dicoba. Keduanya menghasilkan baris yang sama, karena itu menebak memakan waktu satu sore.

Bandingkan pasangannya sebelum menyentuh rahasia mana pun. Cocokkan tunnel, titik akhir rekan, jendela waktu, dan konfigurasi jarak jauh, karena dua tunnel redundan dapat menyimpan rahasia berbeda dan layar di depan Anda mungkin bukan yang gagal.

Deteksi NAT adalah tahap lain

Deteksi NAT menanyakan bagaimana paket ditulis ulang, bukan siapa rekannya. Gateway pelanggan di belakang NAT tetap mengautentikasi dengan benar ketika identitas yang dikonfigurasi adalah yang diharapkan rekan, dan masalah NAT muncul sebagai ketidakcocokan proposal atau port, bukan perbandingan autentikasi yang gagal.

Jangan membawa pernyataan lama tentang satu rilis vendor ke penerapan saat ini. Apa yang dibutuhkan lintasan NAT pada rilis Anda ada di dokumentasinya sendiri, dan frasa MAC mismatch bukan bukti untuk atau menentangnya.

Putuskan dari pasangannya, bukan dari layar

Baca kedua konfigurasi berdampingan dengan rahasia disamarkan, lalu ajukan tiga pertanyaan. Apakah identitas di setiap sisi persis seperti yang diharapkan sisi lain, karakter demi karakter? Apakah kedua ujung menggunakan versi IKE dan metode autentikasi yang sama? Apakah tunnel yang gagal sesuai dengan konfigurasi yang Anda baca? Jawaban tidak pada salah satunya menentukan perbaikan tanpa menyentuh rahasia.

Jika ketiganya bersih, ganti rahasia melalui alur kerja yang disetujui alih-alih menyunting di sekitarnya.

Setelah rekan mengautentikasi

Setelah autentikasi berhasil, permukaan kegagalan berikutnya adalah asosiasi keamanan anak: proposal dan pemilih lalu lintas. Merotasi rahasia yang sudah diterima tidak dapat memperbaiki kegagalan anak, dan memperpanjang gangguan. Baca status anak, lalu pemilih dan rentang terlindungi di kedua sisi, dan cocokkan panduan pemecahan masalah Cloud VPN dengan tahap yang benar-benar gagal.

Korelasikan log baru dari kedua ujung untuk pasangan dan jendela yang sama. Satu sisi saja memberi putusan tanpa masukan sisi lain, dan itulah ambiguitas yang pada awalnya menghasilkan pesan itu.

Apa yang tidak boleh disimpulkan

Jangan membaca pesan sebagai tuntutan mengganti alamat MAC, dan jangan menerbitkan rahasia bersama saat meminta bantuan; kutipan yang berisi kunci harus menghapus kuncinya, bukan menyimpan lognya. Jangan pula menganggap ada kesalahan perutean, karena rekan yang tidak dapat saling menjangkau tidak menghasilkan perbandingan autentikasi sama sekali. Dan jangan menggeneralisasi batasan terdokumentasi satu keluarga produk ke setiap implementasi IPsec.

Catat pasangan yang gagal, status tunnel sebelum dan sesudah, dan kondisi mana dari dua itu yang Anda ubah. Catatan itu menjadikan kejadian berikutnya pemeriksaan lima menit.