Hvorfor casting slutter å virke når ruter-VPN slås på
Oppdagelse 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 fungerte før ruter-VPN ble slått på og feiler umiddelbart etterpå, mens vanlig nettsurfing på telefonen fortsatt virker. De to faktumene er konsistente, fordi casting ikke er én tilkobling. Telefonen oppdager og styrer mottakeren over det lokale nettet, og deretter henter mottakeren mediet over sin egen tilkobling.
To veier som feiler ulikt
Kontrollveien er lokal. En telefon finner en mottaker ved å spørre det lokale nettet, og åpner så en kontrolltilkobling til adressen den lærte. Hvis mottakeren aldri dukker opp i listen, feilet oppdagelsen før noe medie ble forespurt.
Medieveien er ikke nødvendigvis lokal. Mange mottakere henter strømmen selv, over sin egen tilkobling og med egne påloggingsdata, så telefonens rute beskriver ikke mottakerens rute. En telefon som ser ut til å bruke én utgang, sier ingenting om hvor TV-ens trafikk går.
Denne delingen er grunnen til at feilen virker merkelig. Tunnelen endret telefonens rutetabell og endret ikke TV-ens, så et symptom som vises på én side av paret, må spores på den siden. Å undersøke feil enhet er den vanlige grunnen til at en rettelse ser ut til å ikke gjøre noe.
Hvorfor oppdagelsen ryker først
Oppdagelse 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 begrenset til én lenke av design, og derfor videresender ikke ruteren dem mellom segmenter uten hjelp fra 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.
Så den første feilen har ingenting med kryptering å gjøre. Telefonens multicast forlater grensesnittet det ble sendt på, mottakeren er i et segment som aldri ser det, og enhetslisten kommer tilbake tom. En tom liste er ikke bevis for at TV-en mistet internettilgangen.
Isolasjon gir et identisk symptom uten noen VPN involvert. Gjestenettverk og klientisolasjon på aksesspunktet hindrer bevisst enheter i å snakke sammen, og å slå på ruter-VPN oppå et isolert segment endrer ingenting ved det. Sjekk isolasjonsinnstillingen før du sjekker tunnelen. Det er det billigere svaret og det vanligere.
Segmentoppsettet er den andre halvdelen. En andre ruter, en mesh-node i en annen modus eller et kablet segment bak en annen NAT plasserer alle mottakeren der telefonens oppdagelsestrafikk ikke når.
Hvorfor en standardregel i policyen kan sluke en lokal forespørsel
En ruter som sender all trafikk inn i en tunnel, installerer en standardrute på tunellgrensesnittet. Hvis LAN-prefikset ikke er utelatt fra den policyen, samsvarer nå en pakke adressert til en enhet to meter unna standardruten, og ruteren sender kontrollforespørselen inn i tunnelen i stedet for til 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 |
Regelrekkefølgen avgjør resultatet. Policy-ruting vurderer regler i prioritetsrekkefølge, så et unntak for det lokale prefikset må stå før regelen som velger tunelltabellen. Å legge unntaket etter tunellregelen har ingen effekt, og derfor kan en konfigurasjon som ser riktig ut fortsatt sende LAN-trafikk til en ekstern utgang.
Rettelsen er smal: tillat de konkrete lokale destinasjonene castingflyten trenger, og la resten av isolasjonen være i fred. Å fjerne klientisolasjon som første steg helbreder symptomet, men kaster bort en kontroll nettet var designet for å ha.
Et raskt oppslag på telefonen avgjør hvilken av de to feilene du har. Hvis ruten til mottakeren peker mot tunnelen, er policyen problemet. Hvis den peker 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 endret seg, ikke landet
Registrerte observasjoner slår gjentatte eksperimenter. Noter om mottakeren vises i enhetslisten, om en kontrollforespørsel når den, og om avspilling starter når en strøm er valgt. Hvert svar fjerner ett trinn fra mistanke.
Test deretter hvert trinn direkte i stedet for å bytte utgangssted. Å bytte VPN-land tester medieveien og lar oppdagelses- og kontrolltrinnene være urørt, så det kan se ut som det hjelper ved et uhell uten å lære deg noe.
På mottakersiden, sjekk 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 resultatet ned som én setning om hvilket trinn som brøt og hva som endret det. Den setningen er verdt mer enn en uke med landbytting, og den overlever neste fastvareoppdatering.
Casting er et godt testtilfelle for en generell regel om tunneler. Når en 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.