IKEv2 tek bir el sıkışma değildir: IKE SA, kimlik doğrulama, sonra CHILD SA

IKEv2 bağlantısının trafiğinizi şifreleyerek biten tek bir alışveriş olduğunu sanabilirsiniz. En az ikidir ve birincisi kimseyi doğrulamaz. Taraflar kontrol mesajlarıyla başlar, kriptografik parametrelerde anlaşır, kimliği kanıtlar ve ancak ondan sonra uygulama paketlerini taşıyan durumu müzakere eder. Bu sıra, insanların sürekli bildirdiği uyumsuzluğu açıklar: ağ geçidi yanıt verir, istemci bağlı görünür, özel uygulama yine de zaman aşımına uğrar. Her aşamanın gerçekte ne yaptığı ve sonrasında neyin doğru olması gerektiği aşağıdadır.

Efsane: ağ geçidi yanıt veriyorsa bağlısınız

İlk mesaja verilen yanıt, uç noktanın erişilebilir ve konuşmaya istekli olduğunu kanıtlar. Bir hesabın kabul edildiğini, bir sertifika zincirinin doğrulandığını veya herhangi bir veri politikasının kurulduğunu kanıtlamaz.

Bu hatalar daha sonra olur ve farklı belirtiler verir. Sertifika reddi veya EAP hatası, ilk alışveriş zaten başarılı olduktan sonra gelir; bu yüzden UDP 500'e ping ve yeşil istemci simgesi çok az şey söyler.

IKE_SA_INIT: parametrelerde anlaşın, kimlikte değil

İlk alışveriş IKE güvenlik ilişkisi için önerileri taşır: şifreleme ve bütünlük algoritmaları, sözde rastgele bir fonksiyon ve bir Diffie-Hellman grubu. Taraflar nonce de paylaşır ve her taraf IKE SA için anahtar malzemesini bu değerlerin ürettiği ortak sırdan türetir. Bu alışverişte hiçbir şey karşı tarafın kim olduğunu belirlemez. Yalnızca iki tarafın aynı anahtarları hesaplayabildiğini ve bir öneri üzerinde anlaştığını belirler. Hiçbir öneriyi beğenmeyen yanıtlayıcı alışverişi burada reddeder; bu yüzden sürüm veya algoritma uyuşmazlığı sunucu düşmüş gibi görünür.

Bu noktada oluşturulan IKE SA sonraki tüm yönetim alışverişlerini korur. Bu onun işidir ve paketlerinizi korumaktan farklı bir iştir.

IKE_AUTH: kimliği kanıtlayın, sonra ilk CHILD SA'yı kurun

İkinci alışveriş kimliği taşır. Sertifikalarla her taraf kendi özel anahtarıyla imzalar ve diğerinin doğrulaması gereken bir zincir sunar; EAP ile yanıtlayıcı, seçilen yöntemle başlatıcıya meydan okur. Yanlış sunucu adı, süresi geçmiş sertifika veya reddedilen parola nihayet burada ortaya çıkar.

Normalde IKE_AUTH ilk CHILD SA'yı da müzakere eder, böylece veri koruması aynı gidiş dönüşte kararlaştırılır. Başlatıcı trafik seçicileri önerir, yanıtlayıcı bunları daraltır veya reddeder ve veri yolu anahtarları IKE SA'dan türetilir. Yani tek bir alışveriş çok farklı iki yerde başarısız olabilir: kimlik veya politika. Genel el sıkışma hatası yerine bildirim yükünü veya hatayı okuyun, çünkü birinin çözümü sertifika, diğerininki alt ağ uyuşmazlığıdır.

İki SA, iki iş

Onları ayrı tutmak hata gibi görünen iki davranışı açıklar. Tünel kurulmuş görünürken arka planda anahtar yenileme başarısız olabilir ve istemci bağlantıyı kaybetmeden CHILD SA değiştirilebilir.

strongSwan'da IKEv2 yapılandırma başvurusu ve swanctl --list-sas iki düzeyi birden gösterir; ip xfrm state ile ip xfrm policy ise çekirdeğin gerçekte ne kurduğunu gösterir. Bu iki görünümü karşılaştırmak, müzakere bitti mi yoksa bitmiş gibi mi göründü anlamanın en hızlı yoludur. Daemon, çekirdeğin durumu olmadığı bir CHILD SA listeliyorsa kurulum sessizce başarısız olmuştur. Çekirdek, daemonun bilmediği bir durum tutuyorsa önceki bir denemenin kalıntısına bakıyorsunuz.

Tünel açıldıktan sonra hâlâ ne doğru olmalı

Trafik seçiciler hangi adreslerin kapsandığını tanımlar. İstemci bir alt ağ önerirken sunucu başkasını bekliyorsa, CHILD SA kurulur ama yararlı hiçbir şey taşımaz, ve hata müzakere değil yönlendirme sorunu olarak görünür. Sonra yerel yığın işbirliği yapmalıdır: ana makinenin yönlendirdiği yerde iletim açık, tünele giden yollar, kapsülden çıkarılmış paketlere izin veren güvenlik duvarı kuralları ve özel adlar söz konusuysa iç çözümleyici. Bunların her biri ayrı ayrı başarısız olur ve hiçbiri IKE daemonunu yeniden başlatarak düzelmez.

Tanı koyarken günlüğü görünür tutun: ilk alışveriş, sonra kimlik doğrulaması, uygulanıyorsa kullanıcı kimlik doğrulaması, sonra CHILD kurulumu ve son olarak uygulama trafiği. Duran aşama düzeltilecek aşamadır ve sonraki bir yönlendirme hatası, zaten geçmiş kimlik denetimlerini gevşetmek için asla gerekçe değildir.