Casten stopt op een VPN: ontdekking, besturing of stream?

Casten breekt op drie plekken die vanaf de bank identiek lijken. De telefoon ziet de ontvanger misschien nooit, de ontvanger kan verschijnen en daarna de sessie weigeren, of de sessie kan starten en een minuut later vastlopen. Een tunnel op de telefoon verandert elk van die paden anders, en voor een ervan verandert hij helemaal niets. Benoem eerst de falende fase en beslis daarna of een beleidswijziging überhaupt de juiste hendel is.

Benoem de falende fase voordat je het beleid wijzigt

Kijk wat de telefoon doet direct nadat je op het castpictogram tikt. Een lege lijst is een ontdekkingsresultaat, een tik die een fout meldt is een besturingsresultaat, en een sessie die start voordat hij vastloopt is een afspeelresultaat. Die drie hebben verschillende eigenaren, en alleen de eerste twee raken normaal gesproken de tunnelinstellingen van de telefoon.

Schrijf de fase op voordat je iets verandert. Een oplossing op de verkeerde fase maakt de volgende test onleesbaar, en de meeste castverhalen komen precies uit die verwarring.

Ontdekking is lokaal verkeer, en een tunnel verbergt het

Ontvangers adverteren zichzelf via lokale aankondigingen en de telefoon vindt ze met queries op dezelfde verbinding, dus alles wat de telefoon van die verbinding haalt, haalt de ontvanger uit de lijst. Een tunnel die al het verkeer weg van het LAN leidt, kan die uitwisselingen verbergen, en een lokale-netwerktoestemming op appniveau kan ze blokkeren zelfs als de route bestaat. Gast-Wi-Fi met clientisolatie levert dezelfde lege lijst op zonder enige VPN. Bewijs dat de twee apparaten een segment delen voordat je de tunnel de schuld geeft.

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

De eerste opdracht somt op wat zich op het segment van de hulpmachine aankondigt, en de tweede vraagt de multicast-DNS-groep direct. Een ontvanger die in beide ontbreekt, verschijnt ook niet in een telefoonapp, wat de tunnelstatus van de telefoon ook is. Als de ontvanger zichtbaar is vanaf een apparaat met de tunnel uit en onzichtbaar vanaf een met de tunnel aan, heb je de fase en de oorzaak samen gevonden.

Een LAN-uitzondering houdt de tunnel actief

Veel clients bieden een lokale-netwerkuitzondering die de tunnel actief laat terwijl lokale adressen worden toegestaan. Gebruik die gedocumenteerde instelling in plaats van de kill switch of de hele firewall uit te zetten, want die veranderen veel meer dan casten nodig heeft. Als het netwerk slimme apparaten bewust scheidt, vraag de eigenaar dan om het specifieke ontdekkings-, besturings- en retourverkeer in plaats van om platte toegang.

nc -vz 192.168.1.50 8009

Een besturingstest naar de ontvanger scheidt toestemming van bereikbaarheid: een poort die antwoordt betekent dat het pad bestaat, terwijl een weigering betekent dat de telefoon het apparaat mocht ontdekken en er nog steeds niet mee kan praten. Poorten 8008 en 8009 zijn de gebruikelijke castpoorten, en een app kan andere gebruiken, dus zie één geweigerde poort als een aanwijzing en niet als een vonnis. De uitzondering en de apptoestemming blijven onafhankelijk, want lokale toegang geeft geen route en een route geeft geen toestemming. Een kill switch kan na opnieuw verbinden ook lokaal verkeer laten vallen, en daarom moet ontdekking opnieuw worden getest zodra de tunnel terug is.

Afspelen gebruikt misschien niet de verbinding van de telefoon

In een app-gestuurde sessie geeft de telefoon de ontvanger een media-adres en haalt de ontvanger het over zijn eigen verbinding op, dus het wijzigen van het publieke adres van de telefoon doet niets voor de stream. Een titel met accountbeperking kan nog steeds om eigen redenen falen, en de castvereisten van Google dekken app- en apparaatcompatibiliteit in plaats van het netwerkpad. De televisie zelf door een tunnel leiden is een aparte configuratie met eigen beleidsvragen.

Twee aanwijzingen onderscheiden de modi. Een cast die blijft lopen als het scherm van de telefoon op slot gaat, is app-gestuurd, omdat de ontvanger zelf ophaalt; een spiegel die stopt wanneer het scherm van de afzender op slot gaat, is een continue stream vanaf de telefoon. Als ontdekking en besturing slagen maar het afspelen vastloopt, kijk dan naar de Wi-Fi-verbinding van de ontvanger en zijn internetpad, want een snelheidstest op de telefoon beschrijft de telefoon en niet de televisie.

Draai de uitzondering terug en test opnieuw

Elke tijdelijke wijziging heeft een weg terug nodig, en de volgorde maakt uit. Verwijder de LAN-uitzondering, verbind de tunnel opnieuw zodat de client zijn beleid opnieuw toepast, herhaal dan de ontdekkingsstap en noteer of de ontvanger weer verdwijnt. Die volgorde vertelt je of de uitzondering het werk deed of dat er iets anders tussenin veranderde.

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

Controleer daarna de drie fasen apart, want een geslaagde test van één zegt niets over de andere. Controleer vervolgens of niet-verwante telefoonapps nog steeds de bedoelde route volgen, want een lokale uitzondering die stilletjes een volledige omzeiling werd, is een slechter resultaat dan casten dat één extra tik nodig heeft.