Nebula static_host_map: alamat yang tidak bisa diberikan mercusuar

Setiap mercusuar dapat memberi tahu sebuah host tentang setiap peer lain kecuali di mana mercusuar itu sendiri berada. Sesuatu harus diketahui sebelum overlay ada, dan Nebula menaruh sesuatu itu dalam satu peta kecil. Peta memasangkan identitas overlay dengan alamat yang bekerja di jaringan biasa. Semua yang dipelajari kemudian bergantung pada pasangan itu benar.

Dua alamat dengan dua tugas

Setiap host Nebula memiliki alamat overlay yang tetap selama perangkat berpindah antarjaringan. Alamat itu adalah identitas yang dipakai sertifikat, aturan firewall, dan hubungan peer, dan sendirian ia tidak merutekan ke mana pun. Titik akhir yang dapat dijangkau adalah hal lain: nama host atau alamat di jaringan dasar ditambah port UDP, dan berubah setiap kali mesin berpindah lokasi. Peta statis adalah sambungan antara keduanya.

Hanya host yang harus dihubungi dingin yang masuk peta, yang biasanya berarti mercusuar dan mungkin satu relay. Menjaga daftar itu tetap pendek adalah tujuan desain, karena setiap entri manual menjadi fakta yang harus dipelihara seseorang. Mencampur kedua jenis alamat adalah kesalahan konfigurasi yang lazim: alamat publik yang ditaruh di daftar mercusuar tidak membuat penemuan mulai.

Identitas pergi ke tempat identitas diharapkan. Keterjangkauan pergi ke peta.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomi entri peta

Kuncinya adalah alamat overlay yang ditulis sebagai string dalam tanda kutip, dan nilainya adalah daftar titik akhir, sehingga satu identitas dapat memiliki beberapa titik masuk. Setiap titik akhir membawa host dan port, dan port harus cocok dengan yang benar-benar didengarkan sisi lain. Bawaan Nebula adalah UDP 4242, yang merupakan titik awal, bukan janji tentang penerapan Anda.

Beberapa titik akhir berguna ketika sebuah mercusuar punya lebih dari satu jalur masuk, seperti alamat publik dan alamat privat bagi host di segmen yang sama. Klien mencobanya berurutan, jadi taruh yang paling andal lebih dulu. Untuk IPv6, letakkan alamat dalam tanda kurung siku sebelum menambahkan port; salah melakukannya menghasilkan kesalahan parsing yang menunjuk baris yang salah.

Port yang salah menghasilkan kesunyian alih-alih kesalahan, karena UDP tidak punya handshake untuk menolak. Karena itu format entri layak diperiksa terhadap referensi static_host_map Nebula dan bukan ingatan. Referensi itu juga mencakup daftar titik akhir dan perilaku penyegaran DNS.

Bootstrap harus bekerja sebelum overlay

Nama DNS dalam peta harus diselesaikan melalui resolver yang dimiliki host sebelum ada terowongan apa pun, yaitu resolver sistem biasa. Ujilah dari mesin yang sama, saat boot, dengan overlay dimatikan. Nama yang hanya diselesaikan melalui DNS milik overlay tidak dapat mem-bootstrap overlay. Uji yang sama berlaku untuk rute: aturan firewall yang mengizinkan overlay tetapi tidak pertukaran UDP pertama akan memblokir paket awal.

Periksa port dengan alat UDP alih-alih menganggapnya terbuka. Pastikan penerusan port apa pun di jalur menuju host internal yang benar dan ada jalur kembali. Jika nama host diselesaikan ke beberapa alamat, uji masing-masing, karena klien dapat memilih alamat yang tidak pernah Anda periksa.

Entri statis dihubungi langsung dan tidak pernah bertanya kepada mercusuar. Itulah sebabnya kegagalan di sini tampak seperti timeout biasa tanpa peer yang terlibat.

Apa yang terjadi setelah handshake pertama

Begitu sebuah host mencapai mercusuar, ia mempelajari peer dan alamat mereka yang dapat dijangkau tanpa entri manual tambahan. Host yang berpindah sejak koneksi terakhir menjadi dapat ditemukan melalui kanal itu. Itulah imbalan karena menjaga peta manual tetap kecil.

Host juga dapat mengumumkan alamat tambahannya yang dapat dijangkau, dan begitulah peer di balik alamat publik yang dikenal membantu orang lain menemukannya. Pengumuman itu dipelajari, bukan diketik ke peta statis.

Perilaku penyegaran penting untuk titik akhir yang ditulis sebagai nama DNS, karena alamat yang diselesaikan dapat berubah selama proses terus berjalan. Pengaturan Nebula mengatur bagaimana pencarian itu terjadi, termasuk resolver mana yang dipakai, jadi bacalah alih-alih menganggap bawaan sistem. Pada host yang resolvernya berubah ketika terowongan naik, pengaturan yang salah dapat mengubah bootstrap yang berfungsi menjadi nama yang berhenti diselesaikan di tengah sesi. Menyematkan pencarian ke resolver yang stabil sering menjadi pembeda antara overlay yang andal dan yang terputus-putus.

Ketika penemuan bekerja dan satu peer tidak

Jika mercusuar dapat dijangkau dan sebagian besar peer terhubung, bootstrap bukan masalahnya. Pasangan yang tersisa entah tidak menemukan jalur yang dapat dipakai satu sama lain atau gagal di atas keterjangkauan. Menambahkan ejaan lain dari alamat mercusuar tidak dapat memperbaiki kedua kasus itu.

Periksa pasangan sebelum menyunting peta yang sudah menjadi tumpuan segala hal lain. Perubahan peta mengganggu setiap host, jadi itu hal terakhir yang disentuh, bukan yang pertama.

Mulailah dengan sertifikat dari otoritas yang sama, karena handshake yang ditolak dapat terlihat dari jauh seperti peer yang tidak terjangkau. Lalu periksa apakah pasangan dapat membangun jalur langsung dan apakah relay dikonfigurasi untuk jaringan yang menolak lalu lintas langsung. Relay menambah satu lompatan dan satu ketergantungan, tetapi itu jawaban yang didukung, dan memperbaiki jalur peer adalah tugas berbeda dari memperbaiki penemuan.