Bir Windows IKEv2 istemcisi bağlanır ve RADIUS isteği, hesap adının olması gereken yerde bir adresle gelir. Henüz hiçbir şey başarısız olmadı ve asıl kafa karıştıran da bu: ağ geçidi istemcinin IKE katmanında sunduğu kimliği bildiriyor. Arka ucunuzun istediği kullanıcı adı, henüz gerçekleşmemiş ayrı bir EAP alışverişinden geliyor olabilir. Hesabı değiştirmeden önce bunu kimin isteyeceğine karar verin.

Tek bir bağlantıda iki kimlik seyahat eder

Tek bir bağlantıda iki ad görünebilir. IKE kimliği, tünel kurulumu sırasında eşi tanımlar ve eap-radius eklentisi onu başlangıçta RADIUS User-Name alanına kopyalar. EAP kimliği kullanıcı kimlik doğrulaması için kullanılan farklı bir değerdir ve kimse istemezse hiç gönderilmeyebilir.

Bu yüzden hesap var ve parola doğruyken RADIUS günlüğü bir adres gösterebilir. Arka uca yanlış katman soruluyor. RADIUS özniteliği yalnızca seçilen ad için taşıyıcıdır.

Ağ geçidinden bir EAP kimliği istemesini isteyin

Desteklenen bir düzenleme, ağ geçidinin kimlik doğrulamayı RADIUS'a devretmeden önce EAP kimliğini istemesini sağlar. Bağlantının uzaktan kimlik doğrulama bölümünde yöntemi eap-radius olarak ayarlayın ve EAP kimliğini açıkça isteyin. Aşağıdaki parça kendi dosyasına değil, mevcut bir bağlantı bloğunun içine aittir. Başka bir dağıtımdan sözdizimi kopyalamadan önce bağlantıyı ve yapılandırma arka ucunu doğrulayın.

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

Bununla arka uç, IKE adresi yerine istemcinin EAP alışverişinde sağladığı kimliği alır. Bağlantıyla ilgili başka hiçbir şey değişmez.

Ya da RADIUS EAP alışverişini başlatsın

Diğer düzenleme ilk hamleyi RADIUS tarafına bırakır. Eklenti, ilk kimlik yanıtını beklemek yerine bir EAP-Start göstergesi gönderebilir; bu da sunucunun alışverişi yönetmesini sağlar. Bu, eklenti düzeyinde bir yapılandırmadır, dolayısıyla eklentiyi kullanan her bağlantıyı etkiler.

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

İkisini de etkinleştirip ummak yerine RADIUS operatörüyle tek bir düzenleme seçin. Farklı iş akışlarını tanımlarlar ve başlamayı bekleyen bir sunucu, konuşmayı başlatan ağ geçidiyle mutlaka başa çıkamaz. Eklenti belgeleri her iki durumu da açıklar; her adımın hangi kimliği taşıdığı dahil.

Tek bir denemeyi iki günlükte izleyin

Tek bir denemeyi iki günlükte ilişkilendirin. IKE kimliğine, ardından bir EAP-Identity alışverişi olup olmadığına, ardından kimlik doğrulama adımının hangi adı aldığına bakın. Adresi EAP alışverişinden önce reddeden bir arka uç, amaçladığınız kimlik hiç görülmeden süreci durdurabilir.

journalctl -u strongswan -f

Kimlik sisteminin beklediği tam kullanıcı adı biçimini, alan adı öneki dahil koruyun. Asla adres biçimli bir değerden hesap uydurmayın ve bir ilke kuralını karşılamak için asla kimlik doğrulamayı kapatmayın. EAP kimliği iddia edilen bir addır ve yöntem onu yine de kanıtlamak zorundadır. Ortaya çıkan adı test kaydına yazın ki sonraki deneme bilinen bir durumdan başlasın.

Düzeltilmiş akış doğru hesaba ulaşıp yine de reddedilirse, sonraki kanıt kimlik değil EAP yöntemi ve arka uç ilkesidir. Parola sıfırlamayı yinelemek, daha önceki bir protokol katmanında seçilen bir değeri onaramaz.

İlgili makaleler