Mengapa RADIUS Melihat Alamat IP dan bukan Nama Pengguna VPN

strongSwan boleh meletakkan identiti IKE dalam RADIUS User-Name sebelum sebarang pertukaran EAP. Tentukan siapa meminta identiti akaun, kemudian kaitkan satu percubaan.

Klien Windows IKEv2 menyambung, dan permintaan RADIUS tiba dengan alamat di tempat yang sepatutnya nama akaun. Belum ada apa-apa yang gagal, dan itulah bahagian yang mengelirukan: gateway melaporkan identiti yang dikemukakan klien pada lapisan IKE. Nama pengguna yang dikehendaki backend anda mungkin datang daripada pertukaran EAP berasingan yang belum berlaku. Tentukan siapa yang memintanya sebelum menukar akaun.

Dua identiti bergerak dalam satu sambungan

Dua nama boleh muncul dalam satu sambungan. Identiti IKE mengenal pasti rakan semasa persediaan terowong, dan pemalam eap-radius mula-mula menyalinnya ke RADIUS User-Name. Identiti EAP ialah nilai berbeza, digunakan untuk pengesahan pengguna, dan ia mungkin tidak pernah dihantar jika tiada siapa memintanya.

Sebab itulah log RADIUS boleh menunjukkan alamat sedangkan akaun wujud dan kata laluan betul. Backend ditanya tentang lapisan yang salah. Atribut RADIUS hanyalah pengangkutan bagi nama yang dipilih.

Minta gateway meminta identiti EAP

Satu susunan yang disokong membolehkan gateway meminta identiti EAP sebelum menyerahkan pengesahan kepada RADIUS. Dalam bahagian pengesahan jauh sambungan, tetapkan kaedah kepada eap-radius dan minta identiti EAP secara jelas. Serpihan di bawah tergolong di dalam blok sambungan sedia ada, bukan dalam fail tersendiri. Sahkan sambungan dan backend konfigurasi sebelum menyalin sintaks daripada penggunaan lain.

remote {
    auth = eap-radius
    eap_id = %any
}

Dengan itu, backend menerima identiti yang dibekalkan klien dalam pertukaran EAP dan bukannya alamat IKE. Tiada perkara lain pada sambungan berubah.

Atau biarkan RADIUS memulakan pertukaran EAP

Susunan lain meletakkan langkah pertama di pihak RADIUS. Pemalam boleh menghantar petunjuk EAP-Start dan bukannya menunggu respons identiti awal, yang membolehkan pelayan memandu pertukaran. Itu konfigurasi peringkat pemalam, jadi ia mempengaruhi setiap sambungan yang menggunakan pemalam itu.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Pilih satu susunan dengan pengendali RADIUS dan bukannya mengaktifkan kedua-duanya lalu berharap. Kedua-duanya menerangkan aliran kerja berbeza, dan pelayan yang menjangka untuk memulakan tidak semestinya mengendalikan gateway yang memulakan perbualan. Dokumentasi pemalam menerangkan kedua-duanya, termasuk identiti yang dibawa oleh setiap langkah.

Ikuti satu percubaan dalam kedua-dua log

Kaitkan satu percubaan merentas kedua-dua log. Perhatikan identiti IKE, kemudian sama ada pertukaran EAP-Identity berlaku, kemudian nama apa yang diterima oleh langkah pengesahan. Backend yang menolak alamat sebelum pertukaran EAP boleh menghentikan proses sebelum identiti yang dimaksudkan pernah dilihat.

journalctl -u strongswan -f

Kekalkan format nama pengguna tepat yang dijangka sistem identiti, termasuk awalan domain. Jangan sekali-kali mencipta akaun daripada nilai berbentuk alamat, dan jangan sekali-kali mematikan pengesahan untuk memenuhi peraturan dasar. Identiti EAP ialah nama yang didakwa, dan kaedah itu masih perlu membuktikannya. Tulis nama yang terhasil dalam rekod ujian supaya percubaan seterusnya bermula daripada keadaan yang diketahui.

Jika aliran yang diperbetulkan mencapai akaun yang betul dan masih ditolak, bukti seterusnya ialah kaedah EAP dan dasar backend, bukan identiti. Mengulang set semula kata laluan tidak dapat membaiki nilai yang dipilih pada lapisan protokol terdahulu.

Artikel berkaitan