IKEv1 ile XAuth ve OTP: her istem ne istiyor

PSK, XAuth ve OTP ile IKEv1 tek bir karmaşık parola istemiyor. Eşler arasında paylaşılan bir anahtarı, bir kullanıcı değişimini ve backend'in nasıl isteneceğine karar verdiği ikinci bir faktörü üst üste koyar. Her katmanın kendi sahibi ve kendi hata iletisi vardır. Bunları karıştırmak, insanların grup sırrını saklayan bir alana tek kullanımlık kodu yeniden yazmasına yol açar.

Başka bir istemci kurmadan veya bir kimlik bilgisini sıfırlamadan önce her istemi onu isteyen katmanla eşleştirin.

Üç sır, üç sahip

Ön paylaşımlı anahtar eş ilişkisine aittir ve iki ucu da yöneten kişi tarafından bir kez yapılandırılır. Kullanıcı kimlik bilgisi kimlik doğrulama backend'ine aittir ve her oturum açmada doğrulanır. İkinci faktör, yanıtı her denemede değişen bir token sistemine aittir. Hiçbiri diğerinin yerini tutmaz ve üçünü tek bir parola olarak ele alan bir kurulum, kimsenin belgelemediği katmanda başarısız olur.

Üç sütun yazın: sahip, ömür ve her birinin ürettiği hata iletisi. Teşhis aracı o tablodur, istemcideki alan adları değil.

PSK: kişinin değil, eşin

Bu eski düzenlemede ön paylaşımlı anahtar ağ geçidi çiftini doğrular, bu yüzden kullanıcının oturum açması onun yerini asla almaz. Ayrıca istem yerine genel bir anlaşma hatası üreten biçimde en sık yanlış olan değerdir. Tünel herhangi bir kullanıcı istemi görünmeden önce başarısız olursa şüpheliler anahtar veya tekliflerdir.

Kullanıcı kimlik bilgisi birinci aşama hatasını onaramaz. Onu döndürmek, güvenle döndürebileceğiniz tek kimlik bilgisini harcar ve yanlış kuramı güçlendirir.

XAuth: eski kullanıcı değişimi

XAuth, IKEv1 eş kimlik doğrulamasının üzerine bir kullanıcı kimlik doğrulama değişimi ekler ve hangi backend'in bunu doğrulayacağına ağ geçidi karar verir. O backend'e bağlı olarak değişim bir dizin parolasını, bir RADIUS kimlik bilgisini veya bir token yanıtını kabul edebilir. XAuth sözcüğü değişimin taşımasını adlandırır, kimlik bilgisi türünü değil.

Ağ geçidi profilinin hangi backend'i işaret ettiğini kontrol edin. Bu, kullanıcıdan ne isteneceğini ve parola sıfırlamanın gerçekte neyi değiştirdiğini söyler; ikisi de bir istemci profilinde görünmez.

OTP: backend ne isterse

Bazı kurulumlar paroladan sonra ayrı bir tek kullanımlık kod ister, diğerleri belgelenmiş bir ayırıcıyla birleşik bir giriş biçimi tanımlar. İkisi de vardır ve önünüzdeki profil hangisi olduğuna karar verir. Başka bir yerde çalıştı diye bir birleştirme uydurmak, kayıt token'ını yakmanın en yaygın yoludur. Bunu yalnızca ağ geçidinin kendi belgeleri çözer.

Belgelenmiş biçimi, ağ geçidinin sunduğu değişimi tamamlayabilen bir istemciyle kullanın.

İstemci sınırının ısırdığı yer

Fortinet, FortiClient 7.4.4 ve sonrasının IPsec VPN'ler için IKEv1'i artık desteklemediğini belgeliyor; bu, FortiClient uyumluluk notunun kaydettiği gibi evrensel bir kaldırma değil, ürün ve sürüm sınırıdır. Diğer istemciler de birbirinin yerini tutmaz: OpenConnect ve openfortivpn belirli ağ geçidi protokollerini konuşur, rastgele IKEv1 profillerini değil. Kurulu istemcinin IKE sürümünü, PSK modunu, XAuth desteğini ve etkileşim modelini tek tek kontrol edin. Farklı bir yöntemle bağlanan bir istemci, asıl gereksinimi kanıtlamış olmaz.

IKEv1 kullanımdan kaldırıldı, bu yüzden desteklenmeyen eski bir istemci üzerine kurulu yeni bir dağıtım kısa ömürlü bir çözümdür. Ağ geçidi sahibinden desteklenen bir geçiş yolu isteyin; ikinci faktörün orada nasıl ele alınacağı da buna dahil.

Faktörü kapatmadan teşhis etmek

Günlükteki aşamaları ayırın: eş anlaşması, kullanıcı değişimi, ikinci faktör sonucu, ardından adres ve yol ataması. Kodu her alanda denemek yerine bileşeni ve aşamayı kaydedin. Bir test geçsin diye faktörü kapatmak, dağıtım hakkında hiçbir şey kanıtlamayan bir tünel üretir.

Kayıt sırlarını ve paylaşılan anahtarı kuruluşun sürecine göre korumalı depolamada tutun. Kalıcı bir dosyadaki tek kullanımlık kod, artık faktör olmaktan çıkmış bir faktördür.