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