Kvifor casting sluttar å verke når rutar-VPN vert slått på
Oppdaging går over link-local multicast, medan TV-en hentar mediet sjølv. Ein standardregel i policyen kan fange LAN-førespurnaden og sende han inn i tunnelen.
Casting fungerte før rutar-VPN vart slått på og feilar med ein gong etterpå, medan vanleg nettsurfing på telefonen framleis verkar. Dei to fakta er konsistente, fordi casting ikkje er éi tilkopling. Telefonen oppdagar og styrer mottakaren over det lokale nettet, og deretter hentar mottakaren mediet over si eiga tilkopling.
To vegan som feilar ulikt
Kontrollvegen er lokal. Ein telefon finn ein mottakar ved å spørje det lokale nettet, og opnar så ei kontrolltilkopling til adressa han lærte. Viss mottakaren aldri dukkar opp i lista, feila oppdaginga før noko medie vart spurt etter.
Medievegen er ikkje nødvendigvis lokal. Mange mottakarar hentar strøymen sjølv, over si eiga tilkopling og med eigne påloggingsdata, så ruta til telefonen skildrar ikkje ruta til mottakaren. Ein telefon som ser ut til å bruke éin utgang, seier ingenting om kvar trafikken til TV-en går.
Denne delinga er grunnen til at feilen verkar merkeleg. Tunellen endra rutetabellen til telefonen og endra ikkje den til TV-en, så eit symptom som viser seg på éi side av paret, må sporast på den sida. Å undersøkje feil eining er den vanlege grunnen til at ei retting ser ut til å ikkje gjere noko.
Kvifor oppdaginga ryker fyrst
Oppdaging går vanlegvis 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 avgrensa til éin lenkje av design, og difor vidaresender ikkje rutaren dei mellom segment utan hjelp frå ein repeater eller proxy. Eit ruta VPN utvidar ikkje ei multicast-gruppe, og ei policy-rute kan ikkje få ei gruppe som aldri forlét lenkja til å dukke opp på ei anna.
Så den første feilen har ingenting med kryptering å gjere. Multicast frå telefonen forlét grensesnittet det vart sendt på, mottakaren er i eit segment som aldri ser det, og eininglista kjem tilbake tom. Ei tom liste er ikkje prov på at TV-en mista internettilgangen.
Isolasjon gir eit identisk symptom utan nokon VPN involvert. Gjestenettverk og klientisolasjon på aksesspunktet hindrar med vilje einingar i å snakke saman, og å slå på rutar-VPN oppå eit isolert segment endrar ingenting ved det. Sjekk isolasjonsinnstillinga før du sjekkar tunellen. Det er det billegare svaret og det vanlegare.
Segmentoppsettet er den andre halvdelen. Ein andre rutar, ein mesh-node i ein annan modus eller eit kablet segment bak ein annan NAT plasserer alle mottakaren der oppdagingstrafikken til telefonen ikkje når.
Kvifor ein standardregel i policyen kan sluke ein lokal førespurnad
Ein rutar som sender all trafikk inn i ein tunnel, installerer ei standardrute på tunellgrensesnittet. Viss LAN-prefikset ikkje er utelate frå den policyen, samsvarar no ein pakke adressert til ei eining to meter unna standardruta, og rutaren sender kontrollførespurnaden inn i tunnelen i staden 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 |
Regelrekkjefølgja avgjer resultatet. Policy-ruting vurderer reglar i prioritetsrekkjefølgje, så eit unntak for det lokale prefikset må stå før regelen som vel tunelltabellen. Å leggje unntaket etter tunellregelen har ingen effekt, og difor kan ein konfigurasjon som ser riktig ut framleis sende LAN-trafikk til ein ekstern utgang.
Rettinga er smal: tillat dei konkrete lokale destinasjonane castingflyten treng, og lat resten av isolasjonen vere i fred. Å fjerne klientisolasjon som første steg lækjer symptomet, men kastar bort ein kontroll nettet var designa for å ha.
Eit raskt oppslag på telefonen avgjer kva av dei to feila du har. Viss ruta til mottakaren peikar mot tunnelen, er policyen problemet. Viss ho peikar mot LAN og oppdaginga framleis feilar, er multicast eller isolasjon problemet, og inga ruteendring vil hjelpe.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTest trinnet som endra seg, ikkje landet
Registrerte observasjonar slår gjentekne eksperiment. Noter om mottakaren viser seg i eininglista, om ein kontrollførespurnad når han, og om avspeling startar når ein strøym er vald. Kvart svar fjernar eitt trinn frå mistanke.
Test deretter kvart trinn direkte i staden for å byte utgangsstad. Å byte VPN-land testar medievegen og let oppdagings- og kontrolltrinna vere urørte, så det kan sjå ut som det hjelper ved eit uhell utan å lære deg noko.
På mottakarsida, sjekk den eiga ruta og den eigen kontotilstanden. Ein TV som hentar media gjennom ein annan utgang enn telefonen er eit normalt design, og ein feil der er eit spørsmål om nettverkspolicyen til mottakaren, ikkje om tunellen til telefonen.
Skriv resultatet ned som éi setning om kva trinn som braut og kva som endra det. Den setninga er verdt meir enn ei veke med landbyting, og ho overlever neste fastvareoppdatering.
Casting er eit godt testtilfelle for ein generell regel om tunnelar. Når ein vert lagd til eit nettverk, er det første spørsmålet kva destinasjonar som aldri burde ha hamna i han. Det andre er kva av dei policyen likevel godtok i det stille.