Не работает multicast linux
Обновлено: 06.07.2024
Заметки по ходу настройки "разного" в Linux. Хочу разобраться - читаю исходники. Программирование, администрирование, микроэлектроника, фотографирование и пр.
вторник, 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. Просмотр различных каналов на различных компьютерах домашней сети.
И все эти вещи удалось настроить.
Также стоит заметить, что все это проделывается в "колыбели революции". В иных территориях, надо делать по аналогии.
Для начала надо уточнить ряд вопросов.
2. Как получить доступ к IPTV?
Доступ к бесплатным каналам IPTV, является приятным дополнением к услуге "Интернет Билайн", однако официально это широко не рекламируется. Хотя это, серьезный маркетинговый инструмент привлечения новых подписчиков.
На форумах советуют использовать анализаторы трафика, для выяснения параметров доступа.
К параметрам доступа отнесем: список бесплатных каналов, адреса видеосерверов, протоколы доступа, используемые видео-аудио кодеки, рекомендуемое ПО, настройки сетевой конфигурации.
Назовем это все мультиплекс, по аналогии с 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-протокола идет в комплекте.
Для просмотра надо открыть список воспроизведения, сформированный ранее.
Эту часть можно проехать, до настройки на домашнем компьютере. Просто разрозненные цитатки из разных источников. Не редактированная часть.
Немного знаний о технологии Multicast и ее принципах функционирования, для лучшего понимания того, что делаю.
Цитата: "Основным механизмом доставки телевизионных программ до абонентов в локальных сетях является вещание в виде широковещательных IP-пакетов (иногда такой поток называют "мультикаст" от английского "multicast"). ".
"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 работает.
Т.е. возникает необходимость выяснения структуры вещания, адреса каналов и пр.
У меня, в автоматических маршрутах приходит и маршрут до сетки: 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)
Для надежности, проделывается тоже самое по другим каналам, чтобы выявить иные подсети.
Я сделал предположение, что все вещатели находятся в одной подсети, так удобнее для вещающих.
В принципе маршруты могут динамически изменяться, но тут уж ничего не сделаешь, таковы особенности бесплатного приложения.
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.
Выглядит все приблизительно так, на домашнем компьютере
- интернет 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 в такой недоконфигурации.
Делаем трассировку на сервере, до вещателя.
Делаем трассировку на настольном компьютере, до вещателя.
На клиенте видим прохождение нашего сервера-шлюза, остальное совпадает.
Ну что же, похоже решение сводиться к включению 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
Зададим в нем следующие опции:
После перезагрузки сервера, можно проверять эти опции, они должны соответствовать.
Если нет желания перезагружать, то можно выполнить команду
$sudo sysctl -p
Впрочем эти же опции меняются также через файловую систему /proc, на лету, записью в их файлы, что удобно для выявления их воздействия, на функционирование той или иной части системы "сервер-клиенты", а по-простому на домашнюю компьютерную инфраструктуру.
Маршруты на микросервере
Просмотрим маршруты на сервере.
$ip route
Существенным фактором является маршрут 224/4. В рамках только сервера, при наличии только подключения beeline, с маршрутом по-умолчанию, с отключенными другими интерфейсами, он является определяющим для работоспособности IPTV.
Остальные маршруты, это вопрос конкретной конфигурации, для клиентской сети и пр.
Дополнение от 20 марта: в порядке экспериментов выяснилось, что и этот маршрут можно не вносить в таблицу маршрутизации. И получается, нижеследующий файл - не нужен.
Исполнять у себя нет смысла, у Вас своя конфигурация, свои маршруты и пр.
Настройка (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) будет является, наличие следующих правил.
Выполнение работа по настройке сего, требует прав суперпользователя на сервере.
Эти все правила не нужны, это можно утверждать по опыту использования igmpproxy.
Это достаточно хорошо видно при инспекции трафика на интерфейсах.
Также, при включенном файрволе может разрешения для протокола igmp, по схеме, аналогично вышеприведенному.
Для просмотра правил NAT.
$sudo iptables -t nat -L
или
$sudo iptables -t nat -S
По настройке файрвола у меня отдельная тема. А его, я еще не включал.
Диагностика
Для быстрой диагностики состоянии настроек для iptv, я создаю скрипт, который проверяет разные параметры, опции ядра.
$ sudo tcpdump -i any igmp -n
$ sudo trafshow -i beeline
Как использовать информацию из следующих файлов, я пока не придумал. Да видно, ну и что? Как управлять?
Настройка демона групповой маршрутизации IGMP proxy в Ubuntu Server 12.04
VXLAN (Virtual eXtensible Local Area Network) – это оверлейная сеть, предназначенная для передачи Ethernet-трафика по существующей (масштабируемой и высокодоступной) IP-сети с одновременным размещением множества пользовательских групп. Именно такое определение мы увидим, если ознакомимся с технической спецификацией RFC 7348. В этой статье мы рассмотрим стандартную настройку сети VXLAN в Линукс в IP-сети мультивещания.
VXLAN вполне себе реализован в Linux, а уже начиная с версии 3.12, обеспечивается поддержка как мультивещания (multicast), так и одноадресной передачи (unicast), ну и, разумеется, IPv6 и IPv4. Так как традиционно VXLAN работают с применением групп мультивещания, о них и поговорим.
Вообще, термин “оверлейная” означает, что сеть VXLAN создаёт логические сети поверх физических: в нашем случае — логические сети L2 поверх IP-сети. В результате VXLAN имеет основные характеристики оверлейных сетей: • связь устанавливается между 2-мя конечными точками туннеля (VXLAN Tunnel Endpoints или VTEP); • в сети VXLAN оригинальные пакеты инкапсулируются в новый заголовок. К примеру, оверлейная технология IPSec VPN инкапсулирует в IP-заголовок оригинальный IP-кадр.
Перейдём к способам конфигурации VXLAN и рассмотрим пример развёртывания:
Для иллюстрации наших примеров будем использовать следующие настройки: • транспортная IP-сеть (масштабируемая и высокодоступная); • три Linux-моста в качестве VTEP; • четыре сервера, находящиеся в общем Ethernet-сегменте.
VXLAN-туннель распределяет отдельные сегменты Ethernet по 3-м мостам, предоставляя тем самым единый виртуальный Ethernet-сегмент, где с одного хоста (к примеру, H1) можно связаться с остальными хостами, сделав это напрямую.
Стандартная настройка VXLAN
В случае стандартного развёртывания, VXLAN использует IP-группу мультивещания (multicast) в целях соединения c другими VTEP:
Вышеуказанные команды создают новый интерфейс, который выступает в роли конечной точки туннеля VXLAN vxlan100, помещая его в мост с обычными интерфейсами (говоря по правде, это лишь один из вариантов реализации. Дело в том, что мост нужен, только если надо обеспечить присоединение локальных интерфейсов к VXLAN. Другой вариант заключается в применении интерфейсов MACVLAN).
Каждый VXLAN-сегмент связан с 24-битным ID, VXLAN Network Identifier либо VNI. В нашем случае в качестве VNI по дефолту указан id 100.
Когда сеть VXLAN впервые реализовали в Linux 3.7, порт UDP не был определен. Ряд вендоров использовали 8472, в результате чего Linux стал применять то же значение. Дабы не нарушать уже существующие конфигурации, такое значение применяется по умолчанию. Следовательно, если вам надо использовать порт, назначенный IANA, нужно точно указать его посредством dstport 4789.
Раз мы используем multicast, следует указать группу мультивещания (group ff05::100) и, разумеется, физическое устройство (dev eth0). При применении multicast значение TTL по дефолту равняется единице. Если же ваша multicast-сеть задействует какую-нибудь маршрутизацию, значение надо немного увеличить, допустим, как в примере выше — ttl 5.
Устройство vxlan100 играет функцию транспортного устройства для моста с удалёнными VTEP в виде виртуальных портов: • оно обеспечивает рассылку широковещательных, одноадресных и многоадресных (BUM) кадров всем VTEP, применяя группу мультивещания; • оно обеспечивает обнаружение связи MAC-адресов Ethernet с IP-адресами VTEP, изучая для этого адреса источников кадров.
Ниже отображена общая конфигурация с применением базы MAC (FDB, Forwarding Database) моста Линукс (с изучением локальных МАС-адресов) и FDB устройства VXLAN (с изучением удалённых МАС-адресов):
Используя команду bridge, вы сможете посмотреть содержимое FDB на устройстве VXLAN. Когда MAC-адрес назначения существует, кадр посылается VTEP, который с ним связан (если речь идёт об одноадресной сети). Нулевой адрес применяется лишь в том случае, если МАС-адрес назначения не обнаружен.
Какие преимущества несёт использование VXLAN в IP-сети мультивещания: • автоматическое обнаружение других VTEP внутри одной multicast-группы; • эффективное применение полосы пропускания (репликация пакетов осуществляется как можно позднее); • дизайн отличается децентрализованностью и не требует управления.
Настройка статической multicast-маршрутизации на дистрибутивах ALT Linux.
Содержание
Рассмотрим типичную схему multicast-маршрутизации с выделенным сервером, имеющим два сетевых интерфейса:
- eth0 — публичный интерфейс, на который придет поток от провайдера;
- eth1 — интерфейс в локальную сеть, в которой находятся клиенты.
Multicast-маршрутизация осуществляется по протоколу IGMP. IGMP (англ. Internet Group Management Protocol — протокол управления группами Интернета) — протокол управления групповой (multicast) передачей данных в сетях, основанных на протоколе IP. В данном руководстве используется IGMP версии 1.
На шлюзе должна быть разрешена пересылка сетевых пакетов (forwarding) и запущен демон multicast-маршрутизации. Мы рекомендуем использовать в качестве такого демона igmpproxy. При этом клиенты должны явно присоединиться к MC-группе. Вы можете явно назначить multicast-маршруты без этого требования к клиентам, если используете пакет smcroute.
Примечание: интерфейсы в дистрибутивах на базе Пятой платформы будут соответственно breth0 и breth1, однако мы не рекомендуем делать на них маршрутизацию.
Для начала необходимо установить дистрибутив ALT Linux и пакет демон multicast-маршрутизации igmpproxy и программу настройки статических маршрутов smcroute из соответствующего репозитория:
Также необходимы пакеты iptables net-tools iproute2, в дистрибутивах ALT Linux они присутствуют по умолчанию.
Для мониторинга можно установить пакеты tcpdump, wireshark и iperf
Все манипуляции осуществляются под правами пользователя root.
Файл /etc/igmpproxy.conf:
Для дистрибутивов на базе Пятой платформы файл /etc/igmpproxy.conf вместо eth0 и eth1 исполь-зуйте breth0 и breth1 соответственно.
1. Шлюз должен быть настроен для маршрутизации сетевых пакетов:
- Находится в режиме "Шлюз" в модуле "Брандмауэр" в дистрибутивах на базе Пятой платформы;
- или настраиваем вручную: в файле /etc/net/sysctl.conf параметр net.ipv4.ip_forward должен быть установлен в "1":
Также в файл /etc/net/sysctl.conf добавляем параметры: отключаем reverse path filtering для eth0 и для ядер 2.6.x указываем версию IGMP (igmpproxy поддерживает только IGMPv1 и IGMPv2 на внутреннем интерфейсе):
Примечание: после внесения изменений в этот файл необходимо перезагрузить компьютер.
2. Проверяем готовность к маршрутизации:
3. Настраиваем цепочки iptables для работы со специальными multicast-подсетями:
Вам может потребоваться выполнить эти команды в соответствии с вашими требованиями.
Я могу привести несколько примеров, где вам это понадобится.
При добавлении нового сетевого интерфейса или при создании нового виртуального сетевого интерфейса из исходного физического интерфейса.
вам может понадобиться отослать эти команды, чтобы вызвать новый интерфейс.
Кроме того, если вы внесли какие-либо изменения или если они не работают, вам нужно выполнить одну из следующих команд, чтобы применить их.
Это можно сделать разными способами, и мы хотели бы добавить лучшие пять методов, которые мы использовали в статье.
Это можно сделать, используя следующие пять методов.
Приведенные ниже выходные данные показывают информацию о доступной сетевой карте (NIC) в моей системе Linux.
1) Как подключить и отключить сетевой интерфейс в Linux с помощью команды ifconfig?
Команда ifconfig используется для настройки сетевого интерфейса.
Он используется во время загрузки для настройки интерфейсов по мере необходимости.
Он предоставляет много информации о NIC.
Мы можем использовать команду ifconfig, когда нам нужно внести какие-либо изменения в сетевую карту.
Общий синтаксис для ifconfig:
Выполните следующую команду, чтобы отключить интерфейс enp0s3 в Linux.
Запишите его, вы должны ввести имя вашего интерфейса вместо нашего варианта.
Да действительно, данный интерфейс не работает согласно следующему выводу.
Выполните следующую команду, чтобы включить интерфейс enp0s3 в Linux.
Да, данный интерфейс работает сейчас согласно следующему выводу.
2) Как включить и отключить сетевой интерфейс в Linux с помощью команды ifdown / up?
Примечание. Она не работает с новым интерфейсным именем устройства, таким как enpXXX.
Общий синтаксис для ifdown / ifup:
Выполните следующую команду, чтобы отключить интерфейс eth1 в Linux.
Выполните следующую команду, чтобы включить интерфейс eth1 в Linux.
Да, данный интерфейс работает сейчас согласно следующему выводу.
ifup и ifdown не поддерживают последние имена интерфейсных устройств enpXXX.
3) Как вывести из строя или поднять сетевой интерфейс в Linux с помощью команды ip?
Команда ip используется для управления картой сетевого интерфейса (NIC).
Это замена старой и устаревшей команды ifconfig в современных системах Linux.
Она похожа на команду ifconfig, но имеет много мощных функций, которые недоступны в команде ifconfig.
Общий синтаксис для IP:
Выполните следующую команду, чтобы отключить интерфейс enp0s3 в Linux.
Да, данный интерфейс не работает согласно следующему выводу.
Выполните следующую команду, чтобы включить интерфейс enp0s3 в Linux.
Да, данный интерфейс работает сейчас согласно следующему выводу.
4) Как включить и отключить сетевой интерфейс в Linux с помощью команды nmcli?
Его можно использовать в качестве замены для nm-applet или других графических клиентов. nmcli используется для создания, отображения, редактирования, удаления, активации и деактивации сети.
подключения, а также контролировать и отображать состояние сетевого устройства.
Выполните следующую команду, чтобы определить имя интерфейса, потому что команда nmcli выполняет большую часть задачи, используя имя профиля вместо имени устройства.
Общий синтаксис для IP:
Выполните следующую команду, чтобы отключить интерфейс enp0s3 в Linux.
Вы должны дать имя профиля вместо имени устройства, чтобы отключить его.
Да, данный интерфейс не работает согласно следующему выводу.
Выполните следующую команду, чтобы включить интерфейс enp0s3 в Linux. Вы должны дать имя профиля вместо имени устройства, чтобы включить его.
Да, данный интерфейс работает сейчас согласно следующему выводу.
5) Как вывести из строя сетевой интерфейс в Linux с помощью команды nmtui?
При запуске nmtui пользователю предлагается выбрать действие для выполнения, если оно не было указано в качестве первого аргумента.
Запустите следующую команду, чтобы запустить интерфейс nmtui.
Выберите «Подключится» и нажмите «ОК».
Выберите интерфейс, который хотите отключить, затем нажмите кнопку «отключить».
Читайте также: