Log Masuk VPN Terhenti Selepas Access-Challenge RADIUS

Kata laluan anda betul, log masuk VPN tetap gagal, dan pelayan RADIUS mungkin telah melakukan tepat apa yang diarahkan. Get laluan mungkin menerima Access-Challenge, tidak memaparkan apa-apa yang berguna, kemudian tamat masa atau menganggap jawapan itu sebagai penolakan. Dari sisi klien ia kelihatan seperti kelayakan yang salah atau terowong yang rosak. Puncanya biasanya terletak di tengah-tengah perbualan yang tidak dirakam oleh sesiapa.

Satu log masuk, dua pertukaran RADIUS

Apabila bahagian belakang mahu faktor kedua, ia tidak menjawab permintaan pertama dengan penerimaan atau penolakan. Ia menjawab dengan kod 11 dan menunggu respons pengguna seterusnya, yang perlu dihantar semula oleh get laluan dalam permintaan susulan. Permintaan susulan itu tergolong dalam perbualan pengesahan yang sama, bukan percubaan log masuk baharu.

Dalam persediaan yang berfungsi, pengguna melihat gesaan kedua: kata laluan dahulu, kemudian kod sekali guna, atau satu gesaan gabungan jika pengendali telah mendokumenkannya. Dalam persediaan yang rosak, gesaan kedua tidak pernah muncul dan log masuk terus gagal.

Itulah simptom yang perlu dikejar, dan mudah disahkan hanya dari sisi klien: jika klien VPN meminta tepat satu rahsia dan kemudian menolak kata laluan yang anda tahu sah, pertukaran itu mungkin berakhir pada cabaran.

Apa yang sebenarnya dibawa oleh cabaran

Spesifikasi RADIUS menerangkan kod 11 dalam bahagian 4.4 dan membenarkan dua atribut yang penting di sini. Reply-Message menyimpan teks untuk pengguna, dan State menyimpan nilai legap yang pelayan mahu dipulangkan. NAS tidak sepatutnya mentafsir State, hanya memulangkannya tanpa perubahan.

Permintaan susulan menggunakan Identifier baharu dan Request Authenticator baharu, dan ia mesti membawa nilai State yang sama serta respons pengguna. Pelayan memadankannya dengan cabaran yang belum selesai melalui State itu, sebab itulah get laluan yang menjana semula atau menggugurkan atribut tidak dapat melengkapkan upacara tersebut. Response authenticator pada setiap balasan juga mesti disahkan, jika tidak NAS patut membuang paket itu.

Bahagian 4.4 menambah perincian yang menerangkan kebanyakan kegagalan senyap: NAS yang tidak dapat menyokong cabaran menganggap Access-Challenge sebagai penolakan. Jika perkhidmatan VPN get laluan anda lebih tua daripada sokongan itu atau meninggalkannya, permintaan bahagian belakang untuk faktor kedua menjadi «pengesahan gagal» serta-merta tanpa sebarang gesaan.

Di mana permintaan berantai hilang

Suspek pertama ialah laluan gesaan, bukan kelayakan. Portal yang memaparkan medan OTP untuk log masuk web tidak berbuat demikian secara automatik untuk perkhidmatan VPN, dan sesetengah get laluan hanya menyalurkan cabaran kepada klien yang mengumumkan keupayaan itu. Uji akaun yang sama di kedua-dua titik masuk; jika portal berfungsi dan VPN tidak, anda sedang melihat penyerahan, bukan token.

Format input ialah suspek kedua. Menggabungkan kata laluan dan kod tanpa pemisah yang didokumenkan oleh vendor, atau membiarkan kelayakan tersimpan memainkan semula kod lama, gagal dengan cara yang kelihatan sama seperti kata laluan salah. Gunakan gesaan berasingan atau format gabungan yang didokumenkan oleh pengendali, dan jangan sekali-kali mereka pemisah sendiri.

Kecacatan khusus keluaran memang wujud, tetapi senarai versi yang dibaiki dari bertahun-tahun lalu bukan diagnosis untuk penggunaan hari ini. Baca nota keluaran perisian yang benar-benar anda jalankan, dan simpan peringkat pertukaran yang diperhatikan sebagai bukti anda.

Jejaki satu percubaan dari awal hingga akhir

Hasilkan semula sekali, dengan nyahpepijat sebelah pelayan dihidupkan, dan jauhkan setiap sesi lain daripada tetingkap tangkapan:

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

Dalam output, cari bentuk perbualan dan bukan satu baris. Access-Request pertama dengan Identifier 3, Access-Challenge yang membawa State, kemudian Access-Request kedua dengan Identifier 4 yang mengulangi State itu dan menyertakan respons pengguna. Jika permintaan kedua tiada, get laluan tidak pernah menyusuli. Jika ia tiba tanpa State, pelayan tidak dapat memadankannya dengan cabaran yang belum selesai dan biasanya akan menolaknya.

Sembunyikan kelayakan, token dan data identiti yang tidak perlu apabila berkongsi jejak, dan kaitkan peristiwa daripada satu percubaan dan bukannya mencampurkan percubaan semula daripada beberapa tab pelayar. Cap masa ialah rakan anda di sini; cabaran yang tiba selepas klien menyerah kelihatan seperti penolakan kepada pengguna dan seperti balasan lambat dalam log.

Keadaan akhir yang anda mahu ialah perbualan yang lengkap dan dibenarkan, diikuti akses perkhidmatan yang dimaksudkan. Balasan yang tiba daripada pelayan RADIUS membuktikan jauh lebih sedikit daripada itu.