Nahinto ang casting sa VPN: pagtuklas, kontrol o stream?

Nababali ang casting sa tatlong lugar na magkapareho ang hitsura mula sa sopa. Baka hindi makita ng telepono ang receiver, maaaring lumitaw ang receiver at tanggihan ang sesyon, o magsimula ang sesyon at huminto makalipas ang isang minuto. Iba-iba ang binabago ng tunnel sa telepono sa bawat landas, at sa isa sa kanila wala itong binabago. Unahin ang pagpangalan sa yugtong nabibigo, saka magpasya kung ang pagbabago ng patakaran ang tamang hawakan.

Pangalanan ang yugtong nabibigo bago baguhin ang patakaran

Pagmasdan ang ginagawa ng telepono kaagad pagkatapos mong pindutin ang icon ng cast. Ang walang laman na listahan ay resulta ng pagtuklas, ang pagpindot na nag-uulat ng pagkabigo ay resulta ng kontrol, at ang sesyong nagsisimula bago huminto ay resulta ng pag-play. May magkaibang may-ari ang tatlong iyon, at karaniwang ang unang dalawa lang ang may kinalaman sa mga setting ng tunnel ng telepono.

Isulat ang yugto bago magbago ng anuman. Ang pagwawasto na inilapat sa maling yugto ay nagpapahirap basahin ang susunod na pagsubok, at karamihan sa alamat ng casting ay nagmumula sa pagkalitong iyon.

Ang pagtuklas ay lokal na trapiko, at itinatago ito ng tunnel

Nag-aanunsyo ang mga receiver sa sarili nila sa pamamagitan ng lokal na anunsyo at hinahanap sila ng telepono gamit ang mga tanong sa parehong link, kaya anumang nag-aalis sa telepono sa link na iyon ay nag-aalis sa receiver sa listahan. Ang tunnel na naglilipat ng lahat ng trapiko palayo sa LAN ay maaaring magtago ng mga palitan iyon, at ang pahintulot sa lokal na network sa antas ng app ay maaaring humarang kahit may ruta. Ang guest Wi-Fi na may paghihiwalay ng kliyente ay nagbibigay ng parehong walang laman na listahan nang walang VPN. Patunayan na magkapareho ng segment ang dalawang device bago sisihin ang tunnel.

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

Inililista ng unang utos kung ano ang nag-aanunsyo sa segment ng helper machine, at ang pangalawa ay direktang nagtatanong sa multicast DNS group. Ang receiver na wala sa pareho ay hindi rin lilitaw sa app sa telepono, anuman ang estado ng tunnel ng telepono. Kung nakikita ang receiver mula sa device na patay ang tunnel at hindi nakikita mula sa buhay ang tunnel, nahanap mo nang sabay ang yugto at ang dahilan.

Pinapanatili ng eksepsyon sa LAN na buhay ang tunnel

Maraming kliyente ang nag-aalok ng eksepsyon sa lokal na network na nag-iiwan ng buhay na tunnel habang pinahihintulutan ang lokal na address. Gamitin ang nakadokumentong setting na iyon sa halip na patayin ang kill switch o ang buong firewall, dahil mas malaki ang binabago ng mga iyon kaysa kailangan ng casting. Kung sadyang hinihiwalay ng network ang mga smart device, hilingin sa may-ari ang partikular na trapiko ng pagtuklas, kontrol at pagbabalik sa halip na pantay na access.

nc -vz 192.168.1.50 8009

Ang pagsubok sa kontrol patungo sa receiver ay naghihiwalay ng pahintulot sa maabot: ang port na sumasagot ay nangangahulugang may ruta, samantalang ang pagtanggi ay nangangahulugang pinayagan ang telepono na matuklasan ang device at hindi pa rin ito makausap. Ang port 8008 at 8009 ang karaniwang port ng cast, at maaaring gumamit ng iba ang app, kaya ituring ang isang tinanggihang port na pahiwatig at hindi hatol. Nananatiling magkahiwalay ang eksepsyon at ang pahintulot ng app, dahil ang pagbibigay ng lokal na access ay hindi gumagawa ng ruta at ang pagdaragdag ng ruta ay hindi nagbibigay ng pahintulot. Maaari ring ibagsak ng kill switch ang lokal na trapiko pagkatapos ng muling pagkonekta, kaya kailangang subukan muli ang pagtuklas kapag bumalik ang tunnel.

Maaaring hindi gamitin ng pag-play ang koneksyon ng telepono

Sa sesyong pinangungunahan ng app, ibinibigay ng telepono sa receiver ang isang media address at hinihila ito ng receiver sa sarili nitong koneksyon, kaya walang nagagawa ang pagbabago ng pampublikong address ng telepono sa stream. Ang titulong limitado ng account ay maaari pa ring mabigo dahil sa sariling dahilan, at ang mga kinakailangan sa casting ng Google ay sumasaklaw sa pagiging tugma ng app at device sa halip na ang landas ng network. Ang pagruruta sa telebisyon mismo sa tunnel ay hiwalay na configuration na may sariling mga tanong sa patakaran.

Dalawang palatandaan ang naghihiwalay sa mga mode. Ang cast na tumutuloy kahit naka-lock ang screen ng telepono ay pinangungunahan ng app, dahil ang receiver ang humihila; ang mirror na humihinto kapag nag-lock ang screen ng nagpapadala ay tuloy-tuloy na stream mula sa telepono. Kapag nagtagumpay ang pagtuklas at kontrol pero huminto ang pag-play, tingnan sa halip ang Wi-Fi link ng receiver at ang landas nito sa internet, dahil inilalarawan ng speed test sa telepono ang telepono at hindi ang telebisyon.

Ibaba ang eksepsyon at subukan muli

Bawat pansamantalang pagbabago ay kailangan ng daan pabalik, at mahalaga ang pagkakasunod-sunod. Alisin ang eksepsyon sa LAN, ikonekta muli ang tunnel para ilapat muli ng kliyente ang patakaran nito, pagkatapos ulitin ang hakbang ng pagtuklas at itala kung muling mawawala ang receiver. Sinasabi ng sekwensyang iyon kung ang eksepsyon ang gumagawa ng trabaho o may ibang nagbago sa pagitan.

# 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'

Pagkatapos, i-verify nang hiwalay ang tatlong yugto, dahil ang pagpasa sa isa ay walang sinasabi tungkol sa iba. Pagkatapos, tingnan kung ang mga walang kaugnayang app sa telepono ay sumusunod pa rin sa nilalayong ruta, dahil ang lokal na eksepsyon na tahimik na naging buong bypass ay mas masamang resulta kaysa sa cast na kailangan ng isang karagdagang pindot.