Hvorfor casting slutter å virke etter at ruter-VPN er slått på
Oppdagelsen går over link-local multicast, mens TV-en henter mediet selv. En standardregel i policyen kan fange LAN-forespørselen og sende den inn i tunnelen.
Casting virket før ruter-VPN ble slått på og feiler umiddelbart etterpå, mens vanlig nettsurfing på telefonen fortsatt virker. De to observasjonene er konsistente, fordi casting ikke er én enkelt tilkobling. Telefonen oppdager og styrer mottakeren over det lokale nettet, og deretter henter mottakeren mediet over sin egen tilkobling.
To veier som feiler på hver sin måte
Kontrollveien er lokal. En telefon finner en mottaker ved å spørre det lokale nettet, og åpner så en kontrolltilkobling til adressen den har lært. Dersom mottakeren aldri dukker opp i listen, feilet oppdagelsen før noe medie ble etterspurt.
Medieveien er ikke nødvendigvis lokal. Mange mottakere henter strømmen selv, over egen tilkobling og med egne påloggingsdata, slik at telefonens rute ikke beskriver mottakerens rute. En telefon som ser ut til å bruke én utgang, sier ingenting om hvor TV-ens trafikk tar veien.
Det er denne delingen som gjør feilen underlig. Tunnelen endret rutetabellen til telefonen og lot TV-ens tabell være, så et symptom på én side av paret må spores på nettopp den siden. Å granske feil enhet er den vanligste grunnen til at en rettelse tilsynelatende ikke virker.
Hvorfor oppdagelsen svikter først
Oppdagelsen går vanligvis over link-local 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 etter sin natur begrenset til én lenke, og derfor videresender ikke ruteren dem mellom segmenter uten hjelp av en repeater eller proxy. En rutet VPN utvider ikke en multicast-gruppe, og en policy-rute kan ikke få en gruppe som aldri forlot lenken til å dukke opp på en annen.
Den første feilen har altså ingenting med kryptering å gjøre. Telefonens multicast forlater grensesnittet det ble sendt ut på, mottakeren befinner seg i et segment som aldri ser det, og enhetslisten kommer tilbake tom. En tom liste er ikke bevis for at TV-en har mistet internettilgangen.
Isolasjon gir et identisk symptom uten at noen VPN er inne i bildet. Gjestenettverk og klientisolasjon på aksesspunktet hindrer med vilje enheter i å snakke sammen, og å slå på ruter-VPN over et isolert segment endrer ingenting ved det. Sjekk isolasjonsinnstillingen før du sjekker tunnelen. Det er det rimeligere svaret og det vanligste.
Segmentoppsettet er den andre halvdelen. En ekstra ruter, en mesh-node i annen modus eller et kablet segment bak en annen NAT plasserer mottakeren der telefonens oppdagelsestrafikk ikke når fram.
Hvorfor en standardregel i policyen kan sluke en lokal forespørsel
En ruter som leder all trafikk inn i en tunnel, setter opp en standardrute på tunellgrensesnittet. Dersom LAN-prefikset ikke er holdt utenfor den policyen, vil en pakke til en enhet to meter unna nå treffe standardruten, og ruteren sender kontrollforespørselen inn i tunnelen i stedet for ut på svitsjen.
| 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 |
Rekkefølgen av regler avgjør utfallet. Policy-ruting vurderer reglene etter prioritet, så et unntak for det lokale prefikset må komme før regelen som velger tunelltabellen. Legger du unntaket etter tunellregelen, har det ingen virkning, og derfor kan en konfigurasjon som ser riktig ut likevel sende LAN-trafikk til en ekstern utgang.
Rettelsen er smal: tillat de bestemte lokale destinasjonene castingflyten trenger, og la resten av isolasjonen være. Å fjerne klientisolasjon som første skritt kurerer symptomet, men kaster bort en kontroll nettet var ment å ha.
Et raskt oppslag på telefonen avgjør hvilken av de to feilene du står i. Peker ruten til mottakeren mot tunnelen, er policyen problemet. Peiler den mot LAN og oppdagelsen fortsatt feiler, er multicast eller isolasjon problemet, og ingen ruteendring vil hjelpe.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTest trinnet som ble endret, ikke landet
Nedskrevne observasjoner er bedre enn gjentatte forsøk. Noter om mottakeren dukker opp i enhetslisten, om en kontrollforespørsel når fram til den, og om avspillingen starter når en strøm er valgt. Hvert svar fjerner ett trinn fra mistanken.
Deretter bør du teste hvert trinn direkte i stedet for å bytte utgangssted. Å skifte VPN-land tester medieveien og lar oppdagelses- og kontrolltrinnene være urørt, så det kan se ut som det hjelper ved en tilfeldighet uten å lære deg noe.
På mottakersiden bør du sjekke dens egen rute og dens egen kontotilstand. En TV som henter medier gjennom en annen utgang enn telefonen, er et normalt design, og en feil der er et spørsmål om mottakerens nettverkspolicy, ikke om telefonens tunnel.
Skriv ned resultatet som én setning om hvilket trinn som brast og hva som endret det. Den setningen er verdt mer enn en uke med landbytting, og den tåler neste fastvareoppdatering.
Casting er et godt testtilfelle for en generell regel om tunneler. Når en tunnel legges til et nettverk, er det første spørsmålet hvilke destinasjoner som aldri burde ha havnet i den. Det andre er hvilke av dem policyen likevel godtok i stillhet.