Mengapa Windows IKEv2 asli langsung tiada medan PSK

Dokumentasi get laluan menyatakan kunci yang dikongsi terlebih dahulu dimasukkan ke dalam klien, tetapi profil Windows tiada medan untuknya. Jurang ini bukan pepijat yang dielakkan dengan menaip kunci dalam kotak kata laluan. Ia ialah perbezaan antara apa yang boleh dilakukan protokol dan apa yang ditawarkan oleh pelaksanaan tertentu.

Keupayaan protokol bukan sokongan klien

Spesifikasi IKEv2 merangkumi pengesahan kunci dikongsi, jadi get laluan boleh dikonfigurasikan untuknya secara sah. Profil capaian jauh asli Windows sebaliknya mendokumenkan susunan sijil dan EAP, dan keupayaan protokol tidak mencipta medan, parameter atau nilai pendaftaran yang klien tidak pernah miliki.

Orang biasanya berakhir di rujukan PowerShell untuk menambah sambungan VPN, dan di sana L2tpPsk dipaparkan untuk susunan L2TP. Parameter itu milik L2TP dan bukan rahsia IKEv2 umum. Tetapan pemilihan algoritma memilih parameter perlindungan, yang merupakan perkara ketiga dan tidak berkaitan. Peranan penghalaan Windows Server juga bukan objek yang sama. Antara muka pelayan boleh mempunyai kawalan konfigurasi yang tiada pada profil klien desktop, dan menyalin tetapan pelayan ke profil stesen kerja tidak menghasilkan semula keupayaan itu.

Pilih antara sijil, EAP atau L2TP

Jika pengendali get laluan menerima pengesahan sijil, itu biasanya destinasi paling bersih: klien mengemukakan sijil, get laluan mengesahkannya dengan pengeluar dipercayai, dan tiada rahsia dikongsi tertinggal dalam profil untuk disalin oleh sesiapa. Ia memerlukan pendaftaran, rantaian dipercayai dan konfigurasi get laluan yang memetakan sijil kepada keputusan kebenaran.

EAP dengan kelayakan pengguna ialah laluan lain yang disokong pada klien ini, dan ia memindahkan keputusan kepada pembekal identiti. Ia juga membawa kebergantungannya sendiri, kerana kaedah EAP, sijil pelayan dan kepercayaan klien terhadap sijil itu semuanya mesti selaras. Bertukar kepada L2TP/IPsec semata-mata untuk mendapatkan medan biasa mengubah tindanan protokol. Itu boleh diterima apabila ia pilihan yang disokong dengan sebab didokumenkan, dan ia hasil yang buruk apabila ia berlaku kerana seseorang mencari kotak untuk menaip kunci.

Semak apa yang akan diterima oleh get laluan

Tanya pengendali kaedah pengesahan yang ditawarkan oleh perkhidmatan capaian jauh hari ini, bukan yang disokong produk secara umum. Perkhidmatan yang dikonfigurasikan untuk IKEv2 dengan PSK sahaja tidak akan menerima sijil kerana klien lebih menyukainya.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Baca kaedah pengesahan profil dan stor sijil bersama-sama. Profil yang ditetapkan kepada EAP tanpa sijil boleh guna di belakangnya gagal dengan cara yang kelihatan seperti masalah pelayan.

Jika jawapannya hanya PSK tersedia, pilihan jujurnya ialah klien diluluskan yang menyokongnya atau perubahan pada reka bentuk pengesahan get laluan. Kedua-duanya bukan jalan pintas setempat, dan berpura-pura sebaliknya menghasilkan sambungan yang hanya boleh dihasilkan semula oleh orang yang mengkonfigurasikannya.

Catat keputusan dan rahsianya

Catat kaedah yang dipilih, sauh kepercayaan, identiti yang sepadan dengannya dan orang yang meluluskan perubahan itu. Rekod itulah yang diperlukan oleh semakan insiden, dan ia juga menghalang jurutera seterusnya daripada menemui semula jalan mati yang sama.

Asingkan rahsia dalam nota anda: kata laluan akaun, frasa laluan kunci peribadi dan kunci yang dikongsi terlebih dahulu bagi get laluan ialah tiga perkara berbeza, walaupun skrin tetapan menamakan semuanya kata laluan. Mengelirukannya ialah cara kunci berakhir dalam tiket. Uji profil yang terhasil dengan sambungan baharu dan satu permintaan aplikasi ke sumber peribadi. Terowong berjaya tanpa perkhidmatan yang boleh dicapai ialah hasil separa, dan profil tidak sepatutnya digambarkan sebagai siap sehingga sumber itu juga berfungsi.