IKEv1 dengan XAuth dan OTP: apa yang diminta tiap prompt
PSK grup, pertukaran XAuth pengguna, dan tantangan OTP adalah tiga masukan yang berbeda. Cocokkan tiap prompt dengan pemiliknya sebelum memasang klien lain.
IKEv1 dengan PSK, XAuth, dan OTP tidak meminta satu kata sandi yang rumit. Lapisan yang ditumpuknya adalah kunci bersama antar peer, pertukaran pengguna, dan faktor kedua yang cara memintanya ditentukan oleh backend. Setiap lapisan punya pemilik dan pesan kegagalannya sendiri. Mencampuradukkan ketiganya membuat orang mengetik ulang kode sekali pakai ke kolom yang menyimpan rahasia grup.
Cocokkan tiap prompt dengan lapisan yang memintanya sebelum memasang klien lain atau mengatur ulang kredensial.
Tiga rahasia, tiga pemilik
Kunci pre-shared milik hubungan antar peer dan dikonfigurasi sekali oleh pihak yang mengelola kedua ujung. Kredensial pengguna milik backend autentikasi dan divalidasi pada tiap login. Faktor kedua milik sistem token yang responsnya berubah pada tiap percobaan. Tidak ada yang menggantikan yang lain, dan penerapan yang memperlakukan ketiganya sebagai satu kata sandi akan gagal pada lapisan yang tidak didokumentasikan siapa pun.
Tuliskan tiga kolom: pemilik, masa berlaku, dan pesan kegagalan yang dihasilkan masing-masing. Tabel itulah alat diagnosisnya, bukan nama kolom di klien.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: milik peer, bukan milik orang
Dalam susunan lama ini, kunci pre-shared mengautentikasi pasangan gateway, sehingga login pengguna tidak pernah menggantikannya. Nilai ini juga paling sering salah dengan cara yang menghasilkan galat negosiasi umum alih-alih prompt. Bila tunnel gagal sebelum prompt pengguna muncul, tersangkanya adalah kunci atau proposal.
Kredensial pengguna tidak bisa memperbaiki kegagalan fase pertama. Merotasinya hanya membuang satu-satunya kredensial yang aman untuk dirotasi, dan memperkuat teori yang salah.
XAuth: pertukaran pengguna warisan
XAuth menambahkan pertukaran autentikasi pengguna di atas autentikasi peer IKEv1, dan gateway yang menentukan backend mana yang memvalidasinya. Bergantung pada backend itu, pertukaran dapat menerima kata sandi direktori, kredensial RADIUS, atau respons token. Kata XAuth menamai transport pertukaran, bukan jenis kredensial.
Periksa backend mana yang dituju profil gateway. Itu memberi tahu apa yang akan diminta dari pengguna dan apa yang sebenarnya diubah oleh reset kata sandi, dan keduanya tidak terlihat di profil klien.
OTP: tergantung apa yang diminta backend
Sebagian penerapan meminta kode sekali pakai terpisah setelah kata sandi, sementara yang lain mendefinisikan format masukan gabungan dengan pemisah yang didokumentasikan. Keduanya ada, dan profil di depan Anda yang menentukan. Mengarang cara penggabungan karena berhasil di situs lain adalah cara paling umum membakar token pendaftaran. Dokumentasi gateway sendiri adalah satu-satunya sumber yang memutuskan.
Gunakan format yang didokumentasikan dengan klien yang dapat menyelesaikan pertukaran yang ditawarkan gateway.
Di mana batas klien menggigit
Fortinet menyatakan bahwa FortiClient 7.4.4 dan versi setelahnya tidak lagi mendukung IKEv1 untuk VPN IPsec, yang merupakan batas produk dan versi, bukan penghapusan menyeluruh, sebagaimana dicatat dalam catatan kompatibilitas FortiClient. Klien lain juga tidak bisa saling menggantikan: OpenConnect dan openfortivpn berbicara protokol gateway tertentu, bukan profil IKEv1 sembarang. Periksa versi IKE, mode PSK, dukungan XAuth, dan model interaksi klien yang terpasang satu per satu. Klien yang terhubung dengan metode lain belum membuktikan kebutuhan aslinya.
IKEv1 sudah usang, jadi peluncuran baru di atas klien lama yang tidak didukung adalah solusi berumur pendek. Mintalah jalur migrasi yang didukung kepada pemilik gateway, termasuk bagaimana faktor kedua akan ditangani di sana.
Mendiagnosis tanpa mematikan faktor
Pisahkan tahapan di log: negosiasi peer, pertukaran pengguna, hasil faktor kedua, lalu penetapan alamat dan rute. Catat komponen dan tahapannya alih-alih mencoba kode di setiap kolom. Mematikan faktor agar sebuah uji lolos menghasilkan tunnel yang tidak membuktikan apa pun tentang penerapan.
Simpan rahasia pendaftaran dan kunci bersama di penyimpanan terproteksi sesuai proses organisasi. Kode sekali pakai di berkas permanen adalah faktor yang sudah berhenti menjadi faktor.