Varför castning slutar fungera när du slår på router-VPN
Upptäckten går över link-local multicast, medan TV:n hämtar mediet själv. En standardregel i policyn kan fånga LAN-förfrågan och skicka in den i tunneln.
Castningen fungerade innan router-VPN slogs på och misslyckas direkt efteråt, medan vanligt surfande på telefonen fortfarande fungerar. De två fakta är konsekventa, eftersom castning inte är en enda anslutning. Telefonen upptäcker och styr mottagaren via det lokala nätet, och därefter hämtar mottagaren mediet via sin egen anslutning.
Två vägar som misslyckas olika
Kontrollvägen är lokal. En telefon hittar en mottagare genom att fråga det lokala nätet och öppnar sedan en kontrollanslutning till adressen den lärt sig. Om mottagaren aldrig dyker upp i listan har upptäckten misslyckats innan något medie efterfrågades.
Medievägen är inte nödvändigtvis lokal. Många mottagare hämtar strömmen själva, via egen anslutning och med egna inloggningsuppgifter, så telefonens rutt beskriver inte mottagarens rutt. En telefon som ser ut att använda en utgång säger ingenting om vart TV:ns trafik tar vägen.
Den här delningen är anledningen till att felet verkar märkligt. Tunneln ändrade telefonens routingtabell och ändrade inte TV:ns, så ett symptom som visar sig på ena sidan av paret måste spåras på den sidan. Att undersöka fel enhet är det vanliga skälet till att en åtgärd verkar göra ingenting.
Varför upptäckten brister först
Upptäckten går vanligtvis över link-local multicast. mDNS skickar till 224.0.0.251 på UDP-port 5353, och SSDP skickar till 239.255.255.250 på UDP-port 1900. Båda är av konstruktion begränsade till en länk, och därför vidarebefordrar inte routern dem mellan segment utan hjälp av en repeater eller proxy. En routad VPN utökar inte en multicast-grupp, och en policyrutt kan inte få en grupp som aldrig lämnade länken att dyka upp på en annan.
Så det första felet har ingenting med kryptering att göra. Telefonens multicast lämnar det gränssnitt det skickades på, mottagaren finns i ett segment som aldrig ser det, och enhetslistan kommer tillbaka tom. En tom lista är inte bevis för att TV:n förlorade internetåtkomsten.
Isolering ger ett identiskt symptom utan någon VPN inblandad. Gästnätverk och klientisolering på åtkomstpunkten hindrar medvetet enheter från att prata med varandra, och att slå på router-VPN ovanpå ett isolerat segment ändrar ingenting i det. Kontrollera isoleringsinställningen innan du kontrollerar tunneln. Det är det billigare svaret och det vanligare.
Segmentlayouten är den andra halvan. En andra router, en mesh-nod i ett annat läge eller ett trådbundet segment bakom en annan NAT placerar alla mottagaren där telefonens upptäcktstrafik inte når.
Varför en standardregel i policyn kan svälja en lokal förfrågan
En router som skickar all trafik in i en tunnel installerar en standardrutt på tunnelgränssnittet. Om LAN-prefixet inte är undantaget från den policyn matchar ett paket adresserat till en enhet två meter bort nu standardrutten, och routern skickar kontrollförfrågan in i tunneln i stället för till switchen.
| 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 |
Regelordningen avgör resultatet. Policyroutning utvärderar regler i prioritetsordning, så ett undantag för det lokala prefixet måste stå före regeln som väljer tunneltabellen. Att lägga undantaget efter tunnelregeln har ingen effekt, och därför kan en konfiguration som ser korrekt ut ändå skicka LAN-trafik till en avlägsen utgång.
Åtgärden är smal: tillåt de specifika lokala destinationer som castningsflödet behöver, och lämna resten av isoleringen i fred. Att ta bort klientisolering som första steg botar symptomet men kastar bort en kontroll som nätet var designat att ha.
En snabb kontroll på telefonen avgör vilket av de två felen du har. Om rutten till mottagaren pekar mot tunneln är policyn problemet. Om den pekar mot LAN och upptäckten ändå misslyckas är multicast eller isolering problemet, och ingen ruttändring hjälper.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTesta steget som ändrades, inte landet
Dokumenterade observationer slår upprepade experiment. Anteckna om mottagaren visas i enhetslistan, om en kontrollförfrågan når den, och om uppspelningen startar när en ström valts. Varje svar tar bort ett steg från misstanken.
Testa sedan varje steg direkt i stället för att byta utgångsplats. Att byta VPN-land testar medievägen och lämnar upptäckts- och kontrollstegen orörda, så det kan se ut att hjälpa av en slump utan att lära dig något.
På mottagarsidan, kontrollera dess egen rutt och dess egen kontostatus. En TV som hämtar medier via en annan utgång än telefonen är en normal design, och ett fel där är en fråga om mottagarens nätverkspolicy, inte om telefonens tunnel.
Skriv ner resultatet som en enda mening om vilket steg som gick sönder och vad som ändrade det. Den meningen är värd mer än en vecka av landsbyten och överlever nästa firmwareuppdatering.
Castning är ett bra testfall för en allmän regel om tunnlar. När en läggs till i ett nätverk är den första frågan vilka destinationer som aldrig borde ha hamnat i den. Den andra är vilka av dem policyn ändå tyst accepterade.