Трансляція через VPN: виявлення, керування чи потік?

Трансляція ламається в трьох місцях, які з дивана виглядають однаково. Телефон може так і не побачити приймач, приймач може з'явитися і потім відхилити сеанс, або сеанс може початися і завмерти за хвилину. Тунель на телефоні змінює кожен із цих шляхів по-різному, а для одного з них не змінює нічого. Спершу назвіть етап, що відмовив, а потім вирішуйте, чи зміна політики взагалі є правильним важелем.

Назвіть етап, що відмовив, перш ніж змінювати політику

Подивіться, що телефон робить одразу після натискання на значок трансляції. Порожній список — це результат виявлення, натискання з повідомленням про помилку — результат керування, а сеанс, який починається і лише потім завмирає, — результат відтворення. У цих трьох різні власники, і зазвичай лише перші два стосуються налаштувань тунелю телефона.

Запишіть етап, перш ніж щось змінювати. Виправлення, застосоване не до того етапу, робить наступну перевірку нечитабельною, і більшість історій про трансляцію походить саме з цієї плутанини.

Виявлення — це локальний трафік, і тунель його ховає

Приймачі оголошують про себе локальними анонсами, а телефон знаходить їх запитами в тому самому сегменті, тож усе, що прибирає телефон із цього сегмента, прибирає приймач зі списку. Тунель, що виводить увесь трафік за межі 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'

Потім перевірте три етапи окремо, бо успіх на одному нічого не каже про інші. Далі переконайтеся, що сторонні застосунки на телефоні досі йдуть заданим маршрутом, бо локальний виняток, який тихо став повним обходом, гірший за трансляцію, що потребує одного зайвого натискання.