IKEv2 NO_PROPOSAL_CHOSEN: hangi aşama paketi reddetti?

Günlükteki NO_PROPOSAL_CHOSEN insanları önceden paylaşılan anahtara yönlendirir ve hata değişiklikten sonra da sürer. Bu hiçbir zaman bir kimlik bilgisi sorunu değildi: eş, o değişim için sunulan her teklifi reddetti; bu, kimlik değil algoritmalar hakkında bir ifadedir. İlk yararlı soru hangi algoritmanın düzenleneceği değil, hangi değişimin reddedildiğidir. Herhangi bir şeyi karşılaştırmadan önce buna cevap verin. Ardından sunulan tam paketi eşin izin verdiği tam paketle karşılaştırın.

Önce: hangi değişim reddedildi

IKEv2 iki tür ilişkiyi müzakere eder. IKE SA müzakerenin kendisini korur ve CHILD SA trafiği korur. Her birinin kendi teklif kümesi vardır ve her biri aynı bildirimle başarısız olabilir. Başlangıç IKE müzakeresi sırasındaki ret ile CHILD müzakeresi sırasındaki ret farklı düzeltmeler gerektirir ve günlük genellikle değişimi bildirimin bir iki satır üstünde adlandırır. Bu iki satırı birlikte okuyun, yoksa yanlış teklif listesini düzenlersiniz.

Bildirim tek başına değişimi tanımlamaz. Üstündeki satır, müzakere edilen SA'yı adlandırır ve bu ad, incelenmesi gereken teklif listesine işaret eder.

Tek tek anahtar sözcükleri değil, tam paketleri karşılaştırın

Teklif bir birleşimdir: şifreleme algoritması, bütünlük veya AEAD, anahtar değişim grubu ve herhangi bir sözde rastgele işlev. Yalnızca şifreleme adını karşılaştırmak olağan hatadır, çünkü iki eş AES-256 üzerinde anlaşıp SHA-1 ile SHA-256 konusunda hâlâ anlaşamayabilir. Başarısız aşamada sunulan ve izin verilen paketleri yan yana yazın, sonra boş kesişimi arayın.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Ayrıca her iki uygulamanın da yapılandırdığınız şeyi desteklediğini kontrol edin. Başka bir platformdan kopyalanan bir ad sözdizimsel olarak tanıdık görünebilir oysa eklenti veya uygulama tamamen yoktur.

IKE paketi ile ESP paketi farklı nesnelerdir

IKE teklifini düzenlemek reddedilen CHILD teklifini onarmaz ve bunun tersi de doğrudur. strongSwan'da bunlar ayrı ayarlardır, kabaca IKE SA için proposals = aes256-sha256-modp2048 ve CHILD SA için ayrı bir ESP listesi. Başarısız değişime karşılık gelen listeyi değiştirin, sonra düzeltmenin işe yaradığını varsaymak yerine günlüğü yeniden okuyun.

CHILD SA için ilgili ayar ESP teklif listesidir, IKE listesi değil. IKE satırını oraya kopyalamak, ayrıştırılan ama yanlış nesneyi müzakere eden bir yapılandırma üretir.

Çalışan bir tünelin anahtar yenilemede başarısız olması

Tünel bir saat çalışıp sonra başarısız olduysa, ilk müzakere sorun değildir. Anahtar yenileme başka koşulları deneyebilir: ilk değişimden sonra farklı bir anahtar değişim grubu, eşler arasında yaşam süresi uyuşmazlığı veya değişmiş bir yanıtlayıcı ilkesi. Yenileme zaman damgasını ve ilişki tanımlayıcılarını iki taraftan da saklayın. Bu örüntü, yenilemede teklif karşılaştırması gerektirir, daha uzun bir zaman aşımı değil. Zaman aşımını değiştirmek belirtiyi gizler ve uyuşmazlığı yerinde bırakır.

ipsec statusall her ilişkiyi ve gerçekte müzakere edilen algoritmaları gösterir. Bu çıktı hangi listenin kullanıldığını doğrulamanın en hızlı yoludur ve bir yapılandırma hatasını hiç yeniden müzakere edilmemiş eski bir tünelden ayırır.

ipsec statusall | grep -E "IKE:|ESP:"

Bir kesişim seçin, sonra iki aşamayı doğrulayın

Yöneticiden her iki eşin desteklediği belgelenmiş modern bir kesişim seçmesini ve yazmasını isteyin. Hatayı tüm eski algoritmaları etkinleştirerek veya kimlik doğrulamayı devre dışı bırakarak çözmeyin, çünkü ikisi de bir redden kaynaklanmaz. Değişiklikten sonra yeni bir bağlantı kurun ve ardından anahtar yenilemeyi zorlayın. Yalnızca ilk bağlantı yenileme yolunun çalıştığını kanıtlamaz.

Kabul edilen birleşimi ürün yazılımı sürümleriyle birlikte saklayın. Sonraki hata trafik seçicilerle ilgiliyse ayrı ele alın, çünkü kriptografi konusundaki anlaşma tünelin hangi alt ağları koruduğu hakkında hiçbir şey söylemez. strongSwan'ın teklif belgeleri iki listenin sözdizimini kapsar.