GDOI: anahtar sunucusu neden veri yolunuzda değil

Grup anahtar sunucusu ilkeyi ve anahtarları üyelere dağıtır, üyeler trafiği kendileri korur. Bu cümle, bir tasarım denetleyiciyi her korumalı paket için aktarıcı olarak görmeye başlayana kadar bir formalite gibi görünür; o noktada topoloji hiç ihtiyaç duymadığı bir atlama kazanır ve trafik yolu yalnızca durum dağıtmak için tasarlanmış bir cihaza bağlı hale gelir. Anahtar sunucusunun nerede olduğunu söylemek ve verinin nereye aktığını söylemek iki farklı şemadır ve GDOI tam olarak bu fark etrafında inşa edilmiştir. Bunu ters anlamak küçük bir modelleme hatası değildir, çünkü neyi izlediğinizi ve neyi ölçeklediğinizi değiştirir. Aşağıdaki bölümler protokolün kendi bölünmesini izler.

İki tür güvenlik durumu

RFC 6407 üyenin ilke ve anahtar malzemesi istemek için çekme değişimini ve yetkili üyelere ilke ile anahtar güncellemeleri dağıtan itme değişimini tanımlar. İkisi de güvenlik ilişkilerini yönetir. Hiçbiri uygulamanın veri akışı değildir, bu yüzden başarılı bir değişim yalnızca kontrol kanalının çalıştığını kanıtlar. Bir üye temiz kayıt olabilir, geçerli anahtarlar tutabilir ve veri ilkesi yanlışsa trafiği koruyamaz veya iletemez. Hangi değişimin hangisini taşıdığını bildiğinizde bu iki arıza tamamen farklı görünür.

Standart ayrıca anahtar güncelleme mesajlarını koruyan bir anahtar yenileme güvenlik ilişkisini, üyelerin trafiği nasıl koruduğunu açıklayan veri güvenlik ilişkilerinden ayrı olarak adlandırır.

Şemayı değil, değişimleri izleyin

Her mesajın ne için olduğuna bakın. Kayıt, denetleyiciye hangi üyenin sorduğunu söyler ve durum oluşturur; anahtar yenileme, üyelere ilkenin veya anahtarların değiştiğini söyler; ardından korumalı uygulama trafiği kurulu veri güvenlik ilişkisini kullanarak üyeler arasında akar. Denetleyicinin adresi ilk ikisinde görünür ve üçüncüsünde hiç görünmek zorunda değildir.

Bu yüzden fiziksel komşuluğa göre çizilmiş bir arayüz şeması burada yanıltıcıdır. Denetleyicinin arayüzü bir kontrol kaynağıdır, her şifreli paket için otomatik olarak sonraki atlama değildir.

Saklamaya değer üç kayıt

Üyenin kimliği doğrulanmış kaydını ve ulaşabildiği kontrol kaynağını, sonraki anahtar güncellemelerini teslim eden yolu ve korumalı uygulama trafiğini taşıyan rotalar ile bağlantıları yazın. Üç kayıt, üç sahip ve herhangi birindeki arıza farklı bir belirti verir. Kayıt olup sonra hiç güncelleme almayan bir üye, iki kayıt da sizde yoksa eski ilkeyle kayıt olmuş bir üyeyle aynı görünür.

Bunları kimsenin belleğinde değil, yapılandırmanın yanında tutun. Üyelik değişiklikleri o kadar seyrektir ki gerekçe ihtiyaç duyulduğunda her zaman çoktan kaybolmuştur.

Arayüz, hizmet bağlantısı, işleme yolu

Hizmet tabanlı bir ağ geçidinde bir ayrım daha vardır: fiziksel alt katman adresi yerel hizmet bağlantısıyla aynı şey değildir ve trafiğin IPsec işleme yoluna nasıl ulaştığına platformun uygulaması karar verir. Bir hizmeti fiziksel arayüze taşımak veya bir hata iletisi hizmet arayüzü kuralından söz etti diye ilgisiz çeviri eklemek, onarım kılığındaki bir tahmindir.

Hizmet bağlantısının trafiği nasıl aldığına dair platformun kendi belgelerini okuyun. Protokol standart olsa bile mekanizma satıcıya özgüdür.

Standartlaştırılmış protokol mesajları da satıcılar arasında uyumluluk kurmaz. İki uygulamanın birlikte çalışacağını varsaymadan önce gerekli özellikleri, ilke ve ilişki niteliklerini, kimlik doğrulama yöntemini ve tam platform ile sürümü karşılaştırın.

Kontrol kullanılabilirliği ve veri yönlendirme ayrı kontrollerdir

Denetleyiciye erişilebilirliği normal işletim, üyelik değişiklikleri ve anahtar güncellemeleri için planlayın. Zaten kurulu durumda başarılı olan bir uygulama değişimi, sonraki kaydın veya yenilemenin üyeye ulaşabileceğini kanıtlamaz ve boşluk genellikle saatler sonra yeni üye kabul etmeyi bırakan bir tünel olarak ortaya çıkar. Yalnızca çalışan bir oturumu değil, yeni bir kaydı test edin.

Ardından yönlendirmeyi denetleyici olmadan ayrı olarak test edin. İki kontrol, iki sonuç ve hangi yarının bozuk olduğuna dair çok daha kısa bir tartışma.