Relay Nebula sudah dikonfigurasi tetapi tidak terpakai: tiga pengaturan yang perlu diperiksa

Anda menambahkan host relay, menaruh alamat Nebula-nya di sebuah konfigurasi, dan kedua peer tetap tidak bisa berkomunikasi. Itu terjadi karena jalur relay membutuhkan tiga pernyataan terpisah yang harus cocok, dan hanya satu di antaranya berada di mesin yang mungkin Anda edit. Saya sudah menelusuri ini dua kali: sekali ketika host penerus tidak pernah diberi peran relay, dan sekali ketika pengaturannya ditulis di sisi koneksi yang salah. Urutan di bawah ini memeriksa peran, pengumuman, dan izin dalam urutan itu, dan setiap langkah punya perintah yang memberi tahu apakah Anda harus melanjutkan.

Petakan ketiga peran sebelum Anda mengedit konfigurasi

Nebula memberi setiap host sebuah tugas, dan tugas itu tidak diwariskan. Lighthouse menjawab pertanyaan seperti di mana peer ini agar host dapat saling menemukan. Relay meneruskan lalu lintas antara dua peer yang tidak punya jalur langsung yang berfungsi. Host biasa tidak melakukan keduanya. Ketiga pengaturan yang penting berada di tiga mesin berbeda, dan itulah sebabnya konfigurasi klien yang tampak lengkap bisa membuat kedua peer 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 gejala memisahkan dua kelas kegagalan. Jika kedua peer saling mencantumkan dan log menunjukkan upaya handshake yang tidak pernah selesai, penemuan berjalan dan jalur data diblokir oleh NAT atau firewall. Jika sebuah peer sama sekali tidak mengetahui alamat peer lain, masalahnya ada di lighthouse atau peta host statisnya, dan pengaturan relay tidak dapat memperbaikinya.

Pastikan konfigurasi mana yang benar-benar dimuat setiap host sebelum Anda mengubah hal lain. Unit yang membaca jalur berbeda dari berkas yang Anda edit adalah penyebab umum dan memalukan dari „perubahan tidak melakukan apa-apa”:

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

Baris versi penting di armada campuran. Penanganan relay, perilaku punching, dan kunci konfigurasi yang diterima tidak identik antar rilis, jadi jangan berasumsi build lama memahami bagian yang tidak ditulis untuknya. Samakan host pada seri minor yang sama, lalu jalankan nebula -test -config /etc/nebula/config.yml di setiap host dan bandingkan keluarannya sebelum Anda men-debug transport yang tidak diimplementasikan kode.

Aktifkan peran penerusan di host relay

Peran relay adalah satu flag di host penerus, dan terpisah dari menjadi lighthouse. Host dengan penemuan aktif dan penerusan relay nonaktif tetap hanya layanan penemuan. Di relay:

relay:
  am_relay: true

Flag itu menyatakan niat; ia tidak menciptakan keterjangkauan. Relay harus dapat dijangkau dari kedua peer, yang dalam praktik berarti alamat publik, UDP masuk pada port Nebula terbuka di firewall host dan di grup keamanan cloud mana pun, serta tidak ada NAT ganda di depannya. Periksa socket yang mendengarkan, lalu amati apakah paket peer datang:

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

Dua batasan menghemat waktu nanti. Relay tidak dapat dijangkau melalui relay lain, jadi rantai nama relay dalam konfigurasi bukan pengganti jalur yang dapat dipakai ke host penerus. Dan relay meneruskan paket; ia tidak memberikan izin, aturan masuk tujuan sendiri yang tetap menentukan apakah aliran yang diteruskan diizinkan. Peran dan persyaratannya dijelaskan di dokumentasi konfigurasi relay.

Umumkan relay dari tujuan, bukan dari klien

Inilah pembalikan yang memakan paling banyak jam. Daftar relay melekat pada host yang ingin Anda capai, karena memberi tahu peer lain relay mana yang boleh dipakai untuk mencapai host itu. Menaruhnya di klien yang memulai koneksi tidak berguna bagi arah yang dibutuhkan klien:

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

Peer melaporkan daftar itu bersama alamatnya saat mendaftar ke lighthouse, jadi pengumuman menyebar melalui penemuan dan bukan melalui pertukaran langsung. Jika tujuan tidak mencapai lighthouse mana pun, daftar relay-nya tidak pernah menyebar dan relay yang dikonfigurasi dengan benar tetap menganggur. Kegagalan itu terlihat persis seperti relay rusak dan bukan.

Beri tujuan jalur bootstrap pada langkah yang sama. Peta host statis mengikat alamat Nebula ke endpoint publik agar handshake pertama punya tujuan, dan peta itu perlu entri untuk relay jika tujuan harus menerima lalu lintas yang diteruskan dari host yang tidak dapat dijangkau langsung:

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

Izinkan peer yang menghubungkan diri memakai relay

Sisi yang memulai butuh izinnya sendiri. relay.use_relays aktif secara default, jadi kasus yang layak dicari adalah false eksplisit, sering disalin dari templat yang ditulis sebelum fitur relay ada atau ditinggalkan oleh upaya sebelumnya memaksakan jalur langsung:

relay:
  use_relays: true

Izin di sisi ini bukan satu-satunya gerbang. Aturan masuk tujuan tetap berlaku untuk paket yang diteruskan, dan sumber yang dicocokkan adalah identitas di dalam tunnel, bukan alamat relay itu sendiri. Ketika handshake yang diteruskan selesai dan aplikasi masih gagal, baca log tujuan untuk sumber yang dicatatnya sebelum Anda menulis ulang aturan.

Pengaturan penembusan NAT berinteraksi dengan semua ini. punchy.punch membantu dua peer membuka jalur langsung, dan bila berhasil tidak ada lalu lintas relay yang bisa diamati; itu keberhasilan, bukan relay yang hilang. Pasangan yang bekerja sesekali biasanya berarti punching hanya berhasil kadang-kadang, jadi uji pasangan itu beberapa kali alih-alih menarik kesimpulan dari satu percobaan.

Verifikasi dengan pasangan yang gagal, lalu muat ulang

Uji kedua host yang benar-benar gagal, dengan aplikasi yang mereka butuhkan. Ping yang berhasil dari workstation Anda ke layanan relay itu sendiri tidak membuktikan apa pun tentang penerusan antara dua peer lain, dan itu adalah positif palsu paling umum di seluruh prosedur ini.

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

Muat ulang alih-alih memulai ulang, dan pastikan proses yang berjalan sudah mengambil berkas yang Anda edit. Memulai ulang memutus setiap tunnel dan membuat tes berikutnya lebih sulit dibaca, sedangkan SIGHUP mempertahankan proses dan memintanya membaca ulang konfigurasi:

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

systemctl reload hanya berfungsi bila unit lokal mendefinisikan ExecReload, dan unit yang disertakan proyek tidak melakukannya, jadi systemctl kill -s HUP adalah langkah yang berhasil pada instalasi standar. Setelah memuat ulang, baca journal untuk jalur konfigurasi yang dibuka proses, agar Anda tahu berkas baru yang dibaca dan bukan berkas yang Anda anggap termuat.

Pengaturan relay dan punching NAT keduanya bekerja pada jalur; keduanya tidak bekerja pada identitas. Jika pasangan masih gagal handshake setelah am_relay, relays, dan use_relays dikonfirmasi di konfigurasi yang berjalan, periksa apakah kedua host menyajikan sertifikat yang diterbitkan untuk nama yang mereka gunakan dan apakah CA-nya sama di kedua sisi. Jaga konfigurasi sertifikat dan firewall tetap selama Anda mengubah satu pengaturan transport pada satu waktu, karena perubahan sertifikat dan perubahan relay dalam tes yang sama tidak memberi tahu Anda mana yang menggeser handshake. Ketidakcocokan nama atau CA gagal di tempat yang sama dengan relay yang tidak pernah ditemukan, dan itulah sebabnya pemeriksaan balik ini termasuk dalam langkah yang sama.

Lalu pastikan setiap pernyataan berada di berkas tempat ia berada:

• am_relay: true di host penerus, dan host itu dapat dijangkau lewat UDP dari kedua sisi.
• relays: dengan alamat Nebula host itu di tujuan.
• use_relays: true di peer yang memulai koneksi.
• Aturan masuk di tujuan yang masih mengizinkan sumber sebenarnya setelah jalur berubah.