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