Nebula: aktarma yapılandırılmış ama kullanılmıyor — denetlenecek üç ayar

Bir aktarma ana makinesi eklediniz, Nebula adresini bir yapılandırmaya yazdınız ve iki eş hâlâ konuşmuyor. Bunun nedeni, bir aktarma yolunun üç ayrı ifadenin uyuşmasını gerektirmesi ve bunlardan yalnızca birinin büyük olasılıkla düzenlediğiniz makinede bulunmasıdır. Bunu iki kez kovaladım: birinde iletme ana makinesine hiçbir zaman aktarma rolü verilmemişti, diğerinde ayarlar bağlantının yanlış tarafına yazılmıştı. Aşağıdaki sıra rolü, duyuruyu ve izni bu sırayla denetler ve her adımda devam edip etmeyeceğinizi söyleyen bir komut vardır.

Bir yapılandırmayı düzenlemeden önce üç rolü haritalayın

Nebula her ana makineye bir görev verir ve görevler miras alınmaz. Deniz feneri 'bu eş nerede' sorularını yanıtlar, böylece ana makineler birbirini bulabilir. Aktarma, çalışan doğrudan yolu olmayan iki eş arasındaki trafiği iletir. Sıradan bir ana makine ikisini de yapmaz. Önemli üç ayar üç ayrı makinede yaşar, bu yüzden eksiksiz görünen bir istemci yapılandırması iki eşi de bekletiyor bırakabilir.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Bir belirti iki arıza sınıfını ayırır. İki eş birbirini listeliyorsa ve günlük hiç tamamlanmayan el sıkışma denemeleri gösteriyorsa, keşif çalışıyor ve veri yolu NAT ya da güvenlik duvarı tarafından engellenmiş demektir. Bir eş diğerinin adresini hiç öğrenmiyorsa sorun deniz fenerinde ya da onun statik ana makine haritasındadır ve aktarma ayarları bunu onaramaz.

Başka bir şeyi düzenlemeden önce her ana makinenin gerçekte hangi yapılandırmayı yüklediğini doğrulayın. Düzenlediğiniz dosyadan farklı bir yolu okuyan birim, 'değişiklik hiçbir şey yapmadı' sözünün yaygın ve utanç verici nedenidir:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Karışık bir filoda sürüm satırı önemlidir. Aktarma işleyişi, delme davranışı ve kabul edilen yapılandırma anahtarları sürümler arasında aynı değildir, bu yüzden eski bir derlemenin kendisi için yazılmadığı bir bölümü anladığını varsaymayın. Ana makineleri aynı küçük seriye hizalayın, sonra her ana makinede nebula -test -config /etc/nebula/config.yml çalıştırın ve kodun uygulamadığı bir taşımayı hata ayıklamadan önce çıktıyı karşılaştırın.

Aktarma ana makinesinde iletme rolünü etkinleştirin

Aktarma rolü, iletme ana makinesindeki tek bir bayraktır ve deniz feneri olmaktan ayrıdır. Keşif etkin ve aktarma iletimi devre dışı olan bir ana makine hâlâ yalnızca bir keşif hizmetidir. Aktarmada:

relay:
  am_relay: true

Bu bayrak niyeti bildirir; erişilebilirlik yaratmaz. Aktarma iki eşten de erişilebilir olmalıdır; bu pratikte genel bir adres, ana makinenin güvenlik duvarında ve herhangi bir bulut güvenlik grubunda Nebula bağlantı noktasında açık gelen UDP ve önünde çift NAT olmaması anlamına gelir. Dinleyen soketi denetleyin, sonra eşin paketlerinin geldiğini gözleyin:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

İki sınır sonradan zaman kazandırır. Bir aktarmaya başka bir aktarma üzerinden erişilemez, bu yüzden yapılandırmadaki aktarma adları zinciri, iletme ana makinesine kullanılabilir bir yol vermenin yerini tutmaz. Ve aktarma paketleri iletir; izin vermez, bu yüzden aktarılan akışa izin verilip verilmediğine hedefin kendi gelen kuralları karar verir. Rol ve gereksinimleri aktarma yapılandırma belgelerinde açıklanmıştır.

Aktarmayı istemciden değil, hedeften duyurun

En çok saat yiyen tersine çevirme budur. Aktarma listesi, ulaşmaya çalıştığınız ana makinede olmalıdır, çünkü diğer eşlere o ana makineye ulaşmak için hangi aktarmaların kullanılabileceğini söyler. Onu bağlantıyı başlatan istemciye koymak, istemcinin ihtiyaç duyduğu yön için hiçbir şey yapmaz:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Eşler deniz fenerine kaydolurken bu listeyi adresleriyle birlikte bildirir, bu yüzden duyuru doğrudan değiş tokuş yerine keşif yoluyla yayılır. Hedef bir deniz fenerine ulaşamıyorsa aktarma listesi asla yayılmaz ve doğru yapılandırılmış bir aktarma boşta kalır. Bu arıza tam olarak bozuk bir aktarma gibi görünür ve öyle değildir.

Aynı geçişte hedefe bir başlangıç yolu verin. Statik ana makine haritası bir Nebula adresini genel bir uç noktaya bağlar, böylece ilk el sıkışmanın gidecek bir yeri olur ve hedef, doğrudan ulaşamadığı ana makinelerden aktarılan trafiği kabul edecekse aktarma için bir girdiye ihtiyaç duyar:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Bağlanan eşin aktarmayı kullanmasına izin verin

Başlatan tarafın kendi iznine ihtiyacı vardır. relay.use_relays varsayılan olarak açıktır, bu yüzden aranmaya değer durum açık bir false'tur; çoğu zaman aktarma özelliği var olmadan önce yazılmış bir şablondan kopyalanmış ya da doğrudan yolları zorlamaya yönelik daha eski bir denemeden kalmıştır:

relay:
  use_relays: true

Bu taraftaki izin tek kapı değildir. Hedefin gelen kuralları aktarılan paket için hâlâ geçerlidir ve eşleştirdikleri kaynak, aktarmanın kendi adresi değil tünelin içindeki kimliktir. Aktarılan el sıkışma tamamlandığında uygulama yine de başarısız olursa, bir kuralı yeniden yazmadan önce hedefin günlüğünde kaydettiği kaynağı okuyun.

NAT geçiş ayarları tüm bunlarla etkileşir. punchy.punch iki eşin doğrudan bir yol açmasına yardımcı olur ve başarılı olduğunda gözlenecek aktarma trafiği yoktur; bu başarıdır, eksik bir aktarma değildir. Aralıklı çalışan bir çift genellikle delmenin bazen başarılı olduğu anlamına gelir, bu yüzden tek bir denemeden sonuç çıkarmak yerine o çifti birkaç kez deneyin.

Başarısız olan çiftle doğrulayın, sonra yeniden yükleyin

Gerçekten başarısız olan iki ana makineyi ihtiyaç duydukları uygulamayla test edin. İş istasyonunuzdan aktarmanın kendi hizmetine başarılı bir ping, iki başka eş arasındaki iletme hakkında hiçbir şey kanıtlamaz ve bu, tüm bu prosedürdeki en yaygın yanlış pozitiftir.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Yeniden başlatmak yerine yeniden yükleyin ve çalışan sürecin düzenlediğiniz dosyayı aldığını doğrulayın. Yeniden başlatma her tüneli yıkar ve sonraki testi okumayı zorlaştırır, oysa SIGHUP süreci korur ve yapılandırmayı yeniden okumasını sağlar:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload yalnızca yerel birim ExecReload tanımladığında çalışır ve projeyle gelen birim bunu tanımlamaz, bu yüzden standart bir kurulumda başarılı olan adım systemctl kill -s HUP'tür. Yeniden yüklemeden sonra sürecin açtığı yapılandırma yolu için günlüğü okuyun, böylece varsaydığınız dosya değil yeni dosyanın okunduğunu bilirsiniz.

Aktarma ayarları ve NAT delme ikisi de yol üzerinde etkilidir; hiçbiri kimlik üzerinde etkili değildir. Çalışan yapılandırmada am_relay, relays ve use_relays doğrulandıktan sonra çift hâlâ el sıkışmada başarısız oluyorsa, iki ana makinenin de yapılandırıldıkları adlar için verilmiş sertifikalar sunduğunu ve CA'nın iki tarafta da aynı olduğunu denetleyin. Sertifikayı ve güvenlik duvarı yapılandırmasını sabit tutup taşıma ayarlarını birer birer değiştirin, çünkü aynı testte yer alan bir sertifika düzenlemesi ile bir aktarma düzenlemesi el sıkışmayı hangisinin hareket ettirdiğini söylemez. Bir ad ya da CA uyuşmazlığı, hiç bulunamayan bir aktarmayla aynı yerde başarısız olur, bu yüzden bu karşı denetim de aynı geçişe aittir.

Sonra her ifadenin ait olduğu dosyada durduğunu doğrulayın:

• am_relay: true iletme ana makinesinde ve o ana makine iki taraftan da UDP ile erişilebilir olmalı.
• relays: hedefte o ana makinenin Nebula adresini belirtmeli.
• use_relays: true bağlantıyı başlatan eşte olmalı.
• Yol değiştikten sonra da hedefin gelen kuralları gerçek kaynağa izin verir.