Nebula static_host_map: alamat yang tidak boleh diberikan oleh rumah api

Setiap rumah api boleh memberitahu hos tentang setiap rakan lain kecuali di mana rumah api itu sendiri berada. Sesuatu mesti diketahui sebelum overlay wujud, dan Nebula meletakkan sesuatu itu dalam satu peta kecil. Peta memasangkan identiti overlay dengan alamat yang berfungsi pada rangkaian biasa. Semua yang dipelajari kemudian bergantung pada pasangan itu betul.

Dua alamat dengan dua tugas

Setiap hos Nebula mempunyai alamat overlay yang kekal tetap semasa peranti bergerak antara rangkaian. Alamat itu ialah identiti yang digunakan oleh sijil, peraturan firewall dan hubungan rakan, dan sendirian ia tidak menghala ke mana-mana. Titik akhir yang boleh dicapai ialah perkara lain: nama hos atau alamat pada rangkaian asas serta port UDP, dan ia berubah setiap kali mesin bertukar lokasi. Peta statik ialah sambungan antara kedua-duanya.

Hanya hos yang mesti didail sejuk masuk ke dalam peta, yang biasanya bermaksud rumah api dan mungkin satu geganti. Mengekalkan senarai itu pendek ialah matlamat reka bentuk, kerana setiap entri manual menjadi fakta yang seseorang perlu selenggara. Mengelirukan dua jenis alamat ialah kesilapan konfigurasi biasa: alamat awam yang diletakkan dalam senarai rumah api tidak memulakan penemuan.

Identiti pergi ke tempat identiti dijangka. Ketercapaian pergi ke dalam 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 ialah alamat overlay yang ditulis sebagai rentetan dalam tanda petikan, dan nilainya ialah senarai titik akhir, jadi satu identiti boleh mempunyai beberapa titik masuk. Setiap titik akhir membawa hos dan port, dan port mesti sepadan dengan apa yang didengar oleh pihak lain sebenarnya. Lalai Nebula ialah UDP 4242, yang merupakan titik permulaan dan bukan janji tentang penggunaan anda.

Beberapa titik akhir berguna apabila rumah api mempunyai lebih daripada satu laluan masuk, seperti alamat awam dan alamat peribadi untuk hos pada segmen yang sama. Klien mencubanya mengikut urutan, jadi letakkan yang paling boleh dipercayai dahulu. Untuk IPv6, letakkan alamat dalam kurungan segi empat sama sebelum menambah port; kesilapan di sini menghasilkan ralat penghuraian yang menunjuk baris yang salah.

Port yang salah menghasilkan senyap dan bukan ralat, kerana UDP tidak mempunyai handshake untuk menolak. Sebab itu format entri patut diperiksa terhadap rujukan static_host_map Nebula dan bukan ingatan. Rujukan itu juga merangkumi senarai titik akhir dan tingkah laku penyegaran DNS.

Bootstrap mesti berfungsi sebelum overlay

Nama DNS dalam peta mesti diselesaikan melalui penyelesai yang ada pada hos sebelum sebarang terowong wujud, iaitu penyelesai sistem biasa. Ujinya dari mesin yang sama, semasa but, dengan overlay dihentikan. Nama yang hanya diselesaikan melalui DNS overlay itu sendiri tidak boleh memulakan bootstrap overlay. Ujian yang sama terpakai pada laluan: peraturan firewall yang membenarkan overlay tetapi bukan pertukaran UDP pertama menghalang paket awal.

Periksa port dengan alat UDP dan bukan menganggapnya terbuka. Sahkan bahawa sebarang pemajuan port pada laluan menyasarkan hos dalaman yang betul dan laluan balik wujud. Jika nama hos diselesaikan kepada beberapa alamat, uji setiap satu, kerana klien mungkin memilih alamat yang tidak pernah anda periksa.

Entri statik didail terus dan tidak pernah bertanya kepada rumah api. Sebab itu kegagalan di sini kelihatan seperti tamat masa biasa tanpa rakan yang terlibat.

Apa yang berlaku selepas handshake pertama

Sebaik sahaja hos mencapai rumah api, ia mempelajari rakan dan alamat mereka yang boleh dicapai tanpa lebih banyak entri manual. Hos yang telah bergerak sejak sambungan terakhir menjadi boleh ditemui melalui saluran itu. Itulah ganjaran kerana mengekalkan peta manual kecil.

Hos juga boleh mengumumkan alamat tambahan mereka yang boleh dicapai, dan begitulah rakan di belakang alamat awam yang dikenali membantu orang lain menemuinya. Pengumuman itu dipelajari, bukan ditaip ke dalam peta statik.

Tingkah laku penyegaran penting untuk titik akhir yang ditulis sebagai nama DNS, kerana alamat yang diselesaikan boleh berubah semasa proses masih berjalan. Tetapan Nebula mengawal cara carian itu berlaku, termasuk penyelesai mana yang digunakan, jadi bacalah dan bukan menganggap lalai sistem. Pada hos yang penyelesainya berubah apabila terowong naik, tetapan yang salah boleh menukar bootstrap yang berfungsi kepada nama yang berhenti diselesaikan di tengah sesi. Menyemat carian kepada penyelesai yang stabil selalunya menjadi perbezaan antara overlay yang boleh dipercayai dan yang terputus-putus.

Apabila penemuan berfungsi dan satu rakan tidak

Jika rumah api boleh dicapai dan kebanyakan rakan bersambung, bootstrap bukan masalahnya. Pasangan yang tinggal sama ada tidak menemui laluan yang boleh digunakan ke satu sama lain atau gagal di atas ketercapaian. Menambah ejaan lain bagi alamat rumah api tidak boleh membaiki mana-mana daripada dua kes itu.

Periksa pasangan itu sebelum menyunting peta yang sudah menjadi tempat bergantung segala-galanya. Perubahan peta mengganggu setiap hos, jadi ia perkara terakhir yang disentuh, bukan yang pertama.

Mulakan dengan sijil daripada pihak berkuasa yang sama, kerana handshake yang ditolak boleh kelihatan dari jauh seperti rakan yang tidak boleh dicapai. Kemudian periksa sama ada pasangan itu boleh membina laluan langsung dan sama ada geganti dikonfigurasikan untuk rangkaian yang menolak trafik langsung. Geganti menambah satu hop dan satu kebergantungan, tetapi ia jawapan yang disokong, dan membaiki laluan pasangan ialah tugas berbeza daripada membaiki penemuan.