Waarom casten stopt met werken nadat je de router-VPN inschakelt
Detectie verloopt via link-local multicast, terwijl de tv de media zelf ophaalt. Een standaardregel in het beleid kan het LAN-verzoek onderscheppen en de tunnel in sturen.
Casten werkte voordat de router-VPN werd ingeschakeld en faalt direct daarna, terwijl gewoon browsen op de telefoon nog werkt. Die twee feiten zijn consistent, want casten is niet één verbinding. De telefoon ontdekt en bestuurt de ontvanger via het lokale netwerk, en daarna haalt de ontvanger de media op via zijn eigen verbinding.
Twee paden die verschillend falen
Het controlekanaal is lokaal. Een telefoon vindt een ontvanger door het lokale netwerk te vragen, en opent dan een controleverbinding naar het adres dat hij heeft geleerd. Als de ontvanger nooit in de lijst verschijnt, is de ontdekking mislukt voordat er media is opgevraagd.
Het mediakanaal is niet per se lokaal. Veel ontvangers halen de stream zelf op, via hun eigen verbinding en met hun eigen inloggegevens, dus de route van de telefoon beschrijft niet de route van de ontvanger. Een telefoon die één uitgang lijkt te gebruiken, zegt niets over waar het verkeer van de tv heen gaat.
Die splitsing is de reden dat de storing vreemd lijkt. De tunnel veranderde de routetabel van de telefoon en niet die van de tv, dus een symptoom aan één kant van het paar moet aan die kant worden onderzocht. Het verkeerde apparaat onderzoeken is de gebruikelijke reden dat een oplossing niets lijkt te doen.
Waarom detectie als eerste breekt
Ontdekking verloopt meestal via link-local multicast. mDNS stuurt naar 224.0.0.251 op UDP-poort 5353, en SSDP stuurt naar 239.255.255.250 op UDP-poort 1900. Beide zijn door hun ontwerp tot één link beperkt, daarom stuurt de router ze niet tussen segmenten door zonder hulp van een repeater of proxy. Een gerouteerde VPN breidt geen multicast-groep uit, en een beleidsroute kan een groep die de link nooit heeft verlaten niet op een andere link laten verschijnen.
De eerste storing heeft dus niets met versleuteling te maken. De multicast van de telefoon verlaat de interface waarop hij is verzonden, de ontvanger zit in een segment dat die nooit ziet, en de apparatenlijst komt leeg terug. Een lege lijst is geen bewijs dat de tv de internettoegang kwijt is.
Isolatie levert hetzelfde symptoom op zonder enige VPN. Gastnetwerken en client-isolatie op het accesspoint houden apparaten bewust van elkaar weg, en een router-VPN aanzetten bovenop een geïsoleerd segment verandert daar niets aan. Controleer de isolatie-instelling voordat je de tunnel controleert. Dat is het goedkopere antwoord en het meest voorkomende.
De segmentindeling is de andere helft. Een tweede router, een mesh-node in een andere modus of een bedraad segment achter een andere NAT zetten de ontvanger allemaal daar waar het ontdekkingsverkeer van de telefoon niet komt.
Waarom een standaardregel van het beleid een lokaal verzoek kan inslikken
Een router die al het verkeer de tunnel in stuurt, installeert een standaardroute op de tunnelinterface. Als het LAN-prefix niet van dat beleid is uitgesloten, voldoet een pakket voor een apparaat twee meter verderop nu aan de standaardroute, en stuurt de router het controleverzoek de tunnel in in plaats van naar de switch.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
De volgorde van regels bepaalt de uitkomst. Beleidsroutering beoordeelt regels in prioriteitsvolgorde, dus een uitzondering voor het lokale prefix moet vóór de regel staan die de tunneltabel kiest. De uitzondering na de tunnelregel toevoegen heeft geen effect, en daarom kan een configuratie die er correct uitziet toch LAN-verkeer naar een externe uitgang sturen.
De reparatie is smal: sta de specifieke lokale bestemmingen toe die de caststroom nodig heeft, en laat de rest van de isolatie met rust. Client-isolatie als eerste stap weghalen geneest het symptoom, maar gooit een beheersing weg die het netwerk volgens ontwerp hoorde te hebben.
Een snelle blik op de telefoon bepaalt welke van de twee storingen je hebt. Wijst de route naar de ontvanger op de tunnel, dan is het beleid het probleem. Wijst die op het LAN en faalt de ontdekking nog steeds, dan is multicast of isolatie het probleem, en geen routewijziging zal helpen.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTest de fase die veranderde, niet het land
Vastgelegde observaties verslaan herhaalde experimenten. Noteer of de ontvanger in de apparatenlijst verschijnt, of een controleverzoek hem bereikt, en of het afspelen begint zodra een stream is gekozen. Elk antwoord haalt één fase uit de verdenking.
Test daarna elke fase rechtstreeks in plaats van van uitgangslocatie te wisselen. Een ander VPN-land test het mediakanaal en laat de ontdekkings- en controlekanaal onaangeroerd, dus het kan bij toeval helpen zonder je iets te leren.
Controleer aan de ontvangerkant zijn eigen route en zijn eigen accountstatus. Een tv die media via een andere uitgang ophaalt dan de telefoon is een normaal ontwerp, en een storing daar is een vraag over het netwerkbeleid van de ontvanger, niet over de tunnel van de telefoon.
Schrijf het resultaat op als één zin over welke fase brak en wat die veranderde. Die zin is meer waard dan een week landen wisselen, en hij overleeft de volgende firmware-update.
Casten is een goede testcase voor een algemene regel over tunnels. Wanneer er een aan een netwerk wordt toegevoegd, is de eerste vraag welke bestemmingen er nooit in hadden moeten belanden. De tweede is welke daarvan het beleid toch stilzwijgend heeft geaccepteerd.