Защо прехвърлянето към телевизора спира след включване на рутер 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 тества медийния път и оставя етапите на откриване и контрол непокътнати, така че може случайно да изглежда, че помага, без да ви научи на нищо.
От страната на приемника проверете собствения му маршрут и състоянието на собствения му акаунт. Телевизор, който изтегля медия през друга изходна точка, различна от телефона, е нормален дизайн, а отказ там е въпрос за мрежовата политика на приемника, а не за тунела на телефона.
Запишете резултата като едно изречение за това кой етап се е счупил и какво го е променило. Това изречение струва повече от седмица смяна на държави и оцелява след следващата актуализация на фърмуера.
Прехвърлянето е добър тестов случай за общо правило за тунелите. Когато такъв се добави към мрежа, първият въпрос е кои дестинации никога не е трябвало да влизат в него. Вторият е кои от тях политиката все пак е приела мълчаливо.