Wêrom casting ophâldt te wurkjen nei it ynskeakeljen fan de router-VPN
Ûntdekking giet oer lokaal multicast, wylst de televyzje de media sels hellet. In standertbelied kin it LAN-fersyk pakke en yn de tunnel stjoere.
Casting wurke foardat de router-VPN ynskeakele waard en mislearret daliks dêrnei, wylst gewoan browsen op de telefoan noch wurket. De beide feiten binne ferienichber, want casting is net ien ferbining. De telefoan ûntdekt en bestjoert de ûntfanger oer it lokale netwurk, en de ûntfanger hellet dêrnei de media oer syn eigen ferbining.
Twa paden dy’t ferskillend mislearje
It bestjoeringspaad is lokaal. In telefoan fynt in ûntfanger troch it lokale netwurk te freegjen en iepenet dan in bestjoeringsferbining nei it adres dat er leard hat. As de ûntfanger nea yn de list ferskynt, is de ûntdekkingsstap mislearre foardat der media oanfrege waard.
It mediapaad is net needsaaklik lokaal. In protte ûntfangers helje de stream sels, oer har eigen ferbining en mei har eigen bewiis, sadat de rûte fan de telefoan de rûte fan de ûntfanger net beskriuwt. In telefoan dy’t ien útgong liket te brûken, seit neat oer wêr’t it ferkear fan de televyzje hinne giet.
Dy splitsing is de reden dat de flater frjemd liket. De tunnel feroare de routingtabel fan de telefoan en net dy fan de televyzje, dus in symptoom dat oan ien kant fan it pear ferskynt, moat oan dy kant folge wurde. It ferkearde apparaat folgje is de gewoane reden dat in reparaasje liket neat te dwaan.
Wêrom ûntdekking earst brekt
Ûntdekking giet meastentiids oer link-lokaal multicast. mDNS stjoert nei 224.0.0.251 op UDP-poarte 5353, en SSDP stjoert nei 239.255.255.250 op UDP-poarte 1900. Beide binne neffens ûntwerp ta ien link beheind, en dêrom stjoert in router se net tusken segminten troch sûnder help fan in repeater of in proxy. In routed VPN wreidet in multicast-groep net út, en in beliedsrûte kin in groep dy’t de link nea ferlitten hat, net op in oare ferskine litte.
Dat de earste flater hat dus neat mei fersifering te meitsjen. It multicast fan de telefoan ferlit de ynterface wêrop it stjoerd waard, de ûntfanger sit op in segmint dat it nea sjocht, en de apparaatlist komt leech werom. In lege list is gjin bewiis dat de televyzje de ynternetstagong kwytrekke is.
Isolearring jout itselde symptoom sûnder hokker VPN dan ek. Gastnetwurken en kliïntisolearring op tagongspunten foarkomme mei opsetsin dat apparaten mei elkoar prate, en in router-VPN boppe op in isolearre segmint ynskeakelje feroaret dêr neat oan. Kontrolearje de isolearringsynstelling foardat jo de tunnel kontrolearje. Dat is it goedkeapere antwurd en it meast foarkommende.
De yndieling fan segminten is de oare helte. In twadde router, in mesh-knooppunt yn in oare modus of in bedraaid segmint efter in oare NAT sette de ûntfanger allegear earne dêr’t it ûntdekkingsferkear fan de telefoan net komt.
Wêrom in standertbelied in lokaal fersyk opslokke kin
In router dy’t al it ferkear yn in tunnel liedt, ynstallearret in standertrûte op de tunnelinterface. As it LAN-prefiks net fan dat belied útsletten is, past in pakket nei in apparaat twa meter fierder no op de standert, en de router stjoert it bestjoeringsfersyk de tunnel yn ynstee fan nei de switch.
| 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 |
De oarder fan regels beskiedt it resultaat. Beliedsrouting beöardielet regels yn prioriteitsfoaroarder, dus in útsûndering foar it lokale prefiks moat foar de regel ferskine dy’t de tunneltabel kiest. It tafoegjen fan de útsûndering nei de tunnelregel hat gjin effekt, en dêrom kin in konfiguraasje dy’t korrekt liket noch hieltyd LAN-ferkear nei in fiere útgong stjoere.
De reparaasje is smal: stean de spesifike lokale bestimmings ta dy’t de castingstream nedich hat, en lit de rest fan de isolearring gewurde. Kliïntisolearring as earste stap fuorthelje makket it symptoom goed, mar smyt in kontrôle wei dy’t it netwurk ûntwurpen wie om te hawwen.
In flugge kontrôle op de telefoan beslist hokker fan de twa flaters jo hawwe. As de rûte nei de ûntfanger nei de tunnel wiist, is it belied it probleem. As er nei it LAN wiist en ûntdekking mislearret noch, is multicast of isolearring it probleem, en gjin rûteferoaring sil helpe.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTest de stap dy’t feroare, net it lân
Fêstleine waarnimmings binne better as werhelle eksperiminten. Notearje oft de ûntfanger yn de apparaatlist ferskynt, oft in bestjoeringsfersyk him berikt en oft de wjerjefte begjint as in stream keazen is. Elk antwurd hellet ien stap út de fertinking.
Test dêrnei elke stap direkt ynstee fan útgongslokaasjes te wikseljen. In VPN-lân feroarje test it mediapaad en lit de ûntdekkings- en bestjoeringsstappen ûnoantaast, dus it kin by tafal helpe lykje sûnder jo wat te learen.
Kontrolearje oan de ûntfangerskant syn eigen rûte en syn eigen akkountstatus. In televyzje dy’t media oer in oare útgong hellet as de telefoan is in normaal ûntwerp, en in flater dêr is in fraach oer it netwurkbelied fan de ûntfanger, net oer de tunnel fan de telefoan.
Skriuw it resultaat op as ien sin oer hokker stap bruts en wat dy feroare. Dy sin is mear wurdich as in wike lannen wikselje, en hy oerlibbet de folgjende firmware-update.
Casting is in goed testgefal foar in algemiene regel oer tunnels. As der ien oan in netwurk tafoege wurdt, is de earste fraach hokker bestimmings der nea yn komme moatten hiene. De twadde is hokker dêrfan it belied dochs stilwei akseptearre hat.