Casting stoppar på VPN: oppdaging, kontroll eller straum?

Casting bryt saman på tre stader som ser like ut frå sofaen. Telefonen ser kanskje aldri mottakaren, mottakaren kan dukke opp og deretter avvise økta, eller økta kan starte og stoppe eitt minutt seinare. Ein tunnel på telefonen endrar kvar av desse vegane ulikt, og for éin av dei endrar han ingenting. Namngje det sviktande trinnet først, og avgjer deretter om ei policyendring i det heile er rett spak å trekkje i.

Namngje det sviktande trinnet før du endrar policy

Sjå kva telefonen gjer rett etter at du trykkjer på cast-ikonet. Ei tom liste er eit oppdagingsresultat, eit trykk som rapporterer feil er eit kontrollresultat, og ei økt som startar før ho stoppar er eit avspelingsresultat. Desse tre har ulike eigarar, og berre dei to første rører vanlegvis tunnelinnstillingane til telefonen.

Skriv ned trinnet før du endrar noko. Ei retting brukt på feil trinn gjer neste test uleseleg, og det meste av casting-folkeminne kjem nettopp frå den forvirringa.

Oppdaging er lokal trafikk, og ein tunnel gøymer han

Mottakarar annonserer seg gjennom lokale kunngjeringar, og telefonen finn dei med spørjingar på same lenkja, så alt som fjernar telefonen frå den lenkja fjernar mottakaren frå lista. Ein tunnel som ruter all trafikk bort frå LAN-et kan gøyme desse utvekslingane, og ei lokalnett-tillating på appnivå kan blokkere dei sjølv når ruta finst. Gjest-Wi-Fi med klientisolering gir same tomme liste utan VPN i det heile. Bevis at dei to einingane deler segment før du gir tunnelen skulda.

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

Den første kommandoen listar opp det som annonserer seg på segmentet til hjelpemaskina, og den andre spør multicast-DNS-gruppa direkte. Ein mottakar som manglar i begge, viser seg heller ikkje i ein telefonapp, uansett tunnelstatusen til telefonen. Viss mottakaren er synleg frå ei eining med tunnelen av og usynleg frå ei med tunnelen på, har du funne trinnet og årsaka saman.

Eit LAN-unntak held tunnelen oppe

Mange klientar tilbyr eit lokalnett-unntak som lèt tunnelen vere aktiv medan lokale adresser blir tillatne. Bruk den dokumenterte innstillinga i staden for å slå av kill switch eller heile brannmuren, fordi dei endrar langt meir enn casting treng. Viss nettverket skil smarteiningar med vilje, be eigaren om den konkrete oppdagings-, kontroll- og returtrafikken i staden for flat tilgang.

nc -vz 192.168.1.50 8009

Ein kontrolltest mot mottakaren skil tillating frå nåbarheit: ein port som svarar betyr at vegen finst, medan ei avvising betyr at telefonen fekk lov til å oppdage eininga og framleis ikkje kan snakke med henne. Portane 8008 og 8009 er dei vanlege cast-portane, og ein app kan bruke andre, så handsam éin avvist port som eit hint og ikkje ein dom. Unntaket og apptillatinga held fram med å vere uavhengige, sidan lokal tilgang ikkje lagar ei rute og ei rute ikkje gir tillating. Ein kill switch kan også droppe lokal trafikk etter ei ny tilkopling, og difor må oppdaginga testast på nytt når tunnelen er tilbake.

Avspeling brukar kanskje ikkje tilkoplinga til telefonen

I ei appstyrt økt gir telefonen mottakaren ei medieadresse, og mottakaren hentar henne over si eiga tilkopling, så å endre den offentlege adressa til telefonen gjer ingenting for straumen. Ein kontobegrensa tittel kan framleis feile av eigne grunnar, og Googles casting-krav dekkjer app- og einingkompatibilitet snarare enn nettverksvegen. Å rute sjølve TV-en gjennom ein tunnel er ein eigen konfigurasjon med eigne policy-spørsmål.

To haldepunkt skil modusane. Ein cast som overlever at telefonskjermen blir låst, er appstyrt, fordi mottakaren hentar sjølv; ei spegling som stoppar når skjermen til sendaren blir låst, er ein kontinuerleg straum frå telefonen. Når oppdaging og kontroll lukkast men avspelinga stoppar, sjå på Wi-Fi-lenkja til mottakaren og internettvegen hans i staden, sidan ein hastigheitstest på telefonen skildrar telefonen og ikkje TV-en.

Angre unntaket og test på nytt

Kvar mellombels endring treng ein veg tilbake, og rekkjefølgja betyr noko. Fjern LAN-unntaket, kople tunnelen til på nytt slik at klienten brukar policyen sin igjen, og gjenta deretter oppdagingstrinnet og noter om mottakaren forsvinn igjen. Den sekvensen fortel deg om unntaket gjorde jobben eller om noko anna endra seg imellom.

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

Stadfest dei tre trinna kvar for seg etterpå, fordi ein bestått test på eitt seier ingenting om dei andre. Sjekk deretter at urelaterte telefonapplikasjonar framleis følgjer den tiltenkte ruta, sidan eit lokalt unntak som stille vart ei full omgåing er eit verre utfall enn ein cast som treng eitt ekstra trykk.