LINUX.ORG.RU
решено Форум — Admin  

Передача IpTV в другую сеть.

 , , ,


0

2

Приветствую ЛОР!
Прошу помощи разобраться в следующем:
Имеется:
Сеть №1 с IpTV от провайдера.
IP cервера вещания у провайдера 10.8.0.136
Группа multicast 239.0.0.0/8
В сети установлен шлюз с Ubuntu на борту.
eth0 - 94.73.222.31 (интерфейс смотрящий в строну провайдера)
tun10 - 192.168.47.1 (IP over IP туннель с сетью №2)

Сеть №2
Шлюз сети на Ubuntu
eth0 - (192.168.0.254) локалка за шлюзом
eth1 - (91.230.41.211) инет от провайдера
tun10 - 192.168.47.2 (IP over IP туннель с сетью №1)
На обоих шлюзах iptables стоит в режиме ACCEPT по всем фильтрам.

Задача:
Забрать IpTV из сети №1 и отдать эти потоки в сеть №2 используя туннель между сетями.
Выбор пал на igmpproxy т.к в большинстве хардварных хоум-роутеров именно он отдает IpTV своим клиентам, причем отдает отлично.
Поехали:
Туннель поднят, маршрутизация в туннеле работает, сервера видят друг друга отлично, сеть 192.168.0.0/24 видит сервер на другом конце туннеля отлично.
На шлюзе из Сети №1 IpTV показывает.
Поставил igmpproxy на шлюз из сети №1 со следующим конфигом: 

quickleave
##------------------------------------------------------
## Configuration for eth0 (Upstream Interface)
##------------------------------------------------------
phyint eth0 upstream  ratelimit 0  threshold 1
        altnet 10.0.0.0/8
        altnet 224.0.0.0/8
        altnet 239.0.0.0/8
##------------------------------------------------------
## Configuration for eth1 (Downstream Interface)
##------------------------------------------------------
phyint tun10 downstream  ratelimit 0  threshold 1
##------------------------------------------------------
## Configuration for eth2 (Disabled Interface)
##------------------------------------------------------
phyint eth2 disabled
На шлюзе из Сети №2 поставил igmpproxy со следующим конфигом: 
##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
##------------------------------------------------------
## Configuration for eth0 (Upstream Interface)
##------------------------------------------------------
phyint tun10 upstream  ratelimit 0  threshold 1
        altnet 10.0.0.0/8
        altnet 224.0.0.0/8
        altnet 239.0.0.0/8
##------------------------------------------------------
## Configuration for eth1 (Downstream Interface)
##------------------------------------------------------
phyint eth0 downstream  ratelimit 0  threshold 1
##------------------------------------------------------
## Configuration for eth2 (Disabled Interface)
##------------------------------------------------------
phyint tap0 disabled
phyint ppp0 disabled
phyint virbr0 disabled
phyint vnet0 disabled
phyint br0 disabled
Пытаюсь посмотреть какой-нибудь из каналов на компе из сети 192.168.0.0/24 - не катит. Плейлист взят у провайдера с которого хотим забрать IpTV.
Сталкиваюсь с этим в первый раз, поэтому прошу сильно не пинать.
Где я что-то не доделал?
Говорите что нужно показать.
Буду рад любой помощи.

★

wireshark что показывает? Должно быть подрубание к multicast group.

Да и плиз файрвол, на всякий случай проверь.

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

Со стороны Сети №2 запускаю на шлюзе tcpdump (wireshark никогда не юзал) 

root@net2:/home/cemka# tcpdump igmp -i tun10 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun10, link-type RAW (Raw IP), capture size 96 bytes
14:55:19.800075 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 5 group record(s)
14:55:24.372573 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:55:24.660080 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:26.400073 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:27.479517 IP 94.73.222.31 > 224.0.0.1: igmp query v2
14:55:27.483901 IP 94.73.222.31 > 224.0.0.2: igmp v2 report 224.0.0.2
14:55:28.850075 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:29.610072 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:31.500074 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:33.441328 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:34.540073 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:35.941326 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:37.710076 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:37.730080 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:42.400075 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:55:46.190083 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:47.390075 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 3 group record(s)
14:55:50.020077 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:50.590071 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s)

Со стороны сети №1 на шлюзе так же: 
root@net1:~# tcpdump igmp -i tun10 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun10, link-type RAW (Raw IP), capture size 65535 bytes
14:55:18.901906 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 5 group record(s)
14:55:23.474132 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:55:23.761655 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:25.501567 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:26.580294 IP 94.73.222.31 > 224.0.0.1: igmp query v2
14:55:26.584675 IP 94.73.222.31 > 224.0.0.2: igmp v2 report 224.0.0.2
14:55:27.951446 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:28.711403 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:30.601305 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:32.542481 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:33.641163 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:35.042343 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:36.810980 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:36.831023 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:41.500784 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:55:45.290618 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:46.490587 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 3 group record(s)
14:55:49.120429 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 2 group record(s)
14:55:49.690389 IP 192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:55:58.461462 IP 94.73.222.31 > 224.0.0.1: igmp query v2
14:56:02.948707 IP 94.73.222.31 > 224.0.0.2: igmp v2 report 224.0.0.2


Файрволл на шлюзе сети№1: 

root@net1:~# iptables-save
# Generated by iptables-save v1.4.12 on Tue Oct  8 14:58:55 2013
*nat
:PREROUTING ACCEPT [2202:399806]
:INPUT ACCEPT [1499:360950]
:OUTPUT ACCEPT [909:64026]
:POSTROUTING ACCEPT [893:62946]
-A POSTROUTING -s 192.168.47.0/24 -j SNAT --to-source 94.73.222.31
COMMIT
# Completed on Tue Oct  8 14:58:55 2013
# Generated by iptables-save v1.4.12 on Tue Oct  8 14:58:55 2013
*filter
:INPUT ACCEPT [92956:51655401]
:FORWARD ACCEPT [84451:87831910]
:OUTPUT ACCEPT [159273:220351028]
-A INPUT -d 224.0.0.0/4 -i eth0 -j ACCEPT
-A INPUT -d 239.0.0.0/8 -i eth0 -j ACCEPT
-A FORWARD -d 224.0.0.0/4 -p udp -j ACCEPT
-A FORWARD -d 239.0.0.0/8 -p udp -j ACCEPT
COMMIT
# Completed on Tue Oct  8 14:58:55 2013
root@net1:~#

Файрволл на шлюзе сети 2 

root@net2:/home/cemka# iptables-save
# Generated by iptables-save v1.4.4 on Tue Oct  8 15:00:05 2013
*mangle
:PREROUTING ACCEPT [2542291880:2172824247174]
:INPUT ACCEPT [897919048:880443055146]
:FORWARD ACCEPT [1643924402:1291994395611]
:OUTPUT ACCEPT [755357507:450389972866]
:POSTROUTING ACCEPT [2399403615:1742365030912]
COMMIT
# Completed on Tue Oct  8 15:00:05 2013
# Generated by iptables-save v1.4.4 on Tue Oct  8 15:00:05 2013
*filter
:INPUT ACCEPT [897918965:880443052446]
:FORWARD ACCEPT [1643863012:1291907189619]
:OUTPUT ACCEPT [755142903:450331493845]
-A INPUT -i tun10 -j ACCEPT
-A FORWARD -i tun10 -j ACCEPT
COMMIT
# Completed on Tue Oct  8 15:00:05 2013
# Generated by iptables-save v1.4.4 on Tue Oct  8 15:00:05 2013
*nat
:PREROUTING ACCEPT [28697405:2269320556]
:POSTROUTING ACCEPT [17354359:1258379587]
:OUTPUT ACCEPT [18751728:1364859349]
-A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
-A POSTROUTING -s 192.168.5.0/24 -j MASQUERADE
-A POSTROUTING -s 192.168.253.0/24 -j MASQUERADE
COMMIT
# Completed on Tue Oct  8 15:00:05 2013


Мб какие-то маршруты нужно прописывать? иль где-то нат для какой-то сети включить?

CeMKa ★
() автор топика
Ответ на: комментарий от CeMKa

Со стороны Сети №2 запускаю на шлюзе tcpdump (wireshark никогда не юзал)

Wireshark этот грубо говоря тот же tcpdump только графический и с опциями -vvv . В нем даже пакеты подкрашиваются(если красный значит что то не так, удобно одним словом) .

По файрволам выруби на втором все и посмори что получается. Отпишись по результам.

P.S Я щас сам подбираю софт которые их multicasta перегоняет в http unicast , просто потому, что младшие инженеры, боюсь не осилят настройку igmp на модемах клиентах + не понятно как с мультаксом дела обстоят у всех новомодных smart tv.

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

дома установлен udpxy. работает больше года. нареканий нет

cac2s ★
()
Ответ на: комментарий от CeMKa

а зачем Вам это: 

-A POSTROUTING -s 192.168.47.0/24 -j SNAT --to-source 94.73.222.31

cac2s ★
()
Ответ на: комментарий от sergej

а разве igmp proxy не подменяет адрес подписчика, оставляя snat на совести iptables?

если так, то зачем тогда трогать altnet?..

или я чего-то не понимаю?

cac2s ★
()
Последнее исправление: cac2s (всего исправлений: 1)
Ответ на: комментарий от cac2s

Я особо не разбирался, но пока я не узнал, что мой провайдер шлет iptv с 192.168.13.0/24 и не добавил эту сеть в конфиг оно не работало.

sergej ★★★★★
()
Ответ на: комментарий от sergej

как я понимаю [возможно и неправильно =) ]

altnet отвечает как раз за апстрим-сети, а у ТСа апстримом всегда должна быть 239.0.0.0/8, т.е. с неё будуть лететь udp с видео.

таким образом с проблемной сети (№2) будет отправляться запрос на 192.168.0.254, на этой карточке igmpproxy будет подменять ip подписчика на tun0-ip (не путать с nat'ом) и форвардить в tun0

на сервере №1 igmpproxy слушает запросы клиентов на своём tun0. при получении запроса, делает так же, как и igmpproxy_№2, только форвардит в wan (так же подменяя адрес подписчика на свой wan-ip)

поэтому и не понятно мне зачем nat'ить пакеты на tun0...

cac2s ★
()
Последнее исправление: cac2s (всего исправлений: 2)

Попробуй udpxy, уже писали выше, юзаю уже больше года, TV смотрю в том числе и в дугих подсетях (на работе :)) через VPN, ,без замечаний.

aeX1pu2b ★
()
Ответ на: комментарий от cac2s

апстримом всегда должна быть 239.0.0.0

это мультикаст сеть. Лететь будет в неё, а не из неё. И именно в апстриме надо указаь source ip для этих мультикаст пакетов.

если всё будет совсем плохо - да, udpxy тоже работает

sergej ★★★★★
()
Последнее исправление: sergej (всего исправлений: 1)
Ответ на: комментарий от CeMKa

Всем еще раз привет! Проблему решил совсем банально,из сети №2 сделал: 

route add -net 10.0.0.0/8 gw 192.168.47.1
и все взлетело. Видать надо как-то «стучать» на iptv сервер провайдера, чтоб он тебя включил в группу рассылки 239.0.0.0.
Поэтому и стоит: 
-A POSTROUTING -s 192.168.47.0/24 -j SNAT --to-source 94.73.222.31

Насчет udpxy - в инете много положительных отзывов, но мне как-то не хочется переписывать плейлист провайдера, темболее он у них частенько меняется.
Еще раз всем спасибо!!!

CeMKa ★
() автор топика
Ответ на: комментарий от CeMKa

а что там сложного в переписывании для udpxy? 

sed -e 's/^udp:\/\/\@/http:\/\/my_server:8888\/udp\//' -i playlist.m3u
плейлист ложишь у себя на веб-сервере и отдаешь лок. клиентам его url, а не url провайдера

cac2s ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin