SSM di Atas OpenVPN: Mengikuti Satu Sumber dan Grup dari Awal hingga Akhir

Pilih satu aliran dan satu penerima, lalu ikuti pasangan itu melalui setiap hop alih-alih menguji multicast sebagai kategori. Desain khusus sumber gagal tepat di satu dari empat tempat: penerima tidak pernah bergabung, perute menolak paket pada jalur baliknya, kernel tidak memiliki status, atau terowongan tidak pernah mengirimkan salinan. Bekerja dalam urutan itu memakan waktu beberapa menit per hop dan memberi tahu Anda mana dari keempatnya yang sebenarnya Anda miliki.

Tetapkan sumber, grup, dan penerima terlebih dahulu

Catat tiga nilai sebelum menyentuh perangkat apa pun: alamat sumber yang akan mengirim, alamat grup yang akan dimasuki penerima, dan subnet tempat penerima berada. Untuk aliran IPv4 ilustratif, sumber 10.50.0.10 dan grup 232.20.30.40 adalah jenis pasangan yang cocok untuk desain khusus sumber. Apa pun yang lebih kabur dari ketiga nilai itu tidak dapat diuji.

Rentang 232/8 dicadangkan untuk multicast khusus sumber, dan modelnya dijelaskan dalam RFC 4607. Jika grup Anda berada di luar rentang itu sementara Anda yakin menjalankan SSM, berhentilah dan pastikan apa yang sebenarnya dimaksudkan oleh penerapan, karena keanggotaan penerima dan keputusan penerusan perute keduanya bergantung pada model yang konsisten.

Periksa bahwa penerima telah bergabung ke sumber

Laporan keanggotaan hanya untuk grup bukanlah gabungan khusus sumber. Tanyakan kepada penerima sumber mana yang dimintanya, dan pada perute hop pertama lihat status grup untuk melihat apakah daftar sumber muncul. Jika laporan tidak membawa sumber, perute akan memperlakukannya sebagai gabungan dari sumber mana pun dan seluruh desain diam-diam merosot menjadi sesuatu yang tidak Anda rencanakan.

Pada penerima Linux, periksa apa yang sebenarnya disubscribe oleh soket dan apa yang dicatat kernel. File konfigurasi aplikasi bukan bukti; tabel keanggotaan adalah buktinya. Bacalah saat penerima benar-benar berjalan, karena entri dapat bertahan sebentar setelah proses yang membuatnya keluar. Entri basi dari pengujian sebelumnya adalah sumber kepercayaan diri palsu yang andal.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Jika gabungan ada dengan sumber yang diharapkan, lanjutkan ke perute. Jika tidak ada, tidak ada konfigurasi terowongan yang akan membantu, karena tidak ada yang bisa diteruskan.

Verifikasi jalur balik sebelum melihat terowongan

Perutean multicast melakukan pemeriksaan jalur balik, dan paket yang tiba pada antarmuka selain yang ditunjuk oleh rute unicast akan dibuang. Ini adalah alasan paling umum mengapa aliran yang jelas sedang dikirim tidak pernah mencapai hop berikutnya, dan sama sekali tidak menghasilkan kesalahan tingkat aplikasi yang berguna.

Pada perute yang menghadap sumber, bandingkan rute menuju sumber dengan antarmuka tempat paket benar-benar tiba. Pada perute yang menghadap penerima, lakukan hal yang sama untuk subnet penerima sendiri dan pastikan daftar antarmuka keluar mencakup tautan ke arahnya. Ketidakcocokan di salah satu arah adalah kegagalan RPF, bukan kegagalan keanggotaan.

Lalu pastikan TTL sumber cukup besar untuk bertahan melewati hop terutekan yang Anda rancang. Aliran yang berfungsi pada perute pertama dan mati pada perute kedua sering kali merupakan pertanyaan TTL, bukan pertanyaan kebijakan.

Baca status multicast kernel alih-alih konfigurasi

Konfigurasi memberi tahu Anda apa yang Anda minta; kernel memberi tahu Anda apa yang terjadi. Pada setiap hop Linux, baca entri perutean multicast dan pastikan daftar antarmuka masuk dan keluar ada untuk pasangan sumber dan grup yang tepat. Entri untuk grup dengan sumber wildcard adalah objek yang berbeda, dan itu tidak akan menjelaskan aliran khusus sumber.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Daemon perutean menyimpan pandangan mereka sendiri di atas status itu, dan perintah yang mencetaknya bergantung pada implementasi mana yang terpasang. Prinsipnya tetap: tanyakan kepada daemon entri hulu untuk pasangan itu, lalu tanyakan kepada kernel apakah entri penerusan ada. Daemon yang mengira sedang meneruskan sementara kernel tidak memiliki entri adalah masalah cakupan konfigurasi pada host itu.

Ketika keduanya tidak sepakat, perbaiki host, bukan VPN. Tidak ada yang di hilir dapat mengimbangi hop yang tidak meneruskan aliran yang Anda tanyakan. Catat pasangan, antarmuka masuk, dan daftar keluar untuk setiap hop selama aliran berfungsi. Catatan itu mengubah kegagalan berikutnya menjadi perbandingan alih-alih penyelidikan baru.

Putuskan bagaimana terowongan sebenarnya mereplikasi

Di sinilah multicast melalui VPN berhenti menjadi rutin. Terowongan titik-ke-titik mengirimkan paket ke satu-satunya rekan di ujung lain, sehingga salinan mencapai tepat satu klien. Segmen dijembatani berperilaku lebih seperti tautan bersama, karena terowongan membawa frame dan jembatan memutuskan apa yang dibanjiri. Itu adalah model pengiriman yang berbeda, dan desain yang mengasumsikan yang kedua sementara menjalankan yang pertama akan tampak berhasil untuk satu penerima dan gagal untuk penerima berikutnya.

Untuk lebih dari satu penerima melalui server multipoint, replikasi harus dirancang secara eksplisit. Memasang rute multicast di gateway tidak mengajari server VPN rekan mana yang harus menerima salinan, dan tidak ada rute sisi klien yang membuat keputusan itu untuknya. Jika persyaratannya banyak penerima, gunakan replikasi yang didukung atau alternatif yang dipilih dengan sengaja, dan tuliskan mana yang Anda pilih.

Terakhir, verifikasi di penerima dengan pengamatan sempit: sumber, grup, dan port yang tepat, pada antarmuka yang Anda harapkan, sementara satu penerima yang berwenang telah bergabung. SSM memilih pengirim, dan pemilihan bukanlah autentikasi pengirim itu, juga bukan izin bagi lalu lintas multicast lain untuk melewati kebijakan yang sama.