Login VPN Terhenti Setelah Access-Challenge RADIUS

Kata sandi Anda benar, login VPN tetap gagal, dan server RADIUS mungkin telah melakukan persis apa yang diperintahkan. Gateway kemungkinan menerima Access-Challenge, tidak menampilkan apa pun yang berguna, lalu kehabisan waktu atau menganggap jawaban itu sebagai penolakan. Dari sisi klien tampak seperti kredensial salah atau tunnel yang rusak. Penyebabnya biasanya berada di tengah percakapan yang tidak pernah ditangkap siapa pun.

Satu login, dua pertukaran RADIUS

Saat backend menginginkan faktor kedua, ia tidak menjawab permintaan pertama dengan penerimaan atau penolakan. Ia menjawab dengan kode 11 dan menunggu respons pengguna berikutnya, yang harus dikirim gateway kembali dalam permintaan lanjutan. Permintaan lanjutan itu milik percakapan autentikasi yang sama, bukan percobaan login baru.

Pada penyiapan yang berfungsi, pengguna melihat permintaan kedua: kata sandi dulu, lalu kode sekali pakai, atau satu permintaan gabungan jika operator mendokumentasikannya. Pada penyiapan yang rusak, permintaan kedua tidak pernah muncul dan login sekadar gagal.

Itulah gejala yang harus dikejar, dan mudah dikonfirmasi hanya dari sisi klien: jika klien VPN meminta tepat satu rahasia lalu menolak kata sandi yang Anda tahu valid, pertukaran kemungkinan berakhir pada tantangan itu.

Apa yang sebenarnya dibawa tantangan

Spesifikasi RADIUS menjelaskan kode 11 di bagian 4.4 dan mengizinkan dua atribut yang penting di sini. Reply-Message memuat teks untuk pengguna, dan State memuat nilai buram yang ingin dikembalikan server. NAS tidak seharusnya menafsirkan State, hanya mengembalikannya tanpa perubahan.

Permintaan lanjutan memakai Identifier baru dan Request Authenticator baru, dan harus membawa nilai State yang sama plus respons pengguna. Server mencocokkannya dengan tantangan yang tertunda melalui State itu, karena itulah gateway yang meregenerasi atau membuang atribut tidak dapat menyelesaikan upacara. Response authenticator pada setiap balasan juga harus tervalidasi, atau NAS seharusnya membuang paket.

Bagian 4.4 menambahkan perincian yang menjelaskan sebagian besar kegagalan senyap: NAS yang tidak dapat mendukung tantangan memperlakukan Access-Challenge sebagai penolakan. Jika layanan VPN gateway Anda lebih tua dari dukungan itu atau menghilangkannya, permintaan backend akan faktor kedua menjadi «autentikasi gagal» seketika tanpa permintaan apa pun.

Di mana permintaan berantai hilang

Tersangka pertama adalah jalur permintaan, bukan kredensial. Portal yang menampilkan kolom OTP untuk login web tidak melakukannya secara otomatis untuk layanan VPN, dan sebagian gateway hanya meneruskan tantangan kepada klien yang mengumumkan kemampuan itu. Uji akun yang sama di kedua titik masuk; jika portal berfungsi dan VPN tidak, Anda sedang melihat penyerahan, bukan token.

Format masukan adalah tersangka kedua. Menggabungkan kata sandi dan kode tanpa pemisah yang didokumentasikan vendor, atau membiarkan kredensial tersimpan memutar ulang kode lama, gagal dengan cara yang tampak identik dengan kata sandi salah. Gunakan permintaan terpisah atau format gabungan yang didokumentasikan operator, dan jangan pernah mengarang pemisah.

Cacat khusus rilis memang ada, tetapi daftar versi yang diperbaiki dari bertahun-tahun lalu bukan diagnosis untuk penerapan hari ini. Baca catatan rilis perangkat lunak yang benar-benar Anda jalankan, dan simpan tahap pertukaran yang diamati sebagai bukti Anda.

Lacak satu percobaan dari awal sampai akhir

Reproduksi sekali, dengan debugging sisi server aktif, dan jauhkan setiap sesi lain dari jendela penangkapan:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Di keluaran, cari bentuk percakapan, bukan satu baris. Access-Request pertama dengan Identifier 3, Access-Challenge yang membawa State, lalu Access-Request kedua dengan Identifier 4 yang mengulangi State itu dan menyertakan respons pengguna. Jika permintaan kedua tidak ada, gateway tidak pernah menindaklanjuti. Jika datang tanpa State, server tidak dapat mencocokkannya dengan tantangan yang tertunda dan biasanya akan menolak.

Sembunyikan kredensial, token, dan data identitas yang tidak perlu saat membagikan jejak, dan korelasikan peristiwa dari satu percobaan alih-alih mencampur percobaan ulang dari beberapa tab peramban. Stempel waktu adalah teman Anda di sini; tantangan yang tiba setelah klien menyerah tampak seperti penolakan bagi pengguna dan seperti balasan lambat di log.

Keadaan akhir yang Anda inginkan adalah percakapan yang selesai dan diotorisasi, lalu akses layanan yang dimaksud. Balasan yang tiba dari server RADIUS membuktikan jauh lebih sedikit daripada itu.