mDNS melalui WireGuard: tiga pintu sebelum peer menjawab

Menetapkan bendera multicast pada peranti WireGuard menjadikan antara muka layak untuk perisian penemuan, dan itu sahaja yang dilakukan bendera itu. Ia tidak memberitahu protokol ke mana paket kumpulan patut pergi, dan pada peranti dengan beberapa peer tiada satu jawapan yang jelas. Tiga pintu berasingan berdiri antara daemon yang berjalan dan perkhidmatan yang ditemui.

Uji mengikut urutan, kerana lulus satu pintu tidak memberitahu apa-apa tentang pintu seterusnya.

Pintu pertama: bendera dan dasar daemon

Peranti WireGuard Linux dicipta sebagai pautan titik-ke-titik tanpa ARP, dan secara lalai tidak membawa bendera multicast. Menambah bendera ialah perubahan antara muka tempatan, dilakukan oleh apa sahaja yang menguruskan peranti. Avahi mempunyai pandangan dunianya sendiri di atas itu, dan dasar lalainya melangkau antara muka titik-ke-titik sepenuhnya. Jadi dua ujian kelayakan bebas terpakai sebelum satu paket pun bergerak.

Jadi daemon memerlukan keputusan eksplisit, bukan sekadar proses yang berjalan. Kawalan terdokumentasinya termasuk allow-interfaces, deny-interfaces dan allow-point-to-point, dan yang terakhir ialah tetapan yang orang terlepas pandang.

Pemeriksaan di bawah melaporkan bendera pautan, laluan multicast dan sama ada konfigurasi daemon dihuraikan sama sekali:

ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check

Daemon yang berjaya dimulakan belum tentu membuka soket pada antara muka yang anda pedulikan. Baca konfigurasi efektifnya daripada menganggap status perkhidmatan sama dengan liputan.

Pintu kedua: laluan ke kumpulan

Pintu kedua ialah penghalaan biasa. Paket yang dialamatkan ke 224.0.0.251 mengikut jadual penghantaran seperti perkara lain, dan jika jadual menghantarnya keluar melalui antara muka LAN fizikal, tiada konfigurasi WireGuard akan mengubahnya. Betulkan laluan dahulu dan baki siasatan menjadi lebih pendek. Lihat apa yang dilaporkan kernel untuk alamat kumpulan sebelum menyentuh mana-mana kunci peer.

Tanpa laluan khusus, kernel kembali kepada pengendalian multicast pautan itu sendiri, sebab itulah lalai kelihatan betul pada LAN rata dan salah sebaik sahaja trafik kumpulan yang sama perlu keluar melalui terowong. Kegagalan itu senyap dari sisi penghantar: pertanyaan pergi ke suatu tempat, dan jawapan tidak pernah tiba.

Pintu ketiga: WireGuard memilih satu peer bagi setiap paket

WireGuard memilih peer keluar dengan mencari destinasi dalam set alamat yang dibenarkan, dan laluan penghantaran Linux melakukan carian itu sekali bagi setiap paket. Hasilnya satu, dan paket disulitkan untuk peer itu. Prefiks kumpulan yang sama muncul dalam senarai dibenarkan beberapa peer tidak mencipta keahlian atau replikasi; ia mencipta carian kabur yang diselesaikan kepada salah satu daripadanya.

Pada pautan dua hujung khusus, inilah tepatnya yang anda mahukan, kerana ada satu penerima yang dimaksudkan untuk trafik kumpulan yang dibawa dengan sengaja. Pada antara muka dengan lima peer ini ialah had, bukan ciri, dan pembetulannya terletak pada reka bentuk, bukan pada konfigurasi mana-mana satu peer.

Reka bentuk penyebaran memerlukan geganti eksplisit, pautan berasingan atau mekanisme penemuan yang sama sekali berbeza. Menerbitkan resipi dua hujung sebagai penyelesaian berbilang klien kerana setiap klien boleh ping gateway ialah cara ini digunakan secara salah.

Arah masuk diperiksa secara berbeza: sumber paket yang diterima mesti jatuh dalam senarai dibenarkan peer yang disahkan. Menambah destinasi multicast di situ tidak menggantikan pemilikan sumber sebenar penghantar.

Pantulan ialah sempadan, bukan jambatan

Reflektor Avahi menghasilkan semula mesej mDNS antara antara muka yang dipilihnya, pada lapisan aplikasi. Ia ialah sempadan penemuan antara rangkaian, bukan jambatan Ethernet dan bukan penghala multicast umum. Dua reflektor yang disambungkan ke rangkaian yang sama akan dengan senang hati mencipta gelung pengumuman berulang.

Pantulan juga menyerahkan nama perkhidmatan dan metadatanya kepada rangkaian lain, yang merupakan keputusan privasi sama seperti keputusan penghalaan. Hadkan antara muka yang dipilih, dan gunakan penapis perkhidmatan di mana versi yang dipasang menyokongnya, supaya hanya pengumuman yang diperlukan pengguna yang dibenarkan melintasi sempadan.

Penemuan dan penggunaan kekal sebagai hasil berasingan. Klien boleh melihat pengumuman untuk perkhidmatan yang alamat diiklankannya tidak dapat dicapai dari tempat klien berada, atau yang portnya ditolak oleh dasar aksesnya. Sahkan sambungan perkhidmatan selepas pengumuman muncul, dan jika aplikasi menyokong nama DNS yang stabil atau alamat pelayan eksplisit, utamakan itu daripada melanjutkan penemuan setempat pautan. Keterangan penghalaan kunci kripto merangkumi pemilihan peer berdasarkan destinasi yang menjadi asas semua ini.