Mengapa multicast tidak melintasi VPN tanpa rencana

Dua situs bisa saling menjangkau dengan sempurna lewat unicast dan tetap berperilaku seolah salah satunya tidak melihat pengumuman penemuan printer, aliran IPTV, atau detak jantung klaster. Ini bukan terowongan rusak; ini perbedaan antara tujuan dan grup. Pengiriman multicast membutuhkan model keanggotaan, status penerusan di sepanjang jalur, dan antarmuka yang bersedia membawa lalu lintas, dan tidak satu pun dari itu berasal dari rute unicast. Berjalan dari grup aplikasi ke satu penerima yang berfungsi adalah jalur terpendek menuju jawaban.

Mulai dari grup dan aplikasi

Tanyakan alamat grup mana yang dipakai aplikasi dan untuk apa lalu lintasnya. Protokol penemuan yang mengumumkan layanan, aliran streaming, dan paket halo protokol perutean adalah tiga masalah berbeda dengan tiga jawaban berbeda yang dapat diterima. Alamat grup itu sendiri memberi tahu cakupannya: alamat di blok kendali jaringan lokal tidak dimaksudkan untuk diteruskan keluar tautan oleh perutean biasa, dan aplikasi yang memakainya biasanya mengasumsikan satu domain siaran. Aliran streaming pada grup dengan cakupan global adalah rancangan berbeda dari protokol penemuan yang mengharapkan setiap perangkat mendengar setiap kueri, dan hanya yang kedua peduli pada ukuran domain siaran.

Putuskan apakah kebutuhannya adalah layanan atau mekanisme penemuan, karena kedua jawaban itu berbeda biaya sebesar satu orde besaran. Yang satu meminta alamat yang tidak berubah; yang lain meminta domain siaran yang diperluas melintasi tautan area luas beserta semua yang mengikutinya.

Penemuan lokal seharusnya berhenti

Multicast DNS seperti dijelaskan dalam RFC 6762 dirancang di sekitar satu tautan: kueri menuju grup tetap, jawaban dikirim ke grup yang sama, dan protokolnya bergantung pada setiap peserta mendengar semua orang. Router tidak meneruskan lalu lintas itu secara bawaan, dan itu keputusan rancangan, bukan kelalaian. Batas itu ada agar perangkat di satu gedung tidak bisa sembarangan mengumumkan dirinya ke gedung lain. Terowongan yang tampak memperbaiki penemuan dengan membawa grup ke mana-mana telah menghapus batas itu bagi setiap aplikasi, bukan hanya yang membutuhkan bantuan.

Pengulang dan pemantul ada, dan itu layanan nyata dengan akibat nyata: setiap nama yang diumumkan di satu situs menjadi terlihat di situs lain, termasuk nama perangkat yang mengidentifikasi orang atau peralatan. Jika kebutuhan sebenarnya adalah agar layanan tertentu dapat ditemukan, catatan layanan yang diterbitkan di DNS biasanya perubahan yang lebih kecil, dan itu mengungkap satu nama alih-alih aliran nama.

Tiga hal yang dibutuhkan multicast yang dirutekan

Multicast yang dirutekan membutuhkan tiga hal yang bekerja bersama: penerima yang bergabung ke grup, router yang memelihara status penerusan untuknya, dan terowongan yang memperlakukan alamat grup sebagai lalu lintas yang harus dibawa. Terowongan dengan kebijakan yang hanya mencantumkan subnet unicast akan menjatuhkan lalu lintas grup di batas enkripsi, dan itulah sebabnya gejala pertama sering kali diam, bukan kesalahan. Antarmuka berbasis rute seperti terowongan GRE atau VTI membawa apa yang dikirim tabel perutean ke dalamnya, yang membuat grup terjangkau begitu status multicast ada.

Keterjangkauan sumber adalah paruh kedua. Protokol perutean multicast seperti PIM membangun pohon distribusi dengan memeriksa bahwa jalur kembali ke sumber adalah jalur yang diharapkan, jadi rute unicast yang menunjuk ke tempat lain merusak pohon itu bahkan ketika keanggotaan grup benar. Memasang rute untuk penerima tidak melakukan apa pun untuk pemeriksaan itu, dan inilah kesalahan yang menghasilkan ping yang bekerja dan aliran yang gagal. Verifikasi dulu jalur balik sumber, lalu tambahkan keanggotaan, dan baru setelah itu lihat aplikasi.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Dua baris pertama menunjukkan ke apa hos bergabung dan apa yang diteruskan kernel, baris ketiga menunjukkan keanggotaan aplikasi itu sendiri, dan yang terakhir jalur unicast yang akan dipakai pemeriksaan jalur balik. Membacanya bersama membedakan aplikasi yang tidak pernah bergabung dari jaringan yang tidak pernah meneruskan.

Buktikan dengan satu sumber dan satu penerima

Sebelum menyentuh konfigurasi, pastikan aplikasi bekerja pada satu segmen. Jika gagal secara lokal, perutean multicast bukan masalahnya dan tidak ada perubahan terowongan yang akan menolong. Lalu ulangi dengan satu penerima di seberang terowongan dan amati paket di kedua sisi batas enkripsi.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Paket yang terlihat di dalam terowongan tetapi tidak ada di luarnya menunjuk pada enkapsulasi atau kebijakan; paket yang terlihat di kedua sisi tanpa kemajuan aplikasi menunjuk pada keanggotaan penerima atau pengikatan aplikasi. Jaga tangkapan tetap pendek dan tersaring, karena tangkapan multicast yang luas pada segmen sibuk sebagian besar adalah derau.

Pilih alamat layanan bila hanya butuh layanannya

Penemuan ada untuk menemukan sesuatu yang bergerak. Server dengan nama stabil tidak butuh penemuan, dan alamat terdokumentasi di DNS privat menjawab pertanyaan sebenarnya pengguna tanpa memperluas domain siaran melintasi tautan area luas. Alasan yang sama berlaku untuk printer, peranti, dan layanan web internal. Nama di DNS dapat dijangkau dari setiap situs yang membutuhkannya sambil tidak mengumumkan apa pun ke situs yang tidak, dan tetap bekerja ketika perangkat diganti dengan yang beralamat berbeda.

Ketika sebuah protokol benar-benar membutuhkan multicast, batasi pada grup dan situs yang membutuhkannya, dokumentasikan alasannya, dan tinjau kembali keputusan itu ketika aplikasi berubah. Memperluas penemuan ke mana-mana mudah dilakukan sekali, dan sulit dibatalkan setelah setahun perangkat yang diam-diam bergantung padanya.