IKEv1 hibrit kimlik doğrulaması IKEv2 kullanıcı kimlik doğrulamasına nasıl geçer
Hibrit mod, ağ geçidinin kanıtını kullanıcının kanıtından ayırıyordu. IKEv2'ye geçiş bu ayrımı korur, ancak değişimi, EAP yöntemini ve sertifika kontrollerini değiştirir.
Önce sunucu sertifikası, sonra kullanıcı adı isteyen her eski VPN profili, tek bir değişimde iki kimlik doğrulama olayı taşır ve bu biçim, onu getiren protokolden daha uzun yaşar. IKEv1 hibrit modu tam bunun için kurulmuştur: ağ geçidi kendini açık anahtarla kanıtlar, kullanıcı ise kendini daha sonra XAuth ile kanıtlar. IKEv2 aynı iki adımlı fikri başka bir mekanizmayla ifade eder ve geçişler tam da bu farklarda başarısız olur. Hiçbir sürüm numarası birini diğerine dönüştürmez ve eski seçenek adlarını yeni bir profile kopyalamak, anlaşan ve sonra hiçbir şeyi doğrulamayan bir istemci verir.
Hibrit mod IKEv1 içinde ne yapıyordu
Hibrit bir profilde yanıtlayan taraf birinci faz değişimini kendi sertifikasıyla imzalar, başlatan taraf ise bilerek hiçbirini sunmaz. Kimlik kanıtı bu yüzden asimetriktir ve bu, bir ağ geçidinin mevcut PKI'sını korumasını, kullanıcıların da dizin parolalarını korumasını sağladı. Birinci faz tamamlandığında XAuth, artık şifrelenmiş ISAKMP kanalı içinde kullanıcı adı ve parola özniteliklerini taşıyan bir istek ve yanıt olarak çalışır.
Güvenin nereye düştüğüne dikkat edin. Sertifika, istemcinin hangi ağ geçidine ulaştığını yanıtlar; XAuth, hangi kullanıcının erişim istediğini yanıtlar. Hiçbiri diğerinin yerini tutmaz ve herhangi bir sunucu sertifikasını kabul edecek şekilde yapılandırılmış bir istemci ilk yanıtı sessizce çöpe atmıştır. Hibrit etiketi, önceden paylaşılan anahtar artı XAuth ile agresif mod için de kullanılır; aynı kullanıcı deneyimine sahip farklı bir düzen, bu yüzden adı değil profili okuyun. Her iki varyant da hiçbir zaman standart olmayan taslaklardan gelir ve bu yüzden iki üretici hibrit modu uygulayıp hiçbiriyle birlikte çalışamayabilir.
IKEv2 aynı iki kanıta nasıl ulaşır
IKEv2 işi IKE_SA_INIT ile IKE_AUTH arasında böler. İlk değişim, hiç kimlik olmadan öneriler ve anahtarlar üzerinde anlaşır; ikincisi IDi, IDr ve AUTH yüklerini taşır. EAP altında başlatanın ilk AUTH yükü boş çıkar, yanıtlayan önce kendi sertifikası ve imzasıyla kimliğini doğrular, ardından EAP konuşması IKE_AUTH mesajlarının içinde yürür.
Bunu güvenli kılan mekanizma anahtar malzemesidir. Başarılı bir EAP yöntemi bir oturum anahtarı dışa aktarır ve başlatanın son AUTH yükü bundan hesaplanır, böylece kullanıcının kanıtı ile tünelin anahtarları birbirine bağlanır. XAuth'un eşdeğeri yoktur: öznitelikleri birinci fazdan sonra gelir ve anahtarlara hiçbir katkı yapmaz. IKEv2 çerçevesi tam bu boşluğu kapatmak için tasarlandı ve bu yüzden çalışan bir IKEv2 oturumu bir şey sormadan önce sunucu sertifikasını doğrular.
Bu sıralama aynı zamanda yararlı bir tanıdır. Bir istemci size sertifika göstermeden önce kimlik bilgilerinden şikâyet ediyorsa, hiç IKEv2 EAP değişimi yapmıyor demektir.
Üç kimliği ayrı tutun
Bir geçiş, üç kimlik tek alanda çöktüğünde ters gider. İstemcinin doğruladığı ağ geçidi kimliği vardır, genellikle sertifikanın subject veya SAN alanındaki bir DNS adı. EAP içinde sunulan kullanıcı kimliği vardır; bir etki alanı oturumu, bir adres ya da açık bir EAP kimlik dizesi olabilir. Bir de o kullanıcıyı ağlara ve rotalara eşleyen yetkilendirme kaynağı vardır.
strongSwan'ın swanctl sözdizimi ayrımı görünür kılar: bağlantı ağ geçidi için remote { auth = pubkey } ve kullanıcı için local { auth = eap-mschapv2 } ayarlar, EAP kimliği ayrı taşınır.
Yeni profildeki kullanıcı kimliği eski XAuth özniteliklerinden farklıysa, örneğin kısa ad yerine bir UPN ise, kimlik doğrulama sunucusu bilinmeyen bir kullanıcı görür ve arıza yanlış parola gibi görünür. Kimlik bilgilerini kontrol etmeden önce kimlik dizesini kontrol edin.
Seçenekleri eşleyin, sonra tuzakları bekleyin
Eşleme kısadır ve her satırda yalnızca kimlik doğrulama anında ortaya çıkan bir tuzak vardır.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Bu satırların hiçbiri basit bir yeniden adlandırma değildir. Yapılandırma yükü adresleri ve çözümleyicileri tiplenmiş bir öznitelik listesiyle teslim eder, XAuth'un öznitelik alanı ise kendi icadıydı; onları değiştirilebilir saymak, bir profilin ağ geçidinin asla göndermeyeceği bir ayarı istemesiyle sonuçlanmanın yoludur.
Trafik seçicileri kendi uyarısını hak eder. IKEv1 ilginç trafiği quick mode değişimine bağlı proxy ID'lerle ifade ediyordu; IKEv2 ise seçicileri IKE_AUTH sırasında müzakere eder ve yanıtlayan onları daraltabilir. Uyuşmazlık, child SA'sı olmayan kurulmuş bir IKE SA üretir; bazı istemciler bunu seve seve bağlı olarak gösterir.
Eski bağlantıya bir sınır olarak davranın
RFC 9395 IKEv1'i kullanımdan kaldırılmış ilan eder, yani eski bir hibrit bağlantı üzerinde tarih olan bir uyumluluk sınırıdır, temel değil. Değişim sırasında iki profili yan yana çalıştırın, çünkü önemli olan test yeni profilin açılıp açılmadığı değil, aynı kullanıcının aynı cihazda aynı kaynaklara ulaşıp ulaşmadığıdır.
Sertifika doğrulamasını baştan sona katı tutun. İstemci kendi sertifikasını sunmayı bıraktığında, el sıkışma tamamlanana kadar sunucu kontrolünü gevşetme cazibesi doğar ve bu, geriye kalan tek kanıtı yeşil bir simgeyle değiştirir.
Eski profili kullanımdan kaldırmadan önce dört şey yazın: EAP yöntemi, kimlik dizesi, yetkilendirme kaynağı ve desteğin bittiği tarih.