IPsec tüneliniz neden ilk CHILD SA anahtar yenilemesine kadar çalışır

Tünel ayağa kalktı, ping yanıt verdi ve herkes onayladı. Dört saat sonra oturum düşer, eşler bir teklif veya anahtar değişimi hatası kaydeder ve ilk tahmin ağda bir şeyin değiştiğidir. Hiçbir şey değişmedi. Trafik taşıyan bir tünel, iki eşin nasıl kimlik doğrulayacağı ve ilk alt birliği nasıl koruyacağı konusunda anlaştığını kanıtladı ve yenilemede talep edecekleri anahtar değişimi hakkında hiçbir şey kanıtlamadı. Uyuşmazlık bu iki olay arasındaki boşlukta oturuyor.

Bağlı olmak PFS ayarlarının uyuştuğu anlamına gelmez

IKEv2'de ilk alt birlik kimlik doğrulama değişimi sırasında oluşturulur ve anahtarları IKE birliğinin zaten ürettiği malzemeden türetilir. O alt birlik için ayrı bir Diffie-Hellman değişimi gerçekleşmez, bu yüzden yenilemede bunu şart koşan bir politika ayağa kalkışta denenmez.

Yenileme farklı bir değişimdir. Bir alt birliğin anahtarı yenilendiğinde, eşler tekliflerinde adı geçen grupla yeni bir anahtar değişimi yapabilir ve grup ayarlarının ilk kez karşılaştırıldığı an budur. Bu yüzden uyuşmayan iki eş kimlik doğrulayabilir, alt birlik kurabilir ve trafiği geçirebilir, sonra yenilemede başarısız olabilir.

Uyuşmazlık teklif dizesinde nerede saklanır

strongSwan'da grup alt teklife eklenir, bu yüzden aes256gcm16-prfsha256-ecp256 gibi bir dize şifreleme seçimi gibi görünür ama aynı zamanda anahtar değişimi gereği taşır. Yalnızca aes256gcm16-prfsha256 sunan eşde böyle bir gereklilik yoktur ve iki liste şifrelemede kesişirken değişimde ayrışır.

Alt teklifi ve IKE teklifini ayrı listeler olarak okuyun. IKE listesinde görünen bir grup alt liste hakkında hiçbir şey söylemez ve birini okurken diğerini düzenlemek bunun gözden kaçmasının olağan yoludur.

Hatayı okuyun, düzenlediğiniz dosyayı değil

Değişimi sonlandıran notify'ı bulun. Kabul edilebilir teklif yok döndüren bir alt anahtar yenilemesi teklif listelerine işaret eder; hiç yanıt alamayan bir yenileme isteği yola veya dinlemeyi bırakmış bir eşe işaret eder. Bu ikisi farklı düzeltmeler gerektirir ve günlük satırının ifadesi onları ayırır.

Diskteki değil, çalışan yapılandırmayı doğrulayın. Kaydedilip yüklenmemiş bir dosya veya başka bir include'dan yeniden okunmuş bir bağlantı, görünen dosyayı ne kadar düzenleseniz de düzelmeyecek bir uyuşmazlık üretir.

Hepsinin anahtar yenilemesi dediği üç olay

IKE birliğinin anahtarının yenilenmesi, IKE yeniden kimlik doğrulaması ve alt birliğin anahtarının yenilenmesi ayrı teklif kurallarına sahip ayrı işlemlerdir. Bunlardan birinde bildirilen hata diğerleri hakkında doğrudan hiçbir şey söylemez ve bunları karıştıran günlük, üç olduğu halde tek bir yinelenen arıza gibi okunur.

Eşin hangi olayı adlandırdığına dikkat edin, sonra teklifleri yalnızca o olay için kontrol edin. Bir listeyi değiştirin, yeniden yükleyin ve aynı olayı tekrar zorlayın. Günlük yeniden kimlik doğrulamayı adlandırıyorsa okunması gereken IKE teklifidir. Alt anahtar yenilemesini adlandırıyorsa önemli grubu alt teklif taşır.

Yenilemeyi kapatmak bir düzeltme değildir

Anahtar yenileme süresini sıfıra ayarlamak başarısız olan değişimi bastırır ve tünel ardından sökülene veya eş yeniden başlayana kadar yaşar. Satın aldığınız şey daha uzun ömürlü bir anahtar ve bir geçiş, denetim veya satıcı güncellemesi sırasında yeniden karşınıza çıkacak bir uyuşmazlıktır. Aynısı diğer tarafın beklediği politikanın çok ötesine uzatılan ömürler için de geçerlidir.

Bunun yerine teklifleri hizalayın. Her iki eşin de uyguladığı bir grup seçin, iki uçta da alt teklife koyun ve yenileme politikasını kuruluşun gerçekten gerektirdiği aralıkta tutun.

Başarısız olan değişimle kanıtlayın

Bakım penceresinde alt anahtar yenileme süresini kısaltın ki olay saatler yerine dakikalar içinde gelsin, ya da elle bir alt anahtar yenilemesi tetikleyin. Sonra başarılı bir yenilemeyi izleyin ve trafiğin onun içinden devam ettiğini doğrulayın, çünkü alt birlik kuran ama uygulama akışını düşüren yeni bir el sıkışma başka bir kusurdur.

Ardından normal ömrü geri yükleyin ve iki olay kaydını da saklayın, başarısız olanı ve başarılı olanı. İstediğiniz kanıt, bağlantının kendi yaşam döngüsünü atlatmasıdır, bir ping'i atlatmış olması değil.