Windows ve FortiGate üzerinde IKEv2: insanların birleştirdiği üç ayar
IKE anahtar değişimi, CHILD SA koruması ve eş kimlik doğrulaması üç ayrı satırdır. İki iletişim kutusunda eşleşen grup numaraları onları birleştirmez.
Bir Windows istemcisi ile bir FortiGate ağ geçidi arasındaki IKEv2 anlaşması sürekli başarısız oluyor ve uyuşmayan bir numarayı aramak daha uzun bir numara listesi üretiyor. Liste ancak bağımsız olarak başarısız olan üç satıra bölündüğünde yönetilebilir hale geliyor: IKE'yi koruyan anahtar değişimi, CHILD SA'ya uygulanan koruma ve her tarafın kim olduğunu kanıtlayan kimlik doğrulama. Grup numaraları bu satırların ikisinde görünür ve farklı anlamlara gelir.
Bağımsız olarak başarısız olan üç satır
İlk satır, IKE'nin içindeki anahtar değişimidir ve görüşmeyi koruyan anahtarları üretir. İkincisi, tünelin taşıdığı trafiği koruyan CHILD SA önerisidir. Üçüncüsü, her tarafın ne sunduğuna ve diğerinin bunu nasıl doğruladığına karar veren kimlik doğrulamadır.
Başarısızlıklar farklı yerlere düşer. Bir değişim başarısızlığı, herhangi bir tünel oluşmadan görüşmeyi durdurur. Bir CHILD SA başarısızlığı, kimlik doğrulama başarılı olduktan sonra, bazen yalnızca anahtar yenilenirken gerçekleşir. Yalnızca ilk hatayı okursanız, kimlik doğrulama başarısızlığı günlüklerde değişim başarısızlığı gibi görünebilir.
Satırları bölmek muhasebe değildir. Hangi ayarın değiştirilmeye değer olduğunu değiştirir ve bu alandaki en pahalı hamleyi, yani bir öneri uyuşmazlığını düzeltmek için çalışan sertifikaları yeniden üretmeyi engeller. Bir satırın değişmesi diğer ikisini onunla birlikte değişmeye zorlamamalıdır. Onları ayrı ayrı yazmanın bütün amacı bu bağımsızlıktır.
Windows'taki iki alan neyi kontrol eder
Windows iki alanı ayrı tutar: DHGroup IKE değişiminin kendisini yapılandırır, PfsGroup ise tünellenmiş trafiği koruyan IPsec ilkesini yapılandırır. Farklı evrelere aittirler. Bir Windows IKE alanını bir FortiGate phase-2 değeriyle karşılaştırmak yanlış çifti sınar, ve sayılar eşleşirken alttaki değişim yine de başarısız olabilir.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAİkinci ve üçüncü komutlar gerçekte var olan güvenlik ilişkilerini bildirir, bu da bir istemcinin size verebileceği yanıta en yakın şeydir. quick-mode ilişkisi olmayan bir main-mode ilişkisi bir CHILD SA sorunudur ve sertifika sorunu değil, phase-2 uyuşmazlığının imzasıdır.
Bir denemede neyin teklif edildiğini ve neyin seçildiğini kaydedin. Kabul edilebilir bir öneri içeren teklif listesi ile ağ geçidinin ilkesiyle eşleşmeyen seçilmiş öneri bir yapılandırma anlaşmazlığıdır, birlikte çalışabilirlik gizemi değil.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Eliptik eğri grubu imza anahtarınızı seçmez
Bu alandaki en kalıcı yanlış çıkarım, eliptik eğri DH grubu seçmenin eliptik eğri sertifikası gerektirdiğidir. Bir DH grubu anahtar değişimi malzemesi sağlar; imza algoritması kimlik doğrulama çerçevesi tarafından müzakere edilir ve ikisi IKEv2'de ayrı kararlardır.
RFC 7427 tam da bu kararlar önceden iç içe olduğu için vardır ve imza algoritmalarının anahtar değişiminden bağımsız olarak nasıl duyurulduğunu ve seçildiğini tanımlar. Bir ağ geçidi aynı anda bir eğri grubunu ve bir imza şeması seçimini destekleyebilir.
Bu yüzden bir grup değişikliğinden sonra görüşme başarısız olursa, sertifikanın anahtar türüne bakmadan önce kimlik doğrulama yöntemine bakın. Sertifika değiştirmek yavaş ve riskli bir işlemdir ve nadiren yanıttır; önce onu yapmak hangi değişikliğin gerçekten yardımcı olduğunu söyleme yeteneğinizi yok eder. Sertifika deposuna dokunmadan önce kimlik doğrulama satırını okuyun.
İkisini anlaşma sayfasının ayrı satırlarında tutun, o zaman hata cazip olmaktan çıkar. Bir satır grupları listeler, diğeri imza şemalarını ve kimlikleri listeler ve hiçbiri diğeri hakkında kanıt değildir.
Her özel anahtarı gerçek sahibinin yanına koyun
Kendi sertifikasını sunan bir ağ geçidi, onunla eşleşen özel anahtara ihtiyaç duyar. Bir zinciri doğrulayan eş, CA sertifikasına ihtiyaç duyar ve özellikle CA'nın imzalama anahtarına ihtiyaç duymaz. Bu üç nesneyi karıştırmak, insanların bir sertifikanın başka bir kategoride görünmesini sağlamak için CA özel anahtarını bir VPN cihazına aktarmasına yol açar.
FortiOS'ta roller ayrıdır: anahtarıyla birlikte yerel bir sertifika, bir eşi tanımlamak için kullanılan uzak bir sertifika ve o CA'nın imzaladığı sertifikalara güven kuran bir uzak CA girdisi. Özel anahtarı olmayan bir uzak CA girdisi eksik değildir; amacı için doğrudur.
İçe aktarılan CA imzalama anahtarları, o cihazı okuyabilen herkesin yetkisini genişletir. Ayrıca sıradan eş doğrulamasını çözmezler, çünkü doğrulama ortak sertifikayı ve güven kararını gerektirir, yeni sertifika basma yeteneğini değil.
CA imzalama anahtarını verenin kendi sürecinde tutun ve hangi cihazın hangi anahtarı tuttuğunu kaydedin. Bir denetim kimin kimi taklit edebileceğini sorduğunda kısa bir sahip tablosu, daha uzun bir algoritma tablosundan daha değerlidir. Kimse yalnızca envanter olduğunu bildiği bir anahtarı içe aktarmaz. Envanteri olaydan önce yazın, sonra değil.