MAC tidak sepadan dalam IKE bermakna pemeriksaan kunci dikongsi gagal

Log Cloud VPN anda menunjukkan percubaan kunci dikongsi diikuti MAC mismatched, dan naluri pertama selalunya mencari masalah alamat. Dalam cabang ini MAC ialah kod pengesahan mesej: nilai yang dikira atas pertukaran dengan kunci yang dirundingkan. Rakan sejawat membandingkan pengiraannya sendiri dengan nilai yang diterima, dan kedua-duanya berbeza. Tiada kad rangkaian terlibat, dan tiada tetapan antara muka mengubah perbandingan itu.

Dalam amalan dua keadaan menghasilkannya: rahsia di kedua-dua hujung bukan nilai yang sama, atau identiti yang digunakan untuk memilih rahsia tidak sepadan. Tentukan yang mana dengan membaca pasangan itu, bukan terowong tunggal.

Apa yang dibuktikan peringkat ini

Pemeriksaan berjalan selepas kedua-dua pihak menukar parameter awal dan mengenal pasti diri. Ia memilih kunci dikongsi calon untuk identiti tempatan dan jauh dan cuba mengesahkan data pengesahan yang diterima; apabila tiada yang sah, diagnosis dikeluarkan. Itu kenyataan kuat tentang pengesahan dan lemah tentang punca, kerana ia tidak menyatakan pihak mana yang salah.

Kejayaan terdahulu tidak terbawa ke pemeriksaan ini. IKE_SA_INIT yang selesai, atau muatan pengesanan NAT yang mengembalikan nilai yang dijangka, membuktikan rakan sejawat boleh berkomunikasi. Ia tidak membuktikan apa-apa tentang sama ada mereka berkongsi rahsia.

Dua ralat konfigurasi, satu mesej

Yang pertama ialah ketidakpadanan rahsia sebenar, dan biasanya ia kemalangan penyediaan: nilai yang dijana dipasang pada satu konsol dan ditaip semula pada yang lain, aksara mengekor yang terselamat di satu pihak, atau tanda petikan yang datang bersama tampal. Yang kedua ialah ketidakpadanan identiti, di mana rahsia itu betul tetapi identiti yang dikemukakan oleh rakan sejawat memilih entri lain, jadi rahsia yang betul tidak pernah dicuba. Kedua-duanya menghasilkan baris yang sama, sebab itu meneka mengambil masa satu petang.

Bandingkan pasangan itu sebelum menyentuh mana-mana rahsia. Padankan terowong, titik akhir rakan sejawat, tetingkap masa dan konfigurasi jauh, kerana dua terowong berlebihan boleh menyimpan rahsia berbeza dan skrin di hadapan anda mungkin bukan yang gagal.

Pengesanan NAT ialah peringkat lain

Pengesanan NAT bertanya bagaimana paket ditulis semula, bukan siapa rakan sejawat. Get laluan pelanggan di belakang NAT masih mengesahkan dengan betul apabila identiti yang dikonfigurasikan ialah yang dijangka oleh rakan sejawat, dan masalah NAT muncul sebagai ketidakpadanan cadangan atau port dan bukan perbandingan pengesahan yang gagal.

Jangan bawa kenyataan lama tentang satu keluaran vendor ke dalam penggunaan semasa. Apa yang diperlukan oleh lintasan NAT dalam keluaran anda tergolong dalam dokumentasinya sendiri, dan frasa MAC mismatch bukan bukti menyokong atau menentang.

Tentukan daripada pasangan, bukan skrin

Baca kedua-dua konfigurasi bersebelahan dengan rahsia disembunyikan, kemudian tanya tiga soalan. Adakah identiti pada setiap pihak tepat seperti yang dijangka oleh pihak lain, aksara demi aksara? Adakah kedua-dua hujung menggunakan versi IKE yang sama dan kaedah pengesahan yang sama? Adakah terowong yang gagal sepadan dengan konfigurasi yang anda baca? 'Tidak' pada mana-mana satu daripadanya menentukan pembaikan tanpa menyentuh rahsia.

Jika ketiga-tiganya bersih, gantikan rahsia melalui aliran kerja yang diluluskan dan bukannya menyunting di sekelilingnya.

Selepas rakan sejawat mengesahkan

Sebaik sahaja pengesahan berjaya, permukaan kegagalan seterusnya ialah persatuan keselamatan anak: cadangan dan pemilih trafik. Memutar rahsia yang sudah diterima tidak dapat membaiki kegagalan anak, dan ia memanjangkan gangguan. Baca keadaan anak, kemudian pemilih dan julat terlindung di kedua-dua pihak, dan padankan panduan penyelesaian masalah Cloud VPN dengan peringkat yang benar-benar gagal.

Kaitkan log baharu dari kedua-dua hujung untuk pasangan dan tetingkap yang sama. Satu pihak sahaja memberikan keputusan tanpa input pihak lain, dan itulah kekaburan yang menghasilkan mesej itu pada mulanya.

Apa yang tidak patut disimpulkan

Jangan baca mesej itu sebagai tuntutan untuk menukar alamat MAC, dan jangan terbitkan rahsia dikongsi semasa meminta bantuan; petikan yang mengandungi kunci perlu kuncinya dibuang, bukan log disimpan. Jangan anggap kerosakan penghalaan juga, kerana rakan sejawat yang tidak dapat saling mencapai tidak menghasilkan sebarang perbandingan pengesahan. Dan jangan menggeneralisasi had terdokumentasi satu keluarga produk kepada setiap pelaksanaan IPsec.

Rekodkan pasangan yang gagal, keadaan terowong sebelum dan selepas, dan keadaan mana antara dua itu yang anda ubah. Rekod itu menjadikan kejadian seterusnya pemeriksaan lima minit.