Casting terhenti melalui VPN: penemuan, kawalan atau strim?

Casting rosak di tiga tempat yang kelihatan sama dari sofa. Telefon mungkin tidak pernah nampak penerima, penerima mungkin muncul dan kemudian menolak sesi, atau sesi mungkin bermula dan tersekat seminit kemudian. Terowong pada telefon mengubah setiap laluan itu secara berbeza, dan bagi salah satunya ia tidak mengubah apa-apa. Namakan peringkat yang gagal dahulu, kemudian putuskan sama ada perubahan dasar itu memang tuas yang betul untuk ditarik.

Namakan peringkat yang gagal sebelum menukar dasar

Perhatikan apa yang telefon lakukan sejurus selepas anda mengetik ikon cast. Senarai kosong ialah hasil penemuan, ketikan yang melaporkan kegagalan ialah hasil kawalan, dan sesi yang bermula sebelum tersekat ialah hasil main balik. Ketiga-tiga itu mempunyai pemilik berbeza, dan hanya dua yang pertama biasanya melibatkan tetapan terowong telefon.

Tuliskan peringkat itu sebelum mengubah apa-apa. Pembaikan yang dikenakan pada peringkat yang salah menjadikan ujian seterusnya tidak boleh dibaca, dan kebanyakan cerita rakyat casting datang tepat daripada kekeliruan itu.

Penemuan ialah trafik setempat, dan terowong menyembunyikannya

Penerima mengiklankan diri melalui pengumuman setempat dan telefon menemuinya dengan pertanyaan pada pautan yang sama, jadi apa-apa yang mengeluarkan telefon daripada pautan itu mengeluarkan penerima daripada senarai. Terowong yang menghalakan semua trafik jauh dari LAN boleh menyembunyikan pertukaran itu, dan kebenaran rangkaian setempat pada peringkat aplikasi boleh menyekatnya walaupun laluan wujud. Wi-Fi tetamu dengan pengasingan klien menghasilkan senarai kosong yang sama tanpa VPN sama sekali. Buktikan kedua-dua peranti berkongsi segmen sebelum menyalahkan terowong.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Perintah pertama menyenaraikan apa yang mengiklankan dirinya pada segmen mesin pembantu, dan yang kedua bertanya terus kepada kumpulan DNS multicast. Penerima yang tiada dalam kedua-duanya juga tidak akan muncul dalam aplikasi telefon, apa pun keadaan terowong telefon. Jika penerima kelihatan dari peranti yang terowongnya dimatikan dan tidak kelihatan dari peranti yang terowongnya dihidupkan, anda telah menemui peringkat dan puncanya sekali gus.

Pengecualian LAN mengekalkan terowong

Banyak klien menawarkan pengecualian rangkaian setempat yang membiarkan terowong aktif sambil membenarkan alamat setempat. Gunakan tetapan yang didokumenkan itu daripada mematikan suis bunuh atau seluruh tembok api, kerana ia mengubah jauh lebih banyak daripada keperluan casting. Jika rangkaian memisahkan peranti pintar dengan sengaja, minta pemiliknya trafik penemuan, kawalan dan pulangan yang khusus, bukan akses rata.

nc -vz 192.168.1.50 8009

Ujian kawalan terhadap penerima memisahkan kebenaran daripada ketersampaian: port yang menjawab bermakna laluan wujud, manakala penolakan bermakna telefon dibenarkan menemui peranti itu dan masih tidak boleh bercakap dengannya. Port 8008 dan 8009 ialah port cast biasa, dan aplikasi mungkin menggunakan yang lain, jadi anggap satu port yang ditolak sebagai petunjuk, bukan keputusan. Pengecualian dan kebenaran aplikasi kekal bebas, kerana memberi akses setempat tidak mencipta laluan dan menambah laluan tidak memberi kebenaran. Suis bunuh juga boleh menggugurkan trafik setempat selepas sambung semula, sebab itulah penemuan perlu diuji semula apabila terowong kembali.

Main balik mungkin tidak menggunakan sambungan telefon

Dalam sesi yang dipandu aplikasi, telefon menyerahkan alamat media kepada penerima dan penerima mengambilnya melalui sambungannya sendiri, jadi menukar alamat awam telefon tidak melakukan apa-apa untuk strim itu. Tajuk yang terhad kepada akaun masih boleh gagal atas sebabnya sendiri, dan keperluan casting Google merangkumi keserasian aplikasi dan peranti, bukan laluan rangkaian. Menghalakan televisyen itu sendiri melalui terowong ialah konfigurasi berasingan dengan soalan dasar tersendiri.

Dua petunjuk membezakan mod itu. Cast yang bertahan walaupun skrin telefon dikunci adalah dipandu aplikasi, kerana penerima mengambil sendiri; cermin yang berhenti apabila skrin penghantar dikunci ialah strim berterusan daripada telefon. Apabila penemuan dan kawalan berjaya tetapi main balik tersekat, lihat pautan Wi-Fi penerima dan laluan internetnya, kerana ujian kelajuan pada telefon menerangkan telefon itu, bukan televisyen.

Batalkan pengecualian dan uji semula

Setiap perubahan sementara perlukan jalan balik, dan urutannya penting. Buang pengecualian LAN, sambung semula terowong supaya klien menggunakan semula dasarnya, kemudian ulangi langkah penemuan dan catat sama ada penerima hilang lagi. Urutan itu memberitahu anda sama ada pengecualian itu yang berfungsi atau ada sesuatu lain berubah di antaranya.

# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'

Selepas itu sahkan ketiga-tiga peringkat secara berasingan, kerana lulus pada satu tidak berkata apa-apa tentang yang lain. Kemudian periksa sama ada aplikasi telefon yang tidak berkaitan masih mengikut laluan yang dimaksudkan, kerana pengecualian setempat yang senyap menjadi pintasan penuh ialah hasil yang lebih buruk daripada cast yang perlukan satu ketikan tambahan.