FortiGate Azure anahtar yenileme: peer SA teklifi yerel ilkeyle eşleşmiyor
Çalışan bir IKEv2 tüneli yine de yedek CHILD SA'yı reddedebilir. Yenilemenin gerçekte müzakere ettiği teklifi karşılaştırın, ilk ping'in kullandığını değil.
Tünel açıldı, trafik aktı ve sonra günlük şunu söyler peer SA proposal not match local policy. Çoğu kişi bu satırı iki yapılandırmanın hiçbir zaman eşleşmediğinin kanıtı olarak okur. Genellikle daha dar bir şey anlatır: ilk CHILD SA için eşleştiler ve ilk yenilemede eşleşmeyi bıraktılar, çünkü ilk ilişkilendirme sonrakilerin yaptığı değiş tokuşa hiç ihtiyaç duymadı. Hangi tarafa bakacağınızı bu ayrım belirler.
İlk CHILD SA devralır, sonrakiler müzakere eder
IKEv2'de ilk CHILD SA, IKE_AUTH sırasında oluşturulur ve anahtarları IKE SA'nın anahtar malzemesinden türetilir. O anda ayrı bir Diffie-Hellman değiş tokuşu yoktur, bu yüzden bir eşin kabul edemeyeceği PFS grubu henüz denenmez. Tünel sağlıklı görünür çünkü daha sonra başarısız olacağınız gereksinim hiç test edilmemiştir.
CHILD_SA anahtar yenilemesi farklı bir ileti dizisidir. PFS yapılandırıldığında eşler yeni bir anahtar değiş tokuşu yapar ve her iki tarafın kabul ettiği bir grup ile yeni ilişkilendirme için ESP teklifi üzerinde anlaşmalıdır. Uyumsuzluğun görünür hale geldiği an tam da budur ve hata bu yüzden rota yerine bir teklif adlandırır.
Yani “dün çalışıyordu” size teklif hakkında hiçbir şey söylemez. İlk değiş tokuşun başarılı olduğunu söyler, bunu zaten biliyordunuz.
Başarısız değiş tokuşu okuyun, ilk ping'i değil
Herhangi bir şeyi değiştirmeden önce her iki uçtan başarılı IKE kimlik doğrulamasını, ilk CHILD SA'yı ve başarısız değişikliği toplayın. Sonra işlemi tam olarak adlandırın: IKE SA anahtar yenilemesi, IKE yeniden kimlik doğrulaması ve CHILD SA anahtar yenilemesi üç farklı olaydır ve “2. aşama” günlük konuşmada hepsini kapsar.
Aşağıdaki alanları başarısız olan bağlantı için karşılaştırın, tünel için genel olarak değil.
| Katman | Karşılaştırılacak değerler |
|---|---|
| IKE | Sürüm, şifreleme ve bütünlük veya PRF düzeni, DH grubu |
| IPsec / CHILD | ESP şifrelemesi ve bütünlüğü, amaçlanan PFS veya anahtar değiş tokuşu grubu |
| Korunan trafik | Yerel ve uzak seçiciler, ayrıca ilkeye dayalı herhangi bir seçici ayarı |
FortiGate'te o tünelin 2. aşama teklifini, PFS ayarını ve kabul edilen DH gruplarını açın. Yüklenen değerleri, daha önce kurulmuş bir bağlantıdan çıkarım yapmak yerine okuyun. GUI sayfasının ekran görüntüsü, çalışan yapılandırmadan daha zayıf bir kanıttır, çünkü ikisi bir yükseltmeden sonra farklılaşabilir. Değiştirdiğiniz bölümü dışa aktarın ve bilete ekleyin.
Azure'un varsayılan ilkesi hâlâ bir ilkedir
Bağlantıya özel bir ilke eklenmemiş olması, Azure'un hiçbirini uygulamadığı anlamına gelmez. Bağlantı, ağ geçidinin varsayılan teklif kümesine geri döner ve bu küme FortiGate'inizin sunduğundan daha geniş veya daha dar olabilir. İki küme IKE için örtüşüyor ama PFS'li ESP için örtüşmüyorsa, tam olarak bu başarısızlık örüntüsünü elde edersiniz.
Bu salt okunur görünüm, gizli bilgileri açığa çıkarmadan gerçekten eklenmiş ilkeyi gösterir:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesGerçek kaynak adlarınızı kullanın. Açık bir ilke gerektiğinde bunu bağlantı kaynağında ayarlayın. Bu, tüm ağ geçidi için bir anahtar değildir ve aynı ağ geçidindeki diğer tünellere sessizce uygulanmaz.
Portalda, o bağlantının Configuration sayfası özel bir IPsec/IKE ilkesinin gideceği yerdir. Microsoft'un özel ilkeler kılavuzu desteklenen parametreleri ve SKU gereksinimlerini listeler. Azure bağlantı başına tek bir tam kombinasyon alır, bu yüzden IKE alanlarını ve IPsec alanlarını birlikte belirtirsiniz, tek tek değil.
PFS bir gereksinimdir, çevrilecek bir anahtar değil
Güvenlik temel çizginiz PFS gerektiriyorsa çözüm, her iki eşin her iki tarafta kabul ettiği ve eşleşen bir ilkeyle ifade edilen bir gruptur. Hatayı yok etmek için PFS'yi kapatmak, korumaya çalıştığınız güvenlik özelliğini değiştirir ve genellikle daha sonra başka bir uyumsuzluk olarak geri döner.
Azure'a özgü bir tuzak: ESP için GCM seçtiğinizde şifreleme ve bütünlük seçimleri aynı GCM algoritmasını ve aynı anahtar uzunluğunu belirtmelidir. Bir GCM şifresini ayrı bir bütünlük algoritmasıyla karıştırmak, hizmetin reddettiği bir kombinasyon üretir ve ilkeyi dikkatle okuyana kadar bu bir eş uyumsuzluğu gibi görünür.
Her iki ucun desteklediği ve gereksiniminizin izin verdiği en güçlü kombinasyonu seçin, sonra bunu değişiklik kaydına yazın. Sıradaki kişi o kayıtla karşılaştıracak, çalışan bir tünelin anısıyla değil. İçine PFS grubunu ve ESP teklifini koyun, yalnızca ilkenin adını değil. Birisi daha sonra bir denetimin neden başarısız olduğunu veya bir anahtar yenilemesinin neden yavaş olduğunu sorduğunda, o satır her iki soruyu da yanıtlar.
Başarısız değiş tokuşu doğrulayın
Değişikliği bir kurtarma yoluyla planlayın, çünkü ilkeyi düzenlemek düzeltmeye çalıştığınız tüneli kesintiye uğratabilir. Trafik geri döndükten sonra CHILD_SA yenilemesini bekleyin veya tetikleyin ve yeni ilişkilendirmenin amaçlanan PFS grubuyla kurulduğunu doğrulayın. Ardından uygulama trafiğinin bunun üzerinden devam ettiğini doğrulayın.
İki yanlış izi adlandırmaya değer. SA ömürleri yerel spesifikasyonlardır, bu yüzden eşit olmayan değerler normaldir ve bunları değiştirmek yalnızca sorunun ne zaman ortaya çıkacağını kaydırır. DPD bir eşin canlı olup olmadığını algılar; zaman aşımını yükseltmek ESP veya PFS seçimlerini hizalamaz.
Değişiklikten sonra müzakere edilen sonucu ve sonraki olayı kaydedin. Bağlantı artık IKE kimlik doğrulaması tamamlanmadan başarısız oluyorsa, az önce düzenlediğiniz IKE ayarlarına bakıyorsunuz, özgün CHILD yenileme hatasına değil.