Трансляцыя спыняецца пры VPN: выяўленне, кіраванне ці паток?
Адсутны прыёмнік, адхілены сеанс і паток, які затынаецца, зрываюцца ў розных месцах. Назавіце этап, перш чым змяняць палітыку VPN на тэлефоне або сетку.
Трансляцыя ламаецца ў трох месцах, якія з канапы выглядаюць аднолькава. Тэлефон можа так і не ўбачыць прыёмнік, прыёмнік можа з'явіцца і потым адхіліць сеанс, або сеанс можа пачацца і затыніцца праз хвіліну. Тунель на тэлефоне змяняе кожны з гэтых шляхоў па-рознаму, а для аднаго з іх не змяняе нічога. Спачатку назавіце этап, які зрываецца, і толькі потым вырашайце, ці змена палітыкі ўвогуле з'яўляецца тым рычагом, які варта цягнуць.
Назавіце этап, які зрываецца, перш чым змяняць палітыку
Паглядзіце, што тэлефон робіць адразу пасля націску на значок трансляцыі. Пусты спіс — гэта вынік выяўлення, націск, які паведамляе пра збой, — вынік кіравання, а сеанс, які пачынаецца перад затынаннем, — вынік прайгравання. У гэтых трох розныя ўладальнікі, і звычайна толькі першыя два датычаць налад тунелю на тэлефоне.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Запішыце этап, перш чым нешта змяняць. Выпраўленне, ужытае да няправільнага этапу, робіць наступны тэст нечытэльным, і большасць паданняў пра трансляцыю паходзіць менавіта з гэтай блытаніны.
Выяўленне — гэта лакальны трафік, і тунель хавае яго
Прыёмнікі абвяшчаюць сябе праз лакальныя анонсы, і тэлефон знаходзіць іх запытамі ў тым жа сегменце, таму ўсё, што прыбірае тэлефон з гэтага сегмента, прыбірае прыёмнік са спісу. Тунель, які накіроўвае ўвесь трафік у абыход LAN, можа схаваць гэтыя абмены, а дазвол на лакальную сетку ўзроўню праграмы можа блакаваць іх нават тады, калі маршрут існуе. Гасцявы Wi-Fi з ізаляцыяй кліентаў дае такі ж пусты спіс наогул без VPN. Дакажыце, што дзве прылады падзяляюць сегмент, перш чым вінаваціць тунель.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR
Першая каманда пералічвае тое, што абвяшчае сябе ў сегменце дапаможнай машыны, а другая пытае групу multicast DNS наўпрост. Прыёмнік, адсутны ў абодвух, таксама не з'явіцца ў праграме на тэлефоне, якім бы ні быў стан тунелю. Калі прыёмнік бачны з прылады з выключаным тунелем і нябачны з прылады з уключаным, вы знайшлі этап і прычыну разам.
Выключэнне для LAN пакідае тунель уключным
Многія кліенты прапануюць выключэнне для лакальнай сеткі, якое пакідае тунель актыўным, дазваляючы лакальныя адрасы. Карыстайцеся гэтай дакументаванай наладай, а не адключайце kill switch ці ўвесь файрвол, бо яны змяняюць значна больш, чым патрэбна трансляцыі. Калі сетка наўмысна раздзяляе разумныя прылады, папрасіце ўладальніка пра канкрэтны трафік выяўлення, кіравання і вяртання, а не пра плоскі доступ.
nc -vz 192.168.1.50 8009
Тэст кіравання супраць прыёмніка аддзяляе дазвол ад дасягальнасці: порт, які адказвае, азначае, што шлях існуе, а адмова азначае, што тэлефону дазволілі выявіць прыладу і ён усё роўна не можа з ёй размаўляць. Парты 8008 і 8009 — звычайныя парты трансляцыі, і праграма можа выкарыстоўваць іншыя, таму лічыце адзін адхілены порт падказкай, а не прысудам. Выключэнне і дазвол праграмы застаюцца незалежнымі, бо лакальны доступ не стварае маршрут, а даданне маршруту не дае дазволу. Kill switch можа таксама скінуць лакальны трафік пасля перападключэння, таму выяўленне трэба пераправерыць, як толькі тунель вернецца.
Прайграванне можа не выкарыстоўваць злучэнне тэлефона
У сеансе, якім кіруе праграма, тэлефон перадае прыёмніку адрас медыя, і прыёмнік загружае яго праз уласнае злучэнне, таму змена публічнага адраса тэлефона нічога не робіць для патоку. Загаловак, абмежаваны ўліковым запісам, можа ўсё роўна зваліцца па сваіх прычынах, а патрабаванні да трансляцыі ад Google тычацца сумяшчальнасці праграмы і прылады, а не сеткавага шляху. Маршрутызацыя самога тэлевізара праз тунель — гэта асобная канфігурацыя з уласнымі пытаннямі палітыкі.
Дзве падказкі адрозніваюць рэжымы. Трансляцыя, якая перажывае блакіроўку экрана тэлефона, кіруецца праграмай, бо прыёмнік загружае сам; люстраванне, якое спыняецца, калі экран адпраўніка блакуецца, — гэта бесперапынны паток з тэлефона. Калі выяўленне і кіраванне ўдаюцца, а прайграванне затынаецца, глядзіце замест гэтага на Wi-Fi-злучэнне прыёмніка і яго шлях у інтэрнэт, бо тэст хуткасці на тэлефоне апісвае тэлефон, а не тэлевізар.
Адмяніце выключэнне і пераправерце
Кожная часовая змена патрабуе шляху назад, і парадак важны. Прыбярыце выключэнне для LAN, перападключыце тунель, каб кліент зноў ужыў сваю палітыку, затым паўтарыце крок выяўлення і адзначце, ці знікне прыёмнік зноў. Гэтая паслядоўнасць кажа, ці рабіла працу выключэнне, ці паміж справамі змянілася нешта іншае.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'
Пасля гэтага праверце тры этапы асобна, бо паспяховы праход аднаго нічога не кажа пра іншыя. Затым праверце, што староннія праграмы на тэлефоне па-ранейшаму ідуць патрэбным маршрутам, бо лакальнае выключэнне, якое ціха стала поўным абыходам, горш за трансляцыю, якой патрэбны адзін лішні націск.