RouterOS OpenVPN dan NPS: tetapkan user-auth-method, bukan auth

RouterOS boleh mencapai NPS dengan log masuk OpenVPN dan masih ditolak, dan punca biasa ialah dua tetapan yang namanya kedua-duanya berbunyi seperti pengesahan. Satu memilih digest kriptografi untuk tunnel; satu lagi menentukan bagaimana kelayakan pengguna dibentangkan kepada RADIUS. Menukar digest tidak akan pernah menjadikan permintaan PAP sebagai MS-CHAPv2, berapa kali pun perkhidmatan dimulakan semula. Senarai semak di bawah memisahkan kedua-duanya, kemudian mengikuti satu log masuk yang gagal melalui dasar NPS yang menilainya.

Langkah 1: baca kedua-dua tetapan sebelum menukar mana-mana satu

Cetak konfigurasi pelayan OpenVPN yang berkesan pada penghala yang menamatkan tunnel, bukan daripada sandaran atau catatan forum yang disalin. Dua medan yang anda pedulikan biasanya berada dalam menu yang sama dan dibaca seolah-olah kedua-duanya alternatif. Kedua-duanya bukan: satu tentang saluran data, satu lagi tentang pertukaran kelayakan.

/interface ovpn-server server print
/interface ovpn-server server export

Medan auth menyenaraikan digest seperti sha1 dan sha256 dan mengawal HMAC yang mengesahkan paket tunnel. Medan user-auth-method memilih pap atau mschap2 dan menentukan bagaimana penghala membentangkan kelayakan pengguna kepada RADIUS. Perubahan digest tidak boleh mengubah tingkah laku kedua, dan sebab itulah penolakan yang sama bertahan pada setiap pelarasan yang pertama.

Berhenti di sini jika keluaran anda tidak mendedahkan user-auth-method sama sekali. Binaan RouterOS yang lebih lama mungkin tidak menawarkannya pada pelayan OpenVPN, dan pembetulan itu tergolong dalam keluaran yang boleh anda sokong, bukan dalam arahan yang disalin daripada yang lebih baharu.

Langkah 2: cari dasar yang benar-benar menolak log masuk

Di pihak NPS, permintaan sambungan dinilai terhadap dasar rangkaian, dan kaedah pengesahan yang dinamakan dalam dasar yang sepadan mesti salah satu yang benar-benar ditawarkan oleh klien. Kaitkan satu log masuk yang gagal mengikut masa dan pengguna dan bukannya membaca jumlah ringkasan. Log keselamatan merekodkan permintaan yang dibenarkan dan ditolak dengan kod sebab, yang memberitahu anda lebih banyak daripada baris kegagalan umum penghala.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Baca tiga perkara dalam peristiwa: nama dasar yang sepadan, kaedah pengesahan dan kod sebab. Dasar yang memerlukan MS-CHAPv2 menolak permintaan PAP walaupun kata laluan betul, dan dasar yang memerlukan akaun domain menolak akaun tempatan. Entri klien RADIUS juga mesti sepadan dengan alamat sumber penghala, atau permintaan digugurkan sebelum mana-mana dasar dirujuk. Tiada satu pun daripadanya muncul dalam log OpenVPN.

Berhenti di sini jika permintaan tidak pernah sampai ke NPS. Itu masalah rahsia bersama, alamat klien atau UDP 1812, dan menukar kaedah pengesahan tidak akan membaikinya.

Langkah 3: tukar satu kaedah, pada kedua-dua belah

Jika reka bentuk yang diluluskan ialah MS-CHAPv2, tetapkannya pada penghala dan sahkan bahawa dasar yang sepadan menerimanya. Tukar satu pihak, uji semula, kemudian tukar pihak yang lain; menukar kedua-duanya sekali gus membuat anda tidak dapat mengatakan mana yang penting.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Jangan dayakan setiap kaedah yang lebih lemah pada NPS supaya ralat hilang. Bahagian belakang mesti mempunyai bahan yang boleh disahkan oleh kaedah yang dipilih: MS-CHAPv2 memerlukan akses kepada kata laluan atau domain, dan dasar tidak boleh mencipta bahan itu. Meluaskan dasar juga meluaskan apa yang boleh dicuba penyerang terhadap akaun yang sama. Rekodkan kaedah, nama dasar dan rujukan perubahan bersama-sama, supaya orang seterusnya mewarisi keputusan dan bukan tekaan.

Biarkan pengesahan sijil tunnel tepat seperti sebelumnya. Kaedah kelayakan bukan pengganti identiti pelayan, dan menurunkan pemeriksaan TLS supaya ujian lulus menukar satu masalah dengan masalah yang lebih teruk.

Langkah 4: uji tiga log masuk dan satu kebenaran

Uji pengguna yang dibenarkan, kata laluan yang salah dan pengguna yang dikecualikan, masing-masing dalam sesi baharu. Yang pertama membuktikan laluan, yang kedua membuktikan pemeriksaan kelayakan itu benar, dan yang ketiga membuktikan dasar masih mengecualikan mereka yang sepatutnya. Sesi yang dicache boleh menyembunyikan ketiga-tiganya, jadi putuskan sambungan antara percubaan.

/log print where topics~"ovpn"
/radius monitor 0

Kejayaan pengesahan bukanlah penghujung senarai semak. Periksa alamat yang diterima klien dan sumber yang boleh dicapai oleh alamat itu, kerana pengguna boleh mengesahkan dengan betul dan masih mendarat dalam kumpulan yang salah. Jika alamat yang diberikan salah, masalahnya terletak pada profil atau atribut balasan RADIUS, bukan pada kaedah. Sahkan kedua-duanya sebelum menutup tiket.

Senarai semak selesai apabila tetapan penghala dan dasar NPS menamakan kaedah yang sama, seorang pengguna yang dibenarkan bersambung dengan sesi baharu, satu kata laluan yang salah ditolak, seorang pengguna yang dikecualikan kekal dikecualikan, dan alamat yang diberikan sepadan dengan kumpulan yang dimaksudkan. Apa-apa yang kurang daripada itu menyerahkan log masuk seterusnya kepada kebetulan.