OpenVPN рассылает multicast каждому клиенту, а не подписчикам

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

Три вопроса внутри одного заявления о функции

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

Держите их раздельно, когда оцениваете размер канала. Только третий вопрос задаёт бюджет исходящего трафика на стороне сервера.

Что сервер в пользовательском пространстве делает с групповым пакетом

В традиционном сервере в пользовательском пространстве OpenVPN 2.6 приходящий пакет broadcast или multicast классифицируется на входном пути TUN/TAP и передаётся процедуре широковещательного разветвления, а не поиску по группе. Эта процедура обходит экземпляры клиентов, пропускает отправителя и любой остановленный экземпляр, применяет свою проверку VLAN там, где она настроена, и ставит копию в очередь для каждого оставшегося клиента. Ни один шаг в этом цикле не обращается к таблице членства. Это репликация в стиле broadcast, и это весь механизм.

Считайте это свойством того пути кода, а не универсальным законом. Ускоренные пути данных, другие реализации и разные версии могут вести себя иначе, и ничто из этого не делает TAP требованием или исправлением.

Спланируйте копии, прежде чем что-либо измерять

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

ip -s link show tun0

Прочитайте счётчик отправленных байтов до и после фиксированного интервала с одним известным активным отправителем. Разделите на интервал и сравните со скоростью полезной нагрузки, умноженной на число клиентов. Число, близкое к скорости одного потока, означает, что репликация ограничена; число, близкое к умноженной скорости, означает, что каждая клиентская система получает копию.

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

Тест с двумя клиентами, который решает вопрос охвата

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

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

Затем поменяйте роли. Если результат следует за получателем, а не за группой, вы смотрите на что-то, учитывающее членство, и прежнее предположение было ошибочным в вашу пользу.

Выбор ограниченной схемы вместо снятия ограничений

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

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

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