Hvorfor casting holder op med at virke, når du slår router-VPN til
Opdagelse kører over lokal multicast, mens tv'et selv henter medierne. En standardpolitik kan fange LAN-anmodningen og sende den ind i tunnelen.
Casting virkede, før router-VPN blev slået til, og fejler straks efter, mens almindelig browsing på telefonen stadig virker. De to ting er forenelige, for casting er ikke én forbindelse. Telefonen finder og styrer modtageren over det lokale netværk, og modtageren henter derefter medierne over sin egen forbindelse.
To veje, der fejler forskelligt
Styrevejen er lokal. En telefon finder en modtager ved at spørge det lokale netværk og åbner derefter en styreforbindelse til den adresse, den har lært. Hvis modtageren aldrig dukker op på listen, fejlede opdagelsestrinnet, før der blev bedt om medier.
Medievejen er ikke nødvendigvis lokal. Mange modtagere henter selv streamen over deres egen forbindelse og med deres egne legitimationsoplysninger, så telefonens rute beskriver ikke modtagerens rute. En telefon, der ser ud til at bruge én udgang, siger intet om, hvor tv'ets trafik går hen.
Den opdeling er grunden til, at fejlen ser mærkelig ud. Tunnelen ændrede telefonens routingtabel og ændrede ikke tv'ets, så et symptom, der viser sig på den ene side af parret, skal spores på den side. At spore den forkerte enhed er den sædvanlige grund til, at en rettelse ser ud til ikke at gøre noget.
Hvorfor opdagelse fejler først
Opdagelse kører normalt over link-lokal multicast. mDNS sender til 224.0.0.251 på UDP-port 5353, og SSDP sender til 239.255.255.250 på UDP-port 1900. Begge er efter design begrænset til ét link, og derfor videresender en router dem ikke mellem segmenter uden hjælp fra en repeater eller en proxy. En routet VPN udvider ikke en multicast-gruppe, og en politikrute kan ikke få en gruppe, der aldrig forlod linket, til at dukke op på et andet.
Så den første fejl har intet med kryptering at gøre. Telefonens multicast forlader det interface, den blev sendt på, modtageren er på et segment, der aldrig ser den, og enhedslisten kommer tom tilbage. En tom liste er ikke bevis for, at tv'et har mistet internetadgang.
Isolering giver et identisk symptom uden nogen VPN. Gæstenetværk og klientisolering på adgangspunkter forhindrer bevidst enheder i at tale sammen, og at slå router-VPN til oven på et isoleret segment ændrer intet ved det. Tjek isoleringsindstillingen, før du tjekker tunnelen. Det er det billigere svar og det mest almindelige.
Segmentlayout er den anden halvdel. En ekstra router, en mesh-node i en anden tilstand eller et kablet segment bag endnu en NAT placerer alle modtageren et sted, hvor telefonens opdagelsestrafik ikke når.
Hvorfor en standardpolitik kan sluge en lokal anmodning
En router, der sender al trafik ind i en tunnel, installerer en standardrute på tunnelets interface. Hvis LAN-præfikset ikke er udelukket fra den politik, matcher en pakke rettet mod en enhed to meter væk nu standardruten, og routeren sender styreanmodningen ind i tunnelen i stedet for ud på 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 |
Regelrækkefølgen afgør resultatet. Politikrouting vurderer regler i prioritetsrækkefølge, så en undtagelse for det lokale præfiks skal stå før den regel, der vælger tunnel-tabellen. At tilføje undtagelsen efter tunnelreglen har ingen virkning, og derfor kan en konfiguration, der ser korrekt ud, stadig sende LAN-trafik til en fjern udgang.
Rettelsen er smal: tillad de specifikke lokale destinationer, casting-flowet har brug for, og lad resten af isoleringen være. At fjerne klientisolering som første skridt retter symptomet, men smider en kontrol væk, som netværket var designet til at have.
Et hurtigt opslag på telefonen afgør, hvilken af de to fejl du har. Hvis ruten til modtageren peger på tunnelen, er politikken problemet. Hvis den peger på LAN'et, og opdagelse stadig fejler, er multicast eller isolering problemet, og ingen ruteændring vil hjælpe.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTest det trin, der ændrede sig, ikke landet
Registrerede observationer slår gentagne eksperimenter. Noter, om modtageren dukker op i enhedslisten, om en styreanmodning når den, og om afspilningen starter, når der vælges en stream. Hvert svar fjerner et trin fra mistanke.
Test derefter hvert trin direkte i stedet for at skifte udgangsplacering. At skifte VPN-land tester medievejen og lader opdagelses- og styretrinene være urørt, så det kan se ud til at hjælpe ved et tilfælde uden at lære dig noget.
På modtagerens side, tjek dens egen rute og dens egen kontotilstand. Et tv, der henter medier gennem en anden udgang end telefonen, er et normalt design, og en fejl der er et spørgsmål om modtagerens netværkspolitik snarere end om telefonens tunnel.
Skriv resultatet ned som én sætning om, hvilket trin der brød, og hvad der ændrede det. Den sætning er mere værd end en uge med landeskift, og den overlever den næste firmwareopdatering.
Casting er et godt testtilfælde for en generel regel om tunneler. Når en tilføjes til et netværk, er det første spørgsmål hvilke destinationer der aldrig burde være kommet ind i den. Det andet er, hvilke af dem politikken alligevel stiltiende accepterede.