Чому трансляція перестає працювати після ввімкнення VPN на роутері
Виявлення йде через link-local multicast, а телевізор сам завантажує медіа. Правило за замовчуванням у політиці може перехопити запит LAN і надіслати його в тунель.
Трансляція працювала до ввімкнення VPN на роутері й перестає працювати одразу після, хоча звичайний перегляд сайтів на телефоні триває. Ці два факти узгоджуються, бо трансляція — не одне з'єднання. Телефон знаходить і керує приймачем у локальній мережі, а потім приймач завантажує медіа власним з'єднанням.
Два шляхи, що відмовляють по-різному
Шлях керування локальний. Телефон знаходить приймач, опитуючи локальну мережу, потім відкриває керівне з'єднання до вивченої адреси. Якщо приймач узагалі не з'являється в списку, етап виявлення зазнав невдачі ще до запиту будь-яких медіа.
Шлях медіа не обов'язково локальний. Багато приймачів завантажують потік самі, своїм з'єднанням і зі своїми обліковими даними, тому маршрут телефона не описує маршрут приймача. Телефон, який ніби користується одним виходом, нічого не каже про те, куди йде трафік телевізора.
Саме це розділення робить збій дивним. Тунель змінив таблицю маршрутизації телефона і не змінив таблицю телевізора, тому симптом, що проявився з одного боку пари, треба шукати саме з того боку. Перевірка не того пристрою — звичайна причина, чому виправлення ніби нічого не робить.
Чому виявлення ламається першим
Виявлення зазвичай іде через link-local multicast. mDNS надсилає на 224.0.0.251 через UDP-порт 5353, а SSDP — на 239.255.255.250 через UDP-порт 1900. Обидва за задумом обмежені одним сегментом, тому роутер не пересилає їх між сегментами без допомоги повторювача чи проксі. Маршрутизований VPN не розширює групу multicast, а маршрут політики не може змусити групу, яка ніколи не покидала сегмент, з'явитися в іншому.
Отже, перший збій не має стосунку до шифрування. Multicast телефона залишає інтерфейс, з якого його надіслано, приймач перебуває в сегменті, що його ніколи не бачить, і список пристроїв повертається порожнім. Порожній список не є доказом, що телевізор втратив доступ до інтернету.
Ізоляція дає ідентичний симптом і без жодного VPN. Гостьові мережі та ізоляція клієнтів на точці доступу навмисно не дають пристроям спілкуватися між собою, і ввімкнення VPN на роутері поверх ізольованого сегмента тут нічого не змінює. Перевірте налаштування ізоляції, перш ніж перевіряти тунель. Це дешевша відповідь і частіша.
Розкладка сегментів — друга половина. Другий роутер, mesh-вузол в іншому режимі або дротовий сегмент за іншим NAT ставлять приймач туди, куди трафік виявлення телефона не доходить.
Чому правило за замовчуванням може проковтнути локальний запит
Роутер, який спрямовує весь трафік у тунель, встановлює маршрут за замовчуванням на тунельному інтерфейсі. Якщо префікс LAN не виключений із цієї політики, пакет, адресований пристрою за два метри, тепер відповідає маршруту за замовчуванням, і роутер надсилає керівний запит у тунель, а не на комутатор.
| 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 |
Порядок правил вирішує результат. Маршрутизація за політикою оцінює правила за пріоритетом, тому виняток для локального префікса має стояти перед правилом, що вибирає тунельну таблицю. Додавання винятку після тунельного правила не дає ефекту, тому конфігурація, яка виглядає правильною, все одно може надсилати LAN-трафік на віддалений вихід.
Виправлення вузьке: дозвольте конкретні локальні призначення, потрібні потокові трансляції, і залиште решту ізоляції недоторканою. Видалення ізоляції клієнтів першим кроком лікує симптом, але відкидає контроль, який мережа мала за задумом.
Швидка перевірка на телефоні визначає, який із двох збоїв у вас. Якщо маршрут до приймача вказує на тунель, проблема в політиці. Якщо він вказує на LAN, а виявлення все одно не працює, проблема в multicast або ізоляції, і жодна зміна маршруту не допоможе.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpПеревіряйте змінений етап, а не країну
Записані спостереження кращі за повторні експерименти. Занотуйте, чи приймач з'являється в списку пристроїв, чи доходить до нього керівний запит і чи починається відтворення після вибору потоку. Кожна відповідь прибирає один етап із підозр.
Далі перевіряйте кожен етап безпосередньо, а не перемикайте вихідні точки. Зміна країни VPN перевіряє шлях медіа й залишає етапи виявлення та керування недоторканими, тому може випадково виглядати як допомога, нічого не навчивши.
З боку приймача перевірте його власний маршрут і стан його власного облікового запису. Телевізор, який завантажує медіа через інший вихід, ніж телефон, — це нормальна конструкція, а збій там стосується мережевої політики приймача, а не тунелю телефона.
Запишіть результат одним реченням: який етап зламався і що його змінило. Це речення варте більше за тиждень зміни країн і переживе наступне оновлення прошивки.
Трансляція — добрий тестовий випадок для загального правила про тунелі. Коли тунель додають у мережу, перше питання — які призначення ніколи не мали до нього потрапляти. Друге — які з них політика все ж мовчки прийняла.