Penemuan Chromecast dan DLNA tidak pernah melintasi VPN berpenghalaan

Butang cast tidak menyenaraikan apa-apa, VLC DLNA kekal kosong, dan mesin di hujung sana menjawab ping tanpa rungutan. Gabungan itu bukan masalah lebar jalur dan bukan misteri firewall. Penemuan dalam protokol ini ialah pertukaran kumpulan pada segmen setempat, dan terowong berpenghalaan tidak membawa trafik beralamat kumpulan. Sesi yang anda cuba mulakan tidak pernah ditawarkan.

Kebolehcapaian baik. Penemuan tiada.

Mitos: terowong memerlukan tetapan atau lebih kapasiti

Cadangan biasa ialah mendayakan trafik rakan-ke-rakan, menaikkan MTU, atau menukar jenis peranti terowong. Tiada satu pun menambah domain siaran. Multicast dihantar oleh suis dan oleh tindanan rangkaian setempat, dan antara muka TUN titik-ke-titik tiada alamat kumpulan untuk dilimpahi.

Menukar tetapan boleh menjadikan kegagalan lebih kuat. Ia tidak boleh menjadikan pengumuman muncul di tempat protokol tidak pernah menghantarnya.

Apakah sebenarnya pertukaran penemuan itu

Tiga corak meliputi hampir semua yang anda akan temui. mDNS menghantar ke 224.0.0.251 melalui UDP 5353, SSDP menghantar ke 239.255.255.250 melalui UDP 1900, dan senarai layaran SMB lama pergi ke alamat siaran subrangkaian. Setiap satu dialamatkan kepada kumpulan dan bukan kepada hos, dan setiap satu menjangka pendengar pada segmen yang sama. Penerima di seberang terowong berpenghalaan bukan pada segmen itu, jadi tiada apa yang tiba.

Malah pengumuman yang disampaikan semula membawa muatan: biasanya alamat LAN dan port penghantar, yang mesti dapat dicapai oleh penonton jauh.

Baca tangkapan sebelum menukar terowong

Tangkap pada antara muka terowong semasa aplikasi mengimbas. Tangkapan kosong bermakna pengumuman tidak pernah melintasi sempadan, dan tiada penalaan terowong mengubahnya. Paket yang tetap muncul semasa aplikasi masih tidak menunjukkan apa-apa biasanya bermakna alamat yang diumumkan tidak dapat dicapai dari penonton, iaitu masalah penghalaan yang memakai pakaian penemuan.

Dua minit tangkapan menggantikan satu jam meneka tentang port: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tiga pembetulan, yang paling murah dahulu

Halakan klien terus ke alamat perkhidmatan. Untuk DLNA, SMB dan pelayan media biasa ini melangkau penemuan sepenuhnya dan membuktikan laluan muatan berfungsi, yang menjadikannya ujian pertama terbaik dan juga jalan pintas yang boleh digunakan. Chromecast ialah pengecualian, kerana penerima menjangka dirinya ditemui dan bukan dialamatkan.

Sampaikan semula protokol di gateway. Pemantul mDNS mengulang pengumuman antara terowong dan LAN, dan Avahi menyediakan bahagian pemantul yang mengambil senarai antara muka yang jelas. Kekalkan penyampaian semula itu sempit, dan sahkan alamat yang diumumkan dapat dicapai dari kedua-dua belah, jika tidak balasan masih menunjuk ke subrangkaian yang tidak dapat dihalakan oleh penonton.

Jambatani dan bukan menghalakan. Segmen TAP dengan pelayan menjambatani peranti tap ke LAN meletakkan kedua-dua hujung dalam satu domain siaran, jadi pengumuman melintas tanpa perubahan. Ia juga pilihan paling mahal, kerana satu subrangkaian bermakna satu domain kegagalan dan setiap perkhidmatan multicast di LAN kini mencapai setiap rakan setara.

Apa yang tidak membantu, walau sesering mana pun dicadangkan

Menukar dev tun kepada dev tap tanpa jambatan meninggalkan peranti TAP yang masih dihalakan, jadi tingkah laku tidak berubah. client-to-client membenarkan unicast rakan-ke-rakan dan tidak melimpahi siaran. Menghantar port penemuan ke satu hos tidak menyampaikan trafik beralamat kumpulan. Pelayan media yang terikat pada satu alamat terus menjawab pada alamat itu sehingga konfigurasinya sendiri menyenaraikan antara muka VPN.

Uji satu permintaan unicast terus, kemudian satu permintaan yang diumumkan. Jika yang pertama berfungsi dan yang kedua tidak, terowong sihat dan penemuan ialah keseluruhan masalah.