Dua LAN di NetBird: peer mana yang merutekan, dan siapa yang boleh bicara

Sebuah workstation di LAN barat membuka peramban, mengetik alamat aplikasi di LAN timur, dan menunggu sampai waktu habis. Setiap layar NetBird mengatakan peer terhubung, yang benar dan tidak relevan: berada di satu jaringan overlay tidak sama dengan memiliki kedua subnet lokal dalam satu jaringan. Penelusuran di bawah dimulai dari workstation itu dan berakhir dengan permintaan yang ditolak desain dengan sengaja, dan setiap perhentian adalah sesuatu yang Anda baca dari perangkat, bukan tebak. Perkirakan bagian yang hilang adalah rute atau kebijakan, bukan overlay.

Baca kegagalan dari workstation lebih dulu

Sebelum membuka konsol manajemen, tetapkan apa yang sebenarnya dikirim workstation. Tabel peruteannya sendiri menentukan apakah paket menuju gateway situs, antarmuka lokal, atau tidak ke mana-mana, dan keputusan itu terlihat tanpa alat overlay apa pun. Mesin tanpa rute untuk prefiks jauh akan gagal seberapa sehat pun daftar peer terlihat. Rentang overlay dan prefiks situs itu sendiri adalah ruang alamat berbeda, dan pendaftaran hanya mengonfigurasi salah satunya.

Setelah itu pisahkan resolusi nama dari keterjangkauan, karena peramban melaporkan keduanya sebagai waktu habis yang sama. Ulangi permintaan berdasarkan alamat dari mesin yang menjalankan klien NetBird, lalu dari workstation biasa yang tidak menjalankannya. Jika mesin terdaftar berhasil dan yang biasa gagal, celahnya ada di perutean lokal; jika keduanya gagal, teruskan membaca sebelum mengubah rute.

Pilih satu peer perutean per situs

Peer perutean adalah host yang mewakili LAN-nya di overlay, jadi pilih mesin Linux dengan keterjangkauan stabil ke subnet, bukan workstation meja seseorang. Daftarkan lewat proses normal dan masukkan ke grup yang dinamai sesuai peran, karena sumber daya jaringan dan kebijakan keduanya akan merujuk ke grup itu. Satu perwakilan per situs tetap mudah dibaca; sekumpulan sukarelawan yang mengiklankan prefiks yang sama mengubah setiap pertanyaan berikutnya menjadi sesi awakutu. Alamat peer di segmen lokal sama pentingnya dengan identitasnya di overlay, karena alamat itu menjadi hop berikutnya yang diberitahukan ke setiap perangkat biasa.

Tulis rencananya sebelum menyentuh konsol, karena nama dan prefiks adalah tempat desain ini melenceng: prefiks, gateway, alamat peer, dan grup, per situs. Barat adalah 10.52.0.0/24 yang dilayani 10.52.0.5 dan timur adalah 10.63.0.0/24 yang dilayani 10.63.0.5; kedua grup adalah west-routers dan east-routers, dan tidak ada prefiks yang boleh tumpang tindih dengan yang lain, dengan rentang overlay, atau dengan tujuan terutekan lain.

Buat sumber dayanya, pertahankan penyamaran

Di dasbor yang terpasang, buat satu sumber daya jaringan per situs dan lampirkan grup peer perutean situs itu ke sana. Sumber daya adalah prefiks dan grup adalah host yang menjawabnya, dan keduanya harus ada sebelum apa pun diiklankan. Pastikan versi swakelola yang terpasang setidaknya memiliki alur kerja Jaringan, karena antarmuka lama dengan objek rute bernama serupa adalah fitur lain.

Biarkan penyamaran aktif. Panduan NetBird situs-ke-situs mewajibkannya dalam susunan ini, dan mematikannya agar setiap alamat asli tetap terlihat bukanlah desain yang sama dengan satu hop lebih sedikit; itu mengubah apa yang dilihat pemeriksaan sumber dan kebijakan overlay. Konsekuensinya layak dikatakan terus terang: layanan penerima mencatat peer perutean sebagai sumber, bukan workstation individual. Jika daftar izin atau audit layanan itu mengharapkan alamat workstation, entah harapannya berubah atau identitas harus ditegakkan di batas situs sebelum penerjemahan.

Beri wewenang pada pemrakarsa, bukan pada prefiks

Rute membuat alamat dapat dijangkau dan kebijakan menentukan siapa yang boleh memakainya; keduanya objek terpisah dengan pemilik terpisah. Tulis kebijakannya mundur dari beban kerja: grup mana yang memprakarsai, sumber daya mana yang dituju, dan layanan TCP mana yang dibutuhkan. Jaringan yang mengiklankan kedua prefiks ke setiap peer terdaftar telah menciptakan keterjangkauan dan belum menyelesaikan apa pun.

Lalu baca apa lagi yang sudah diizinkan, karena aturan baru yang sempit tidak mencabut aturan lama yang lebar di atasnya. Ketika timur juga harus memulai koneksi ke barat, tulis arah itu sebagai kebijakannya sendiri; lalu lintas balik untuk sesi yang dibuka barat adalah pertanyaan berbeda dari mengizinkan sesi baru ke timur. Jika hanya sebagian workstation barat yang harus mencapai aplikasi timur, pilih mereka di batas situs sebelum penerjemahan dan pertahankan autentikasi aplikasi itu sendiri. Peer perutean membawa lalu lintas LAN sebagai seluruh situs, bukan sebagai identitas overlay per pengguna, jadi akuntansi per pengguna harus datang dari tempat lain.

Ajari setiap gateway hop berikutnya, lalu uji penolakan

Perangkat biasa tidak pernah melihat overlay, jadi gateway mereka sendiri memerlukan rute statis yang mengarahkan prefiks jauh ke alamat LAN peer perutean. Inilah langkah yang dilewati orang, karena semua yang terlihat di dalam NetBird sudah bekerja sementara workstation biasa masih kehabisan waktu. Gateway mempertahankan rute bawaannya seperti semula; prefiks ini adalah tambahan, bukan pengganti.

Kedua deskripsi rute masuk ke konfigurasi gateway masing-masing situs, bukan ke penimpaan pada host. Keduanya rute statis biasa, dan tidak satu pun menyentuh rute bawaan:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Uji dengan aplikasi yang benar-benar dibutuhkan proyek, dari workstation biasa, dan catat tiga hal: hop berikutnya yang dipilih di sisi pengirim, kebijakan yang cocok, dan alamat sumber yang dicatat layanan. Uji juga penolakan, karena desain yang belum pernah menolak apa pun punya tepi yang tidak diketahui, dan penolakan adalah satu-satunya bukti bahwa kebijakan, bukan perutean, yang bekerja. Ketika timur juga harus memprakarsai, mulai koneksi baru dari sisi itu alih-alih menganggap arah kedua mengikuti. Rencanakan juga mulai ulang, peningkatan, dan penggantian peer perutean, karena satu host telah menjadi ketergantungan situs.

Nama privat memerlukan desain resolver sendiri, karena keterjangkauan tidak membuat catatan DNS dan jalur IP yang bekerja dengan nama rusak terbaca persis seperti jalur rusak. Jika peer perutean berjalan di dalam jaringan awan, tinjau juga aturan penerusan dan tembok api penyedia, karena pendaftaran tidak mengesampingkannya. Simpan pengamatan dari uji di samping rencana, karena orang berikutnya yang mengawakutu ini akan menginginkan kebijakan yang cocok dan alamat sumber yang tercatat, bukan deskripsi topologi.