Sijil gateway sudah betul: mengapa log masuk IKEv2 PEAP masih gagal

Sijil gateway VPN anda masih sah, rantaian disahkan, dan klien IKEv2 masih menolak log masuk dengan mesej tentang selang kesahihan sijil. Naluri pertama ialah mengeluarkan semula sijil gateway atau menukar kaedah EAP, dan kedua-duanya biasanya salah. Percubaan log masuk membawa dua identiti pelayan yang berasingan: sijil gateway yang digunakan oleh IKE, dan sijil yang dibentangkan oleh apa sahaja yang menamatkan PEAP. Salah satunya betul, dan yang satu lagi ialah sebab klien berhenti.

Dua identiti, satu percubaan log masuk

Sijil dalam profil VPN tergolong dalam pertukaran IKE: ia membuktikan bahawa gateway ialah rakan yang dinamakan oleh profil, di bawah dasar IKE yang dikonfigurasikan. Sijil yang gagal di sini tergolong dalam perbualan lain, sesi TLS yang dibuka PEAP dengan apa sahaja yang mengesahkan pengguna, yang selalunya pelayan RADIUS seperti NPS dan bukan gateway itu sendiri. Semakan ketiga, kelayakan pengguna, berlaku di dalam sesi itu. Kata laluan yang sah tidak boleh membaiki sijil pelayan yang tamat tempoh, dan sijil gateway yang sah tidak boleh menjamin titik akhir PEAP.

Pelapisan ini menjelaskan mengapa ralat sijil muncul di tempat yang satu-satunya sijil dikonfigurasikan ialah sijil gateway. Ia juga menjelaskan mengapa mengeluarkan semula sijil itu tidak mengubah apa-apa.

Baca baris log berbanding peringkat

Cari mesej yang menamakan sebab dan tarikh. Aduan tentang selang kesahihan di sebelah ralat subjek bermakna pelayan menolak sijil yang diberikan kepadanya, bukan pengguna menolak log masuk. Kemudian cari peringkat: log charon strongSwan menunjukkan IKE_SA .* established sebelum pertukaran EAP bermula, jadi ralat sijil selepas baris itu tergolong dalam identiti EAP, manakala ralat sebelumnya menunjuk kepada gateway. Teks peringkat dalam panel sambungan klien Windows mengatakan perkara yang sama.

Periksa jam klien sebelum menyentuh mana-mana sijil. Peranti yang terpesong beberapa jam menghasilkan ralat kesahihan yang sama seperti sijil yang benar-benar tamat tempoh. Menetapkan semula jam ialah pembetulan lima saat, dan menggantikan sijil yang tidak pernah menjadi masalah ialah gangguan perkhidmatan.

Ketahui titik akhir mana yang menamatkan PEAP

Dalam reka bentuk gateway tambah RADIUS, gateway meneruskan EAP dan tidak menamatkannya. Pemalam eap-radius strongSwan menyerahkan pertukaran kepada pelayan RADIUS, yang memiliki sesi TLS PEAP dan sijilnya. Kaitkan satu percubaan gagal dalam kedua-dua log dan sahkan proses mana yang benar-benar memilih sijil untuk sesi itu.

Untuk NPS sijil mesti berada dalam stor komputer setempat, membawa tujuan pengesahan pelayan, sepadan dengan nama yang dijangka oleh klien, dan boleh dibaca oleh akaun perkhidmatan. Keperluan sijil Microsoft untuk NPS menyenaraikan syarat-syarat itu. Pelayan EAP lain mempunyai peraturan pemilihan sendiri, jadi jangan salin keistimewaan NPS ke dalam penggunaan FreeRADIUS atau sebaliknya. Peraturan yang kekal dalam kedua-dua keadaan ialah titik akhir yang menamatkan PEAP memiliki sijil yang akan anda tukar.

Gantikan sijil di tempat EAP tamat

Perbaharui atau gantikan sijil pada titik akhir yang menamatkan PEAP, melalui proses yang disokong, dengan mengekalkan tujuan pengesahan pelayan dan nama yang dijangka. Pasang rantaian penuh di tempat perkhidmatan mencarinya dan beri perkhidmatan akses kepada kunci peribadi. Mulakan semula atau ikat semula perkhidmatan, kerana banyak perkhidmatan menyimpan sijil lama dalam memori dan terus membentangkannya. Fail yang disalin ke mesin tidak membuktikan apa-apa tentang sijil yang sebenarnya dibentangkan oleh perkhidmatan.

Sahkan perubahan dengan mengaitkan percubaan seterusnya dengan log perkhidmatan itu sendiri, atau dengan memeriksa sijil yang dibentangkan oleh sesi. Jika log itu masih menunjukkan cap jari lama, permulaan semula tidak berkesan.

Jangan andaikan bahawa fail terbaharu dalam direktori ialah yang sedang digunakan. Salinan dengan nama yang betul dan kebenaran yang salah tidak mengubah apa-apa. Nilai perubahan itu dari segi identiti yang dibentangkan, bukan cap masa fail.

Apa yang tidak patut dilakukan

Jangan lumpuhkan pengesahan PEAP atau paksa kaedah dalaman yang lebih lemah untuk melepasi ralat. Itu mengubah dasar dan membuang sifat pengesahan pelayan yang menangkap sijil tamat tempoh pada mulanya. Anda akan menukar semakan yang berfungsi dengan sambungan yang berfungsi, dan sijil tamat tempoh seterusnya akan tiba tanpa apa-apa yang mengumumkannya.

Jangan anggap sambungan berjaya sistem pengendalian lain sebagai bukti bahawa sijil itu boleh diterima. Klien itu mungkin menggunakan kaedah EAP lain, stor kepercayaan lain atau tiada pengesahan pelayan langsung, jadi kejayaannya tidak mengatakan apa-apa tentang semakan yang gagal di sini. Kekalkan satu ujian negatif yang disengajakan, seperti sijil dengan nama salah atau rantaian yang tidak dipercayai, yang gagal seperti dijangka. Jika ujian itu kini lulus, anda telah membuang semakan dan bukan membaiki sijil. Catat identiti mana yang gagal, supaya orang seterusnya tidak bermula lagi dengan sijil gateway.