mDNS di atas WireGuard: tiga gerbang sebelum peer menjawab
Avahi membutuhkan antarmuka yang memenuhi syarat, rute ke grup, dan peer yang memiliki tujuan. Tiga gerbang, tiga pemeriksaan terpisah, dan tanpa penyebaran.
Menyetel flag multicast pada perangkat WireGuard membuat antarmuka memenuhi syarat bagi perangkat lunak penemuan, dan hanya itu yang dilakukan flag tersebut. Flag itu tidak memberi tahu protokol ke mana paket grup harus pergi, dan pada perangkat dengan beberapa peer tidak ada satu jawaban yang jelas. Tiga gerbang terpisah berdiri antara daemon yang berjalan dan layanan yang ditemukan.
Ujilah secara berurutan, karena lulus satu gerbang tidak memberi tahu apa pun tentang gerbang berikutnya.
Gerbang pertama: flag dan kebijakan daemon
Perangkat WireGuard di Linux dibuat sebagai tautan point-to-point tanpa ARP, dan secara bawaan tidak membawa flag multicast. Menambahkan flag adalah perubahan antarmuka lokal, yang dilakukan oleh apa pun yang mengelola perangkat. Avahi memiliki pandangannya sendiri tentang dunia di atas itu, dan kebijakan bawaannya melewati antarmuka point-to-point sepenuhnya. Jadi dua uji kelayakan independen berlaku sebelum satu paket pun bergerak.
Jadi daemon memerlukan keputusan eksplisit, bukan sekadar proses yang berjalan. Kontrolnya yang terdokumentasi mencakup allow-interfaces, deny-interfaces, dan allow-point-to-point, dan yang terakhir adalah pengaturan yang orang lewatkan.
Pemeriksaan di bawah ini melaporkan flag tautan, rute multicast, dan apakah konfigurasi daemon dapat diuraikan sama sekali:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkDaemon yang berhasil dimulai belum tentu membuka soket pada antarmuka yang Anda pedulikan. Bacalah konfigurasi efektifnya alih-alih menganggap status layanan sama dengan cakupan.
Gerbang kedua: rute ke grup
Gerbang kedua adalah perutean biasa. Paket yang dialamatkan ke 224.0.0.251 mengikuti tabel penerusan seperti hal lainnya, dan jika tabel mengirimkannya keluar melalui antarmuka LAN fisik, tidak ada konfigurasi WireGuard yang akan mengubahnya. Perbaiki rute terlebih dahulu dan sisa penyelidikan menjadi lebih singkat. Lihat apa yang dilaporkan kernel untuk alamat grup sebelum menyentuh kunci peer apa pun.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
Tanpa rute khusus, kernel kembali ke penanganan multicast milik tautan itu sendiri, itulah sebabnya bawaan terlihat benar di LAN datar dan salah begitu lalu lintas grup yang sama mestinya keluar lewat terowongan. Kegagalannya diam dari sisi pengirim: kueri pergi ke suatu tempat, dan jawabannya tidak pernah tiba.
Gerbang ketiga: WireGuard memilih satu peer per paket
WireGuard memilih peer keluar dengan mencari tujuan di himpunan alamat yang diizinkan, dan jalur transmisi Linux melakukan pencarian itu sekali per paket. Hasilnya satu, dan paket dienkripsi untuk peer tersebut. Prefiks grup yang sama muncul di daftar yang diizinkan beberapa peer tidak menciptakan keanggotaan atau replikasi; itu menciptakan pencarian ambigu yang bermuara pada salah satunya.
Pada tautan dua titik ujung yang khusus, inilah tepatnya yang Anda inginkan, karena ada satu penerima yang dimaksudkan untuk lalu lintas grup yang dibawa dengan sengaja. Pada antarmuka dengan lima peer ini adalah batasan, bukan fitur, dan perbaikannya ada pada desain, bukan pada konfigurasi salah satu peer.
Desain dengan penyebaran membutuhkan relai eksplisit, tautan terpisah, atau mekanisme penemuan yang sama sekali berbeda. Menerbitkan resep dua titik ujung sebagai solusi banyak klien karena setiap klien dapat melakukan ping ke gateway adalah cara ini diterapkan secara keliru.
Arah masuk diperiksa secara berbeda: sumber paket yang diterima harus berada di dalam daftar yang diizinkan milik peer yang terautentikasi. Menambahkan tujuan multicast di sana tidak menggantikan kepemilikan sumber sebenarnya dari pengirim.
Pemantulan adalah batas, bukan jembatan
Reflektor Avahi mereproduksi pesan mDNS di antara antarmuka yang dipilihnya, pada lapisan aplikasi. Itu adalah batas penemuan antarjaringan, bukan jembatan Ethernet dan bukan perute multicast umum. Dua reflektor yang terhubung ke jaringan yang sama akan dengan senang hati membuat lingkaran pengumuman berulang.
Pemantulan juga menyerahkan nama layanan dan metadatanya ke jaringan lain, yang merupakan keputusan privasi sama seperti keputusan perutean. Batasi antarmuka yang dipilih, dan gunakan filter layanan di mana versi yang terpasang mendukungnya, sehingga hanya pengumuman yang dibutuhkan pengguna yang berwenang yang melintasi batas.
Penemuan dan penggunaan tetap menjadi hasil yang terpisah. Klien dapat melihat pengumuman untuk layanan yang alamatnya diumumkan tidak dapat dijangkau dari tempat klien berada, atau yang portnya ditolak oleh kebijakan aksesnya. Konfirmasikan koneksi layanan setelah pengumuman muncul, dan jika aplikasi mendukung nama DNS yang stabil atau alamat server eksplisit, utamakan itu daripada memperluas penemuan lokal tautan. Penjelasan perutean kunci kripto mencakup pemilihan peer berbasis tujuan yang menjadi dasar semua ini.