IKEv2 değişimi çalışıyor, sonra kimlik doğrulama başarısız oluyor: nereye bakmalı
Tünel bir yanıt alır ve sonra durur: anahtar değişimi başarılı oldu, sonraki denetim olmadı. Hangi kimliğin reddedildiğini bulmak için ret aşamasını kullanın.
IKEv2 yanıtı alan bir istemci, ağ geçidinin erişilebilir olduğunu, iki tarafın bir öneri üzerinde pazarlık yapabildiğini ve ilk anahtar değişiminin tamamlandığını kanıtlamıştır. Ancak kimsenin kimliğinin doğrulandığını kanıtlamamıştır. Sonraki değişim kimlikleri, sertifikaları veya EAP'yi taşır ve bağlantı genellikle orada durur. Bu denetimlerden hangisinin başarısız olduğunu okumak tüm tanıdır ve hata iletisi tek başına bunu nadiren söyler.
Denetim 1: aşamayı okuyun, iletiyi değil
Bir ret üç yerden gelebilir: istemcinin sunucunun kimliğini reddetmesi, ağ geçidinin istemcinin kanıtını reddetmesi ve harici bir kimlik doğrulama hizmetinin hesabı reddetmesi.
Her biri farklı bir makinede farklı bir günlük satırı üretir ve her birinin düzeltmesi farklıdır. İstemci tarafında sunucu sertifikasının reddedilmesi istemcide bir güven veya adlandırma sorunudur; ağ geçidi tarafında istemci sertifikasının reddedilmesi ağ geçidinde bir güven sorunudur; EAP hatası bir hesap veya arka uç sorunudur. Gördüğünüz ileti genellikle istemcinin bunlardan biriyle ilgili özetidir, bu yüzden ağ geçidi günlüğü istemcininki kadar önemlidir.
Denetim 2: hangi kimlik denetlendi
İstemci, herhangi bir kullanıcı kimlik bilgisi sunulmadan önce sunucu sertifikasını veya beklenen kimliği reddedebilir ve çalışan bir sunucu adresi bu denetimin yerini tutmaz. İstemcinin beklediği tanımlayıcı, ağ geçidinin sunduğuyla eşleşmelidir, bu bir ağ değil yapılandırma gerçeğidir.
strongSwan terimleriyle bu, istemcide rightid ve diğer tarafta ağ geçidinin kendi kimliğidir ve uyuşmazlık EAP konuşulmadan önce başarısız olur.
Ağ geçidi ayrıca istemci sertifikasını, anahtar kanıtını veya hesap kimlik doğrulamasını reddedebilir ve bu üçü birbirinin yerine geçmez. Bir kullanıcının parolasını sıfırlamak cihaz sertifikasını yenilemez ve cihaz sertifikasını yeniden kurmak yanlış sunucu kimliğini düzeltmez. Sertifika hatalarında önce saati, sonra güven zincirini, sonra beklenen tanımlayıcıyı denetleyin; saati birkaç dakika kayan bir istemci, güven hatasına benzeyen bir geçerlilik denetiminde başarısız olur. swanctl --list-certs her iki uçta her tarafın gerçekte ne tuttuğunu gösterir.
Denetim 3: EAP işin içindeyse
İstemci ve sunucu desteklenen bir yöntem üzerinde anlaşmalı ve arka uç sağlanan kimliği kabul etmelidir.
Bir kullanıcı adı, dağıtımın gerektirdiği bir alan son eki veya belirli bir hesap biçimi gerektirebilir ve biçim tahmin edilebilir değil belgelenmiştir. İşletmecinin belgelenmiş alanlarını sağlamak varyantları denemekten daha hızlıdır ve ikinci bir sorunu önler: yinelenen denemeler hesap kilidine yol açabilir ve bu da özgün aşamayı yeni bir hatanın arkasına saklar. Yöntem bir dizine karşı EAP-MSCHAPv2 ise hata VPN'e değil dizine ait olabilir.
Kimlik sorunlarını kimlik denetimlerini kapatarak test etmeyin. Bu, tanılanabilir bir hatayı tanılanamaz hale getirir ve bağlantıyı eskisinden daha zayıf bırakır.
Denetim 4: başarılı bir oturum açmadan sonra ne olur
IKE_AUTH tamamlandığında, CHILD_SA pazarlığı hangi trafik seçicilerinin kurulacağına karar verir ve tam orada bir bağlantı başarılı olup yine de hiçbir şey geçirmeyebilir.
Yeni çalışan bir oturum açma, daha önce kimlik doğrulama hatasının arkasında gizlenen bir seçici veya yol sorununu sık sık ortaya çıkarır. Tünel açılıp bir uygulama hâlâ hedefine ulaşamıyorsa, yeniden kimliğe değil, pazarlık edilen seçicilere ve yollara bakın. O noktada kimlik ayarlarını değiştirmek yanlış aşamayı hedefler ve genellikle çalışan bir oturum açmayı bozar. swanctl --list-sas ile doğrulayın; bu, çocukları ve seçicilerini IKE SA'dan ayrı gösterir.
Denetim 5: desteğe ne verilmeli
Temizlenmiş bir zaman çizelgesi ve kesin ret, tam bir tanılama dışa aktarımından daha değerlidir ve dışa aktarım paylaşmamanız gereken özel anahtarlar veya kimlik bilgileri içerebilir.
Saati saat dilimiyle, istemci ve ağ geçidi sürümlerini, yöntemi, parola yerine sunulan kimlik dizesini ve onu reddeden kesin aşamayı kaydedin. strongSwan IKEv2 yapılandırma belgeleri bu sonuçları belirleyen kimlik ve EAP ayarlarını açıklar ve bir alanı değiştirmeden önce okunması gereken başvuru odur. Sonra tek bir şeyi değiştirin ve yeni bir bağlantıyı yeniden test edin, çünkü önbelleğe alınmış bir oturum size eski yapılandırmayı anlatacaktır.