Casting stopper på VPN: oppdaging, kontroll eller strøm?
En manglende mottaker, en avvist sesjon og en strøm som stopper feiler på ulike steder. Navngi trinnet før du endrer telefonens VPN-policy eller nettverket.
Casting bryter sammen på tre steder som ser like ut fra sofaen. Telefonen ser kanskje aldri mottakeren, mottakeren kan dukke opp og deretter avvise sesjonen, eller sesjonen kan starte og stoppe et minutt senere. En tunnel på telefonen endrer hver av disse veiene ulikt, og for én av dem endrer den ingenting. Navngi det sviktende trinnet først, og avgjør deretter om en policyendring i det hele tatt er riktig spak å trekke i.
Navngi det sviktende trinnet før du endrer policy
Se hva telefonen gjør umiddelbart etter at du trykker på cast-ikonet. En tom liste er et oppdagingsresultat, et trykk som rapporterer feil er et kontrollresultat, og en sesjon som starter før den stopper er et avspillingsresultat. Disse tre har forskjellige eiere, og bare de to første involverer vanligvis telefonens tunnelinnstillinger.
| 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 |
Skriv ned trinnet før du endrer noe. En rettelse brukt på feil trinn gjør neste test uleselig, og det meste av casting-folkloristikk kommer nettopp fra den forvirringen.
Oppdaging er lokal trafikk, og en tunnel skjuler den
Mottakere annonserer seg gjennom lokale kunngjøringer, og telefonen finner dem med spørringer på samme lenke, så alt som fjerner telefonen fra den lenken fjerner mottakeren fra listen. En tunnel som ruter all trafikk bort fra LAN-et kan skjule disse utvekslingene, og en lokalnett-tillatelse på appnivå kan blokkere dem selv når ruten finnes. Gjest-Wi-Fi med klientisolering gir samme tomme liste uten VPN i det hele tatt. Bevis at de to enhetene deler segment før du gir tunnelen skylden.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRDen første kommandoen lister opp det som annonserer seg på hjelpemaskinens segment, og den andre spør multicast-DNS-gruppen direkte. En mottaker som mangler i begge, vises heller ikke i en telefonapp, uansett telefonens tunnelstatus. Hvis mottakeren er synlig fra en enhet med tunnelen av og usynlig fra en med tunnelen på, har du funnet trinnet og årsaken sammen.
Et LAN-unntak holder tunnelen oppe
Mange klienter tilbyr et lokalnett-unntak som lar tunnelen være aktiv mens lokale adresser tillates. Bruk den dokumenterte innstillingen i stedet for å slå av kill switch eller hele brannmuren, fordi de endrer langt mer enn casting trenger. Hvis nettverket skiller smartenheter med vilje, be eieren om den konkrete oppdagings-, kontroll- og returtrafikken i stedet for flat tilgang.
nc -vz 192.168.1.50 8009En kontrolltest mot mottakeren skiller tillatelse fra nåbarhet: en port som svarer betyr at veien finnes, mens en avvisning betyr at telefonen fikk lov til å oppdage enheten og fortsatt ikke kan snakke med den. Portene 8008 og 8009 er de vanlige cast-portene, og en app kan bruke andre, så behandle én avvist port som et hint og ikke en dom. Unntaket og apptillatelsen forblir uavhengige, siden lokal tilgang ikke lager en rute og en rute ikke gir tillatelse. En kill switch kan også droppe lokal trafikk etter en ny tilkobling, og derfor må oppdagingen testes på nytt når tunnelen er tilbake.
Avspilling bruker kanskje ikke telefonens tilkobling
I en appstyrt sesjon gir telefonen mottakeren en medieadresse, og mottakeren henter den over sin egen tilkobling, så å endre telefonens offentlige adresse gjør ingenting for strømmen. En kontobegrenset tittel kan fortsatt feile av egne grunner, og Googles casting-krav dekker app- og enhetskompatibilitet snarere enn nettverksveien. Å rute selve TV-en gjennom en tunnel er en egen konfigurasjon med egne politiske spørsmål.
To holdepunkter skiller modusene. En cast som overlever at telefonskjermen låses, er appstyrt, fordi mottakeren henter selv; en speiling som stopper når avsenderens skjerm låses, er en kontinuerlig strøm fra telefonen. Når oppdaging og kontroll lykkes men avspillingen stopper, se på mottakerens Wi-Fi-lenke og internettveien i stedet, siden en hastighetstest på telefonen beskriver telefonen og ikke TV-en.
Angre unntaket og test på nytt
Hver midlertidig endring trenger en vei tilbake, og rekkefølgen betyr noe. Fjern LAN-unntaket, koble til tunnelen på nytt slik at klienten bruker policyen sin igjen, og gjenta deretter oppdagingstrinnet og noter om mottakeren forsvinner igjen. Den sekvensen forteller deg om unntaket gjorde jobben eller om noe annet endret 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'Bekreft de tre trinnene hver for seg etterpå, fordi en bestått test på ett sier ingenting om de andre. Sjekk deretter at urelaterte telefonapplikasjoner fortsatt følger den tiltenkte ruten, siden et lokalt unntak som stille ble en full omgåelse er et verre utfall enn en cast som trenger ett ekstra trykk.