Penemuan Chromecast dan DLNA tidak pernah melintasi VPN yang dirutekan

Tombol cast tidak menampilkan apa pun, VLC DLNA tetap kosong, dan mesin di ujung lain menjawab ping tanpa keluhan. Kombinasi itu bukan masalah bandwidth atau misteri firewall. Penemuan pada protokol ini adalah pertukaran grup di segmen lokal, dan terowongan yang dirutekan tidak membawa lalu lintas beralamat grup. Sesi yang ingin Anda mulai tidak pernah ditawarkan.

Keterjangkauan baik-baik saja. Penemuannya hilang.

Mitos: terowongan butuh pengaturan atau kapasitas lebih

Saran biasanya adalah mengaktifkan lalu lintas peer-to-peer, menaikkan MTU, atau mengganti jenis perangkat terowongan. Tidak satu pun menambahkan domain siaran. Multicast dikirim oleh switch dan oleh tumpukan jaringan lokal, dan antarmuka TUN titik-ke-titik tidak punya alamat grup untuk dibanjiri.

Mengubah pengaturan bisa membuat kegagalan lebih nyaring. Itu tidak bisa memunculkan pengumuman di tempat protokolnya tidak pernah mengirim satu pun.

Apa sebenarnya pertukaran penemuan itu

Tiga pola mencakup hampir semua yang akan Anda temui. mDNS mengirim ke 224.0.0.251 lewat UDP 5353, SSDP mengirim ke 239.255.255.250 lewat UDP 1900, dan daftar jelajah SMB yang lebih lama menuju alamat siaran subnet. Masing-masing dialamatkan ke grup, bukan ke host, dan masing-masing mengharapkan pendengar di segmen yang sama. Penerima di seberang terowongan yang dirutekan tidak berada di segmen itu, jadi tidak ada yang tiba.

Bahkan pengumuman yang diteruskan membawa muatan: biasanya alamat LAN dan port pengirim, yang harus bisa dijangkau oleh penonton jauh.

Baca tangkapan sebelum mengubah terowongan

Tangkap di antarmuka terowongan saat aplikasi memindai. Tangkapan kosong berarti pengumuman tidak pernah melintasi batas, dan tidak ada penyetelan terowongan yang mengubahnya. Paket yang tetap muncul saat aplikasi masih tidak menampilkan apa pun biasanya berarti alamat yang diumumkan tidak terjangkau dari penonton, yaitu masalah routing yang memakai kostum penemuan.

Dua menit tangkapan menggantikan satu jam menebak soal port: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tiga perbaikan, yang termurah dahulu

Arahkan klien langsung ke alamat layanan. Untuk DLNA, SMB, dan server media biasa ini melewati penemuan sepenuhnya dan membuktikan jalur muatan bekerja, yang membuatnya menjadi uji pertama terbaik sekaligus jalan pintas yang bisa dipakai. Chromecast adalah pengecualian, karena penerima mengharapkan dirinya ditemukan, bukan dialamati.

Teruskan protokol di gateway. Reflektor mDNS mengulang pengumuman antara terowongan dan LAN, dan Avahi menyediakan bagian reflektor yang menerima daftar antarmuka eksplisit. Jaga penerusan tetap sempit, dan pastikan alamat yang diumumkan terjangkau dari kedua sisi, jika tidak balasannya tetap menunjuk ke subnet yang tidak bisa dirutekan oleh penonton.

Jembatani alih-alih merutekan. Segmen TAP dengan server menjembatani perangkat tap ke LAN menempatkan kedua ujung dalam satu domain siaran, sehingga pengumuman lewat tanpa perubahan. Ini juga opsi termahal, karena satu subnet berarti satu domain kegagalan dan setiap layanan multicast di LAN sekarang menjangkau setiap peer.

Apa yang tidak membantu, sesering apa pun disarankan

Mengganti dev tun menjadi dev tap tanpa jembatan menyisakan perangkat TAP yang masih dirutekan, jadi perilakunya tidak berubah. client-to-client mengizinkan unicast peer-to-peer dan tidak membanjiri siaran. Meneruskan port penemuan ke satu host tidak mengantarkan lalu lintas beralamat grup. Server media yang terikat ke satu alamat terus menjawab pada alamat itu sampai konfigurasinya sendiri mencantumkan antarmuka VPN.

Uji satu permintaan unicast langsung, lalu satu permintaan yang diumumkan. Jika yang pertama bekerja dan yang kedua tidak, terowongannya sehat dan penemuan adalah seluruh masalahnya.