Kodėl transliavimas nustoja veikti įjungus maršrutizatoriaus VPN
Aptikimas vyksta link-local multicast, o televizorius mediją atsisiunčia pats. Politikos numatytasis maršrutas gali pagauti LAN užklausą ir nusiųsti ją į tunelį.
Transliavimas veikė prieš įjungiant maršrutizatoriaus VPN ir iš karto po to sugenda, o įprastas naršymas telefone vis dar veikia. Šie du faktai neprieštarauja vienas kitam, nes transliavimas nėra viena jungtis. Telefonas randa ir valdo imtuvą vietiniame tinkle, o paskui imtuvas mediją atsisiunčia savo jungtimi.
Du keliai, kurie sugenda skirtingai
Valdymo kelias yra vietinis. Telefonas randa imtuvą paklausęs vietinio tinklo, tada atidaro valdymo jungtį į sužinotą adresą. Jei imtuvas sąraše niekada nepasirodo, aptikimo etapas žlugo dar neprašius jokios medijos.
Medijos kelias nebūtinai vietinis. Daugelis imtuvų srautą atsisiunčia patys, savo jungtimi ir savo prisijungimo duomenimis, todėl telefono maršrutas neaprašo imtuvo maršruto. Telefonas, kuris atrodo naudojantis vieną išėjimą, nieko nesako apie tai, kur eina televizoriaus srautas.
Dėl šio atskyrimo gedimas atrodo keistai. Tunelis pakeitė telefono maršrutų lentelę, o televizoriaus nepakeitė, todėl simptomą, pasireiškusį vienoje poros pusėje, reikia tirti toje pusėje. Netinkamo įrenginio tyrimas yra įprasta priežastis, kodėl pataisymas atrodo nieko nedarantis.
Kodėl aptikimas sugenda pirmas
Aptikimas paprastai vyksta link-local multicast. mDNS siunčia į 224.0.0.251 UDP prievadu 5353, o SSDP siunčia į 239.255.255.250 UDP prievadu 1900. Abu pagal konstrukciją apriboti viena jungtimi, todėl maršrutizatorius jų nepersiunčia tarp segmentų be kartotuvo ar tarpinio serverio pagalbos. Maršrutuojamas VPN neišplečia multicast grupės, o politikos maršrutas negali priversti grupės, kuri niekada nepaliko jungties, pasirodyti kitoje.
Todėl pirmasis gedimas neturi nieko bendra su šifravimu. Telefono multicast palieka sąsają, kuria buvo išsiųstas, imtuvas yra segmente, kuris jo niekada nemato, ir įrenginių sąrašas grįžta tuščias. Tuščias sąrašas nėra įrodymas, kad televizorius neteko interneto prieigos.
Izoliacija sukuria identišką simptomą ir be jokio VPN. Svečių tinklai ir prieigos taško klientų izoliacija sąmoningai neleidžia įrenginiams kalbėtis tarpusavyje, o maršrutizatoriaus VPN įjungimas izoliuotame segmente nieko to nekeičia. Patikrinkite izoliacijos nustatymą prieš tikrindami tunelį. Tai pigesnis atsakymas ir dažnesnis.
Segmentų išdėstymas yra kita pusė. Antras maršrutizatorius, kitame režime veikiantis mesh mazgas ar laidinis segmentas už kito NAT visi padeda imtuvą ten, kur telefono aptikimo srautas nepasiekia.
Kodėl numatytasis politikos maršrutas gali praryti vietinę užklausą
Maršrutizatorius, nukreipiantis visą srautą į tunelį, tunelio sąsajoje įdiegia numatytąjį maršrutą. Jei LAN priešdėlis nepašalintas iš šios politikos, paketas, adresuotas įrenginiui už dviejų metrų, dabar atitinka numatytąjį maršrutą, ir maršrutizatorius valdymo užklausą siunčia į tunelį, o ne į komutatorių.
| 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 |
Taisyklių tvarka lemia rezultatą. Politikos maršrutizavimas vertina taisykles prioriteto tvarka, todėl vietinio priešdėlio išimtis turi būti prieš taisyklę, pasirenkančią tunelio lentelę. Išimties pridėjimas po tunelio taisyklės neturi poveikio, todėl teisingai atrodanti konfigūracija vis tiek gali siųsti LAN srautą į nuotolinį išėjimą.
Pataisymas siauras: leiskite konkrečius vietinius tikslus, kurių reikia transliavimo srautui, o likusią izoliaciją palikite nepaliestą. Klientų izoliacijos pašalinimas kaip pirmas žingsnis išgydo simptomą, bet atmeta kontrolę, kurią tinklas turėjo pagal konstrukciją.
Greita patikra telefone nustato, kuris iš dviejų gedimų pas jus. Jei maršrutas į imtuvą rodo į tunelį, problema yra politikoje. Jei rodo į LAN, o aptikimas vis tiek žlunga, problema yra multicast arba izoliacija, ir joks maršruto pakeitimas nepadės.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTikrinkite pasikeitusį etapą, o ne šalį
Užrašyti stebėjimai vertingesni už kartotinius eksperimentus. Pažymėkite, ar imtuvas pasirodo įrenginių sąraše, ar valdymo užklausa jį pasiekia ir ar atkūrimas prasideda pasirinkus srautą. Kiekvienas atsakymas pašalina vieną etapą iš įtarimų.
Tada tikrinkite kiekvieną etapą tiesiogiai, o ne kaitaliokite išėjimo vietas. VPN šalies keitimas tikrina medijos kelią, o aptikimo ir valdymo etapus palieka nepaliestus, todėl gali atrodyti, kad padeda atsitiktinai, nieko neišmokydamas.
Imtuvo pusėje patikrinkite jo paties maršrutą ir jo paskyros būseną. Televizorius, kuris mediją atsisiunčia kitu išėjimu nei telefonas, yra normali konstrukcija, o gedimas ten yra klausimas apie imtuvo tinklo politiką, o ne apie telefono tunelį.
Užrašykite rezultatą vienu sakiniu apie tai, kuris etapas sugedo ir kas jį pakeitė. Tas sakinys vertas daugiau nei savaitė šalių kaitaliojimo ir išlieka po kito programinės įrangos atnaujinimo.
Transliavimas yra geras bendros taisyklės apie tunelius bandymas. Kai tunelis pridedamas prie tinklo, pirmas klausimas yra kurie tikslai niekada neturėjo į jį patekti, o antras – kuriuos iš jų politika vis tiek tyliai priėmė.