SSM поверх OpenVPN: проследить один источник и группу от начала до конца

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

Сначала зафиксируйте источник, группу и получателя

Запишите три значения, прежде чем касаться любого устройства: адрес источника, который будет отправлять, адрес группы, к которой присоединится получатель, и подсеть, в которой находится получатель. Для иллюстративного потока IPv4 источник 10.50.0.10 и группа 232.20.30.40 — как раз та пара, которая подходит для дизайна, специфичного для источника. Всё, что менее определённо, чем эти три значения, проверить нельзя.

Диапазон 232/8 зарезервирован для multicast, специфичного для источника, а модель описана в RFC 4607. Если ваша группа находится за пределами этого диапазона, а вы считаете, что запускаете SSM, остановитесь и подтвердите, что на самом деле имеет в виду развёртывание, потому что присоединение получателя и решение маршрутизатора о пересылке оба зависят от согласованности модели.

Проверьте, что получатель присоединился к источнику

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

На получателе Linux проверьте, на что сокет действительно подписался и что записало ядро. Файл конфигурации приложения не является доказательством; доказательством является таблица членства. Читайте её, пока получатель действительно работает, потому что запись может задержаться ненадолго после выхода создавшего её процесса. Устаревшая запись из более раннего теста — надёжный источник ложной уверенности.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Если присоединение есть с ожидаемым источником, переходите к маршрутизаторам. Если его нет, никакая настройка туннеля не поможет, потому что пересылать нечего.

Проверьте обратный путь, прежде чем смотреть на туннель

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

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

Затем подтвердите, что TTL источника достаточно велик, чтобы пережить спроектированные маршрутизируемые переходы. Поток, который работает на первом маршрутизаторе и умирает на втором, часто является вопросом TTL, а не политики.

Читайте состояние multicast в ядре, а не конфигурацию

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

Когда эти двое не совпадают, чините хост, а не VPN. Ничто ниже по потоку не компенсирует переход, который не пересылает поток, о котором вы спрашивали. Записывайте пару, входящий интерфейс и исходящий список для каждого перехода, пока поток работает. Эта запись превращает следующий отказ в сравнение, а не в новое расследование.

Решите, как туннель на самом деле реплицирует

Здесь multicast поверх VPN перестаёт быть рутиной. Туннель «точка-точка» доставляет пакет единственному партнёру на другом конце, поэтому копия доходит ровно до одного клиента. Сегмент, объединённый мостом, ведёт себя скорее как общий канал, потому что туннель несёт кадр, а мост решает, что затапливать. Это разные модели доставки, и дизайн, который предполагает вторую, работая по первой, будет выглядеть рабочим для одного получателя и откажет для следующего.

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

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