AH mi ESP mi? Paketin neyi koruması gerektiğine göre karar verin

İki IPsec önerisi aynı SHA tabanlı bütünlük algoritmasını adlandırıp yine de farklı koruma protokolleri talep edebilir; AH ve ESP tek bir kimlik doğrulama ayarının iki yazımı değildir. Önce protokolü, sonra algoritmalarını, sonra modunu okuyun; belirsizliğin çoğu kaybolur. AH paketi, yolda değişmeden kalan IP başlık alanları dâhil doğrular; ESP ise kapsadığı içeriği doğrular ve şifreler, dış başlığı ise olduğu gibi bırakır. Bu fark, herhangi bir hash adından daha fazla kurulumu belirler.

AH kapsar ama ESP kapsamaz

AH bütünlük, veri kaynağı doğrulaması ve kendi tanımladığı tekrar önleme hizmetini sağlar; hiçbir gizlilik sağlamaz. Kapsamı, üst katman verilerini ve kurallarının değişmez saydığı IP başlık alanlarını içerir; yani ESP taşıma modunda tam olarak bu kısmı dışarıda bırakır. Bir gereksinim IP başlığının kendisinin doğrulanmasını istiyorsa buna yanıt veren protokol AH olur.

Bu kapsam, AH neden sahada kırılgan olduğunun da nedenidir. TTL, başlık sağlama toplamı ve bazı seçenekler gibi değişken alanlar doğrulanamaz çünkü yönlendiriciler bunları yeniden yazabilir; bu yüzden protokol, sağlama hesaplanmadan önce onları sıfırlar. Dolayısıyla adresleri yeniden yazan her şey yalnızca politikayı değil, hesaplamayı da bozar.

NAT seçimi bir kısıta dönüştürür

Adres çevirisi, AH az önce doğruladığı IP başlığındaki kaynağı veya hedefi yeniden yazar; bu yüzden bütünlük denetimi öbür uçta başarısız olur ve okunabilir bir mesaj olarak değil, protokol hatası olarak başarısız olur. ESP dış başlığı doğrulamaz; bu yüzden NAT geçişiyle ESP çalışır, NAT arkasındaki AH çalışmaz. İki ucu da sıradan yönlendiricilerin arkasında olan bir tünel, bunun ilk göründüğü yerdir. Bu yüzden ilk soru hangi protokolün daha güçlü olduğu değil, uçlar arasında bir çevirici olup olmadığıdır.

Varsa AH elenir ve konuşma ESP ile onun algoritma seçimlerine geçer. Bu bir tercih değil kısıttır; bu yüzden kararın sonunda değil başında yer alır.

Mod soruyu çoğaltır

ESP taşıma modunda üst katman yükünü korur ve IP başlığına dokunmaz; tünel modunda iç IP başlığı dâhil tüm iç paketi kapsar ve onu korur. AH da aynı iki moda sahiptir; yani AH ya da ESP, herhangi bir algoritma seçilmeden önce aslında dört birleşimdir.

Birleşik modlu ESP algoritmaları sonra bütünlüğü ikinci bir protokol olmadan çözer. AES-GCM ve ChaCha20-Poly1305 tek bir yapıda doğrular ve şifreler; bu yüzden üstüne AH eklemek bir şey kazandırmaz ama bir başlık ve bir müzakere daha harcar. Mimari AH ile ESP birlikte kabul eder ve pratik soru ağ geçidinizin ve sürümünüzün bu birleşimi destekleyip desteklemediği ve sonradan birinin onu sürdürüp sürdüremeyeceğidir.

Yalnızca AH için dürüst ikame

Yalnızca bütünlük sağlayan ESP varyantı algoritmayı korur ve şifreleme iddiasını taklit etmek yerine bırakır; NAT geçer. Eski bir tasarım gizlilik olmadan kimlik doğrulama gerektiği için AH kullandıysa, o varyant doğrudan çeviridir, üzerine not iliştirilmiş şifreli bir tünel değil.

Bir öneride ESP görmek de şifrelemenin kanıtı değildir. Şifreleme algoritmasını okuyun: NULL girdisi yalnızca bütünlük, birleşik mod girdisi ise ikisini birden anlatır.

Üç soruyla karar verin

Gizlilik gerekiyor mu, yolda bir çevirici var mı ve hangi başlık alanları doğrulanmalı diye sorun. Bu üç yanıt tek bir protokole ve tek bir moda işaret eder; onları yazmak, sonradan RFC leri yeniden okumaktan daha az zaman alır.

Sonra önerileni değil kabul edileni doğrulayın. ip xfrm state kurulu ilişkilendirmenin protokolünü, modunu ve algoritmalarını gösterir; uyuşmazlık hiçbir şey kurmaz, bu da amaçlanan koruma olmadan açılan bir tünelden daha temiz bir başarısızlıktır.

Kimlik doğrulama hatalarını, seçici kapsamını ve yönlendirme hatalarını bu seçimden ayrı tutun. Farklı belirtiler verirler ve seçici sorununda protokolü suçlamak, sebepsiz yere hash değiştirerek bir gün geçirmenin güvenilir yoludur.