Перестал работать IPTV

[kosyak_kpol]

Теперь, что касается трассировки источников мультикаста. У моего провайдера источники пингуются и, соответственно, трассируются. Первым хопом является провайдерский DHCP, вторым - некий "промежуточный" сервер (всегда один и тот же), а уже третьим - сам источник. То есть, с трассировкой моя и ваша ситуация отличаются кардинально. Здесь я ничего не могу предположить дельного, кроме как - поставить тот D-Link, что работает и пробовать с него трассировать. Если трассировка и/или пингу пойдут, то смотреть его маршруты. И сравнивать.

P.S. от 20.09.2020. В аспекте "разборок" с трассировкой, можно добавить в роуты (основную таблицу) статический маршрут до источника мультикаста, например, до 172.21.255.99/32 через bridge1 и посмотреть, начнёт ли трассироваться\пинговаться этот источник. А если начнёт, то проверить, пошла ли "картинка" от какого-нибудь канала этого источника. Например, "Первого канала". Это я уже гадаю "на кофейной гуще"

[Chupaka]

Да, именно так, цель моего предложения - именно проверить, что IGMP Proxy нормально работает с таким Src-адресом. Ведь объективно, это - всё, что принципиально поменялось в сравнении со старой схемой...

А вот трассировка вообще не имеет значения, она ж юникастом идёт, а нас мультикаст интересует. Более того, на роутер-то он приходит, так что проблема определённо локальная.

[kosyak_kpol]

Собрал я макет по проверочной схеме, предложенной ув. Chupaka.

Кстати, роутер взял точно такой же, как ваш... И, в итоге, получил точно такую же "картину маслом", как и у вас. На WAN udp-поток приходит, динамический маршрут в IGMP-proxy появляется, а в бридже: "тишина... и мёртвые с косами стоят".

Из того, что уже опробовано вами, так же ничего не помогло. Пришлось подумать и .... добавить в Мангл правило:

chain=prerouting action=change-ttl new-ttl=increment:1 passthrough=yes dst-address=224.0.0.0/4 log=no log-prefix=""

После этого, давно известного "колдовства" от "жадных провайдеров", в моём макете всё "заколосилось". Попробуйте и вы у себя.

P.S. Спасибо мэтру за хорошую "проверочную" идею. Я, по крайней мере, кое-что переосмыслил.
PP.SS. Достаточно инкрементировать TTL на единицу - исправил правило.

[Chupaka]

Семён Семёнович, ну!..

Вот что значит уже три года как из провайдинга ушёл... TTL - первое, на что надо было обратить внимание!

kosyak_kpol, спасибо за расследование (как хорошо совпало, что у VLC по умолчанию TTL единичка)

[kosyak_kpol]

.. как хорошо совпало, что у VLC по умолчанию TTL единичка

Верно, - я тоже об этом сразу подумал. Очень удачно...

[nefrid12]

Ну точно, я думал что можно через mangle, но не знал как. kosyak_kpol, Chupaka спасибо огромное за помощь. Заработало в общем.

[sugar]

Столкнулся со сложностями настройки iptv вроде всё просто на словах и по ютубу.

Подскажите в чем дело:
правила файрвола настроены.
на порт приходит iptv трафик, torch видит все мультикастовые группы на порту.
порт не входит ни в какой бридж, порт сам по себе.
Я настраиваю IGMP Proxy апстрим этот самый порт, даунстрим бридж локальной сети (192.168.0.0/24)
нет возможности проверить работу из бриджа прям на месте, роутер в другом городе у родственников.
дальше я подключаюсь к роутеру по l2tp/ipsec в настройках указываю бридж локальной сети и ожидаю, что мультикаст будет ходить.

и как то можно проверить мультикаст с роутера ?
есть ли какие нибудь особенности с l2tp и мультикастом?

[Chupaka]

Вы бридж в настройках профиля l2tp указываете? Подключаетесь другим микротиком?

[sugar]

да, бридж указываю.
подключаюсь не микротиком, а ПК с windows 10.

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

на соседнем форуме ответили, что Multicast doesn't transit a routing layer (as needed with L2TP) without help.
а помощь, это igmp proxy или pim sm.

[Chupaka]

Что-то помнится мне, что Windows не очень-то поддерживает BCP, нужный для такого бриджа: https://wiki.mikrotik.com/wiki/Manual:B ... _bridging)

Ну и тут вот https://wiki.mikrotik.com/wiki/Manual:P ... r_Profiles написано, что оба конца L2TP-тоннеля должны быть в бриджах, чтобы схема заработала.

[sugar]

хм, спасибо за инфу.
Интересно а в linux можно создать l2tp в bcp режиме ?
я тестирую в windows но хочу записывать трансляции в линукс, каких нибудь программ, чтобы потом смотреть.

т.е. поток мультикаст мне нужно забрать в линукс через l2tp ( ну или любой другой впн )

и ещё один момент. после подключения по l2tp у бриджа адрес 192.168.88.1 и он пингуется с клиента l2tp из windows т.е.
а вот если запустить tools-ping и выбрать интерфейс как бридж и пинговать ип клиента l2tp (192.168.88.100) то пинг не работает...

[Chupaka]

А этот клиент вообще в бридж добавляется? В Bridge -> Ports

[sugar]

нет, после подключения появляется новый интерфейс <l2tp-user1> и на этом всё. внутри бриджа ничего нет.

Сейчас попробую настроить l2tp так, чтобы обе точки были в бридже. т.е. с микротика chr в виртуалке настрою подключение к этому микротику. посмотрю как сработает настройка бриджа в l2tp (l2 transport protocol, который блин этот самый l2 и не пробрасывает ... капец, у меня разрыв шаблона, я свято верил в то, что он сможет это сделать при выборе стека технологий)

[sugar]

проверил теорию с пробросом мультикаста когда оба пира в бридже.
да! именно так!
когда l2tp в бридже на сервере и l2tp в бридже на клиенте, мультикаст доставляется без проблем. только весь канал забивает.

Можно же фильтровать мультикастовые группы и отправить в l2tp только пару каналов ?

[sugar]

а что может не нравится igmp proxy.
на вкладке mfc она видит группу и источник сигнала, а апстрим и даунстрим unknown ? это на том роутере куда приходит мультикаст.

[Chupaka]

На бриджах IGMP Snooping включен? Не совсем понятно, что там забивает весь канал. Неужели от провайдера идёт полный поток, даже когда никто ничего не смотрит?

[sugar]

после включения ничего не меняется.
и поток да, полный идет, не знаю как это возможно. но обслуживанием udp джойнов в мультикастовую группу должен заниматься igmp proxy?
потому сейчас трафик заливается до отказа и vlc не может воспроизвести ничего, wireshark говорит, что пакеты испорченные некоторые... как бы фильтрануть одну группу и всё... пока задача...
не пойму как работает преобразование multicast в unicast, чтобы пробросить только одну группу в l2tp

[Chupaka]

Ну и непонятно, почему igmp proxy пробрасывает весь поток с аплинка на даунлинк... У вас там точно аплинк не в бридже?

[sugar]

1. на одном из портов есть мультикаст трафик
2. у меня сейчас 2 микротика с л2тп впном в бриджах
3. если я включаю порт с мультикастом на первом микротике в бридж, то трафик сразу попадает в л2тп и частично долетает до бриджа второго микротика, но там канал пропускает меньше трафика, поэтому ничего не показывает vlc-player, wireshark видит что пакеты битые долетают, либо null пакеты
4. дальше я порт с мультикастом удаляю из бриджа на первом микротике и настраиваю там igmp proxy и всё, тишина. на вкладке mfc ничего нет, запросы udp join со второго микротика не доходят до igmp proxy первого микротика
5. затем я поднимаю igmp proxy на втором микротике, туда, судя по mfc, долетают запросы igmp но всё равно ничего не показывает плеер, он постоянно ищет сигнал и wireshark не показывает запросов с трафиком mpeg и т.п.
6. igmp snooping почему то не прекращает подачу мультикаста даже если он никому не нужен.

не понимаю как нужно правильно использовать igmp proxy в такой схеме.

я думаю, что igmp proxy должна быть настроена на первом микротике там где мультикастовый порт источник сигналов. и отдавать только нужные каналы по запросу в l2tp впн на второй микротик.. верно думаю ?

[Chupaka]

Да, я тоже за такую схему.

4. а локальные клиенты первого микротика могут проверить, работает ли у них? Я бы попробовал выключить IGMP Snooping на бриджах по пути (как минимум на втором роутере), посмотреть, долетают ли IGMP-запросы до первого. Ну и правила файрвола. Как помню, для работы зачем-то надо в фильтре файрвола разрешать мультикастовый трафик как в input, так и в forward.

[sugar]

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

[sugar]

получилось получить мультикаст через igmp proxy.
создал отдельный бридж со своей адресацией на первом роутере, поместил туда л2тп сервер биндинг и настроил igmp
прописал маршруты на обоих микротиках в 224.0.0.0/4 через l2tp интерфейсы. и полетел только тот трафик, который я запросил, а не весь мультикаст, который есть на аплинке.

вопрос в следующем wireshark говорит что пакеты битые, нифига толком не показывает. думаю на mtu или может ещё что-то нужно тюнить ?

[sugar]

блин... всё дело было в тестовом chr.
прокачал его до 1гбита на порту и пошло дело.

в общем решил свою задачу вроде, всем спасибо!

[kosyak_kpol]

получилось получить мультикаст через igmp proxy.
создал отдельный бридж со своей адресацией на первом роутере, поместил туда л2тп сервер биндинг и настроил igmp
прописал маршруты на обоих микротиках в 224.0.0.0/4 через l2tp интерфейсы. и полетел только тот трафик, который я запросил, а не весь мультикаст, который есть на аплинке.

вопрос в следующем wireshark говорит что пакеты битые, нифига толком не показывает. думаю на mtu или может ещё что-то нужно тюнить ?

Здравствуйте, sugar.

1. А зачем вы создаёте отдельный бридж? Думаю, что это - лишняя сущность. Достаточно просто подключить ваш vpn-интерфейс в существующий igmp-proxy как downstream-interface. Тогда, компьютер с Windows, на котором поднят vpn-клиент, будет нормально получать запрашиваемый канал. Естественно, роутер, на котором поднят vpn-server, должен натить vpn-клиента. А vpn-клиент, - работать через "шлюз в удалённой сети". Тогда vpn-клиент автоматически получит доступ в "дальнюю" сеть источников мультикаста. Такая схема работает. Проверено (с pptp-vpn). Однако, это моё замечание сути вопроса не меняет. Его можно рассматривать как оптимизацию.

2. Честно говоря, не стал вникать зачем нужны дополнительные маршруты "в 224.0.0.0/4". Если сделаете, как в п.п.1, то они не нужны. Но, наверное, вы лучше знаете, что делаете.

3. Думаю, что mtu тоннеля тут "не при делах". Так как скорее всего, провайдер мультикаста отдаёт потоки в виде mpeg-ts, у которого, вероятно, стандартный размер пакета, составляющий 188 байт (можно и нужно проверить). Такой пакет должен нормально "ходить" через vpn-канал.

Что касается "пакеты битые, нифига толком не показывает": если у вас канал "междугородний", то нормального чистого потока вы, скорее всего, не получите. Насколько показывают мои наблюдения, провайдер в своей сети достаточно строго приоритезирует мультикаст, чего на вашей "междугородке" быть не может. Ну, можно поиграть с vpn-ом: отключить шифрование, например, если включено.

[kosyak_kpol]

и ещё один момент. после подключения по l2tp у бриджа адрес 192.168.88.1 и он пингуется с клиента l2tp из windows т.е.
а вот если запустить tools-ping и выбрать интерфейс как бридж и пинговать ип клиента l2tp (192.168.88.100) то пинг не работает...

Включите на бридже arp-proxy.
Из вашего описания не ясно, работает ли ваш vpn-клиент на ПК с W10 в отдельном адресном пространстве на "дальнем" роутере или вы назначаете ему адрес из подсети бриджа. Так вот, если из подсети бриджа, то - arp-proxy на этом бридже исправит ситуацию с "обратным пингом".