SSM melalui OpenVPN: Menjejaki Satu Sumber dan Kumpulan dari Awal hingga Akhir

Pilih satu strim dan satu penerima, kemudian ikuti pasangan itu melalui setiap hop dan bukannya menguji multicast sebagai kategori. Reka bentuk khusus sumber gagal tepat pada satu daripada empat tempat: penerima tidak pernah menyertai, penghala menolak paket pada laluan baliknya, kernel tidak mempunyai keadaan, atau terowong tidak pernah menghantar salinan. Bekerja dalam urutan itu mengambil masa beberapa minit setiap hop dan memberitahu anda yang mana antara empat itu sebenarnya anda hadapi.

Tetapkan sumber, kumpulan dan penerima terlebih dahulu

Catat tiga nilai sebelum menyentuh mana-mana peranti: alamat sumber yang akan menghantar, alamat kumpulan yang akan disertai penerima dan subnet tempat penerima berada. Untuk strim IPv4 ilustratif, sumber 10.50.0.10 dan kumpulan 232.20.30.40 ialah jenis pasangan yang sesuai dengan reka bentuk khusus sumber. Apa-apa yang lebih kabur daripada tiga nilai itu tidak boleh diuji.

Julat 232/8 dikhaskan untuk multicast khusus sumber, dan model itu diterangkan dalam RFC 4607. Jika kumpulan anda berada di luar julat itu sedangkan anda percaya anda menjalankan SSM, berhenti dan sahkan apa yang sebenarnya dimaksudkan oleh penggunaan, kerana penyertaan penerima dan keputusan penghantaran penghala kedua-duanya bergantung pada model yang konsisten.

Semak bahawa penerima telah menyertai sumber

Laporan keahlian untuk kumpulan sahaja bukan penyertaan khusus sumber. Tanya penerima sumber mana yang dimintanya, dan pada penghala hop pertama lihat keadaan kumpulan untuk melihat sama ada senarai sumber muncul. Jika laporan tidak membawa sumber, penghala akan menganggapnya sebagai penyertaan dari mana-mana sumber dan seluruh reka bentuk merosot secara senyap menjadi sesuatu yang tidak anda rancang.

Pada penerima Linux, semak apa yang sebenarnya dilanggan oleh soket dan apa yang direkodkan oleh kernel. Fail konfigurasi aplikasi bukan bukti; jadual keahlian ialah bukti. Bacanya semasa penerima benar-benar berjalan, kerana entri boleh kekal sebentar selepas proses yang menciptanya keluar. Entri basi daripada ujian terdahulu ialah sumber keyakinan palsu yang boleh dipercayai.

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

Jika penyertaan hadir dengan sumber yang dijangka, teruskan ke penghala. Jika ia tiada, sebarang konfigurasi terowong tidak akan membantu, kerana tiada apa untuk dihantar.

Sahkan laluan balik sebelum anda melihat terowong

Penghalaan multicast melakukan pemeriksaan laluan balik, dan paket yang tiba pada antara muka selain yang ditunjukkan oleh laluan unicast akan digugurkan. Ini sebab paling biasa sesuatu strim yang jelas dihantar tidak pernah sampai ke hop seterusnya, dan ia tidak menghasilkan sebarang ralat peringkat aplikasi yang berguna.

Pada penghala yang menghadap sumber, bandingkan laluan ke arah sumber dengan antara muka tempat paket benar-benar tiba. Pada penghala yang menghadap penerima, lakukan perkara yang sama untuk subnet penerima sendiri dan sahkan senarai antara muka keluar merangkumi pautan ke arahnya. Ketidakpadanan dalam mana-mana arah ialah kegagalan RPF, bukan kegagalan keahlian.

Kemudian sahkan TTL sumber cukup besar untuk bertahan melalui hop berpenghala yang anda reka. Strim yang berfungsi pada penghala pertama dan mati pada yang kedua selalunya soal TTL, bukan soal dasar.

Baca keadaan multicast kernel dan bukannya konfigurasi

Konfigurasi memberitahu anda apa yang anda minta; kernel memberitahu anda apa yang berlaku. Pada setiap hop Linux, baca entri penghalaan multicast dan sahkan senarai antara muka masuk dan keluar wujud untuk pasangan sumber dan kumpulan yang tepat. Entri untuk kumpulan dengan sumber kad liar ialah objek berbeza, dan ia tidak akan menerangkan aliran khusus sumber.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Daemon penghalaan menyimpan pandangan mereka sendiri di atas keadaan itu, dan arahan yang mencetaknya bergantung pada pelaksanaan mana yang dipasang. Prinsipnya tetap: tanya daemon entri hulunya untuk pasangan itu, kemudian tanya kernel sama ada entri penghantaran wujud. Daemon yang menyangka ia menghantar sedangkan kernel tiada entri ialah masalah skop konfigurasi pada hos itu.

Apabila kedua-duanya tidak bersetuju, baiki hos dan bukan VPN. Tiada apa di hilir boleh mengimbangi hop yang tidak menghantar aliran yang anda tanyakan. Catat pasangan, antara muka masuk dan senarai keluar untuk setiap hop semasa strim berfungsi. Rekod itu menjadikan kegagalan seterusnya sebagai perbandingan dan bukan penyiasatan baharu.

Tentukan bagaimana terowong sebenarnya mereplikasi

Di sinilah multicast melalui VPN berhenti menjadi rutin. Terowong titik-ke-titik menghantar paket kepada satu-satunya rakan di hujung sana, jadi satu salinan sampai tepat kepada satu klien. Segmen dijambatani berkelakuan lebih seperti pautan dikongsi, kerana terowong membawa bingkai dan jambatan memutuskan apa yang dibanjiri. Ini model penghantaran yang berbeza, dan reka bentuk yang menganggap yang kedua sedangkan menjalankan yang pertama akan kelihatan berfungsi untuk satu penerima dan gagal untuk penerima seterusnya.

Untuk lebih daripada satu penerima melalui pelayan berbilang titik, replikasi mesti direka secara eksplisit. Memasang laluan multicast pada get laluan tidak mengajar pelayan VPN rakan mana yang patut menerima salinan, dan tiada laluan di sisi klien membuat keputusan itu untuknya. Jika keperluan ialah banyak penerima, gunakan replikasi yang disokong atau alternatif yang dipilih dengan sengaja, dan catat mana yang anda pilih.

Akhir sekali, sahkan pada penerima di bawah pemerhatian sempit: sumber, kumpulan dan port yang tepat, pada antara muka yang anda jangkakan, semasa satu penerima sah menyertai. SSM memilih penghantar, dan pemilihan bukan pengesahan penghantar itu, juga bukan kebenaran untuk trafik multicast lain melintasi dasar yang sama.