Castning slutar fungera på VPN: upptäckt, styrning eller ström?

Castning går sönder på tre ställen som ser likadana ut från soffan. Telefonen kanske aldrig ser mottagaren, mottagaren kan dyka upp och sedan neka sessionen, eller sessionen kan starta och stanna en minut senare. En tunnel på telefonen förändrar var och en av de vägarna olika, och för en av dem förändrar den ingenting. Namnge det felande steget först och avgör sedan om en policyändring ens är rätt spak att dra i.

Namnge det felande steget innan du ändrar policyn

Titta på vad telefonen gör direkt efter att du trycker på castikonen. En tom lista är ett upptäcktsresultat, en tryckning som rapporterar fel är ett styrresultat, och en session som startar innan den stannar är ett uppspelningsresultat. De tre har olika ägare, och vanligtvis är det bara de två första som rör telefonens tunnelinställningar.

Skriv ner steget innan du ändrar något. En åtgärd på fel steg gör nästa test oläsbart, och det mesta av castfolkloren kommer just från den förvirringen.

Upptäckt är lokal trafik, och en tunnel döljer den

Mottagare annonserar sig via lokala annonser och telefonen hittar dem med frågor på samma länk, så allt som tar bort telefonen från den länken tar bort mottagaren från listan. En tunnel som routar all trafik bort från LAN kan dölja de utbytena, och en lokalnätbehörighet på appnivå kan blockera dem även när rutten finns. Gäst-Wi-Fi med klientisolering ger samma tomma lista helt utan VPN. Bevisa att de två enheterna delar segment innan du skyller på tunneln.

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

Det första kommandot listar vad som annonserar sig på hjälpmaskinens segment, och det andra frågar multicast-DNS-gruppen direkt. En mottagare som saknas i båda syns inte heller i en telefonapp, oavsett telefonens tunnelstatus. Om mottagaren syns från en enhet med tunneln av och inte syns från en med tunneln på, har du hittat steget och orsaken samtidigt.

Ett LAN-undantag håller tunneln uppe

Många klienter erbjuder ett lokalnätundantag som låter tunneln vara aktiv medan lokala adresser tillåts. Använd den dokumenterade inställningen i stället för att stänga av kill switch eller hela brandväggen, eftersom de ändrar långt mer än castning behöver. Om nätverket medvetet skiljer smarta enheter, be ägaren om den specifika upptäckts-, styr- och returtrafiken i stället för platt åtkomst.

nc -vz 192.168.1.50 8009

Ett styrprov mot mottagaren skiljer behörighet från nåbarhet: en port som svarar betyder att vägen finns, medan ett nekande betyder att telefonen fick upptäcka enheten och fortfarande inte kan prata med den. Portarna 8008 och 8009 är de vanliga castportarna, och en app kan använda andra, så behandla en nekad port som en ledtråd och inte som en dom. Undantaget och appbehörigheten förblir oberoende, eftersom lokal åtkomst inte skapar en rutt och en rutt inte ger behörighet. En kill switch kan också släppa lokal trafik efter en återanslutning, och därför måste upptäckten testas om när tunneln är tillbaka.

Uppspelning använder kanske inte telefonens anslutning

I en appstyrd session ger telefonen mottagaren en medieadress och mottagaren hämtar den över sin egen anslutning, så att byta telefonens publika adress gör ingenting för strömmen. En kontobegränsad titel kan fortfarande misslyckas av egna skäl, och Googles castkrav täcker app- och enhetskompatibilitet snarare än nätverksvägen. Att routa själva tv:n genom en tunnel är en separat konfiguration med egna policyfrågor.

Två ledtrådar skiljer lägena. En cast som överlever att telefonskärmen låses är appstyrd, eftersom mottagaren hämtar själv; en spegling som stoppar när avsändarens skärm låses är en kontinuerlig ström från telefonen. När upptäckt och styrning lyckas men uppspelningen stannar, titta i stället på mottagarens Wi-Fi-länk och dess internetväg, eftersom ett hastighetstest på telefonen beskriver telefonen och inte tv:n.

Ångra undantaget och testa igen

Varje tillfällig ändring behöver en väg tillbaka, och ordningen spelar roll. Ta bort LAN-undantaget, återanslut tunneln så att klienten tillämpar sin policy igen, upprepa sedan upptäcktssteget och notera om mottagaren försvinner igen. Den sekvensen säger om undantaget gjorde jobbet eller om något annat ändrades under tiden.

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

Verifiera sedan de tre stegen separat, eftersom ett godkänt steg inte säger något om de andra. Kontrollera därefter att orelaterade telefonappar fortfarande följer den avsedda rutten, eftersom ett lokalt undantag som tyst blev en fullständig kringgång är ett sämre utfall än en cast som kräver ett extra tryck.