Почему multicast не проходит через VPN без плана

Два сайта могут идеально достигать друг друга через unicast и всё же вести себя так, будто один из них не видит объявление обнаружения принтера, поток IPTV или пульс кластера. Это не сломанный туннель; это разница между адресатом и группой. Для доставки multicast нужна модель членства, состояние пересылки вдоль пути и интерфейс, готовый нести трафик, и ничего из этого не берётся из unicast-маршрута. Пройти от группы приложения до одного работающего получателя — самый короткий путь к ответу.

Начните с группы и приложения

Спросите, какой адрес группы использует приложение и для чего нужен трафик. Протокол обнаружения, объявляющий службы, потоковый канал и пакеты приветствия протокола маршрутизации — это три разные задачи с тремя разными приемлемыми ответами. Сам адрес группы говорит об области: адреса в блоке управления локальной сети не предназначены для пересылки за пределы канала обычной маршрутизацией, а приложения, которые их используют, обычно предполагают один широковещательный домен. Потоковый канал на группе с глобальной областью — это другой проект, чем протокол обнаружения, который ждёт, что каждое устройство услышит каждый запрос, и только второму важнее размер широковещательного домена.

Решите, требуется ли служба или механизм обнаружения, потому что эти ответы различаются по стоимости на порядок. Один просит адрес, который не меняется; другой просит широковещательный домен, растянутый через канал глобальной сети со всем, что из этого следует.

Локальное обнаружение должно остановиться

Multicast DNS, описанный в RFC 6762, построен вокруг одного канала: запросы идут к фиксированной группе, ответы отправляются в ту же группу, и протокол полагается на то, что каждый участник слышит всех. Маршрутизаторы не пересылают такой трафик по умолчанию, и это проектное решение, а не недосмотр. Граница существует для того, чтобы устройство в одном здании не могло запросто объявить себя в другом. Туннель, который якобы чинит обнаружение, перенося группу повсюду, снял эту границу для каждого приложения, а не только для того, которому нужна была помощь.

Повторители и отражатели существуют, и это настоящие службы с настоящими последствиями: каждое имя, объявленное на одном сайте, становится видимым на другом, включая имена устройств, идентифицирующие людей или оборудование. Если настоящее требование в том, чтобы конкретная служба была находимой, запись службы, опубликованная в DNS, обычно меньшее изменение, и она раскрывает одно имя вместо их потока.

Три вещи, которые нужны маршрутизируемому multicast

Маршрутизируемому multicast нужны три вещи, работающие вместе: получатели, вступающие в группу, маршрутизаторы, поддерживающие для неё состояние пересылки, и туннель, который обращается с адресами группы как с трафиком, который нужно нести. Туннель с политикой, где перечислены только unicast-подсети, отбросит трафик группы на границе шифрования, и поэтому первым симптомом часто бывает тишина, а не ошибка. Интерфейс на основе маршрутов, например туннель GRE или VTI, несёт то, что в него отправляет таблица маршрутизации, и это делает группу достижимой, как только состояние multicast существует.

Достижимость источника — вторая половина. Протоколы маршрутизации multicast, такие как PIM, строят деревья распределения, проверяя, что обратный путь к источнику ожидаемый, поэтому unicast-маршрут, указывающий в другое место, ломает дерево даже при правильном членстве в группе. Установка маршрута для получателя ничего не даёт этой проверке, и это та ошибка, которая даёт работающий ping и падающий поток. Сначала проверьте обратный путь источника, затем добавьте членство и только потом смотрите на приложение.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Первые две строки показывают, к чему присоединился хост и что пересылает ядро, третья показывает членство самого приложения, а последняя — unicast-путь, который будет использовать проверка обратного пути. Совместное чтение отличает приложение, которое никогда не присоединялось, от сети, которая никогда не пересылала.

Докажите это одним источником и одним получателем

Прежде чем трогать конфигурацию, убедитесь, что приложение работает в одном сегменте. Если оно сбоит локально, маршрутизация multicast ни при чём и никакое изменение туннеля не поможет. Затем повторите с одним получателем через туннель и понаблюдайте за пакетами по обе стороны границы шифрования.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Пакеты, видимые внутри туннеля, но отсутствующие снаружи, указывают на инкапсуляцию или политику; пакеты, видимые с обеих сторон без прогресса приложения, указывают на членство получателя или привязку приложения. Держите записи короткими и отфильтрованными, потому что широкий захват multicast на загруженном сегменте — это в основном шум.

Выбирайте адрес службы, когда нужна только служба

Обнаружение существует, чтобы найти то, что перемещается. Серверу со стабильным именем обнаружение не нужно, а задокументированный адрес в частном DNS отвечает на настоящий вопрос пользователя, не растягивая широковещательный домен через канал глобальной сети. Те же рассуждения применимы к принтерам, бытовым приборам и внутренним веб-службам. Имя в DNS достижимо из каждого сайта, которому оно нужно, ничего не объявляя сайтам, которым оно не нужно, и оно продолжает работать, когда устройство заменяют другим с другим адресом.

Когда протокол действительно требует multicast, ограничьте его группой и сайтами, которым он нужен, задокументируйте почему и пересмотрите решение, когда приложение изменится. Растянуть обнаружение повсюду легко один раз и трудно отменить после года устройств, которые тихо от него зависят.