Casting berhenti di VPN: penemuan, kendali, atau streaming?
Penerima yang hilang, sesi yang ditolak, dan aliran yang tersendat gagal di tempat berbeda. Sebutkan tahapnya sebelum mengubah kebijakan VPN ponsel atau jaringan.
Casting rusak di tiga tempat yang dari sofa tampak sama. Ponsel mungkin tidak pernah melihat penerima, penerima mungkin muncul lalu menolak sesi, atau sesi mungkin dimulai lalu tersendat semenit kemudian. Tunnel di ponsel mengubah setiap jalur itu secara berbeda, dan untuk salah satunya tidak mengubah apa pun. Sebutkan dulu tahap yang gagal, lalu putuskan apakah perubahan kebijakan memang tuas yang tepat.
Sebutkan tahap yang gagal sebelum mengubah kebijakan
Perhatikan apa yang dilakukan ponsel tepat setelah Anda mengetuk ikon casting. Daftar kosong adalah hasil penemuan, ketukan yang melaporkan kegagalan adalah hasil kendali, dan sesi yang dimulai sebelum tersendat adalah hasil pemutaran. Ketiganya punya pemilik berbeda, dan biasanya hanya dua yang pertama melibatkan pengaturan tunnel ponsel.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Catat tahapnya sebelum mengubah apa pun. Perbaikan yang diterapkan pada tahap yang salah membuat uji berikutnya tidak terbaca, dan sebagian besar cerita rakyat soal casting berasal tepat dari kebingungan itu.
Penemuan adalah lalu lintas lokal, dan tunnel menyembunyikannya
Penerima mengumumkan dirinya lewat pengumuman lokal dan ponsel menemukannya dengan kueri pada tautan yang sama, jadi apa pun yang mengeluarkan ponsel dari tautan itu mengeluarkan penerima dari daftar. Tunnel yang mengarahkan semua lalu lintas menjauh dari LAN dapat menyembunyikan pertukaran itu, dan izin jaringan lokal tingkat aplikasi dapat memblokirnya bahkan ketika rutenya ada. Wi-Fi tamu dengan isolasi klien menghasilkan daftar kosong yang sama tanpa VPN sama sekali. Buktikan kedua perangkat berbagi segmen sebelum menyalahkan tunnel.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRPerintah pertama mendaftar apa yang mengumumkan dirinya di segmen mesin pembantu, dan yang kedua bertanya langsung ke grup DNS multicast. Penerima yang tidak ada di keduanya juga tidak akan muncul di aplikasi ponsel, apa pun status tunnel ponsel. Jika penerima terlihat dari perangkat yang tunnelnya mati dan tidak terlihat dari perangkat yang tunnelnya hidup, Anda menemukan tahap dan penyebabnya sekaligus.
Pengecualian LAN menjaga tunnel tetap hidup
Banyak klien menawarkan pengecualian jaringan lokal yang membiarkan tunnel tetap aktif sambil mengizinkan alamat lokal. Gunakan pengaturan terdokumentasi itu alih-alih mematikan kill switch atau seluruh firewall, karena keduanya mengubah jauh lebih banyak daripada yang dibutuhkan casting. Jika jaringan sengaja memisahkan perangkat pintar, mintalah pemiliknya menyediakan lalu lintas penemuan, kendali, dan kembali yang spesifik alih-alih akses rata.
nc -vz 192.168.1.50 8009Uji kendali ke penerima memisahkan izin dari keterjangkauan: port yang menjawab berarti jalurnya ada, sedangkan penolakan berarti ponsel diizinkan menemukan perangkat itu dan tetap tidak dapat berbicara dengannya. Port 8008 dan 8009 adalah port casting yang biasa, dan aplikasi dapat memakai port lain, jadi perlakukan satu port yang ditolak sebagai petunjuk, bukan putusan. Pengecualian dan izin aplikasi tetap independen, karena memberi akses lokal tidak membuat rute dan menambah rute tidak memberi izin. Kill switch juga dapat menjatuhkan lalu lintas lokal setelah menyambung ulang, itulah sebabnya penemuan harus diuji ulang begitu tunnel kembali.
Pemutaran mungkin tidak memakai koneksi ponsel
Dalam sesi yang diarahkan aplikasi, ponsel memberi penerima alamat media dan penerima mengambilnya lewat koneksinya sendiri, jadi mengubah alamat publik ponsel tidak melakukan apa pun untuk aliran. Judul yang dibatasi akun tetap bisa gagal karena alasannya sendiri, dan persyaratan casting Google mencakup kompatibilitas aplikasi dan perangkat, bukan jalur jaringan. Mengarahkan televisi itu sendiri lewat tunnel adalah konfigurasi terpisah dengan pertanyaan kebijakannya sendiri.
Dua petunjuk membedakan modusnya. Casting yang bertahan saat layar ponsel dikunci diarahkan aplikasi, karena penerima mengambil sendiri; pencerminan yang berhenti saat layar pengirim dikunci adalah aliran terus-menerus dari ponsel. Ketika penemuan dan kendali berhasil tetapi pemutaran tersendat, lihatlah tautan Wi-Fi penerima dan jalur internetnya, karena uji kecepatan di ponsel menggambarkan ponsel, bukan televisi.
Batalkan pengecualian dan uji lagi
Setiap perubahan sementara perlu jalan kembali, dan urutannya penting. Hapus pengecualian LAN, sambungkan ulang tunnel agar klien menerapkan ulang kebijakannya, lalu ulangi langkah penemuan dan catat apakah penerima menghilang lagi. Urutan itu memberi tahu Anda apakah pengecualian yang bekerja atau ada hal lain yang 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'Setelah itu verifikasi ketiga tahap secara terpisah, karena lolos di satu tahap tidak mengatakan apa pun tentang yang lain. Lalu periksa bahwa aplikasi ponsel yang tidak terkait masih mengikuti rute yang dimaksud, karena pengecualian lokal yang diam-diam menjadi jalan pintas penuh adalah hasil yang lebih buruk daripada casting yang butuh satu ketukan tambahan.