Bagaimana pengesahan hibrid IKEv1 beralih kepada pengesahan pengguna IKEv2
Mod hibrid memisahkan bukti gerbang daripada bukti pengguna. Peralihan kepada IKEv2 mengekalkan pemisahan itu tetapi mengubah pertukaran, kaedah EAP dan pemeriksaan sijil.
Setiap profil VPN lama yang meminta sijil pelayan lalu nama pengguna membawa dua peristiwa pengesahan dalam satu pertukaran, dan bentuk itu hidup lebih lama daripada protokol yang memperkenalkannya. Mod hibrid IKEv1 dibina tepat untuk ini: gerbang membuktikan dirinya dengan kunci awam manakala pengguna membuktikan dirinya kemudian melalui XAuth. IKEv2 menyatakan idea dua langkah yang sama dengan mekanisme berbeza, dan dalam perbezaan itulah migrasi gagal. Tiada nombor versi menukar yang satu kepada yang lain, dan menyalin nama pilihan lama ke profil baharu menghasilkan klien yang berunding lalu tidak mengesahkan apa-apa.
Apa yang dilakukan mod hibrid di dalam IKEv1
Dalam profil hibrid pihak penjawab menandatangani pertukaran fasa satu dengan sijilnya manakala pemula sengaja tidak mengemukakan sebarang sijil. Bukti identiti kerana itu tidak simetri, dan itulah yang membolehkan gerbang mengekalkan PKI sedia ada sementara pengguna mengekalkan kata laluan direktori mereka. Setelah fasa satu selesai, XAuth berjalan sebagai permintaan dan jawapan yang membawa atribut nama pengguna dan kata laluan di dalam saluran ISAKMP yang kini disulitkan.
Perhatikan ke mana kepercayaan itu mendarat. Sijil menjawab gerbang mana yang dicapai oleh klien; XAuth menjawab pengguna mana yang mahu akses. Tiada satu menggantikan yang lain, dan klien yang ditetapkan menerima sebarang sijil pelayan telah diam-diam membuang jawapan pertama. Label hibrid juga digunakan untuk mod agresif dengan kunci yang dikongsi lebih awal serta XAuth, susunan lain dengan pengalaman pengguna yang sama, jadi baca profilnya bukan namanya. Kedua-dua varian datang daripada draf yang tidak pernah menjadi piawaian, dan kerana itu dua vendor boleh melaksanakan mod hibrid dan tidak berinteroperasi dengan sesiapa.
Bagaimana IKEv2 mencapai dua bukti yang sama
IKEv2 membahagikan kerja antara IKE_SA_INIT dan IKE_AUTH. Pertukaran pertama menyetujui cadangan dan kunci tanpa sebarang identiti; yang kedua membawa IDi, IDr dan muatan AUTH. Di bawah EAP muatan AUTH pertama pemula keluar kosong, penjawab mengesahkan dirinya dahulu dengan sijil dan tandatangannya, kemudian perbualan EAP berjalan di dalam mesej IKE_AUTH.
Mekanisme yang menjadikan ini selamat ialah bahan kunci. Kaedah EAP yang berjaya mengeksport kunci sesi, dan muatan AUTH terakhir pemula dikira daripadanya, jadi bukti pengguna dan kunci terowong terikat bersama. XAuth tiada persamaan: atributnya tiba selepas fasa satu dan tidak menyumbang apa-apa kepada kunci. Jurang itulah yang direka bentuk untuk ditutup oleh rangka IKEv2, dan kerana itu log masuk IKEv2 yang berfungsi mengesahkan sijil pelayan sebelum meminta apa-apa.
Urutan ini juga diagnostik yang berguna. Apabila klien mengeluh tentang kelayakan sebelum menunjukkan sijil kepada anda, ia langsung tidak melakukan pertukaran EAP IKEv2.
Kekalkan tiga identiti berasingan
Migrasi menjadi salah apabila tiga identiti runtuh ke satu medan. Ada identiti gerbang yang disahkan klien, biasanya nama DNS dalam subject atau SAN sijil. Ada identiti pengguna yang dikemukakan dalam EAP, mungkin log masuk domain, alamat atau rentetan identiti EAP yang jelas. Dan ada sumber kebenaran yang memetakan pengguna itu kepada rangkaian dan laluan.
Sintaks swanctl strongSwan menjadikan pemisahan itu kelihatan: sambungan menetapkan remote { auth = pubkey } untuk gerbang dan local { auth = eap-mschapv2 } untuk pengguna, dengan identiti EAP dibawa berasingan.
Apabila identiti pengguna dalam profil baharu berbeza daripada atribut XAuth lama, contohnya UPN dan bukannya nama pendek, pelayan pengesahan melihat pengguna yang tidak dikenali dan kegagalan itu kelihatan seperti kata laluan salah. Periksa rentetan identiti sebelum memeriksa kelayakan.
Petakan pilihan lalu jangkakan perangkapnya
Pemetaan itu pendek dan setiap baris mempunyai perangkap yang hanya muncul semasa pengesahan.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Tiada baris itu semata-mata menukar nama. Muatan konfigurasi menyampaikan alamat dan penyelesai melalui senarai atribut bertipe, manakala ruang atribut XAuth ialah ciptaannya sendiri; menganggapnya boleh ditukar ganti ialah cara sesuatu profil akhirnya meminta tetapan yang tidak akan dihantar oleh gerbang.
Pemilih trafik wajar mendapat amaran tersendiri. IKEv1 menyatakan trafik menarik melalui ID proksi yang terikat kepada pertukaran quick mode, manakala IKEv2 merundingkan pemilih semasa IKE_AUTH dan penjawab boleh menyempitkannya. Ketidakpadanan menghasilkan IKE SA yang terbentuk tanpa child SA, yang sesetengah klien dengan gembira memaparkannya sebagai bersambung.
Layan sambungan lama sebagai sempadan
RFC 9395 menyatakan IKEv1 usang, jadi sambungan hibrid lama ialah sempadan keserasian bertarikh, bukan asas. Jalankan kedua-dua profil bersebelahan semasa perubahan, kerana ujian yang penting bukanlah sama ada profil baharu naik, tetapi sama ada pengguna yang sama pada peranti yang sama mencapai sumber yang sama.
Kekalkan pengesahan sijil secara ketat sepanjang masa. Sebaik klien berhenti mengemukakan sijilnya sendiri, godaan ialah melonggarkan pemeriksaan pelayan sehingga jabat tangan selesai, dan itu menukar satu-satunya bukti yang tinggal dengan ikon hijau.
Tulis empat perkara sebelum bersara profil lama: kaedah EAP, rentetan identiti, sumber kebenaran dan tarikh sokongan tamat.