Relay Nebula dikonfigurasikan tetapi tidak digunakan: tiga tetapan untuk diperiksa

Anda menambah hos relay, meletakkan alamat Nebula-nya dalam konfigurasi, dan kedua-dua rakan sebaya masih tidak berkomunikasi. Itu berlaku kerana laluan relay memerlukan tiga pernyataan berasingan yang mesti sepadan, dan hanya satu daripadanya terletak pada mesin yang mungkin anda edit. Saya telah menjejaki ini dua kali: sekali hos pemajuan tidak pernah diberi peranan relay, dan sekali tetapan ditulis pada sisi sambungan yang salah. Urutan di bawah memeriksa peranan, pengumuman dan kebenaran dalam urutan itu, dan setiap langkah mempunyai arahan yang memberitahu sama ada anda perlu meneruskan.

Petakan ketiga-tiga peranan sebelum anda mengedit konfigurasi

Nebula memberikan setiap hos satu tugas, dan tugas itu tidak diwarisi. Lighthouse menjawab soalan seperti di manakah rakan sebaya ini supaya hos dapat menemui satu sama lain. Relay memajukan trafik antara dua rakan sebaya yang tidak mempunyai laluan langsung yang berfungsi. Hos biasa tidak melakukan kedua-duanya. Ketiga-tiga tetapan yang penting terletak pada tiga mesin berbeza, dan sebab itulah konfigurasi klien yang kelihatan lengkap boleh membiarkan kedua-dua rakan sebaya menunggu.

# 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

Satu simptom memisahkan dua kelas kegagalan. Jika kedua-dua rakan sebaya menyenaraikan satu sama lain dan log menunjukkan percubaan handshake yang tidak pernah selesai, penemuan berfungsi dan laluan data disekat oleh NAT atau oleh firewall. Jika rakan sebaya tidak pernah mengetahui alamat yang lain langsung, masalahnya ada pada lighthouse atau peta hos statiknya, dan tetapan relay tidak dapat membaikinya.

Sahkan konfigurasi mana yang benar-benar dimuatkan oleh setiap hos sebelum anda mengubah apa-apa yang lain. Unit yang membaca laluan berbeza daripada fail yang anda edit ialah punca biasa dan memalukan bagi „perubahan itu tidak melakukan apa-apa”:

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

Baris versi penting dalam armada bercampur. Pengendalian relay, tingkah laku punching dan kunci konfigurasi yang diterima tidak sama merentas keluaran, jadi jangan andaikan binaan lama memahami bahagian yang tidak ditulis untuknya. Selaraskan hos pada siri minor yang sama, kemudian jalankan nebula -test -config /etc/nebula/config.yml pada setiap hos dan bandingkan output sebelum anda menyahpepijat pengangkutan yang tidak dilaksanakan oleh kod itu.

Dayakan peranan pemajuan pada hos relay

Peranan relay ialah satu bendera pada hos pemajuan, dan ia berasingan daripada menjadi lighthouse. Hos dengan penemuan dihidupkan dan pemajuan relay dimatikan masih hanya perkhidmatan penemuan. Pada relay:

relay:
  am_relay: true

Bendera itu mengisytiharkan niat; ia tidak mencipta kebolehcapaian. Relay mesti boleh dicapai daripada kedua-dua rakan sebaya, yang dalam praktiknya bermaksud alamat awam, UDP masuk pada port Nebula terbuka dalam firewall hos dan dalam mana-mana kumpulan keselamatan awan, dan tiada NAT berganda di hadapannya. Periksa soket yang mendengar dan kemudian perhatikan sama ada paket rakan sebaya tiba:

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

Dua had menjimatkan masa kemudian. Relay tidak boleh dicapai melalui relay lain, jadi rantaian nama relay dalam konfigurasi bukan pengganti laluan yang boleh digunakan ke hos pemajuan. Dan relay memajukan paket; ia tidak memberikan kebenaran, peraturan masuk destinasi sendiri masih menentukan sama ada aliran yang dimajukan dibenarkan. Peranan dan keperluannya diterangkan dalam dokumentasi konfigurasi relay.

Umumkan relay daripada destinasi, bukan daripada klien

Inilah pembalikan yang memakan paling banyak jam. Senarai relay milik hos yang anda cuba capai, kerana ia memberitahu rakan sebaya lain relay mana yang boleh digunakan untuk mencapai hos itu. Meletakkannya pada klien yang memulakan sambungan tidak melakukan apa-apa untuk arah yang diperlukan oleh klien:

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

Rakan sebaya melaporkan senarai itu bersama alamat mereka apabila mereka mendaftar masuk dengan lighthouse, jadi pengumuman itu tersebar melalui penemuan dan bukan melalui pertukaran langsung. Jika destinasi tidak mencapai mana-mana lighthouse, senarai relay-nya tidak pernah tersebar dan relay yang dikonfigurasikan dengan betul kekal terbiar. Kegagalan itu kelihatan tepat seperti relay rosak dan bukan begitu.

Berikan destinasi laluan bootstrap dalam langkah yang sama. Peta hos statik mengikat alamat Nebula kepada titik akhir awam supaya handshake pertama ada tempat untuk pergi, dan ia memerlukan entri untuk relay jika destinasi perlu menerima trafik yang dimajukan daripada hos yang tidak dapat dicapai secara langsung:

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

Biarkan rakan sebaya yang menyambung menggunakan relay

Sisi yang memulakan memerlukan kebenarannya sendiri. relay.use_relays dihidupkan secara lalai, jadi kes yang wajar dicari ialah false eksplisit, selalunya disalin daripada templat yang ditulis sebelum ciri relay wujud atau ditinggalkan oleh percubaan terdahulu untuk memaksa laluan langsung:

relay:
  use_relays: true

Kebenaran di sisi ini bukan satu-satunya pintu. Peraturan masuk destinasi masih terpakai pada paket yang dimajukan, dan sumber yang dipadankan ialah identiti di dalam tunnel dan bukan alamat relay itu sendiri. Apabila handshake yang dimajukan selesai dan aplikasi masih gagal, baca log destinasi untuk sumber yang dicatatkannya sebelum anda menulis semula peraturan.

Tetapan penembusan NAT berinteraksi dengan semua ini. punchy.punch membantu dua rakan sebaya membuka laluan langsung, dan apabila berjaya tiada trafik relay untuk diperhatikan; itu kejayaan, bukan relay yang hilang. Pasangan yang berfungsi secara berselang-seli biasanya bermaksud punching hanya berjaya kadangkala, jadi uji pasangan itu beberapa kali daripada membuat kesimpulan daripada satu percubaan.

Sahkan dengan pasangan yang gagal, kemudian muat semula

Uji kedua-dua hos yang benar-benar gagal, dengan aplikasi yang mereka perlukan. Ping yang berjaya daripada stesen kerja anda ke perkhidmatan relay itu sendiri tidak membuktikan apa-apa tentang pemajuan antara dua rakan sebaya lain, dan ia ialah positif palsu yang paling biasa dalam keseluruhan prosedur ini.

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

Muat semula daripada memulakan semula, dan sahkan bahawa proses yang berjalan telah mengambil fail yang anda edit. Permulaan semula meruntuhkan setiap tunnel dan menjadikan ujian seterusnya lebih sukar dibaca, manakala SIGHUP mengekalkan proses dan menyuruhnya membaca semula konfigurasi:

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

systemctl reload hanya berfungsi apabila unit tempatan mentakrifkan ExecReload, dan unit yang disertakan dengan projek tidak berbuat demikian, jadi systemctl kill -s HUP ialah langkah yang berjaya pada pemasangan standard. Selepas memuat semula, baca jurnal untuk laluan konfigurasi yang dibuka oleh proses itu, supaya anda tahu fail baharu yang dibaca dan bukan fail yang anda andaikan dimuatkan.

Tetapan relay dan punching NAT kedua-duanya bertindak pada laluan; tidak satu pun bertindak pada identiti. Jika pasangan masih gagal handshake selepas am_relay, relays dan use_relays disahkan dalam konfigurasi yang berjalan, periksa sama ada kedua-dua hos mengemukakan sijil yang dikeluarkan untuk nama yang mereka gunakan dan sama ada CA itu sama pada kedua-dua sisi. Kekalkan konfigurasi sijil dan firewall sementara anda menukar satu tetapan pengangkutan pada satu masa, kerana perubahan sijil dan perubahan relay dalam ujian yang sama tidak memberitahu anda yang mana telah menggerakkan handshake. Ketidakpadanan nama atau CA gagal di tempat yang sama seperti relay yang tidak pernah ditemui, dan sebab itulah semakan songsang ini tergolong dalam langkah yang sama.

Kemudian sahkan bahawa setiap pernyataan berada dalam fail yang sepatutnya:

• am_relay: true pada hos pemajuan, dan hos itu boleh dicapai melalui UDP dari kedua-dua pihak.
• relays: dengan alamat Nebula hos itu pada destinasi.
• use_relays: true pada rakan sebaya yang memulakan sambungan.
• Peraturan masuk pada destinasi yang masih membenarkan sumber sebenar selepas laluan berubah.