Multicast forward/routing Linux, OpenBSD (iptv).

/*

в эпоху модемов с поддержкой V.22 (1,200 бит/с) даже думать о потоковом контенте было страшно. времена меняются и в медвежьи берлоги вламываются результаты "электрификации всей стганы" с более-менее приемлимыми тарифными планами. при этом вполне оправдано появление устройств из категории "домашние роутеры", принимающих канал доступа в internet/локалку от провайдера и раздающих ресурсы грубо говоря "на всю квартиру". зачастую эту функцию берут на себя старенькие компы уровня Pentium-Pentium III под управлением Linux/OpenBSD. при этом зачастую Провайдер даёт выход в сеть internet при помощи vpn/dsl туннеля/подключения, а мультикаст (как например услуга iptv - потокового вещания видео) "крутится" в сегменте "локальной" сети. ниже постараюсь описать принципы настройки роутера для работы в данных условиях. материал не претендует на исчерпывающее изложение и какую-либо оригинальность. здесь не будет готовых рецептов - только общие рекомендации. если Вам понравилось или есть чем дополнить - милости прошу оставить комментарий.


***********************************************

намеренно оставил за рамками роутеры на FreeBSD, так как imho (хотел бы ошибаться, но практика, Господа...) эта система не содержит механизмов, позволяющих нормально решать вопросы динамического роутинга/форварда мультикаста одновременно с NAT-ом, о чём честно предупреждает handbook:

31.2.8 Multicast Routing

FreeBSD supports both multicast applications and multicast routing natively. Multicast applications do not require any special configuration of FreeBSD; applications will generally run out of the box. Multicast routing requires that support be compiled into the kernel:

options MROUTING

In addition, the multicast routing daemon, mrouted(8) must be configured to set up tunnels and DVMRP via /etc/mrouted.conf. More details on multicast configuration may be found in the manual page for mrouted(8).

Note: As of FreeBSD 7.0 the mrouted(8) multicast routing daemon has been removed from the base system. It implements the DVMRP multicast routing protocol, which has largely been replaced by pim(4) in many multicast installations. The related map-mbone(8) and mrinfo(8) utilities have also been removed. These programs are now available in the FreeBSD Ports Collection as net/mrouted.

также стоит помнить, что сам по себе демон "mrouted" морально устарел (Ben, it's dead! RIP...) и не рекомендован к использованию при наличии альтернатив.

***********************************************


OpenBSD

тут всё очень просто и понятно. сам механизм прекрасно документирован:

OpenBSD Multicasting

"dvmrpd" работает практически без нареканий и не вызывает трудностей при конфигурировании. также доступен и "старый" mrouted, если вдруг по каким-то причинам Вас не устроит dvmrpd. что-то добавить к замечательно изложенному материалу желания не возникает.


Linux

именно тот случай, когда обилие "оболочек"/(сиречь дистрибутивов) плодит анархию. начну с кратенького обзора специальных девайсов, разработанных в качестве роутеров для домашней сети.

вне зависимости от "железа" основную роль тут играют "прошивки". они могут быть закрытыми ("фирменными", что предустановлены на заводе-изготовителе) или открытыми (как dd-wrt, прошивки Олега для ASUS-ов и т.п.). с задачей форварда/роутинга мультикаста "из коробки" на отлично справляются лишь прошивки от Олега (вне зависимости от наличия vpn соединения). по крайней мере до сего дня dd-wrt содержали баг в ядре и в исходниках igmpproxy, препятствующий нормальному функционированию. подробности.

рассмотрим пример конфигурации роутера:

eth0 - интерфейс к локальной сети Провайдера (пусть будет сеть 10.0.0.0/8), обозначим как $IF_IN
ppp0 - vpn туннель с выходом в internet, обозначим как $IF_VPN
eth1 - интерфейс к "домашней" сети (адреса в пределах 192.168.1.0/24), обозначим как $IF_OUT

для "домашних роутеров" схема конфига осложняется тем, что в качестве eth1 (интерфейса к "домашней" подсети) выступает (как правило) бридж (br0), объединяющий Ethernet и Wireless интерфейсы (ессно при наличии этого самого wifi).

теперь немного чтива для любознательных:

общее описание мультикаста (English Wiki)

1. Multicast over TCP/IP HOWTO - старый, но добрый хау-ту.

2. Multicast Routing Code in the Linux Kernel - тоже не Откровение, но даёт понятие о (как минимум) двух стоящих внимания "хомячка" переменных:

/proc/net/ip_mr_vif - список интерфейсов, вовлечённых в обмен мультикаст пакетами
/proc/net/ip_mr_cache - текущий статус MFC (Multicast Forwarding Cache - кэш мультикаст пакетов)

3. Configuring Linux For Network Multicast - начальные сведения о конфигурации Linux ядра для роутинга мультикаста.

собсно с конфигурирования ядра и начнём. в обязательном порядке нам нужны следующие опции:

CONFIG_IP_ADVANCED_ROUTER=y (или же CONFIG_IP_ROUTER=y)
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=y

кроме того может возникнуть необходимость проконтролировать (cat имя_файла) и/или изменить (echo $ЗНАЧЕНИЕ > имя_файла) некоторые дополнительные параметры:

разрешаем форвард ipv4 пакетов:

$ cat /proc/sys/net/ipv4/conf/default/forwarding
1

разрешаем форвард мультикаста:

$ cat /proc/sys/net/ipv4/conf/[ $IF_IN | $IF_OUT ]/mc_forwarding
1

отключаем reverse path filtering:

$ cat /proc/sys/net/ipv4/conf/$IF_IN/rp_filter
0

для ядер 2.6.* может потребоваться принудительное указание "типа"/версии igmp пакетов (варианты значений - 0, 1 или 2, описание есть в исходниках ядра - /usr/src/linux/net/ipv4/igmp.c):

$ cat /proc/sys/net/ipv4/conf/[ $IF_IN | $IF_OUT ]/force_igmp_version
{0,1,2}


с ядром более-менее разобрались, остался вопрос к прикладному софту. потребуется:

iptables
igmpproxy
пакеты "net-tools" (route, traceroute) и "iproute2" (ip) для управления маршрутами/(роутинг)
tcpdump/wireshark для мониторинга


в роли igmpproxy может выступить pimd или проприетарный gated (эт если из пушки да по воробьям засадить...). есть ещё smcroute, но оно умеет только "статику" (не наш метод). ещё на просторах сети где-то бродят сборки "родного" древнего многострадального mrouted-а с патчами для Linux. не будем ворошить труп. RIP.

для начала на роутере очищаем все цепочки iptables (flush) и рисуем что-то типа:

-A INPUT -d 224.0.0.0/240.0.0.0 -p 2 -j ACCEPT # некоторые опускают ключ -d 224.0.0.0/240.0.0.0 и разрешают весь входящий igmp трафик
-A INPUT -d 224.0.0.0/240.0.0.0 -p udp -m udp ! --dport 1900 -j ACCEPT
-A FORWARD -d 224.0.0.0/240.0.0.0 -p udp -j ACCEPT

также можно включить некоторую страховку от сволочной и шкурной натуры Провайдера, принудительно увеличив TTL мультикаст-потока на одну единичку при прохождении нашего роутера (а то особо умные принудительно на мультикаст ставят TTL == 1, чтобы потешить ЧСВ, не иначе):

-t mangle -A PREROUTING -d 224.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1


после чего делаем тупой конфигурационный файл (читаем man!) для igmpproxy (вместо значений переменных $IF_IN/$IF_OUT подставить имена соответствующих интерфейсов ессно):

$ cat /etc/igmpproxy.conf

# good things to begin with :)
quickleave

phyint $IF_IN upstream
altnet 0.0.0.0/0

phyint $IF_OUT downstream


и запускаем демона (от рута):

# igmpproxy -c /etc/igmpproxy.conf


для того, чтобы тело взлетело осталось лишь правильно настроить роутинг/(маршрутизацию). здесь надо помнить, что источники выдачи сигнала могут присутствовать помимо указанных в плейлисте того же iptv. т.е. кроме собсно мультикаста (net 224.0.0.0/240.0.0.0 ) источник может иметь "левые" ip-ы типа 88.210.40.0/24, 77.94.170.0/24 и т.п.. это легко отслеживается tcpdump-ом/wireshark-ом если непосредственно на роутере стартануть VLC или MPlayer, собранный с поддержкой live555 и получить "картинку" видео. роутинг к этим "левым" адресам должен идти через $IF_IN, не затрагивая $IF_VPN! объясняться подобный "казус" может довольно просто. Провайдер зачастую делает пиринг с теми, кто держит нехилые "фермы", раздающие сам трафик, что и приводит к появлению в локальной сети (Провайдера) подобных "левых" адресов. или же "фермам" присваивают адреса "от фонаря". другими словами адрес, что прописан в плейлисте - это адрес для JOIN/LEAVE ("подписки" и "выписки" из мультикаст-группы), а сам источник udp потока может приползти откуда угодно.

напоследок могу лишь посоветовать посматривать на статистику $IF_IN при пользовании igmpproxy. известно, что [далеко] не всегда "отписка" проходит корректно и это вполне может забить канал рано или поздно (при активной смене каналов вы быстро заметите если что-то пойдёт не так...).

удачи.

*/

SuSE: иного нет у нас пути...

/*
-М-м-м-у-у-у-у!!!
-Шо за "му"?! Опять нажрался, свинота?!

начну с элементарного - русификации консоли (tty/mingetty) в современных SLE/SuSE. где-то с версии SuSE-9.1 "проблема" как-бы исчезла полностью благодаря поддержке UTF-8, но как и что делать вроде никто в отдельную заметку не выносил. по поводу русификации ранних версий есть отличная статейка:

Русификация SuSE 9

но увы и ах - "бойянЪ". задача раскладывается на три составляющие (при условии, что Ваша "локаль" уже задана в /etc/sysconfig/language как RC_LANG="en_US.UTF-8" или RC_LANG="ru_RU.UTF-8"):

1) выбрать "правильный" шрифт (содержащий UTF-8 символы кириллицы как минимум).

чешем в "/usr/share/kbd/consolefonts/" и выбираем тот, который нравится больше всего. после чего вносим его в "/etc/sysconfig/console" как шрифт по умолчанию (пример):

CONSOLE_FONT="UniCyr_8x16.psf.gz"
CONSOLE_MAGIC="(K"

2) задаём UTF-8 кодировку терминала для вывода символов, отличных от ASCII, в "/etc/sysconfig/console":

CONSOLE_ENCODING="UTF-8"

3) выбираем подходящую "раскладку" и "переключалку" (доступные варианты можно просмотреть в /usr/share/kbd/keymaps/i386/qwerty/) и вносим её в "/etc/sysconfig/keyboard" (пример с переключением по правому ALT-у):

KEYTABLE="ru1_win-utf.map.gz"

кроме этого тут же можно установить "шорткат" для переключения между активными терминалами (например по кнопке "Win"):

COMPOSETABLE="clear winkeys"

завершающий штрих - рестарт сервиса "kbd":

/sbin/service kbd restart

после чего можно смело переключиться в "чистую" консоль (Ctl+Alt+F1) и оценить результат.
mission сукесфули комплитед.



Девушки бывают разные:
чёрные, белые, красные...

SuSE/SLE довольно специфичный дистрибутив, ибо содержит огромное количество "вкусностей", недоступных остальным "из коробки". это требует от пользователя определённого знания системы и вырианты решений тех или иных задач могут существенно отличаться (в этом-то и проявляется специфика). где-то эдак годика с 2005-го SuSE включила в базовую поставку системы свою собственную "надстройку" (называйте как хотите - "морда", гуй и т.п.) для управления пакетным фильтром iptables - SuSEfirewall, что до сих пор, imho, остаётся лучшим решением по управлению трафиком.

вся настройка идёт путём правки единственного файла:

$ sudo vim /etc/sysconfig/SuSEfirewall2

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

$ sudo /sbin/SuSEfirewall2 stop
$ sudo /sbin/SuSEfirewall2 start

анализ эффективных цепочек правил легче всего делать при помощи:

$ sudo /usr/sbin/iptables-save | less

"черновую" настройку можно набросать в "гуях" YAST-а:

$ gksu yast2 -> Security and Users -> Firewall

после чего настоятельно рекомендую ввести изменения в силу и в дальнейшем редактировать "/etc/sysconfig/SuSEfirewall2" вручную. особая ценность решения от SuSE в том, что оно не накладывает никаких ограничений "творческой мысли" при редактировании цепочек. если Вы не осилили предлагаемые готовые "пресеты", то никто не запрещает указать:

FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"

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

основным преимуществом использования SuSEfirewall можно считать чётко структурированный подход к работе цепочек фильтрации. по сути это одно большое наглядное практическое пособие о том, как Правильно работать с iptables. весь трафик сперва делится на "зоны" - DMZ, "внешний"/external, "внутренний"/internal, lo - с возможностью определить дополнительные при желании - wlan и т.п.. после чего для каждой "зоны" создаётся отдельная "цепочка" эффективных правил, фильтрующая весь трафик. также идёт прямое указание на загрузку необходимых Вам модулей ядра (пример):

FW_LOAD_MODULES="nf_conntrack_netbios_ns xt_conntrack xt_owner \
xt_iprange xt_CONNMARK xt_limit xt_TCPMSS xt_state\
nf_conntrack_ftp nf_nat_ftp"

в результате мы получаем красивую и логичную схему действующих правил, которая ещё и минимизирует издержки при обработке трафика благодаря stateful природе пакетного фильтра. суть stateful пожалуй можно перевести как установление "статуса" активного соединения и разбору дальнейших пакетов на его основе. т.е. если какое-то соединение признано валидным/состоявшимся, то оно получает статус ESTABLISHED/(установлено), после чего весь соответствующий ему трафик обрабатывается на основе этого статуса, "минуя" цепочки фильтрации. рассмотрим простой пример, наглядно демонстрирующий преимущества решений SuSE:

> sudo iptables-save -t raw

*raw
:PREROUTING ACCEPT [38828:15020523]
:OUTPUT ACCEPT [36327:4135365]
-A PREROUTING -i lo -j NOTRACK
-A OUTPUT -o lo -j NOTRACK
COMMIT

(параметр FW_LO_NOTRACK="yes")

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

-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

здесь мы "синхронизируем" активное соединение с MSS (Maximum Segment Size in TCP), тем самым предотвращая пересылку слишком больших пакетов, требующих насильственного "деления".

рассмотрим далее упрощённый вариант того, что у нас творится в основных "цепочках" таблицы filter (как пример, без наворотов типа DMZ или специальных "зон" - ситуация "из коробки" так сказать...):

> sudo iptables-save -t filter | less

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:forward_ext - [0:0]
:forward_int - [0:0]
:input_ext - [0:0]
:input_int - [0:0]
:reject_func - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m state --state RELATED -j ACCEPT
-A INPUT -i tap0 -j input_int
-A INPUT -i eth1 -j input_ext
-A INPUT -i wlan1 -j input_ext
-A INPUT -i wmaster0 -j input_ext
-A INPUT -j input_ext
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i tap0 -j forward_int
-A FORWARD -i eth1 -j forward_ext
-A FORWARD -i wlan1 -j forward_ext
-A FORWARD -i wmaster0 -j forward_ext
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options
-A FORWARD -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-OUT-ERROR " --log-tcp-options --log-ip-options
*********************
**** прочее обрезано
*********************

нет никакого бардака. определены пять "функции" (отдельные цепочки правил для обработки трафика):

:forward_ext - [0:0]
:forward_int - [0:0]
:input_ext - [0:0]
:input_int - [0:0]
:reject_func - [0:0]

и весь траф поделён на "зоны":

int - "внутренний" - внутри локальной сети
ext - "внешний" - трафик из сетей, которые мы не контролируем (интернет и т.п.)

нетрудно заметить, что к "внутренней" зоне отнесён лишь один сетевой интерфейс - tap0. все остальные интерфейсы работают с "внешним" трафиком. нра? то-то...

для "краткого курса молодого бойца" необходимо и достаточно ознакомиться со следующим файлом:

> vim /usr/share/doc/packages/SuSEfirewall2/EXAMPLES

где дают исчерпывающие примеры по начальной конфигурации пакетного фильтра путём редактирования любимого файла "/etc/sysconfig/SuSEfirewall2". описывают восемь "сценариев":

1. Simple dialup
2. Small home network
3. Small home network with additional WLAN
4. Small company with external mail and web server
5. Company with IPsec tunnel to subsidiary
6. Company with web server in DMZ
7. Complex scenario
8. Laptop in private network but with additional public IP adresses

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

ISP предлагает тариф, позволяющий "качать" порно на скорости 768kbit/s, а вот "отдавать" трафик можно лишь на скорости в 256kbit/s. при этом возможна ситуация, когда при активной "отдаче" вы заметите "паралич" загружаемых файлов. лечение (при условии, что Вы на впн соединении с интерфейсом dsl0):

FW_HTB_TUNE_DEV="dsl0,250"

тут мы при помощи HTB режем исходящий трафик и резервируем 6kbit/s на "технические" нужды (пакеты TCP ACK или interactive SSH).

по умолчанию (для EXT зоны) зарезан broadcast и multicast. это может быть неудобно, поэтому внимательно смотрим на следующие переменные:

FW_ALLOW_FW_BROADCAST_EXT="no"
FW_ALLOW_FW_BROADCAST_INT="no"
FW_ALLOW_FW_BROADCAST_DMZ="no"
# ниже мы игнорируем логирование "дропнутых" ранее броадкастов
FW_IGNORE_FW_BROADCAST_EXT="yes"
FW_IGNORE_FW_BROADCAST_INT="yes"
FW_IGNORE_FW_BROADCAST_DMZ="yes"

для broadcast пакетов имеет смысл лишь открыть определённые порты, т.е. разрешить лишь выбранным приложениям принимать их. для multicast сперва надо ознакомиться с содержимым файла /etc/protocols, после чего уже разрешать определённые протоколы (например):

FW_SERVICES_EXT_IP="GRE MTP PIM"

и/или цепляем FW_CUSTOMRULES=файл_с_ручными_правками_правил, где рисуем:

iptables -A INPUT -j ACCEPT -d 224.0.0.0/24

тем самым разрешая "входящий" мультикаст на все протоколы/интерфейсы.

не будет лишним обратить внимание на:

FW_KERNEL_SECURITY="yes"

этот параметр включает некоторые скрытые защитные механизмы ядра (icmp_ignore_bogus_error_responses, icmp_echoreply_rate, icmp_destunreach_rate, icmp_paramprob_rate, icmp_timeexeed_rate, ip_local_port_range, log_martians, rp_filter, routing flush, bootp_relay, proxy_arp, secure_redirects, accept_source_route, icmp_echo_ignore_broadcasts, ipfrag_time)

если у вас большая и "шаловливая" локалка, то имеет смысл сделать:

FW_REJECT="no"
FW_REJECT_INT="no"

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

имеет смысл как страховку от тупого DDOS-а выставить

FW_ALLOW_FW_SOURCEQUENCH="no"

тут мы "вырезаем" атаку по icmp которая возможна, при следующем условии:

-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT

но теряем на оповещении о статусе соединения от ISP (ежели он соизволит оное раздать ессно, что далеко не факт...)

последняя стадия "Enlightenment-а"/(сиречь Просветления, Мудрости и Духовной Силы) - это прямое редактирование скрипта, ведающего формированием цепочек правил:

> sudo vim /sbin/SuSEfirewall2

тут уж "вольному - воля". кто смел духом - дерзайте (бэкап оригинала не забудьте сохранить на всякий).

Use SuSE, Luke!