Hoekom casting ophou werk nadat jy die router-VPN aanskakel
Ontdekking ry op skakel-plaaslike multicast terwyl die TV self die media haal. ’n Beleidstandaard kan die LAN-versoek vang en in die tonnel instuur.
Casting het gewerk voordat die router-VPN aangeskakel is en misluk dadelik daarna, terwyl gewone blaaiery op die foon steeds werk. Die twee feite is bestaanbaar, want casting is nie een verbinding nie. Die foon ontdek en beheer die ontvanger oor die plaaslike netwerk, en die ontvanger haal dan die media oor sy eie verbinding.
Twee paaie wat verskillend misluk
Die beheerpad is plaaslik. ’n Foon vind ’n ontvanger deur die plaaslike netwerk te vra en maak dan ’n beheerverbinding oop na die adres wat dit geleer het. As die ontvanger nooit in die lys verskyn nie, het die ontdekkingstap misluk voordat enige media aangevra is.
Die mediapad is nie noodwendig plaaslik nie. Baie ontvangers haal die stroom self, oor hul eie verbinding en met hul eie geloofsbriewe, so die foon se roete beskryf nie die ontvanger se roete nie. ’n Foon wat blykbaar een uitgang gebruik, sê niks oor waar die TV se verkeer heen gaan nie.
Daardie verdeling is hoekom die fout vreemd lyk. Die tonnel het die foon se roetertabel verander en nie die TV s’n nie, so ’n simptoom wat aan een kant van die paar verskyn, moet aan daardie kant nagegaan word. Om die verkeerde toestel na te spoor is die gewone rede waarom ’n oplossing lyk of dit niks doen nie.
Hoekom ontdekking eerste breek
Ontdekking ry gewoonlik op skakel-plaaslike multicast. mDNS stuur na 224.0.0.251 op UDP-poort 5353, en SSDP stuur na 239.255.255.250 op UDP-poort 1900. Albei is volgens ontwerp tot een skakel beperk, en daarom stuur ’n router dit nie tussen segmente deur sonder hulp van ’n herhaler of ’n instaanbediener nie. ’n Geroteerde VPN brei nie ’n multicast-groep uit nie, en ’n beleidsroete kan nie ’n groep wat nooit die skakel verlaat het nie, op ’n ander een laat verskyn nie.
Die eerste fout het dus niks met enkripsie te doen nie. Die foon se multicast verlaat die koppelvlak waarop dit gestuur is, die ontvanger is op ’n segment wat dit nooit sien nie, en die toestellys kom leeg terug. ’n Leë lys is nie bewyse dat die TV internettoegang verloor het nie.
Isolasie lewer ’n identiese simptoom sonder enige VPN. Gasternetwerke en kliëntisolasie op toegangspunte keer doelbewus dat toestelle met mekaar praat, en om ’n router-VPN bo-op ’n geïsoleerde segment aan te skakel, verander niks daaraan nie. Kontroleer die isolasie-instelling voordat jy die tonnel kontroleer. Dit is die goedkoper antwoord en die meer algemene een.
Segmentuitleg is die ander helfte. ’n Tweede router, ’n mesh-nodus in ’n ander modus, of ’n bedrade segment agter nog ’n NAT plaas die ontvanger oral waar die foon se ontdekkingsverkeer nie kom nie.
Hoekom ’n beleidstandaard ’n plaaslike versoek kan insluk
’n Router wat alle verkeer in ’n tonnel stuur, installeer ’n standaardroete op die tonnelkoppelvlak. As die LAN-voorvoegsel nie van daardie beleid uitgesluit is nie, pas ’n pakket wat aan ’n toestel twee meter verder geadresseer is, nou by die standaard, en die router stuur die beheerversoek in die tonnel in in plaas van na die skakelaar.
| 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 |
Reëlorde bepaal die uitkoms. Beleidsroetering evalueer reëls in prioriteitsorde, so ’n uitsondering vir die plaaslike voorvoegsel moet voor die reël verskyn wat die tonneltabel kies. Om die uitsondering ná die tonnelreël by te voeg, het geen effek nie, en daarom kan ’n konfigurasie wat korrek lyk, steeds LAN-verkeer na ’n afgeleë uitgang stuur.
Die herstel is smal: laat die spesifieke plaaslike bestemmings toe wat die casting-vloei nodig het, en laat die res van die isolasie staan. Om kliëntisolasie as eerste stap te verwyder, maak die simptoom reg terwyl ’n beheer weggegooi word wat die netwerk ontwerp is om te hê.
’n Vinnige opzoeking op die foon bepaal watter van die twee foute jy het. As die roete na die ontvanger na die tonnel wys, is die beleid die probleem. As dit na die LAN wys en ontdekking misluk steeds, is multicast of isolasie die probleem, en geen roeteverandering sal help nie.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpToets die stap wat verander het, nie die land nie
Vasgelegde waarnemings is beter as herhaalde eksperimente. Let op of die ontvanger in die toestellys verskyn, of ’n beheerversoek hom bereik, en of weergawe begin sodra ’n stroom gekies is. Elke antwoord verwyder een stap van verdenking.
Toets dan elke stap direk eerder as om uitgangliggings te ruil. Om ’n VPN-land te verander, toets die mediapad en laat die ontdekking- en beheerstappe onaangeraak, so dit kan per ongeluk help terwyl dit jou niks leer nie.
Kyk aan die ontvanger se kant na sy eie roete en sy eie rekeningtoestand. ’n TV wat media deur ’n ander uitgang as die foon haal, is ’n normale ontwerp, en ’n fout daar is ’n vraag oor die ontvanger se netwerkbeleid eerder as oor die foon se tonnel.
Skryf die resultaat neer as een sin oor watter stap gebreek het en wat dit verander het. Daardie sin is meer werd as ’n week se lande ruil, en dit oorleef die volgende firmware-opdatering.
Casting is ’n goeie toetsgeval vir ’n algemene reël oor tonnels. Wanneer een by ’n netwerk gevoeg word, is die eerste vraag watter bestemmings nooit daar moes ingegaan het nie. Die tweede is watter van dié die beleid tog stilweg aanvaar het.