Mengapa Casting Berhenti Berfungsi Setelah Anda Mengaktifkan VPN Router
Penemuan berjalan lewat multicast lokal sementara TV mengambil media sendiri. Kebijakan default dapat menangkap permintaan LAN dan mengirimnya ke terowongan.
Casting berfungsi sebelum VPN router diaktifkan dan langsung gagal sesudahnya, sementara penjelajahan biasa di ponsel tetap berjalan. Kedua fakta itu konsisten, karena casting bukan satu koneksi. Ponsel menemukan dan mengendalikan penerima lewat jaringan lokal, lalu penerima mengambil media lewat koneksinya sendiri.
Dua jalur yang gagal dengan cara berbeda
Jalur kendali bersifat lokal. Ponsel menemukan penerima dengan menanyakan jaringan lokal, lalu membuka koneksi kendali ke alamat yang dipelajarinya. Jika penerima tidak pernah muncul di daftar, langkah penemuan gagal sebelum media apa pun diminta.
Jalur media tidak selalu lokal. Banyak penerima mengambil aliran itu sendiri, lewat koneksi dan kredensialnya sendiri, sehingga rute ponsel tidak menggambarkan rute penerima. Ponsel yang tampak memakai satu pintu keluar tidak mengatakan apa pun tentang ke mana lalu lintas TV pergi.
Pemisahan itulah sebabnya kegagalannya terlihat aneh. Terowongan mengubah tabel perutean ponsel dan tidak mengubah tabel TV, jadi gejala yang muncul di satu sisi pasangan harus ditelusuri di sisi itu. Menelusuri perangkat yang salah adalah alasan biasa sebuah perbaikan tampak tidak melakukan apa pun.
Mengapa penemuan gagal lebih dulu
Penemuan biasanya berjalan lewat multicast lokal tautan. mDNS mengirim ke 224.0.0.251 pada port UDP 5353, dan SSDP mengirim ke 239.255.255.250 pada port UDP 1900. Keduanya dibatasi pada satu tautan secara desain, karena itu sebuah router tidak meneruskannya antarsegmen tanpa bantuan pengulang atau proksi. VPN yang dirutekan tidak memperluas grup multicast, dan rute kebijakan tidak dapat membuat grup yang tidak pernah meninggalkan tautan muncul di tautan lain.
Jadi kegagalan pertama tidak ada hubungannya dengan enkripsi. Multicast ponsel meninggalkan antarmuka tempat ia dikirim, penerima berada di segmen yang tidak pernah melihatnya, dan daftar perangkat kembali kosong. Daftar kosong bukan bukti bahwa TV kehilangan akses internet.
Isolasi menghasilkan gejala yang sama tanpa VPN apa pun. Jaringan tamu dan isolasi klien di titik akses sengaja mencegah perangkat saling berbicara, dan mengaktifkan VPN router di atas segmen yang terisolasi tidak mengubah apa pun soal itu. Periksa pengaturan isolasi sebelum memeriksa terowongan. Itu jawaban yang lebih murah dan lebih umum.
Tata letak segmen adalah separuh lainnya. Router kedua, node mesh dalam mode berbeda, atau segmen kabel di belakang NAT lain semuanya menempatkan penerima di tempat yang tidak dijangkau lalu lintas penemuan ponsel.
Mengapa kebijakan default dapat menelan permintaan lokal
Router yang merutekan semua lalu lintas ke terowongan memasang rute default pada antarmuka terowongan. Jika prefiks LAN tidak dikecualikan dari kebijakan itu, paket yang dialamatkan ke perangkat dua meter jauhnya kini cocok dengan default, dan router mengirim permintaan kendali ke terowongan alih-alih ke sakelar.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
Urutan aturan menentukan hasilnya. Perutean kebijakan mengevaluasi aturan dalam urutan prioritas, jadi pengecualian untuk prefiks lokal harus muncul sebelum aturan yang memilih tabel terowongan. Menambahkan pengecualian setelah aturan terowongan tidak berpengaruh, karena itu konfigurasi yang tampak benar masih dapat mengirim lalu lintas LAN ke pintu keluar jauh.
Perbaikannya sempit: izinkan tujuan lokal tertentu yang dibutuhkan alur casting, dan biarkan sisa isolasi apa adanya. Menghapus isolasi klien sebagai langkah pertama memperbaiki gejala tetapi membuang kendali yang memang dirancang dimiliki jaringan.
Pemeriksaan cepat di ponsel menentukan mana dari dua kegagalan itu yang Anda alami. Jika rute ke penerima menunjuk terowongan, kebijakan adalah masalahnya. Jika menunjuk LAN dan penemuan tetap gagal, multicast atau isolasi masalahnya, dan tidak ada perubahan rute yang akan membantu.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpUji tahap yang berubah, bukan negaranya
Pengamatan yang dicatat lebih bernilai daripada percobaan yang diulang. Catat apakah penerima muncul di daftar perangkat, apakah permintaan kendali sampai padanya, dan apakah pemutaran mulai setelah aliran dipilih. Setiap jawaban menghapus satu tahap dari kecurigaan.
Lalu uji setiap tahap secara langsung alih-alih mengganti lokasi keluar. Mengganti negara VPN menguji jalur media dan membiarkan tahap penemuan serta kendali tak tersentuh, jadi bisa tampak membantu secara kebetulan tanpa mengajarkan apa pun.
Di sisi penerima, periksa rutenya sendiri dan status akunnya. TV yang mengambil media lewat pintu keluar berbeda dari ponsel adalah desain normal, dan kegagalan di sana adalah pertanyaan tentang kebijakan jaringan penerima, bukan tentang terowongan ponsel.
Tulis hasilnya sebagai satu kalimat tentang tahap mana yang rusak dan apa yang mengubahnya. Kalimat itu lebih bernilai daripada sepekan berganti negara, dan ia bertahan melewati pembaruan firmware berikutnya.
Casting adalah kasus uji yang baik untuk aturan umum tentang terowongan. Ketika satu terowongan ditambahkan ke jaringan, pertanyaan pertama adalah tujuan mana yang seharusnya tidak pernah memasukinya. Yang kedua adalah mana di antaranya yang tetap diterima kebijakan secara diam-diam.