Страницы

Показаны сообщения с ярлыком routing. Показать все сообщения
Показаны сообщения с ярлыком routing. Показать все сообщения

четверг, 9 января 2014 г.

6to4 IPv6 tunnel на Mikrotik RB951G-2HnD

Настройка IPv6 в домашней сети


Желание передать большой семейный видеофайл частным образом с помощью torrent-протокола привело к понимаю, что необходимо настроить наконец-то белую адресацию домашнего компьютера и перестать мучаться.
Провайдеры в России уже начинают предоставлять доступ по протоколу ipv6, в том числе и мобильные провайдеры, так что можно уже начинать.

Mikrotik для удобства поддерживает переходный механизм 6to4, что даёт возможность установить ipv6-подключение, пока провайдеры тестируют свои сети.
В процессе экспериментов с подключением, чтением справки и руководств, выработалась некая последовательность действий, которая и будет тут приземлена.

Что-бы данная заметка смогла помочь, требуются некоторые условия.

1. Провайдер сети Интернет должен выдавать маршрутизируемый(routed) адрес на интерфейсе подключения, т.е. выдавать "белый" ipv4-адрес. В данной заметке провайдер, а им оказался Rostelecom, подключает по технологии ADSL.
2. Желательно статический маршрутизируемый ipv4 адрес, но может подойти и динамический.

Особенности моего подключения получились следующие:
1. Динамический маршрутизируемый IPv4-адрес.
2. Переподключение каждые 24-часа. Пока не определил, меняется ли адрес или нет. Буду исходить из того, что меняется.

3. Проверить доступность важного ipv4-адреса: 192.88.99.1. Это anycast адрес, который сообщает туннельному клиенту (нашему роутеру) адреса шлюзов IPv4-IPv6.

На Ubuntu:

$ ping 192.88.99.1

На Микротике:

> /ping 192.88.99.1


При использовании трансляции адресов и маскарада (NAT & masquerade) на стороне провайдера, когда IPv4-адрес выдаётся из диапазона немаршрутизируемых сетей, таких как 192.168.x.x, 10.0.0.0 и пр. данная заметка не применима, требуется иное туннельное решение. Но будет частью полезна.

Домашний роутер может быть любой с поддержкой IPv6. Обычно они строятся на платформе Linux или подобной и так или иначе используют сходный набор программ для обслуживания протокола IPv6. Однако Mikrotik RouterOS даёт некоторые возможности управления настройками с помощью пользовательских скриптов, а это важно в случае динамического IPv4-адреса, настройка меняется с помощью скрипта. Также спокойно подойдут и открытые прошивки. Можно посмотреть настройки IPv6 в DD-WRT и Open-WRT.



Простейшее ручное подключение и настройка 6to4 туннеля на маршрутизаторе Mikrotik RB951G-2HnD

Я обновил прошивку роутера, скачав её с сайта производителя и положив в меню "Файлы", после перезагрузился и система RouterOS стала версии 6.7.


1. Итак, в меню роутера Микротик RB951G-2HnD "Interface", надо добавить новый интерфейс туннельного подключения 6to4tunnel, указав в качестве важного свойства "local-address" - текущий ipv4-адрес интернет-соединения, которое должно быть поднято. Свойство Remote-address  заполнить anycast ipv4-адресом 192.88.99.1. Указать MTU=1280.
Если заполнить, то появляется автоматический IP-адрес, из диапазона автоконфигурации, FE80::, вида: FE80::XXXX:XXXX/64.
Таблица маршрутов ipv6 пока пустая.


Итак, для примера, внешний IP-адрес интернет подключения: 77.88.01.239


Можно сделать из консоли:

/interface 6to4 add name=ipng disabled=no local-address=77.88.01.239 remote-address=192.88.99.1 mtu=1280

2. Сформировать и добавить в ручную переходный IPv6-адрес, для туннельного подключения и внести его в меню IPv6/Addresses, привязав к интерфейсу туннельного подключения.
Переходный IPv6-адрес, получен полным отражением полной адресной сети IPv4 (а это 4M адресов) в подсеть IPv6, с префиксом 2002:, если я в правильно выразился.
Формируется так - 32 битный IPv4 адрес преобразуется в шестнадцатиричный вид и укладывается после префикса 2002:, который зарезервирован, при этом соблюдая текстовую нотацию.
Т.е. адрес вида 77.88.01.239 - XXXX:XXXX
Получаем префикс 2002:XXXX:XXXX::/48

Этот префикс будет присутствовать у всех устройств домашней сети. А при изменении внешнего IPv4-адреса, также будет соответственно изменяться, но на роутере это надо будет автоматизировать, поскольку туннель 6to4 всё же любит статические IPv4-адреса. Делаться изменения будут пользовательским скриптом.

Также стоит заметить, что на подсеть (subnet prefix) остается 16 бит (а это 65536 подсетей, от 0 до FFFF).



В консоли:
/ipv6 address add address=2002:XXXX:XXXX::1/16 advertise=no comment=6to4public disabled=no eui-64=no interface=ipng

Т.к. за основу своего скрипта, я взял существующий какой-то скрипт, то метка 6to4public используется в комментарии, чтобы скрипт мог определить, какой адрес менять.

В таблице маршрутов появлятся динамический маршрут 2002::/16, а ipng для него шлюзом.

[admin@MikroTik] >> ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 ADC  2002::/16                ipng                            0

Добавленный адрес, пока не доступен извне.


3. Также надо прописать хитрый шлюз, в спец.формате.

/ipv6 route add disabled=no distance=1 dst-address=2000::/3 gateway=::192.88.99.1%ipng


::192.88.99.1 - это специальный формат IPv6-адреса, т.н. "IPv4-Compatible IPv6 Address".

%ipng указывает через какой интерфейс оно доступно. Через наш туннель.


Префикс 2000::/3 - это весь IPv6 интернет. Он попал в подсеть с этим префиксом, что сузило адресное пространство до 125 бит, а остальное как я понял - зарезервировано.


4. Сформировать и добавить вручную подсеть для домашних ipv6-устройств, таких как Windows, Ubuntu, чтобы они все получили маршрутизируемые IPv6 адреса, доступные из сети Интернет, по протоколу IPv6, через туннель 6to4.

2002:IPv4:Местный префикс::1/64

/ipv6 add address=2002:XXXX:XXXX:1::1/64 advertise=yes comment=6to4subnet disabled=no eui-64=no interface=bridge-local

Здесь важна опция  advertise=yes, чтобы встроенная программа radvd в RouterOS начала выдавать префикс (2002:XXXX:XXXX:1:) клиентам сети, которые на основе этого префикса автоматически сформируют белые маршрутизируемые IPv6 адреса. Эта опция влияет на появление динамического префикса в списке меню /ipv6 nd prefix.


Конечная цель всего этого - сделать так, чтобы клиенты домашней сети, получили доступ в IPv6 автоматически. Простая цель, а сколько тонкостей, а всё из-за того, что подзадержались провайдеры с поддержкой IP New Generation.
Цитата
"RouterOS has Ipv6 Neighbor Detection and stateless address autoconfiguration support using Router Advertisement Daemon (RADVD)".
Т.е. в принципе, не нужно включать DHCPv6 сервер, хотя клиентам Windows может понадобиться.


5. Маршрут на всё
Добавить маршрут ::/0 через шлюз ipng.
[admin@MikroTik] /ipv6 route> print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 A S  ::/0                     ipng                            1
 1 A S  2000::/3                 ::192.88.99.1%ipng              1
 2 ADC  2002::/16                ipng                            0
 3 ADC  2002:XXXX:XXXX:1::/64    bridge-local                    0

Из-за отсутствия этого маршрута, могут быть проблемы с доступностью IPv6 серверов.



На этом шаге, из консоли роутера (ssh command console), можно выполнить пробу любого ipv6-адреса (команда ping) и IPv6 сеть должна быть доступна.
Также извне, можно попробовать достучаться до адреса роутера, присвоенного интерфейсу туннеля (ipng). Я использовал сайт [3].

NOTE: Имеет смысл перезагрузиться и поправить адреса, в соответствии с новыми IP wan-интерфейса. Перезагрузка нужна, если туннель подключается, но пинги не ходят и извне нельзя достучаться по протоколу ipv6.

Из интересных IPv6-адресов:
2001:4860:4860::8888
2001:4860:4860::8844
Это публичные DNS-сервера Google.

Команда Ping (по протоколу IPv6) в выполняется в Mikrotik следующим образом:

> ping 2001:4860:4860::8888

либо при рабочем преобразовании имён:

> ping [:resolve ipv6.google.com]

Надо получить правильные таблицы маршрутов на клиентах и на роутере,
правильные доступные DNS-сервера.
Можно сделать это 2 путями, с помощью RADVD либо DHCPv6.

RADVD - Router Advertisement Daemon
Простейшее встроенное средство рекламы роутера в сети, на основе которого домашние компьютеры (умеющие это) смогут сформировать свои адреса, получить DNS сервера и полностью стать готовыми для работы в сети IPv6.

Во многих случаях, этого будет достаточно. Это называется Stateless Autoconfiguraton.

Однако, есть и Statefull autoconfiguration которое выполняется DHCPv6 сервисом.


6. DNS

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


IPv6-адреса DNS серверов, могут выдаваться роутером с помощью radvd, либо по протоколу конфигурации хоста DHCPv6.

Чтобы указать выдаваемые клиентами ipv6-адреса DNS серверов, можно их добавить в меню "IP/DNS". Указать их в ipv6-формате.

IPv6 DNS сервера в меню IP/DNS Mikrotik
Надёжное функционирование DNSv6 я ещё не исследовал более подробно, так что могут быть ошибки в конфигурации. Да и вообще, микротик ещё та запутанная штука.




Специальные адреса IPv6

1. Клиент (хост) может выполнить команду Ping на адрес: FF02::1 , чтобы найти доступные компьютеры в локальной сети (один широковещательный домен, один хаб, свитч).

На микротике:
[admin@MikroTik] /ping FF02::1

На Ubuntu:
$ ping6 FF02::1%eth0

указывая интерфейс через который надо искать, т.к. адрес немаршрутизируемый.

2. Доступный адрес FF02::2. Список ipv6-адресов роутеров.
Найти роутеры в локальной сети, которые себя рекламируют (Router advertisement) в данном подключении.
Обычно один, но бывает и несколько.


3. FC00::/7 ULA's. Uniq local addresses. Уникальные локальные адреса
Этот префикс можно использовать для статического конфигурирования неприсоединенной IPv6 сети.


4. FE80::/10. Автоматически присваиваемый каждому аппаратному и неаппаратному интерфейсу IPv6-адрес. Т.н. Link-local.
Позволяет сразу обеспечить связь компьютеров.


Тестирование доступности IPv6 сети на клиенте

Перейти по адресам:
test-ipv6.com
ipv6.nic.ru

Ubuntu

ipv6.google.com - спец.сайт, доступный как видно ниже, только по протоколу ipv6.

$ host ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2a00:1450:4010:c03::6a


Если DNS преобразование имён доступно, то можно проверить:
$ ping6 ipv6.google.com
$ traceroute6 ipv6.google.com



Windows Vista, 7 и т.п.

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


> ping -6 ipv6.google.com



Настройка файрволлов на клиентах

Т.к. компьютеры с поддержкой протокола IPv6 становятся доступными из сети Интернет, то требуется настроить Firewall, на каждом IPv6-подключенном устройстве. Базовые правила можно также настроить и на роутере.
Например, не принимать входящие соединения. Однако может отвалиться ping (icmpv6), если не предусмотреть разрешение.


Отладка

Т.к. технология новая, как работает IPv6 на Mikrotik не совсем понятно, то если что-то не работает, надо начинать с чистого листа - удалить добавленное и перезагрузить роутер, затем начать заново.
Пошагово.
Ещё не все зависимости и особенности выявлены.

Отлаживать скрипты на Mikrotik - это вообще "за гранью".
Основные трудности начинаются после смены динамического ipv4-адреса. Тут вступает в работу скрипт, которые я пока отлаживаю.


Помните, т.к. IPv6-адреса клиентов могут меняться очень часто, при автоподключении, то при использовании внешних утилит, проверяйте каждый раз задаваемый IPv6-адрес.Не используйте извне адреса, содержащие MAC-адрес. Не пытайтесь извне пробовать (ping) автоматические link-local адреса, начинающиеся с префикса FE80:/10, они работают только на конретных линках.

Пример трассировки компьютера, с помощью внешнего сервиса http://www.wservice.info/

1 ipv6.wservice.info 0.965 ms 32.612 ms 0.901 ms
2 2a01:230:3::1 0.568 ms 0.627 ms 0.503 ms
3 khouse-tr1.tcinet.ru 2.660 ms 2.567 ms 2.770 ms
4 KHOUSE-TR2.TCINET.RU 2.331 ms 3.927 ms 2.295 ms
5 * * *
6 2002:XXXX:XXXX::1 39.618 ms 38.146 ms 38.525 ms
7 2002:XXXX:XXXX:1:XXXX:XXXX:XXXX:XXXX 39.453 ms 41.635 ms 39.016 ms


Видно, что щупальце добралось до публичного адреса роутера, а затем полезло в домашний компьютер.

Заметил, что в Ubuntu куда-то часто пропадают IPv6-адреса, и компьютер отваливается от ipv6-сети. Проходит время и опять появляются адреса, уже частично другие. Dmesg команда показывает, что периодически Ethernet-интерфейс уходить в down, а затем поднимается опять. Это что-то видимо Network Manager в Gnome. Короче глючки. Когда ipv6-адреса появляются, то становиться доступным и сеть. Какие-то частые переподключения.

Windows 7 также очень часто обновляет IPv6 адреса. Это было у меня установлено время жизни маленьким, на время отладки (несколько минут).

Похоже это связано с временем жизни префикса:
[admin@MikroTik] /ipv6 nd prefix> print
Flags: X - disabled, I - invalid, D - dynamic
 0  D prefix=2002:XXXX:XXXX:1::/64 interface=bridge-local on-link=yes
      autonomous=yes valid-lifetime=2h preferred-lifetime=1h

Свойство autonomous=yes - это значит параметры будут раздаваться в RA-сообщениях.

2 часа - это 7200 секунд, 1 час соотв. 3600 сек.
Итак, Preffered-lifetime - это основное время жизни префикса (и адреса). В течении этого интервала времени, с этим адресом можно устанавливать новые (NEW) соединения и спокойно обмениваться пакетами. По истечении этого интервала, новые соединения уже нельзя, но существующие ещё можно.
Valid-lifetime можно сделать чуть больше, чем Preffered-lifitime.


Вывод сконфигурированных адресов на Linux host. Видны заданные параметры времени жизни адресов, которые уменьшаются со временем (при повторном запуске команды):
$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: home: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2002:XXXX:XXXX:1:xxxx:xxxx:xxxx:xxxx/64 scope global temporary dynamic
       valid_lft 6878sec preferred_lft 3278sec
    inet6 2002:XXXX:XXXX:1:xxxx:xxff:fexx:xxxx/64 scope global dynamic
       valid_lft 6878sec preferred_lft 3278sec
    inet6 fe80::xxxx:xxff:fexx:xxxx/64 scope link
       valid_lft forever preferred_lft forever 
У интерфейса home (переименованный eth0) видны автосконфигурированные ipv6-адреса, как на основе MAC-адреса, так и произвольный (в соответствии с Privacy Extensions), он помечен меткой temporary.
Зная MAC-адрес интерфейса (записав его куда-нибудь), зная принцип формирования префикса, можно извне достучаться до домашнего компьютера. Однако, это очень не полезно, т.к. если временный адрес, замучаются перебирать, то по MAC-легко будет добраться до компьютера.
И как я понимаю, со временем, будут сформированы базы данных MAC-адресов, если эти адреса будут передаваться по сети (в силу различных причин, например, указав однажды в качестве пункта назначения).

scope global - видимость глобальная
scope link - видимость в пределах соединения (link-local).

Шестая версия NMap (v6) поддерживает IPv6 полностью.
$ nmap -6 -Pn 2002:XXXX:XXXX:1:XXXX:XXXX:XXXX:XXXX
Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-08 17:33 MSK
Nmap scan report for cetonia (2002:XXXX:XXXX:1:XXXX:XXXX:XXXX:XXXX)
Host is up (0.00027s latency).
Not shown: 998 closed ports
PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Вот и видно, что SAMBA (SMB/CIFS) висит на своих портах и доступна по протоколу ipv6 (это лучше видно с добавочной опцией -sV).


Скрипт автообновления

Скрипт для автоматического обновления ipv6-адресов, если wan-интерфейс имеет белый динамический ipv4-адрес. Если серый, то ничего не будет работать. Я нашёл в инете какой-то скрипт, который у меня не работал и переделал под свои условия. Получился длинный, т.к. скриптовый язык Mikrotik не очень развит, отсутствуют многие функции (преобразование в шестнадцатиричный вид), которые пришлось написать.
Важную роль играет комментарий к ipv6-адресу, по которому этот скрипт находит его, чтобы изменить префикс.
Его надо запускать, после того как сформированы ipv6 адреса, и поднят туннель 6to4, и сеть ipv6-работает.

Вот такой костыль. Выделять куском и вставлять в окно скриптов.
А потом добавить в расписание запуск этого скрипта, с определённым интервалом. (10 минут или по желанию).

Микротику надо задуматься об добавлении функций в скриптовый язык.

# IPv6 6to4-tunnel endpoint update script
# Automatic update IPv6 address of 6to4 tunnel endpoint when internet connection IPv4 address changed (reconnect)
# Applicable for pppoe (adsl) connection and l2tp with dynamic routed IPv4 address
# Periodic (according setting sheduler) check internet connection IPv4 address and update tunnel endpoint when needed
# Host: router, Mikrotik
# Date: 25.02.2014
# RU: http://gimmor.blogspot.com/2014/01/6to4-ipv6-tunnel-mikrotik-rb951g-2hnd.html

# NOTE: if wan interface down or tunnel disabled then nothing happen.

:local waninterface;
:local 6to4interface;
:local wanaddress;
:local PubAddrComment;
:local SubnetAddrComment;

# IPV4 provider internet connection with routed (white) IPv4 address available on waninterface
:set waninterface "wan";

# 6to4 tunnel
:set 6to4interface "ipng";


# The special lables within comments of ipv6 address needed for script update
:set PubAddrComment "6to4public";
:set SubnetAddrComment "6to4subnet";


# START MAIN LOGIC

:log info "IPv6 6to4-tunnel endpoint update script start...";

:local wanup;
:local ipngup;

# needupdate - flag meens prfixes update needed
# default - false no need update
:local needupdate false;

# Check interfaces up and running
:set wanup (:put [/interface get [/interface find name=$waninterface] running; ]);
:set ipngup (:put [/interface get [/interface find name=$6to4interface] running; ]);

:log info "Wan Interface state: $wanup";
:log info "IPv6 tunnel interface state: $ipngup";

# STARTIF
:if (wanup) do={
:log info "IPv6. WAN interface $waninterface up and running"
:if (wanup && ipngup) do={
:log info "IPv6 tunnel seems to be up and ready to update endpoint";
# Update 6to4 tunnel connection when address changed
:set wanaddress [/ip address get [/ip address find interface=$waninterface] address];
:set wanaddress [:pick [:tostr $wanaddress] 0 [:find [:tostr $wanaddress] "/"]];
#:log info [:put $wanaddress];
:local tunnellocaladdress;
:set tunnellocaladdress [:put [/interface 6to4 get [/interface 6to4 find name=$6to4interface] local-address]];
#:log info $tunnellocaladdress;
:if ($tunnellocaladdress!=$wanaddress) do={
:set needupdate true;
:log info "IPv6. Need update 6to4 tunnel endpoint local-address";

# Disable addresses and tunnel interface prior changes
/ipv6 address disable [find comment=6to4public]
/ipv6 address disable [find comment=6to4subnet]
/interface 6to4 disable $6to4interface;

/interface 6to4 set ($6to4interface) local-address=$wanaddress;
:log info "IPv6. 6to4 tunnel endpoint updated with new local-address $wanaddress";
} else={
:log info "IPv6. No need update 6to4 tunnel endpoint local-address.";
:log info "IPv6. Current tunnel local-address $tunnellocaladdress and WAN address $wanaddress";
}
} else={
:log info "IPv6. 6to4 tunnel $6to4interface needed to be enabled";
}
} else={
:log info "IPv6. IPv4 internet connection (WAN interface) $waninterface must be enabled";
}
# ENDIF




:global toHexDigit do={
:local hexsym;
:set hexsym "0";
:if ($digit < 10) do={ :set hexsym (:tostr $digit); }
:if ($digit = 10) do={ :set hexsym "a"; }
:if ($digit = 11) do={ :set hexsym "b"; }
:if ($digit = 12) do={ :set hexsym "c"; }
:if ($digit = 13) do={ :set hexsym "d"; }
:if ($digit = 14) do={ :set hexsym "e"; }
:if ($digit = 15) do={ :set hexsym "f"; }
:return $hexsym;
};

# Transform ipv4 address into specifix ipv6 address with 2002: prefix and bind to 6to4interface
# 2002:XXXX:XXXX::1
# XXXX:XXXX - a hexadecimal form of public "routed" WAN address stored in wanaddress variable

:local 6to4prefix;
:set 6to4prefix "2002:";

#:log info "STARTF";
{
:local outstr;
:set outstr "";
:local dotpos;
:local numer;

:for i from=1 to=3 do={
:set dotpos [:find $wanaddress "."];
:set numer [:pick $wanaddress 0 $dotpos];
:set wanaddress [:pick $wanaddress ($dotpos + 1) 16];
:if (i=1) do={
 :set outstr ([:put $numer]);
} else={
 :set outstr ([:put $outstr] . "," . [:put $numer]);
};
};
:set outstr ([:put $outstr] . "," . [:put $wanaddress]);
#:log info [:put $outstr];

# Translate array of decimal values into hex values within array
:local octets;
:set octets [:toarray $outstr];
:local j;
:set j (1);
:local outstr;
:foreach octet in=$octets do={
 :local output;
 :local left;
 :local right;
 :local leftsym;
 :local rightsym;
 :set left ($octet / 16);
 :set right ($octet - ($left * 16));
 :set leftsym [:put [$toHexDigit digit=$left]];
 :set rightsym [:put [$toHexDigit digit=$right]];
 :set output ([:put $leftsym] . [:put $rightsym]);
# :log info ([:put $octet] . [:put $output]);
 :if (j=1) do={
  :set outstr ([:put $output]);
 } else={
  :set outstr ([:put $outstr] . "," . [:put $output]);
 };
 :set j ($j + 1);
# :log info [:put $outstr];
};
:local hexoctets;
:set hexoctets [:toarray $outstr];
#:log info [:put $hexoctets];

# Translate array of hex values into required ip prefix
:local ippref;
:set ippref "";
:local kd;
:set kd (1);
:foreach oct in=$hexoctets do={
# :log info [:put $oct];
 :set ippref ([:put $ippref] . [:tostr $oct]);
 :if (kd=2) do={ :set ippref ([:put $ippref] . ":") };
 :set kd ($kd + 1);
};
#:log info [:put $ippref];

# Forming final ipv6 prefix
:local myprefix;
:set myprefix ([:put $6to4prefix] . [:put $ippref]);
:log info ("IPv6. Global IPv6-prefix calculated: " . [:put $myprefix]);

# Update IPv6 white address of 6to4 interface (tunnel)
:foreach i in=[/ipv6 address find interface=$6to4interface] do={
:local addr [/ipv6 address get $i address];
:local cmnt [/ipv6 address get $i comment];
:local name [/ipv6 address get $i interface];
#:log info [:put $i];
#:log info ([:put $name] . [:put $addr]);
#:log info ([:put $cmnt]);
:if ($cmnt=$PubAddrComment) do={
:local newaddr ($myprefix . "::1/16");
if (needupdate) do={
[/ipv6 address set $i address=$newaddr];
 :log info ("IPv6. Changed ipv6-address of interface " . $name . " from " . $addr . " to " . $newaddr);
} else={
 :log info ("IPv6. No changes ipv6-address of interface " . $name . " from " . $addr . " to " . $newaddr);
}
};
}

# Update IPv6 white addresses for LAN

:foreach i in=[/ipv6 address find] do={
:local addr [/ipv6 address get $i address];
:local cmnt [/ipv6 address get $i comment];
:local name [/ipv6 address get $i interface];

:if ($cmnt=$SubnetAddrComment) do={
#:log info ([:put $name] . " " . [:put $addr]);
:local tmp;
:local pos;
:set tmp $addr;
:for j from=0 to=2 do={
 :set pos [:find $tmp ":"];
 :set tmp [:pick $tmp ($pos + 1) 99];
 :if ($j=2) do={
  :set pos [:find $tmp ":"];
  :local newaddr ($myprefix . ":" . [:pick $tmp 0 $pos] . "::1/64");
if (needupdate) do={
[/ipv6 address set $i address=$newaddr];
 :log info ("IPv6. Changed ipv6-address of interface " . $name . " from " . $addr . " to " . $newaddr);
} else={
 :log info ("IPv6. No changes ipv6-address of interface " . $name . " from " . $addr . " to " . $newaddr);
}
 }
}
};
};

# Check another things

};
#:log info "ENDF";

:if (needupdate) do={
:local ipv4addr [/ip address get [find interface=$waninterface] address ]
:local ipv6addr [/ipv6 address get [find comment=6to4public] address ]

# Enable interface and addresses
/interface 6to4 enable $6to4interface
/ipv6 address enable [find comment=6to4public]
/ipv6 address enable [find comment=6to4subnet]

}

:log info "IPv6 End of script Ho-Ho!";





Выводы

Удивительно, до сих пор требуется ручная настройка подключений к сети, с кучей неясных зависимостей. Ха-Ха.
6to4 штука интересная, но надо трясти провайдеров на предмет предоставления нормальной ipv6-сети.

Логика настройки роутера Микротик состоит в том, что вначале готовяться настройки нижнего уровня, а затем верхнего. Т.е. пример - вначале делается pool адресов, а затем конфигурируется DHCP на его основе.


Ресурсы
1. Setting up an IPv6 tunnel via 6to4. http://wiki.mikrotik.com/wiki/Setting_up_an_IPv6_tunnel_via_6to4
. http://www.mikrotik-routeros.com/2010/09/ipv6-and-mikrotik-using-6to4/
. http://6to4.ru/
- Тестирование связи извне по протоколу IPv6. http://www.wservice.info/
- http://wiki.mikrotik.com/wiki/Manual:IPv6_Overview
- IPv6 подключения к Микротику, по протоколу PPP. http://wiki.mikrotik.com/wiki/Manual:IPv6_PD_over_PPP
. http://blog.kladov.su/2013/11/6to4-mikrotik.html
. http://version6.ru/6to4/to-lan
- IPv6 шлюз для локальной сети. http://habrahabr.ru/post/134797/
. http://version6.ru/ip6tables
- IPv6 Address architecture. http://tools.ietf.org/rfc/rfc4291.txt
- IPv6 провайдеры. http://version6.ru/isp
. Internet Protocol Version 6 (IPv6). http://msdn.microsoft.com/en-us/library/windows/desktop/ms738570%28v=vs.85%29.aspx
Настройка IPv6 на OpenWRT. http://wiki.rnet.ru/index.php/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_ipv6_%D0%BD%D0%B0_openwrt
. http://www.mikrotik.by/index.php?showforum=1
. http://tools.ietf.org/html/rfc3056
. http://tools.ietf.org/rfc/rfc2461.txt
. http://wiki.mikrotik.com/wiki/Manual:IPv6/Address
. https://mebsd.com/ipv6-ping-and-traceroute
. http://ipv6-or-no-ipv6.blogspot.ru/2011/11/ipv6-fun-defaced.html

вторник, 20 марта 2012 г.

IPTV Beeline. Просмотр бесплатных каналов в Ubuntu 12.04


Настраивается бесплатное IPTV от Билайна (Билайн-ТВ) в городе Санкт-Петербурге

Домашняя сеть построена следующим образом:
микросервер HP Proliant Microserver - сервер-шлюз на базе Ubuntu 12.04, подключен через интерфейс beeline (быв. eth1) к провайдеру Beeline Интернет. Через интерфейс home (быв. eth0) микросервер подключен к домашней сети в "серых" адресах 192.168.3.0/24. Интернет настроен по VPN-соединению на интерфейсе ppp9 (PPtP). Включен IP forwarding и NAT. Сеть провайдера Билайн также характеризуется использованием "серых" IP-адресов из диапазона 10.0.0.0/8.
В принципе, это стандартная схема подключения, в условиях ограниченных IPv4-адресов, когда только ppp-подключение имеет "белый" динамический IPv4-адрес.

Требуется настроить следующие вещи:
+1. Просмотр бесплатных каналов IPTV на домашнем компьютере
+1a. При подключении домашнего компьютера напрямую к провайдеру
+1б. При подключении домашнего компьютера через сервер-шлюз
+2. Запись бесплатных каналов IPTV на сервере-шлюзе, по требованию, по расписанию.
+3. Доступ в Интернет, одновременно с IPTV.
+3а. При подключении домашнего компьютера напрямую к провайдеру
+3б. При подключении домашнего компьютера через сервер-шлюз
+4. Просмотр различных каналов на различных компьютерах домашней сети.

И все эти вещи удалось настроить.
Также стоит заметить, что все это проделывается в "колыбели революции". В иных территориях, надо делать по аналогии.

Для начала надо уточнить ряд вопросов.

1. Какую технологию IPTV использует Beeline? Конкретные технологические термины и определения.
На этот вопрос, ответ в прямом виде найти сложно, на сайте Билайна в основном инструкции обычного пользователя, но нас интересует технологические подробности, четко и ясно, - Что!.
Услуга «Домашнее цифровое телевидение» и все сервисы базируются на платформе Microsoft Media Room. Пользователю предоставляется специальное настроенное оборудование (т.н. STB - set top box).
Для просмотра бесплатных каналов, это не актуально.

2. Как получить доступ к IPTV?
Доступ к бесплатным каналам IPTV, является приятным дополнением к услуге "Интернет Билайн", однако официально это широко не рекламируется. Хотя это, серьезный маркетинговый инструмент привлечения новых подписчиков.
На форумах советуют использовать анализаторы трафика, для выяснения параметров доступа.
К параметрам доступа отнесем: список бесплатных каналов, адреса видеосерверов, протоколы доступа, используемые видео-аудио кодеки, рекомендуемое ПО, настройки сетевой конфигурации.

3. Список каналов? Что доступно?
По сообщениям форума Билайна (см. Ресурсы), для пользователей остается возможность бесплатного просмотра ряда каналов. Вот их небольшой список. Этот список надо поместить в текстовый файл с расширением m3u, для формирования списка воспроизведения. После этого можно его открывать в vlc.
#EXTM3U
#EXTINF:0,Первый
rtp://@233.33.210.86:5050
#EXTINF:0,Россия
rtp://@233.33.210.92:5050
#EXTINF:0,Россия 2
rtp://@233.33.210.93:5050
#EXTINF:0,Россия Культура
rtp://@233.33.210.60:5050
#EXTINF:0,Вести
rtp://@233.33.210.115:5050
#EXTINF:0,НТВ
rtp://@233.33.210.82:5050
#EXTINF:0,5СПБ
rtp://@233.33.210.6:5050
#EXTINF:0,Русская Ночь
rtp://@233.33.210.96:5050

Назовем это все мультиплекс, по аналогии с DVB-T, хотя и сементически не совсем верно, но слово прикольное. Видимо, в российском обществе слово "пакет", "пакет каналов" уже не котируется, употребляющие их кажутся какими-то отсталыми людьми, неспособными "двигаться в ногу", да и привлечение лишних посетителей не помещает блогу. Итак, в нашем случае, мультиплекс - это бесплатные каналы IPTV.

Из синтаксиса URL каналов заключаем, что используется RTP протокол. Порт 5050.
Также стало известно, что используется  видеокодек h.264.

4. Что требуется настроить на микросервере Linux Ubuntu 12.04, а на домашнем компьютере?
Опции ядра, ответственные за групповую маршрутизацию.
Маршруты в таблице маршрутизации.
IP таблицы netfilter. Проще - Firewall, брандмауэр.
Демона групповой маршутизации (multicast routing daemon).

Домашний компьютер выступает в двух ролях: "песочница" и "телевизор iptv". В "песочнице" проверяются и конфигурируются опции аналогичные серверным. В роли "телевизор iptv" практически ничего настраивать не надо, кроме запуска VLC.

5. Надо ли компилировать ядро, или обойдется настройками существующего. Какие
возможности у существующего ядра в интересующей области.

В Ubuntu server 12.04, не требуется перекомпиляция. Все настраивается опциями ядра.

6. Сторонние серверные программы, какие?
mrouted?
igmpproxy?
udpxy?
smcroute
pimd?
xorp?
rigelmcr?

По первым результатам, самым доступным демоном групповой маршрутизации является igmpproxy. Прост и ясен в настройке. У меня, заработал первым.

7. Как настраивать клиентскую программу просмотра? Какую?
VLC.
$sudo apt-get install vlc
или для сервера
$sudo apt-get install vlc-nox
Настройки, программа VLC, не требует. Поддержка RTP-протокола идет в комплекте.
Для просмотра надо открыть список воспроизведения, сформированный ранее.

8. Как выглядит правильно настроенная поддержка IPTV(multicast, igmp) в Linux
Это можно выяснить из этого сообщения.



Multicast Какой?

Эту часть можно проехать, до настройки на домашнем компьютере. Просто разрозненные цитатки из разных источников. Не редактированная часть.

Немного знаний о технологии Multicast и ее принципах функционирования, для лучшего понимания того, что делаю.

Цитата: "Основным механизмом доставки телевизионных программ до абонентов в локальных сетях является вещание в виде широковещательных IP-пакетов (иногда такой поток называют "мультикаст" от английского "multicast"). ".

Из википедии:
IPTV функционирует в IP-сетях с использованием следующих протоколов:
UDP — для передачи потокового видео
HTTP — для организации интерактивных сервисов (таких как пользовательские меню и пр.)
RTSP — для управления потоками вещания.
RTP — для передачи потокового видео.
IGMP — для управления мультикаст-потоками.

"Class D networks with a range of IP addresses from 224.0.0.0 to 239.255.255.255  have typically been reserved for multicast."

"For a process to receive multicast datagrams it has to request the kernel to join the multicast group and bind the port receiving the datagrams. When a process is no longer interested in the multicast group, a request is made to the kernel to leave the group"
Процесс, желающий принимать широковещательные датаграммы, должен запросить ядро присоединиться к группе вещания и к порту принимающему датаграммы.

"Note that on multihomed systems (more than one IP address/network card), only one device can be configured to handle multicast."

"On the local network, multicast delivery is controlled by IGMP (on IPv4 network)"

"Если IGMP корректно функционирует в сети, то абонентское устройство сможет "увидеть" этот поток"

Т.е. надо обеспечить корректную работу протокола IGMP.

"IGMP snooping разработан для предотвращения широковещательной (broadcast) ретрансляции multicast трафика компьютерам-потребителям, которые явно не заявили о своей заинтересованности в нём"



Первоначальная настройка на домашнем компьютере. Песочница

Подключение сети beeline к домашнему компьютеру напрямую. iptables чистые. VLC версия 1.1.12 из поставки Ubuntu 11.10.
Домашний компьютер, в результате, также имеет 2 интерфейса - beeline и home. VPN подключение отключено. Выяснил, что IPTV не работает при поднятой сети home, одновременно с beeline. При отключении сети home, и переподключении beeline (ifdown/ifup или через GUI) маршрутом по умолчанию становиться мой районный шлюз. IPTV начинает работает при настройках по умолчанию. Список каналов - действительный, они открываются с задержкой 1-2-3 секунды.
При подключении VPN, маршрутом по-умолчанию становиться туннель ppp0, что отключает работоспособность IPTV, в части переключения каналов, однако если идет вещание, то оно не прерывается некоторое время(какая-то особенность).


Основная причина неработоспособности IPTV в данной конфигурации - это похоже маршрутизация. Причем маршрутизация на "multihomed" компьютере, т.е. с несколькими сетевыми адаптерами.
IPTV использует несколько адресов хостов (видеосерверов) и чтобы они были доступны, маршруты до них должны быть прописаны в таблице маршрутизации.
В тестовом случае, когда у меня один интерфейс beeline, все проблемы IP-доступа к видеосерверам решает маршрут по-умолчанию и IPTV работает.

Предположение. RTP - комплексный протокол, и в ответах от указанного в url сервера, могут приходить ссылки на другие IP-адреса, а они могут быть недоступны через имеющиеся маршруты.
Т.е. возникает необходимость выяснения структуры вещания, адреса каналов и пр.

У меня, в автоматических маршрутах приходит и маршрут до сетки: 233.32.240.0/24, а протестированные каналы в сети 233.33.210.0/24
В непроверенном списке с форума, присутствуют каналы в сети 233.33.220.0/24. Маршрута автоматического, до этой сети, нет.

На форуме, также сообщается, что канал Карусель сменил адрес: rtp://@233.33.210.105:5050
Т.е. изначальный список каналов на форуме содержит недостоверные сведения.

Методика настройки IPTV+VPN, примерно следующая.
0. В наличии, только одно подключение beeline. Маршрут по-умолчанию, через районный шлюз на интерфейсе beeline.

1. При работающем IPTV запускается trafshow -i beeline
2. Выясняется "верхний в списке" IP-адрес, он будет с самым большим трафиком. Назовем его   вещатель.
3. Делается трассировка маршрута traceroute до вещателя. Выясняются все промежуточные узлы.
Вот пример от меня до вещателя, который вещает 5 канал (rtp://@233.33.210.6:5050)

traceroute to 78.107.196.212 (78.107.196.212), 30 hops max, 60 byte packets
 1  10.123.240.1 (10.123.240.1)  1.142 ms  1.830 ms  2.764 ms
 2  10.123.1.117 (10.123.1.117)  1.466 ms  2.172 ms  3.114 ms
 3  10.123.1.73 (10.123.1.73)  22.583 ms  23.407 ms  24.097 ms
 4  10.24.254.145 (10.24.254.145)  0.801 ms  0.747 ms  0.703 ms
 5  bmor18-bb-teng1-2-95.spb.corbina.net (85.21.225.100)  1.282 ms  1.224 ms  1.181 ms
 6  bmor18-bb.spb.corbina.net.225.21.85.in-addr.arpa (85.21.225.41)  0.989 ms  0.950 ms  0.979 ms
 7  85.21.225.199 (85.21.225.199)  1.299 ms  1.402 ms  1.488 ms
 8  line21-iptv-rs1-te-1-0-1.spb.corbina.net (85.21.225.113)  1.723 ms  1.828 ms  2.067 ms
 9  line21-iptv-rs1-te-1-0-1.spb.corbina.net (85.21.225.113)  1.431 ms !X  1.483 ms !X *


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

4.  Выбираются подсети, которые проходит пакет и маршруты до них добавляются в таблицу маршрутизации.
10.123.1.0/24
10.24.254.0/24
85.21.225.0/24
78.107.196.0/24 - подсеть вещателей
Дополнение от 20 марта, в принципе и без этих маршрутов у меня заработало, когда я перезагрузился и забыл их внести. Спишем их на процесс отладки. Не нужны. Фактически остается только один маршрут - 224/4.
Еще одно дополнение, "о майн год" и без маршрута 224/4 работает при запущенному igmpproxy.  Я в осадке, наверное моя мысль зашла не в ту ветку.
Я посносил практически все маршруты пришедшие по DHCP.
5. Отключается маршрут по умолчанию.
ip route del default
6. Делается контрольная трассировка до вещателя, но уже без наличия в системе маршрута по умолчанию. На этом этапе трассировка проходит, но не происходит разрешение IP-адресов в DNS-имена.
7. Добавляются маршруты к локальными DNS-серверам. На этом этапе начинают разрешатся IP-адрес в DNS-имена.

8. Удаляется лишнее. В автоматических маршрутах получаемых при поднятии (подключении) интерфейса beeline присутствуют неактуальные сведения, либо назначение этих маршрутов мне неизвестно. Сносим, но можно и не сносить, чтобы чего-нибудь не сломать.
ip route del 233.32.210.0/24
ip route del 233.32.240.0/24
9. Добавляется маршрут multicast адреса 224.0.0.0/4 (или кратко записанный 224/4) через IP-адрес адаптера beeline, полученный под DHCP.
ip route add 224/4 via 10.123.x.x dev beeline
10. Перезапускается VLC. По идее, на этом этапе, должно начать показывать IPTV. Т.е. из всего этого, я делаю вывод, что для показа IPTV требуются маршруты до местных DNS серверов, вещателей и промежуточных узлов, а также multicast адрес, и все они не приходят автоматически.

11. При подключении и отключении VPN, часто восстанавливается маршрут по-умолчанию beeline.

12. Поднимаем сеть home.
# ifconfig home up
# dhclient home
Пока работает (VLC включается, выключается).




Выглядит все приблизительно так, на домашнем компьютере

- интернет default dev ppp0  proto static - подключение VPN

- локальная сеть Билайна - 10.0.0.0/8 via 10.123.240.1 dev beeline  proto static
- промежуточный узел 10.24.254.145 в этой сети - 10.24.254.0/24 via 10.123.240.1 dev beeline
 10.123.240.0/21 dev beeline  proto kernel  scope link  src 10.123.x.x  metric 1
 78.107.23.0/24 via 10.123.240.1 dev beeline  proto static
 78.107.52.0/24 via 10.123.240.1 dev beeline  proto static
 78.107.184.0/24 via 10.123.240.1 dev beeline
вещатели отсюда - 78.107.196.0/24 via 10.123.240.1 dev beeline
 83.102.146.96/27 via 10.123.240.1 dev beeline  proto static
 83.102.254.196 via 10.123.240.1 dev beeline  proto static
 83.102.254.196 via 10.123.240.1 dev beeline  src 10.123.x.x
 83.102.254.196 dev ppp0  proto kernel  scope link  src 93.80.x.x
 83.102.255.224/28 via 10.123.240.1 dev beeline  proto static
 85.21.72.80/28 via 10.123.240.1 dev beeline  proto static
 85.21.79.0/24 via 10.123.240.1 dev beeline  proto static
- промежуточный узел ... в этой сети 85.21.90.0/24 via 10.123.240.1 dev beeline  proto static
 85.21.138.208/28 via 10.123.240.1 dev beeline  proto static
DNS сервер - 85.21.192.3 via 10.123.240.1 dev beeline
- промежуточный узел ... в этой сети 85.21.225.0/24 via 10.123.240.1 dev beeline
 89.179.134.64/28 via 10.123.240.1 dev beeline  proto static
 169.254.0.0/16 dev beeline  scope link  metric 1000
домашняя сеть - 192.168.3.0/24 dev home  proto kernel  scope link  src 192.168.3.5
194.67.1.0/24 via 10.123.240.1 dev beeline  proto static
194.67.18.0/24 via 10.123.240.1 dev beeline  proto static
DNS сервер - 213.234.192.8 via 10.123.240.1 dev beeline
217.118.84.0/24 via 10.123.240.1 dev beeline  proto static
-мультикаст-адрес - 224.0.0.0/4 via 10.123.x.x dev beeline

Где 10.123.x.x - IP-адрес присвоенный интерфейсу beeline
Если доступна информация о более точной конфигурации сети, то можно прописать более узкие подсети, чтобы случайно не сделать недоступной часть сети Интернет, потому что адреса вещателей - уж больно не попадают в диапазон "серых" IP-адресов. Впрочем, /24 - вполне узкая.

Итак, после того как IPTV заработало в песочнике, надо попробовать настроить сервер.
Формируем файл с маршрутами в скрипт, заливаем на сервер, выполняем. Изначально предполагаем неработоспособность IPTV в такой недоконфигурации.
Делаем трассировку на сервере, до вещателя.

traceroute to 78.107.196.11 (78.107.196.11), 30 hops max, 60 byte packets
 1  10.123.240.1 (10.123.240.1)  1.092 ms  2.114 ms  2.989 ms
 2  10.123.1.117 (10.123.1.117)  1.589 ms  2.433 ms  3.148 ms
 3  10.123.1.73 (10.123.1.73)  40.108 ms  40.816 ms  41.535 ms
 4  10.24.254.145 (10.24.254.145)  0.686 ms  0.772 ms  0.743 ms
 5  bmor18-bb-teng1-2-95.spb.corbina.net (85.21.225.100)  1.251 ms  1.431 ms  1.540 ms
 6  m9-crs.msk.corbina.net (78.107.184.212)  14.961 ms  10.760 ms  10.678 ms
 7  8m-iptv-bb-vl92.corbina.net (78.107.184.149)  9.248 ms  9.439 ms  8.990 ms
 8  78-107-196-11.broadband.corbina.ru (78.107.196.11)  8.702 ms  8.805 ms  8.642 ms


Делаем трассировку на настольном компьютере, до вещателя.

traceroute to 78.107.196.11 (78.107.196.11), 30 hops max, 60 byte packets
 1  192.168.3.1 (192.168.3.1)  0.296 ms  0.254 ms  0.247 ms
 2  10.123.240.1 (10.123.240.1)  1.395 ms  2.359 ms  3.163 ms
 3  10.123.1.117 (10.123.1.117)  1.764 ms  2.569 ms  3.293 ms
 4  10.123.1.73 (10.123.1.73)  2.233 ms  3.060 ms  3.792 ms
 5  10.24.254.145 (10.24.254.145)  1.181 ms  1.156 ms  1.138 ms
 6  bmor18-bb-teng1-2-95.spb.corbina.net (85.21.225.100)  1.531 ms  1.557 ms  1.705 ms
 7  m9-crs.msk.corbina.net (78.107.184.212)  10.280 ms  13.532 ms  13.513 ms
 8  8m-iptv-bb-vl92.corbina.net (78.107.184.149)  10.338 ms  10.456 ms  10.315 ms
 9  78-107-196-11.broadband.corbina.ru (78.107.196.11)  9.036 ms  9.057 ms  9.025 ms

На клиенте видим прохождение нашего сервера-шлюза, остальное совпадает.

Ну что же, похоже решение сводиться к включению multicast-роутинга на сервере, опций ядра и пр.


Настройка микросервера-шлюза

Настройка состоит из 4 частей.
1. Настройка опций ядра
2. Настройка маршрутизации
3. Настройка IP tables. Файрвола.
4. Настройка демона групповой маршрутизации

Опции ядра микросервера

Проверка сетевой конфигурации  микросервера.
1. Включен ли IP forwarding?
$cat /proc/sys/net/ipv4/conf/default/forwarding
1
По отдельным интерфейсам:
$cat /proc/sys/net/ipv4/conf/beeline/forwarding
1
$cat /proc/sys/net/ipv4/conf/home/forwarding
1

Видно, что включен IP forwarding, т.е. микросервер выступает в роли роутера между локальными интерфейсами.


Цитата: "Логическая переменная mc_forwarding управляет пересылкой пакетов с групповыми (multicast) адресами. Для использования групповой адресации требуется ядро, со включенной опцией CONFIG_MROUTE и демон, поддерживающий групповую маршрутизацию."

В Ubuntu server 12.04 опция CONFIG_MROUTE включена в конфигурации ядра.

Далее смотрим:
/proc/sys/net/ipv4/conf/all/mc_forwarding.
0
/proc/sys/net/ipv4/conf/all/mc_forwarding
0
$cat /proc/sys/net/ipv4/conf/beeline/mc_forwarding
0
$cat /proc/sys/net/ipv4/conf/home/mc_forwarding
0
Видим, что групповая маршрутизация выключена на интерфейсах. Как я понял из описаний, эта опция включиться при запуске демона. Забегая вперед, скажу, да включилась.

Выведем список групповых маршрутов
$ip mroute
На ненастроенном сервере, в выводе будет пусто.

Оцениваем состояние протокола IGMP.
$cat /proc/sys/net/ipv4/conf/all/force_igmp_version
$cat /proc/sys/net/ipv4/conf/beeline/force_igmp_version
$cat /proc/sys/net/ipv4/conf/home/force_igmp_version

Оцениваем состояние фильтра Reverse path filter
$cat /proc/sys/net/ipv4/conf/beeline/rp_filter
1
$cat /proc/sys/net/ipv4/conf/home/rp_filter
1

Теперь что надо сделать.


Для сохранения состояния опции ядра можно использовать специальный файл /etc/sysctl.conf
Зададим в нем следующие опции:

# Reverse path filter
# Это несколько нарушит безопасность шлюза, но что делать, что делать.
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0

# Принудим систему использовать IGMPv2
#net.ipv4.conf.beeline.force_igmp_version=2
#net.ipv4.conf.home.force_igmp_version=2
net.ipv4.conf.all.force_igmp_version=2
net.ipv4.conf.default.force_igmp_version=2

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

Если нет желания перезагружать, то можно выполнить команду
$sudo sysctl -p
Впрочем эти же опции меняются также через файловую систему /proc, на лету, записью в их файлы, что удобно для выявления их воздействия, на функционирование той или иной части системы "сервер-клиенты", а по-простому на домашнюю компьютерную инфраструктуру.


Маршруты на микросервере
Просмотрим маршруты на сервере.
$ip route

Существенным фактором является маршрут 224/4. В рамках только сервера, при наличии только подключения beeline, с маршрутом по-умолчанию, с отключенными другими интерфейсами, он является определяющим для работоспособности IPTV.
Остальные маршруты, это вопрос конкретной конфигурации, для клиентской сети и пр.

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

Подготавливаю файл скрипт
touch "маршруты для iptv.sh"
Заполняю приблизительно следующим:
#! /bin/sh
# Промежуточные сети узлов через районный шлюз
ip route add 10.24.254.0/24 via 10.123.240.1 dev beeline
ip route add 78.107.184.0/24 via 10.123.240.1 dev beeline
ip route add 78.107.196.0/22 via 10.123.240.1 dev beeline
ip route add 85.21.225.0/24 via 10.123.240.1 dev beeline

# DNS-сервера локальной сети через районный шлюз
ip route add 213.234.192.8 via 10.123.240.1 dev beeline
ip route add 85.21.192.3 via 10.123.240.1 dev beeline
# Мультикаст-адрес через IP-адрес адаптера билайн
ip route add 224.0.0.0/4 via 10.123.x.x dev beeline


Исполнять у себя нет смысла, у Вас своя конфигурация, свои маршруты и пр.


Настройка (IP tables) таблиц протокола IP. Настройка Firewall - "препятствия огню"

Настройка сводиться к разрешению приема широковещательного трафика на интерфейсе beeline и перенаправления его (forwarding), с небольшим изменением времени жизни.

При пустых таблицах на сервере, все и так работает, т.е. при выключенном firewall и включенной опцией ядра(IP forwarding).
Пустые таблицы нужны для отладки такой сложной вещи как групповая маршрутизация.
Если Вы знаете что делаете, можете не очищать, а только настраивать.

Эти строки помогут, когда ничего не помогает и отчаяние велико.
Сохраним конфигурацию netfilter, а потом очистим его.
$sudo iptables-save >"исходная конфигурация netfilter"
$sudo iptables -F

Смотрим:
$sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination      

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination      

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Чистый, как слеза, файрвол на сервере. Зачем все эти ограничения - информация должна быть свободна - это я так.


Если в системе включен файрволл, есть какие-то правила, и главным правилом стоит правило запрета (вида iptables -A INPUT -p all -j DROP), тогда можно отрывать по чуть-чуть.


Вот для этого чуть-чуть, существенным фактором( в закрытом IP-tables) будет является, наличие следующих правил.

Выполнение работа по настройке сего, требует прав суперпользователя на сервере.

# Улучшается время жизни TTL широковещательной датаграммы udp. Перед этим подгружается модуль ядра ответственный за это. В моем случае, работает и без этого правила.
modprobe ipt_TTL
iptables -t mangle -A PREROUTING -d 224/4 -p udp -j TTL --ttl-inc 1

# Прием
# Все пребывающие пакеты с адресом назначения 224/4 прием разрешить
iptables -t filter -A INPUT -d 224/4 -i beeline -j ACCEPT

# Перенаправление.
# Все прибывшие пакеты с адресом назначения 224/4 принять к перенаправлению
iptables -t filter -A FORWARD -d 224/4 -j ACCEPT

Эти все правила не нужны, это можно утверждать по опыту использования igmpproxy.

Так сказать - "открыли краник, а воды и нет".
 Но т.к. мультикаст требует "подписки абонента - аналог платежки ЖКХ", то пока не подпишимся, маршрутизаторы провайдера не будут присылать мультикаст к нам на порт. А подписку за нас сделает VLC.

Это достаточно хорошо видно при инспекции трафика на интерфейсах.

Также, при включенном файрволе может разрешения для  протокола igmp, по схеме, аналогично вышеприведенному.

Для просмотра правил NAT.
$sudo iptables -t nat -L
или
$sudo iptables -t nat -S



По настройке файрвола у меня отдельная тема. А его, я еще не включал.

В порядке экспериментов с iptables, снес всю таблицу на сервере, перестал работать google.com на клиенте. Опомнился, восстановил, гугл заработал. Что интересно, многие обычные сайты работали, а гугл нет. Не сразу заметил.


Диагностика
Для быстрой диагностики состоянии настроек для iptv, я создаю скрипт, который проверяет разные параметры, опции ядра.

использовать ping для диагностики доступности видеосерверов не получиться, icmp-протокол на них фильтруется.
Это тоже можно не включать, по результатам использования igmpproxy. Не влияет.
Включение multicast-пингов:
# echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
0

После этого ping широковещательного адреса начинает работать.
#ping 224.0.0.1

PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 10.123.242.x: icmp_req=1 ttl=64 time=0.115 ms


$ sudo tcpdump -i any igmp -n

$ sudo trafshow -i beeline

$ sudo netstat -g

Как использовать информацию из следующих файлов, я пока не придумал. Да видно, ну и что? Как управлять?

$cat /proc/net/dev_mcast


$cat /proc/net/igmp




Настройка демона групповой маршрутизации IGMP proxy в Ubuntu Server 12.04

Пакета с программой igmpproxy нет в репозиториях. Придется собирать из исходников. Для начала установим пакет программ для сборки.
apt-get install build-essential
С сайта http://sourceforge.net/projects/igmpproxy/ загружаем последнюю версию.

Распаковываем, конфигурируем, устанавливаем. Впрочем, это стандартная процедура сборки из исходных кодов.
Делаю все с привелегиями суперпользователя.
#tar -xzf igmpproxy-0.1.tar.gz
#cd igmpproxy-0.1
#./configure
#make
#make install

Копируем конфигурационный файл из /usr/local/etc/igmpproxy.conf  в /etc/igmpproxy.conf
Редактируем:
$sudo nano /etc/igmpproxy.conf


##------------------------------------------------------
## Configuration for beeline (Upstream Interface)
##------------------------------------------------------
phyint beeline upstream  ratelimit 0  threshold 1
        altnet 10.0.0.0/8
        altnet 224.0.0.0/4
        altnet 78.107.196.0/22
        altnet 10.24.254.0/24
        altnet 85.21.90.0/24
##------------------------------------------------------
## Configuration for home (Downstream Interface)
##------------------------------------------------------
phyint home downstream  ratelimit 0  threshold 1
##------------------------------------------------------
## Configuration for eth2 (Disabled Interface)
## Это интерфейсы вирт.машин и пр.
##------------------------------------------------------
phyint lo disabled
phyint ppp9 disabled
phyint lxcbr0 disabled
phyint virbr0 disabled

Сеть вещателей 78.107.196.0/22 а не /24, как выяснилось.

Запускаю/останавливаю сервис igmproxy следующим образом:
$ service igmpproxy start
$ service igmpproxy stop
Для того чтобы это было возможно, был создан файл /etc/init.d/igmpproxy

$ sudo touch /etc/init.d/igmpproxy 
$ sudo nano /etc/init.d/igmpproxy

#!/bin/bash
### BEGIN INIT INFO
# Provides: igmpproxy
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: IP-TV multicast routing daemon
### END INIT INFO
# Exit if igmpproxy.conf doesn't exist
test -f /etc/igmpproxy.conf || exit 0
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin
NAME=igmpproxy
DAEMON=/usr/local/sbin/$NAME
CONF="/etc/igmpproxy.conf"
test -x $DAEMON || exit 0
start()
{
        echo -n "Запуск IGMP PROXY server: $NAME"
        start-stop-daemon --start --background --exec $DAEMON $CONF
}
stop()
{
        echo -n "Остановка IGMP PROXY server: $NAME"
        start-stop-daemon --stop --name $NAME --oknodo
}
case "$1" in
  start)
        start
        echo "."
;;
  stop)
        stop
        echo "."
;;
  restart)
        stop
        start
        echo "."
;;
  *)
        echo "Использование: /etc/init.d/$NAME {start|stop|restart}"
        exit 1
;;
esac
exit 0


Чтобы происходила загрузка igmpproxy при запуске сервера:
$update-rc.d igmpproxy defaults

 Adding system startup for /etc/init.d/igmpproxy ...
   /etc/rc0.d/K20igmpproxy -> ../init.d/igmpproxy
   /etc/rc1.d/K20igmpproxy -> ../init.d/igmpproxy
   /etc/rc6.d/K20igmpproxy -> ../init.d/igmpproxy
   /etc/rc2.d/S20igmpproxy -> ../init.d/igmpproxy
   /etc/rc3.d/S20igmpproxy -> ../init.d/igmpproxy
   /etc/rc4.d/S20igmpproxy -> ../init.d/igmpproxy
   /etc/rc5.d/S20igmpproxy -> ../init.d/igmpproxy

Однако запуск/остановка сервиса, можно реализовать используя систему Upstart, которая с некоторых пор используется в Ubuntu. В этом случае не надо создавать файл /etc/init.d/igmpproxy . Вместо этого, создается файл в папке /etc/init/igmpproxy.conf со следующим содержимым.


# Служба управления групповой маршрутизации igmpproxy
# сервер: микросервер
# Дата изменения: 23 марта 2012
#
description "Служба групповой маршрутизации igmpproxy"
exec /usr/local/sbin/igmpproxy /etc/igmpproxy.conf

# Запускается, когда устройство beeline (eth1) поднято (UP)
start on net-device-up IFACE=beeline
# Останавливается, когда устройство beeline опущено (DOWN)
stop on net-device-down IFACE=beeline



После этого запуск/остановка выполняется системными средствами Upstart.
$ sudo start igmpproxy
$ sudo stop igmpproxy
Состояние работы "igmpproxy" проверяется так:
$ sudo status igmproxy


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

Просмотреть список запущенных заданий Upstart
$ initctl list



Вот как выглядит вывод команды ip mroute, при работающем igmproxy

$sudo ip mroute show
(78.107.196.5, 233.33.210.92)    Iif: beeline    Oifs: home
(78.107.196.6, 233.33.210.96)    Iif: beeline    Oifs: home

Видно 2 маршрута от разных вещателей. 2 канала IPTV.

Консольный клиент IPTV для записи на сервере

Ну что же, после некоторого просмотра Интернета, наметились пути решения и этого вопроса.
У программы VLC существует консольная реинкарнация CVLC. Правда, не работает под root.
Настроек - море.
Но для IPTV оказалось просто надо запустить:
cvlc -vvv rtp://@233.33.210.6:5050  --sout file/ts:5channel.ts
Команда на приостановку записи - отключение killall vlc.


Установим на сервере vlc-nox, пакет VLC собранный без поддержки графической системы X11. В этом пакете также есть cvlc. Сборка VLC из стандартного репозитория не содержит несвободных кодеков.
$sudo apt-get install vlc-nox

При попытке записи на сервере, выяснилась неприятная особенность - отсутствует звуковая плата в HP Proliant Microserver, из-за этого cvlc не пишет.
После добавления опции --no-audio в строку вызова, cvlc сказал, что он не поддерживает кодек h.264 и я не могу это исправить. Провал.
Тщательное изучение опций, родило такое решение:
cvlc -vvv rtp://@233.33.210.6:5050 --sout 'standard{mux="ts",dst="file.ts"}' --no-audio
Файл пишется со звуком, без перекодировки. Похоже, это то что нужно на первое время. А дальше, чтение справки и тонкая настройка cvlc.

Остается настроить стандартный планировщик CRON. С синтаксисом можно ознакомиться из статьи Wikipedia. Задача стоит так - запускать от имени обычного пользователя сервера видеозапись в определенное время.
А пока воспользуемся более простой командой at.

Подготовим скрипт видеозаписи, например первого канала, вечерних новостей, а также фильма "Робинзон" по состоянию на 19 марта 2012 года.
В расписании фильм занимает время: 21:20—22:20. Реально он начался в 21:30. Эту особенность надо учитывать при планировании времени записи. Закончился в 22.23. Так что, зазор в 5-10 минут, добавлять в конец.
Также есть полезная опция --run-time=<секунды>, ограничивающая время работы записи. Использовать ее надо в следующем синтаксисе, для часовой видеозаписи: --run-time=3600 vlc://quit. vlc://quit - команда на выход из vlc и передачи управления дальше в скрипте. Без этого висит и ждет.



скрипт располагается в домашней директории простого пользователя сервера.
touch "первый_канал.sh"
внесем:

#! /bin/bash
# Скрипт для видеозаписи 1 канала
# Особенности:
# Выходной файл создается с датой-временем,
# при использовании русских букв в имени выходного файла
# надо использовать кавычки в команде mv
# В данном скрипте, видеозапись длиться 1 час 10 минут, что составляет 4200 секунд.
TMP_VIDEOFILE="1.ts"
OUTPUT_VIDEOFILE="avoska/"`date +%Y%m%d-%T`".первый канал.видеозапись.ts"
echo $OUTPUT_VIDEOFILE
cvlc -vvv rtp://@233.33.210.6:5050 --sout '#standard{mux=ts,dst="$TMP_VIDEOFILE"}' --run-time 4200 vlc://quit --no-audio
mv "$TMP_VIDEOFILE" "$OUTPUT_VIDEOFILE"



chmod +x "первый_канал.sh"

Далее под обычным пользователем
$at -f "первый_канал.sh" -v 21:25
Список текущих заданий по расписанию:
$at -l
Удалить задание по номеру в списке.
$at -r 3

Не надо зарываться, с числом пишущихся каналов, иначе провайдер обрубит трафик, так, 2-3 канала.

Один канал, генерирует поток ~ 3 МБит.
Видеофайл, длительностью 1 час, занимает на диске место в размере приблизительно 1,3 ГБайта.


Планировщик CRON можно привлекать в более регулярных случаях, например записи новостей за день. 
Дополнено 21 марта 2012:
Итак, для регулярной записи программ новостей, с помощью CRON изготовлен многоканальный цифровой видеомагнитофон.
В домашней папке пользователя создается файл daynews.sh - заготовка для CRON, приблизительно такого вида:

#!/bin/bash
# Запись новостей телеканала "Первый"
# сервер: микросервер
# Дата создания: 21 марта 2012
#
# Постановка файла на исполнение: crontab -u user  daynews.sh
# Время записи определяется внутри самой команды

00 08 * * * /home/user/"новости_первый_канал.sh" 2> /tmp/daynews.cron
00 12 * * * /home/user/"новости_первый_канал.sh" 2> /tmp/midnews.cron
00 21 * * * /home/user/"вечерние_новости_первый_канал.sh" 2> /tmp/evnnews.cron

#36 08 * * * /home/user/testrec.sh 2> /tmp/test.cron

после этого, он ставится в расписание командой:
$ crontab -u user daynews.sh

или кратко
$ crontab daynews.sh
Выполняется эта команда под обычным пользователем.
Просмотреть задания:
$ crontab -l

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

У VLC есть опция -I telnet. Позволяющая управлять программой через протокол telnet. Может пригодиться.

Важно!. Для функционирования cvlc на сервере должен существовать маршрут 224/4, если его нет, то добавляется : ip route add 224/4 dev beeline

Финальным аккордом, будет разработка дружелюбного консольного пользовательского интерфейса к задуманным функциям.

Также, можно автоматически формировать список воспроизведения из записанных видеоданных, для воспроизведения на клиентских компьютерах.

Замеченное

- Не забыть перезагрузить сервер и проверить настройки. Всегда случаются какие-то упущения.
- При записи на сервере, на клиенте также наблюдается multicast-трафик. При записи нескольких потоков, трафик увеличивается. Клиенты тоже его получают. Сеть нагружается. Тут уже начинает играть роль планирование сети, vlan и пр.
- При слове "видео" сразу возникает слове "хранение". Ну что, HP Proliant microserver позволяет организовать до 16 Тб пространства в стандартной конфигурации, при 4ТБ винчестерах, до 12 Тб, при 3Тб винчестерах, - в половину меньше, при включении режима дублирования RAID 1 ~ 6Тб; этого хватить на 4600 часов видеозаписи или на полгода непрерывной 24-х часовой записи. Получается такой "видеосервер HP proliant microserver".
- При написании скриптов Bash, основные проблемы из-за синтаксических ошибок. А т.к. это интерпретатор, то эффекты бывают разные, "вплоть до".
- Наблюдается плавающий глюк, cvlc иногда пишет, а иногда не пишет и файл нулевого размера. Этот глюк пересекается с тем, что если запустить просмотр на домашнем компьютере, то и на сервере можно писать видео. А если выключить, то и сервер как-бы охладевает к теме записи видео. Надо разобраться. [Решено: добавлены маршруты к 230.33.210.x/24 и 233.33.220.0/24 через IP-адрес beeline]

Резюме - Включить опции ядра и поставить igmpproxy. Все.

На этом все.

Ресурсы, которые помогли прояснить неясное.
. IP multicast. http://en.wikipedia.org/wiki/IP_multicast
. Multicast address. http://en.wikipedia.org/wiki/Multicast_address
. Multicast маршрутизация для IPTV http://habrahabr.ru/post/61466/
. Форум Билайна по цифровому телевидению. http://homenet.beeline.ru/index.php?showforum=730
. Подфорум Билайна по цифровому телевидению на компьютере http://homenet.beeline.ru/index.php?showforum=783
. Linux Network Configuration http://www.yolinux.com/TUTORIALS/LinuxTutorialNetworking.html#MULTICAST
. Kernel configuration http://www.tldp.org/HOWTO/Multicast-HOWTO-3.html
. Описание протокола управления группами Интернета (IGMP). http://ru.wikipedia.org/wiki/IGMP
. Транспортный протокол реального времени. http://ru.wikipedia.org/wiki/RTP
.    http://www.netup.tv/ru-RU/configuring-igmp-in-lan-for-managing-multicast-iptv-streams.php
. Список каналов для vlc. http://homenet.beeline.ru/index.php?showtopic=208098
. Настройка статической multicast-маршрутизации в Alt Linux http://www.altlinux.org/Static_Multicast_Routing
. Распределение протоколов по уровням OSI. http://ru.wikipedia.org/wiki/TCP/IP
. Утилита iptables. http://ru.wikipedia.org/wiki/Iptables
. Непроверенный список каналов с форума, по состоянию на 15 марта 2012 года. http://homenet.beeline.ru/index.php?showtopic=163042&view=findpost&p=1065003113
.   http://blog.lystor.org.ua/2010/03/using-igmpv2-by-default-in-linux.html
. Мультикаст в Linux. http://www.xgu.ru/wiki/Multicast_%D0%B2_Linux
.The ip and smcroute Multicast Utilities. http://fengnet.com/book/ICUNA/ch14lev1sec5.html
. Multicast Architecture. http://etutorials.org/Networking/Integrated+cisco+and+unix+network+architectures/Chapter+14.+Multicast+Architectures/
.igmp тупит. http://forum.ubuntu.ru/index.php?topic=134589.0
.Sysctl. http://www.sysctl.ru/linux.html
.http://mrcat.ru/iptv-local-network
.http://grub4dos.ru/sysadmins/laninet/28-ustanovka-i-nastroyka-igmpproxy-dlya-prosmotra-potokovogo-video-v-ip-tv-player-v-lokalnoy-seti-za-serverom-ubuntu-server-na-primere-provaydera-internet-cntr-chebnet.html
. Igmpproxy - multicast router. http://sourceforge.net/projects/igmpproxy/
. VLC (Video LAN Client). http://ru.wikipedia.org/wiki/VLC
.   http://linuxfresh.blog.com/?p=1231
. Learning rtmpdump Through Examples. http://pclosmag.com/html/Issues/201104/page19.html
. VideoLAN streaming HOWTO. http://www.videolan.org/doc/streaming-howto/en/streaming-howto-en.html
. Системный планировщик CRON. http://ru.wikipedia.org/wiki/Cron
.

P.S. 15 февраля 2014 года. Установил сеть вещателей с маской /22, а не /24, по совету с форумов.