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