static_host_map ve advertise_addrs ayarları ikisi de bir peer'ın önüne adres koyar ve farklı sorulara yanıt verir. Biri, bir overlay adresini ve aranacak underlay uç noktasını listeleyen yerel bir dosyadır. Diğeri, ana makinenin fenerlerine onu hangi ek uç noktaların ulaşabileceğini söylemesidir. Gerçek fark sahipliktir: haritayı ihtiyaç duyan herkes, duyuruyu ise ana makinenin kendisi sürdürür.

Bilgi kimin elinde ise ona göre karar verin

SettingWhere it livesBest for
static_host_mapEvery peer that needs the entryBootstrap endpoints, deliberately fixed paths
advertise_addrsThe host's own configEndpoints the host cannot otherwise discover

Her peer'ın statik dosyasındaki her değişen peer, filonun karesiyle büyüyen bir bakım işidir. Ana makine yanıtı kendisi bildiğinde diğer ayara başvurmanın pratik nedeni budur.

Sahiplik sorunu, bir adres değiştiğinde ne olacağını da öngörür. Statik haritada, eski girdiyi tutan her peer'ı birinin hatırlaması gerekir. Duyuruda ise ana makine yeni uç noktayı yayımlar ve fenerleri onu iletir, böylece değişiklik taşınan makinede yerel kalır.

Bootstrap hâlâ statik girdilere ihtiyaç duyar

İstemci, başkalarına diğer peer'ları sormadan önce en az bir fenere ulaşmalıdır. O ilk sıçrama keşiften gelemez, bu yüzden istemcinin yapılandırmasında statik bir girdi üzerine dayanır. O tek girdiyi doğru yapın ve overlay'in geri kalanı öğrenilebilir.

Harita girdisi bir Nebula adresini bir veya daha fazla erişilebilir IP ya da DNS uç noktası ve bağlantı noktasıyla eşler. Fenerleri orada tutmak normaldir; her peer'ı orada tutmak kötü yaşlanan bir kalıptır, çünkü her yeni peer denetlemediğiniz makinelerde dosya düzenlemek anlamına gelir. Listeyi bir kişinin okuyarak doğrulayabileceği kadar kısa tutun.

Ana makine uç noktayı bildiğinde duyurun

Bağlantı noktası yönlendirmesinin arkasındaki bir ana makine, kendi arabirimlerinden hiçbirine atanmamış genel bir adreste erişilebilir. Kendine bakarak o adresi keşfedemez. advertise_addrs onun uç noktayı fenerleri aracılığıyla yayımlamasına izin verir, böylece diğer peer'lar gerçekten çalışan bir yol öğrenir. Ayar tam da eşlemenin yapıldığını bilen tek tarafın ana makine olması nedeniyle vardır.

Diğer peer'ların gerçekten ulaşabildiği adresi ve bağlantı noktasını kullanın. Aynı mantık, belirli bir ağdaki peer'lar için bir yolun tercih edildiği birden çok ağ yoluna sahip bir ana makine için de geçerlidir. Duyuru, underlay hakkında bir beyandır, herhangi bir şey için istek değildir. Eşleme değiştiğinde duyuruyu ana makinede güncelleyin ve keşfin onu taşımasına izin verin, tüm filoda statik dosyaları düzenlemek yerine.

Duyuru erişilebilirlik değildir

Bir uç noktayı yayımlamak yönlendiricinin iletme kuralını oluşturmaz, yukarı akışta bir güvenlik duvarı açmaz ve bir DNS adını çözülemez kılmaz. Bunlar ayrı iş parçalarıdır ve bağlantı noktası yönlendirmesi eksik doğru bir duyuru, düzeltmeye çalıştığınız arızayı tam olarak üretir. Duyuru erişilebilirlik hakkında bir iddiadır, onu kuran bir mekanizma değil.

Keşfi suçlamadan önce yolu dışarıdan denetleyin. Uç noktayı öğrenip de handshake'i tamamlayamayan bir peer'ın underlay üzerinde yönlendirme ya da filtreleme sorunu vardır ve aynı adresi iki ayarda yinelemek bunu değiştirmez.

Overlay adresini uç noktadan ayrı tutun

Düğümün sertifikası Nebula adresini tanımlar. Duyurulan adresler alttaki ağa aittir ve sertifikaya dokunmadan değişebilir. Farklı bir overlay IP ile yeni sertifika düzenlemek başka bir işlemdir ve eskiyi sabitleyen her güven ilişkisi için kendi sonuçları vardır. İki değişikliği runbook'ta ayrı tutun, yoksa bir uç nokta taşıması yeniden düzenleme olarak kaydedilir.

Triyaj tıkandığında iki katmanı açıkça ayırın: keşif beklenen uç noktayı döndürüyor mu ve bir handshake ona ulaşıyor mu? Keşif doğruysa ve paketler başarısız oluyorsa sorun overlay'in altındadır. Keşif yanlışsa sorun haritada ya da duyurudadır ve düzeltme oraya aittir.

İlgili makaleler