Cast stopper på en VPN: opdagelse, kontrol eller stream?

Cast går i stykker tre steder, som ser ens ud fra sofaen. Telefonen ser måske aldrig modtageren, modtageren kan dukke op og derefter afvise sessionen, eller sessionen kan starte og gå i stå et minut senere. En tunnel på telefonen ændrer hver af disse veje forskelligt, og for én af dem ændrer den slet ingenting. Navngiv først det stadie, der fejler, og beslut derefter, om en politikændring overhovedet er det rigtige håndtag at trække i.

Navngiv det fejlende stadie, før du ændrer politik

Se, hvad telefonen gør umiddelbart efter, at du trykker på cast-ikonet. En tom liste er et opdagelsesresultat, et tryk, der rapporterer fejl, er et kontrolresultat, og en session, der starter før den går i stå, er et afspilningsresultat. De tre har forskellige ejere, og normalt involverer kun de to første telefonens tunnelindstillinger.

Skriv stadiet ned, før du ændrer noget. En rettelse anvendt på det forkerte stadie gør den næste test ulæselig, og det meste cast-folklore kommer netop fra den forveksling.

Opdagelse er lokal trafik, og en tunnel skjuler den

Modtagere annoncerer sig via lokale meddelelser, og telefonen finder dem med forespørgsler på samme link, så alt, der fjerner telefonen fra det link, fjerner modtageren fra listen. En tunnel, der ruter al trafik væk fra LAN'et, kan skjule de udvekslinger, og en lokalnetværkstilladelse på app-niveau kan blokere dem, selv når ruten findes. Gæste-Wi-Fi med klientisolering giver den samme tomme liste helt uden VPN. Bevis, at de to enheder deler et segment, før du bebrejder tunnelen.

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

Den første kommando viser, hvad der annoncerer sig på hjælpemaskinens segment, og den anden spørger multicast DNS-gruppen direkte. En modtager, der mangler i begge, vises heller ikke i en telefonapp, uanset telefonens tunnelstatus. Hvis modtageren er synlig fra en enhed med tunnelen slukket og usynlig fra en med tunnelen tændt, har du fundet både stadiet og årsagen.

En LAN-undtagelse holder tunnelen oppe

Mange klienter tilbyder en lokalnetværksundtagelse, der lader tunnelen være aktiv, mens lokale adresser tillades. Brug den dokumenterede indstilling i stedet for at slå kill switch eller hele firewallen fra, fordi de ændrer langt mere, end cast har brug for. Hvis netværket bevidst adskiller smartenheder, så bed ejeren om den specifikke opdagelses-, kontrol- og returtrafik i stedet for flad adgang.

nc -vz 192.168.1.50 8009

En kontroltest mod modtageren adskiller tilladelse fra nåbarhed: en port, der svarer, betyder, at vejen findes, mens en afvisning betyder, at telefonen fik lov at opdage enheden og stadig ikke kan tale med den. Port 8008 og 8009 er de sædvanlige cast-porte, og en app kan bruge andre, så behandl en enkelt afvist port som et hint og ikke som en dom. Undtagelsen og apptilladelsen forbliver uafhængige, fordi lokal adgang ikke skaber en rute, og en rute giver ikke tilladelse. En kill switch kan også tabe lokal trafik efter en genopkobling, og derfor skal opdagelse testes igen, når tunnelen er tilbage.

Afspilning bruger måske ikke telefonens forbindelse

I en app-styret session giver telefonen modtageren en medieadresse, og modtageren henter den over sin egen forbindelse, så en ændring af telefonens offentlige adresse gør intet for streamen. En kontobegrænset titel kan stadig fejle af sine egne grunde, og Googles cast-krav dækker app- og enhedskompatibilitet snarere end netværksvejen. At route selve tv'et gennem en tunnel er en separat konfiguration med sine egne politikspørgsmål.

To spor adskiller tilstandene. Et cast, der overlever, at telefonens skærm låses, er app-styret, fordi modtageren henter selv; et spejl, der stopper, når afsenderens skærm låses, er en kontinuerlig stream fra telefonen. Når opdagelse og kontrol lykkes, men afspilning går i stå, så se i stedet på modtagerens Wi-Fi-link og dens internetvej, fordi en hastighedstest på telefonen beskriver telefonen og ikke tv'et.

Fortryd undtagelsen, og test igen

Enhver midlertidig ændring skal kunne rulles tilbage, og rækkefølgen betyder noget. Fjern LAN-undtagelsen, genopkobl tunnelen, så klienten anvender sin politik igen, og gentag derefter opdagelsestrinet, og noter, om modtageren forsvinder igen. Den sekvens fortæller, om undtagelsen gjorde arbejdet, eller om noget andet ændrede sig undervejs.

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

Kontroller derefter de tre stadier hver for sig, fordi et bestået trin ikke siger noget om de andre. Kontroller så, at uvedkommende telefonapps stadig følger den tilsigtede rute, fordi en lokal undtagelse, der stille blev en fuld omvej, er et værre resultat end et cast, der kræver ét ekstra tryk.