Чаму трансляцыя спыняецца пасля ўключэння VPN на роўтары
Выяўленне ідзе праз лакальны multicast, а тэлевізар сам загружае медыя. Палітыка па змаўчанні можа перахапіць запыт лакальнай сеткі і адправіць яго ў тунель.
Трансляцыя працавала да ўключэння VPN на роўтары і перастае адразу пасля, пры гэтым звычайны прагляд на тэлефоне працуе далей. Гэтыя два факты не супярэчаць адзін аднаму, бо трансляцыя — не адно злучэнне. Тэлефон знаходзіць прымач і кіруе ім праз лакальную сетку, а прымач потым загружае медыя праз уласнае злучэнне.
Два шляхі, якія ламаюцца па-рознаму
Шлях кіравання лакальны. Тэлефон знаходзіць прымач, запытваючы лакальную сетку, а потым адкрывае злучэнне кіравання на адрас, які даведаўся. Калі прымач ніколі не з’яўляецца ў спісе, этап выяўлення зламаўся яшчэ да таго, як былі запытаны медыя.
Шлях медыя не абавязкова лакальны. Многія прымачы загружаюць паток самі, праз уласнае злучэнне і са сваімі ўліковымі данымі, таму маршрут тэлефона не апісвае маршрут прымача. Тэлефон, які нібыта выходзіць праз адзін выхад, нічога не кажа пра тое, куды ідзе трафік тэлевізара.
Менавіта гэтае раздваенне робіць збой дзіўным. Тунель змяніў табліцу маршрутызацыі тэлефона і не змяніў табліцу тэлевізара, таму сімптом на адным баку пары трэба шукаць на гэтым баку. Пошук на няправільнай прыладзе — звычайная прычына таго, што выпраўленне нібыта нічога не дае.
Чаму выяўленне ламаецца першым
Выяўленне звычайна ідзе праз лакальны multicast. mDNS адпраўляе на 224.0.0.251 праз UDP-порт 5353, а SSDP адпраўляе на 239.255.255.250 праз UDP-порт 1900. Абодва паводле задумы абмежаваныя адным звяном, таму роўтар не перадае іх паміж сегментамі без паўтаральніка або проксі. Маршрутызаваны VPN не пашырае групу multicast, і маршрут палітыкі не можа зрабіць так, каб група, якая ніколі не пакідала звяно, з’явілася на іншым.
Такім чынам, першы збой не мае нічога агульнага з шыфраваннем. Multicast тэлефона пакідае інтэрфейс, на які быў адпраўлены, прымач знаходзіцца ў сегменце, які яго ніколі не бачыць, і спіс прылад вяртаецца пустым. Пусты спіс не даказвае, што тэлевізар страціў доступ да інтэрнэту.
Ізаляцыя дае такі ж сімптом без удзелу VPN. Гасцёвыя сеткі і ізаляцыя кліентаў на кропках доступу наўмысна перашкаджаюць прыладам размаўляць адна з адной, і ўключэнне VPN на роўтары паверх ізаляванага сегмента нічога ў гэтым не змяняе. Праверце наладу ізаляцыі раней, чым тунель. Гэта таннейшы адказ і больш часты.
Другая палова — гэта размяшчэнне сегментаў. Другі роўтар, вузел mesh у іншым рэжыме або правадны сегмент за іншым NAT — усё гэта змяшчае прымач там, куды трафік выяўлення тэлефона не даходзіць.
Чаму палітыка па змаўчанні можа паглынуць лакальны запыт
Роўтар, які накіроўвае ўвесь трафік у тунель, усталёўвае маршрут па змаўчанні на інтэрфейсе тунеля. Калі прэфікс лакальнай сеткі не выключаны з гэтай палітыкі, пакет, адрасаваны прыладзе за два метры, цяпер адпавядае маршруту па змаўчанні, і роўтар адпраўляе запыт кіравання ў тунель замест камутатара.
| 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 |
Парадак правілаў вызначае вынік. Маршрутызацыя палітыкі ацэньвае правілы ў парадку прыярытэту, таму выключэнне для лакальнага прэфікса павінна стаяць перад правілам, якое выбірае табліцу тунеля. Даданне выключэння пасля правіла тунеля не дае эфекту, таму канфігурацыя, якая выглядае правільнай, усё роўна можа адпраўляць лакальны трафік на аддалены выхад.
Выпраўленне вузкае: дазвольце пэўныя лакальныя адрасы, патрэбныя для трансляцыі, і пакіньце астатнюю ізаляцыю як ёсць. Калі зняць ізаляцыю кліентаў першым крокам, сімптом знікне, але разам з ім знікне і кантроль, для якога сетка была спраектавана.
Хуткая праверка на тэлефоне пакажа, які з двух збояў у вас. Калі маршрут да прымача паказвае ў тунель, праблема ў палітыцы. Калі ён паказвае ў лакальную сетку, а выяўленне ўсё яшчэ не працуе, праблема ў multicast або ізаляцыі, і ніякае змяненне маршруту не дапаможа.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpТэстуйце этап, які змяніўся, а не краіну
Закрэпленыя назіранні лепшыя за паўтораныя эксперыменты. Запішыце, ці з’яўляецца прымач у спісе прылад, ці даходзіць да яго запыт кіравання і ці пачынаецца прайграванне пасля выбару патоку. Кожны адказ здымае адзін этап з падазрэння.
Затым правярайце кожны этап наўпрост, а не перамыкайце выхады. Змена краіны VPN тэстуе шлях медыя і пакідае этапы выяўлення і кіравання некранутымі, таму яна можа выпадкова выглядаць як дапамога, нічому не вучачы вас.
З боку прымача праверце яго ўласны маршрут і стан уліковага запісу. Тэлевізар, які загружае медыя праз іншы выхад, чым тэлефон, — гэта звычайная канструкцыя, і збой там ставіць пытанне пра сеткавую палітыку прымача, а не пра тунель тэлефона.
Запішыце вынік адным сказам пра тое, які этап зламаўся і што яго змяніла. Гэты сказ каштоўнейшы за тыдзень перамыкання краін, і ён перажыве наступнае абнаўленне прашыўкі.
Трансляцыя — добры тэст для агульнага правіла пра тунелі. Калі тунель дадаюць у сетку, першае пытанне — якія адрасы не павінны былі ў яго трапіць. Другое — якія з іх палітыка ўсё ж моўчкі прыняла.