Dokumentasi gateway menyebut kunci yang dibagikan sebelumnya diisi di klien, tetapi profil Windows tidak punya kolom untuk itu. Celah ini bukan bug yang diakali dengan mengetik kunci di kotak kata sandi. Ini adalah beda antara apa yang bisa dilakukan protokol dan apa yang ditawarkan implementasi tertentu.

Kemampuan protokol bukan dukungan klien

Spesifikasi IKEv2 mencakup autentikasi kunci bersama, jadi gateway sah-sah saja dikonfigurasi untuk itu. Profil akses jarak jauh bawaan Windows justru mendokumentasikan pengaturan sertifikat dan EAP, dan kemampuan protokol tidak menciptakan kolom, parameter, atau nilai registri yang tidak pernah dimiliki klien.

Orang biasanya berakhir di referensi PowerShell untuk menambahkan koneksi VPN, dan di sana ditampilkan L2tpPsk untuk pengaturan L2TP. Parameter itu milik L2TP dan bukan rahasia IKEv2 umum. Pengaturan pemilihan algoritma memilih parameter perlindungan, yang merupakan hal ketiga dan tidak terkait. Peran perutean Windows Server juga bukan objek yang sama. Antarmuka server bisa punya kendali konfigurasi yang tidak dimiliki profil klien desktop, dan menyalin pengaturan server ke profil workstation tidak mereproduksi kemampuan itu.

Pilih antara sertifikat, EAP, atau L2TP

Jika operator gateway menerima autentikasi sertifikat, itu biasanya tujuan paling bersih: klien menyerahkan sertifikat, gateway memvalidasinya pada penerbit tepercaya, dan tidak ada rahasia bersama yang tertinggal di profil untuk disalin orang. Ini memerlukan pendaftaran, rantai tepercaya, dan konfigurasi gateway yang memetakan sertifikat ke keputusan otorisasi.

EAP dengan kredensial pengguna adalah jalur lain yang didukung di klien ini, dan memindahkan keputusan ke penyedia identitas. Ini juga membawa dependensinya sendiri, karena metode EAP, sertifikat server, dan kepercayaan klien pada sertifikat itu harus semuanya selaras. Beralih ke L2TP/IPsec hanya untuk mendapat kolom yang familier mengubah tumpukan protokol. Itu dapat diterima bila merupakan pilihan yang didukung dengan alasan terdokumentasi, dan hasil buruk bila terjadi karena seseorang mencari kotak untuk mengetik kunci.

Periksa apa yang akan diterima gateway

Tanyakan kepada operator metode autentikasi apa yang ditawarkan layanan akses jarak jauh hari ini, bukan yang didukung produk secara umum. Layanan yang dikonfigurasi untuk IKEv2 hanya dengan PSK tidak akan menerima sertifikat karena klien lebih menyukainya.

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

Baca metode autentikasi profil dan penyimpanan sertifikat bersama-sama. Profil yang disetel ke EAP tanpa sertifikat yang bisa dipakai di belakangnya gagal dengan cara yang tampak seperti masalah server.

Jika jawabannya hanya PSK yang tersedia, opsi jujurnya adalah klien disetujui yang mendukungnya atau perubahan pada desain autentikasi gateway. Keduanya bukan akal-akalan lokal, dan berpura-pura sebaliknya menghasilkan koneksi yang hanya bisa direproduksi oleh orang yang mengonfigurasinya.

Catat keputusan dan rahasianya

Catat metode yang dipilih, jangkar kepercayaan, identitas yang dipetakan padanya, dan orang yang menyetujui perubahan. Catatan itulah yang dibutuhkan tinjauan insiden, dan juga yang mencegah insinyur berikutnya menemukan jalan buntu yang sama.

Pisahkan rahasia dalam catatan Anda: kata sandi akun, frasa sandi kunci privat, dan kunci yang dibagikan sebelumnya milik gateway adalah tiga hal berbeda, bahkan ketika layar pengaturan menyebut semuanya kata sandi. Mencampuradukkannya adalah cara kunci berakhir di tiket. Uji profil yang dihasilkan dengan koneksi baru dan satu permintaan aplikasi ke sumber daya privat. Terowongan yang berhasil tanpa layanan yang bisa dijangkau adalah hasil sebagian, dan profil tidak boleh disebut selesai sampai sumber daya itu juga berfungsi.

Artikel terkait