Bir IPsec önerisi neleri içerir? IKE ve ESP alanları

IKE başlar, iki taraf da AES duyurur ve tünel yine de NO_PROPOSAL_CHOSEN ile başarısız olur. Günlük öneriyi adlandırır ama eşleşmeyen alanı söylemez. Öneri tek bir eksiksiz tekliftir ve tek bir uyumsuz alan yalnızca o satırı değil tüm birleşimi geçersiz kılar. Bunu bağımsız algoritma seçimlerinden oluşan bir torba olarak okumak, uyuşmazlığın görünmez kalmasının olağan nedenidir.

Ayrı öneri listeleri olan iki müzakere

IKEv2 iki güvenlik birliği kurar. Birincisi kontrol alışverişini kendisi koruyan IKE SA, ikincisi trafiğinizi ESP üzerinden taşıyan CHILD SA'dır. Her birinin kendi öneri listesi vardır ve bir taraf birini kabul edip diğerini reddedebilir.

Bu ayrım yaygın bir karışıklığı açıklar: çalışan bir IKE SA yalnızca kontrol kanalı algoritmalarının eşleştiğini kanıtlar. CHILD önerisi başarısız olursa, birinci aşama tamamlanmış ve günlükler üstte sağlıklı görünse de tünel tek bir paket bile taşımaz.

Her listenin içindeki sıra da önemlidir. Yanıtlayan taraf başlatanın sıralı tekliflerinden seçer, bu yüzden geniş uyumlu bir girdiyi dar bir girdinin üstüne taşımak, tek bir algoritma adı değişmeden kurulacak kümeyi değiştirir. Bu sırayı varsayılanlara güvenmek yerine yapılandırmada sabitleyin. Kararlı bir sıra, siteler arasındaki günlük karşılaştırmasını da anlamlı kılar.

Hangi alanlar hangi öneriye ait

Alan kümesi küçüktür ama iki müzakerelerde aynı değildir. Tabloyu satır satır okuyun, çünkü bir sütundaki alan diğerinde olmayabilir. Sözdizimi uygulamaya göre değişir; strongSwan'ın öneri belgeleri tek bir somut başvuru kaynağıdır.

Şifreleme alanı şifreyi ve çoğu sözdiziminde anahtar uzunluğunu belirtir. Bütünlük alanı şifreli metni doğrulamak için kullanılan hash'i belirtir, PRF ise IKE SA için anahtar malzemesi türeten işlevi belirtir. DH grubu yeni ortak gizli malzeme oluşturur, bu yüzden iki tarafta da görünür ama farklı amaçlarla.

Genişletilmiş sıra numaraları yalnızca veri yoluna aittir. Sıra alanını genişletirler ve CHILD önerisinin parçası olarak görüşülürler, bu yüzden oradaki bir uyuşmazlık CHILD teklifini reddederken IKE SA dokunulmadan kalır.

Tek bir eksiksiz teklif nasıl seçilir

Her öneri bir kümedir ve yanıtlayan taraf her zorunlu alanın kabul edilebilir olduğu bir küme arar. İki liste de AES ve SHA-256 içerebilir ve yine de uyumlu bir girdi olmayabilir, çünkü anahtar uzunluğu, PRF veya DH grubu farklıdır. Karşılaştırma algoritma başına değil, öneri başına yapılır.

Hiçbir şey eşleşmezse yanıtlayan taraf başarısız olan SA türüyle NO_PROPOSAL_CHOSEN gönderir. Yapılandırmayı düzenlemeden önce bildirimin hangi öneri listesine ait olduğunu okuyun; IKE önerisi reddedilmişken ESP algoritmalarını değiştirmek bir hata ayıklama döngüsünü boşa harcar.

Bir profili ayarlarken seçim davranışını bilmekte yarar var. Bazı uygulamalar başlatanın sırasını tercih eder, diğerleri yerel politikaya göre yeniden sıralar, bu yüzden iki üretici arasında çalışan bir küme kaybolabilir bağlantıyı hangi tarafın başlattığını tersine çevirdiğinizde.

AEAD alan eklemek yerine alan kaldırır

AES-GCM ve ChaCha20-Poly1305 tek işlemde doğrular ve şifreler. Biri ESP için seçildiğinde bütünlük algoritması ayrıca görüşülmez, çünkü AEAD yapısı onu zaten kapsar. Bu nedenle AES-GCM'i SHA-256 ile eşleştiren öneri en iyi durumda gereksiz, en kötü durumda reddedilir.

PRF IKE tarafında hâlâ ayrıdır, çünkü yükleri korumak yerine kontrol kanalı için anahtarlar türetir. Bu yüzden bir IKE önerisi AEAD şifresini PRF ve DH grubuyla meşru biçimde birleştirebilirken, karşılık gelen ESP önerisi yalnızca AEAD şifresini ve isteğe bağlı PFS grubunu listeler.

Anahtar uzunluğu şifreleme belirtecinin parçasıdır, bu yüzden AES-128-GCM ve AES-256-GCM farklı tekliflerdir. 256-bit anahtar varsayan bir kılavuzdan kopyalanan profil, iki satır da AES-GCM dese bile 128-bit için yapılandırılmış bir uç noktayla eşleşmez. İki taraf şifre ailesinde anlaşabilir ve yine de tireden sonraki sayı yüzünden birbirini reddedebilir.

Yapılandırmayı değil, kurulu SA'yı okuyun

Yapılandırılmış öneri listesi bir tekliftir; kurulu SA sonuçtur. strongSwan ve Linux çekirdeğinde her iki görünüm de kullanılabilir:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas her SA için görüşülen algoritmaları yazdırır, CHILD'ın AEAD kullanıp kullanmadığı da dahil. ip xfrm state çekirdeğin gerçekte ne kurduğunu gösterir, ve anahtar yenilemesinin belgelediğinizden farklı bir kümeye geri düşmediğini doğrulayacağınız yer tam olarak orasıdır.

Bir düzeltmeden sonra bu çıktıyı yapılandırmanın yanında saklayın. Bir istemci güncellemesi varsayılanlarını değiştirdiğinde, kaydedilen küme size karşılaştırma için bir taban çizgisi verir ve karşılaştırma soruşturmayı baştan başlatmak yerine yer değiştiren alana işaret eder.