Не принимается информация по UDP
Модератор: Модераторы разделов
Не принимается информация по UDP
По требованию начальника ("условие потенциального заказчика") стали осваивать RHEL 7.
Конфигурация системы примерно такая.
Программа-демон rd по UDP получает информацию от измерителя (передаётся по UDP на адрес 255.255.255.255) и размещает её в разделяемой памяти.
Программа АРМа отображает эту информацию на экране.
Под Debian (6 и 7) всё работало нормально.
В последний рабочий день (перед 5-дневными выходными) решили запустить на RHEL. Правда, транслировали под Debian 9, так как на RHEL ещё не поставили компиляторы.
Запускаем -- на экране ничего нет. Возникло впечатление, что программа rd не принимает информацию. Ни от измерителя, ни от его имитатора, запущенного на том же компьютере.
Программа tcpdump показывает непрерывный поток данных по UDP (при -i enp8s0 или -i any)
Для проверки запустил свою программу, которая показывает содержимое UDP пакетов в заданном формате. Она тоже НИЧЕГО не показывает.
В чём может быть дело?
Лично у меня два предположения.
1. Программа не ожидает приём данных с этого интерфейса (хотя я не знаю где его указать, tcpdump по умолчанию ждёт с virt..., точное название не помню)
2. Причина в том, что транслированы в Debian 9. Хотя АРМ, сделанный в Qt5 запускается, линии рисует.
Но как заставить программу принимать данные?
Конфигурация системы примерно такая.
Программа-демон rd по UDP получает информацию от измерителя (передаётся по UDP на адрес 255.255.255.255) и размещает её в разделяемой памяти.
Программа АРМа отображает эту информацию на экране.
Под Debian (6 и 7) всё работало нормально.
В последний рабочий день (перед 5-дневными выходными) решили запустить на RHEL. Правда, транслировали под Debian 9, так как на RHEL ещё не поставили компиляторы.
Запускаем -- на экране ничего нет. Возникло впечатление, что программа rd не принимает информацию. Ни от измерителя, ни от его имитатора, запущенного на том же компьютере.
Программа tcpdump показывает непрерывный поток данных по UDP (при -i enp8s0 или -i any)
Для проверки запустил свою программу, которая показывает содержимое UDP пакетов в заданном формате. Она тоже НИЧЕГО не показывает.
В чём может быть дело?
Лично у меня два предположения.
1. Программа не ожидает приём данных с этого интерфейса (хотя я не знаю где его указать, tcpdump по умолчанию ждёт с virt..., точное название не помню)
2. Причина в том, что транслированы в Debian 9. Хотя АРМ, сделанный в Qt5 запускается, линии рисует.
Но как заставить программу принимать данные?
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
Своеобразный подход, мягко говоря.
Настройки файервола смотрели?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
А заодно можно проверить и всякие роутеры (если есть).
Странно, что это вообще работало.
Странно, что это вообще работало.
Re: Не принимается информация по UDP
Там еще selinux может препятствовать
Re: Не принимается информация по UDP
А что тут такого?
Наиболее простой способ передать информацию от измерительного устройства любому клиенту в сети.
Пока с этим вообще не разбирались
А в чём странность?
С этим мообще ещё не имели дела
Узнали про него не так давно, когда узнали про Astra Linux.
Надо будет поразбираться.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
Не любому, а всем. Включая тех, кому оно не надо.
А зря, это в первую очередь надо смотреть.
Она-то тут каким боком?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Адрес 255.255.255.255 широковещательный.
Причём, "совсем" широковещательный - шире некуда.
На весь Интернет, если не ошибаюсь.
И такой трафик разрешен далеко не везде.
Пакет, отправленный "внутри" локальной сети, может и долетит,
а вот отправленный "снаружи", с большой вероятностью зарежется на первом же роутере.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
На всю локалку.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Это в случае ТС или вообще?
В пределах локалки будет что-то вроде 192.168.0.255.
А если, скажем, сетевой кабель от провайдера воткнут прямо в разъем сетевой карты (без всяких роутеров и пр.),
и от провайдера получен белый адрес, например, 117.110.200.35,
то отправленный с этой машины пакет на 255.255.255.255, полетит "на всю локалку"... Куда?
Где границы этой "локалки"? Подсеть провайдера? Или всё-таки шире?
Теоретически как раз "весь Интернет" и получается. На практике - зарежется, конечно, но где именно - неизвестно. Зависит от оборудования.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
https://tools.ietf.org/html/rfc919#section-7
The address 255.255.255.255 denotes a broadcast on a local hardware network, which must not be forwarded. This address may be used, for example, by hosts that do not know their network number and are asking some server for it.
До первого шлюза.Hephaestus писал: ↑07.05.2019 12:21А если, скажем, сетевой кабель от провайдера воткнут прямо в разъем сетевой карты (без всяких роутеров и пр.),
и от провайдера получен белый адрес, например, 117.110.200.35,
то отправленный с этой машины пакет на 255.255.255.255, полетит "на всю локалку"... Куда?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Спасибо сказали:
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Гм. А вот этого я не знал.Bizdelnick писал: ↑07.05.2019 13:56The address 255.255.255.255 denotes a broadcast on a local hardware network, which must not be forwarded.
Просто мы тут давеча WOL хотели испробовать - полноценно не получилось. Из-за этого ограничения что ли?
- Evil_Genius
- Сообщения: 92
- ОС: Fedora
Re: Не принимается информация по UDP
Помню во времена домашних сетей был такой вайпрес чат, работал по умолчанию на широковещательных пакетах, Засорял сеть страшно, чуть ли не до ступора.
Re: Не принимается информация по UDP
В реальной работе это одно и то же.
В реальной работе в локальной сети находятся измеритель, который оцифровывает сигнал и АРМ, оператор которого наблюдает за этим сигналом. АРМов может быть два (пока так начальник говорит), поэтому сеть состоит всего из трёх узлов.
К АРМу могут подключаться другие узлы, но к другому интерфейсу. -1 туда не пройдёт.
Ещё бы разобраться где он устанавливается
Не знаю. Просто
Когда ставили Debian подобных проблем не было. А вот поставили RHEL...
Это мы выяснили давно.Hephaestus писал: ↑06.05.2019 22:47Пакет, отправленный "внутри" локальной сети, может и долетит,
а вот отправленный "снаружи", с большой вероятностью зарежется на первом же роутере.
Когда собирали аналогичную систему (измеритель и два АРМа), при отсутствии хабов (свичей) мне пришлось на компьютерах организовывать бридж между двумя интерфейсами. И при этом возник эффект, объяснение которому я до сих пор найти не могу, но это отдельная тема.
Но а данном случае не "долетают" пакеты, отправленные на том же компьютере другой программой.
Проверить доходят ли UDP пакеты, отправленные на конкретный адрес смогу только в пятницу, после праздников.
Но с работой по ssh -X проблем практически не было.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Стоп! Вы отправляете с машины пакет на 255.255.255.255 и ожидаете, что эта же машина (в числе прочих) его и примет обратно? Я уже вообще ничего не понимаю в этой жизни.
Впрочем, как уже сказали выше, смотрите firewall, может быть и взлетит в конце концов.
Re: Не принимается информация по UDP
Конечно. Когда проверяли на Дебиане, постоянно так отлаживали систему.Hephaestus писал: ↑07.05.2019 21:38Стоп! Вы отправляете с машины пакет на 255.255.255.255 и ожидаете, что эта же машина (в числе прочих) его и примет обратно?
А в жизни много непонятного. Я, например, до сих пор не могу понять почему при выключении одного из компьютеров сети пинг другого возрастал с 0.7 мс до 260 мс.
Кончатся "праздники", выйду на работу и посмотрю.Hephaestus писал: ↑07.05.2019 21:38Впрочем, как уже сказали выше, смотрите firewall, может быть и взлетит в конце концов.
Хотя подозреваю, что причина какая-то простая.
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
В Дебиане фаервол по умолчанию не настроен (читай: выключен). По крайней мере, раньше так было.
Поэтому, весьма вероятно, что перейдя на другой дистр, перестало работать то, что раньше работало.
Я имел в виду другое: зачем нужно из множества вариантов выбирать самый, скажем так, непрозрачный (самый неудобный для отладки), да ещё не оглядываясь на фаерволы? Попроще нельзя было это устроить?
А пинг мог возрастать, например, потому, что физически компьютер из сети исключён, а запись в таблицах маршрутизации осталась (поскольку не обновляется мгновенно). В результате тратится время на маршрут, которого нет. Это так, навскидку.
Самая простая причина, которая может быть - фаервол.
Как я уже сказал, в Дебе он по умолчанию выключен, а в RHEL, скорее всего, включен.
Это с учётом того, что сейчас Вы гоняете пакеты внутри одной машины.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
Когда сеть зафлужена ШВ пакетами, каких только чудес не бывает.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: Не принимается информация по UDP
Действительно "чудеса" Хотя один знакомый и говорил, что "чудес не бывает". Любому "чуду", если разобраться. можно найти объяснение.
Тогда "чудо" заключалось в том, что если этого потока не было, то пинг был нормальным. И второе условие возникновения "чуда" было наличие в сети компьютера с интерфейсом br0 (не было возможности поставить "нормальный" хаб, пришлось делать программный)
Кстати, сейчас проверил. ping server составляет примерно 0.1-0.2 мс, иногда чуть больше. Когда запустил копирование с сервера большого файла, и скорость составляла 33.5 МБ/с, пинг немного возрос, в среднем стал около 0.4 мс. Поток ШВ пакетов от измерителя меньше 3 МБ/с.
Но это так, отступление. Что касается текущего вопроса, то дело действительно оказалось в файрволе. После снятия процесса firewalld информация стала приниматься.
Осталось разобраться, как его сконфигурировать.
Re: Не принимается информация по UDP
Нашёл статью Настройка firewalld в CentOS и увидел там одну фразу:
Потому, что iptables, как я понимаю, просто настраивает таблицы в ядре. Соответственно, получается, что файрвол встроен в ядро.
Но firewalld -- отдельная программа, работающая как демон. Когда я её снял, информация, приходящая по UDP, стала приниматься.
То есть именно эта программа выполняет роль файрвола.
В чём её преимущество перед iptables?
И возник вопрос: что именно делает firewalld?Firewalld — утилита для управления встроенным в ядро Linux брандмауэром Netfilter. Несмотря на собственный синтаксис, имеет такой же принцип работы, как Iptables.
Потому, что iptables, как я понимаю, просто настраивает таблицы в ядре. Соответственно, получается, что файрвол встроен в ядро.
Но firewalld -- отдельная программа, работающая как демон. Когда я её снял, информация, приходящая по UDP, стала приниматься.
То есть именно эта программа выполняет роль файрвола.
В чём её преимущество перед iptables?
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
firewalld — это просто обёртка над iptables (и некоторыми другими бекендами, что в данном случае не имеет значения). Нужна она для того же самого, для чего и другие многочисленные обёртки: упростить настройку файервола, не заставляя администратора вникать в принципы его работы.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Если точнее, никакого файрвола нет. Есть фильтр сетевых пакетов. В ядре, да.
Который выполняет, в частности, роль файрвола. Но можно применить и для других задач, например, рулить "раздачей интернета" в локальную сеть.
Re: Не принимается информация по UDP
Не похоже, чтобы firewalld был "обёрткой над iptables". "Обёртками", скорее, являются firewalld-cmd (CLI) и firewalld-config (GUI).Bizdelnick писал: ↑13.05.2019 15:14firewalld — это просто обёртка над iptables (и некоторыми другими бекендами, что в данном случае не имеет значения). Нужна она для того же самого, для чего и другие многочисленные обёртки: упростить настройку файервола, не заставляя администратора вникать в принципы его работы.
У нас есть "сервер", который отделяет локальную сеть от интернета. И в нём файл iptables_rules с кучей строк видаHephaestus писал: ↑13.05.2019 15:21Если точнее, никакого файрвола нет. Есть фильтр сетевых пакетов. В ядре, да.
Который выполняет, в частности, роль файрвола. Но можно применить и для других задач, например, рулить "раздачей интернета" в локальную сеть.
-A POSTROUTING -s <Local_IP> -o eth0 -j SNAT --to-source 192.168.1.3
(и некоторыми другими)
Который при загрузки системы "запускается" командами
Код: Выделить всё
echo -n "Starting ipchains firewall rules:"
iptables-restore < /etc/iptables_rules;
echo 1 >/proc/sys/net/ipv4/ip_forward
echo "."
Но всё это делается через таблицы в ядре. Никакого отдельного демона для этого нет
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Всё правильно.
Фильтр сетевых пакетов в ядре называется netfilter. iptables - это программа, предоставляющая интерфейс к netfilter. Настройка может оказаться сложной. Однако существует руководство к iptables на русском языке.
Так вот, для тех, кому сложно освоить iptables, существуют всякие надстройки/обертки (для облегчения процесса настройки). Какой бы там ни был демон - под капотом всё равно iptables.
Самым забавным сочетанием такого рода на моей памяти было устройство фаервола в Mandriva.
Там была штука под названием shorewall с графической мордой поверх.
Полная цепочка (вместе со всеми надстройками/обертками) выглядела так:
netfilter=>iptables=>shorewall=>графическая морда для настройки в "два клика".
Вы совершенно правы: да, действительно можно всё настроить напрямую без всяких "демонов".
По этой причине я ушёл с Mandriva. В какой-то момент я обнаружил, что все эти обертки скрывают от меня работу сетевого фильтра, а сгенерированные ими правила не предназначены для чтения человеком.
Понять, как и что там настроено не было никакой возможности. В результате я решил сменить дистр на что-нибудь более серьёзное и ушёл в Debian.
Последний раз редактировалось Hephaestus 13.05.2019 19:13, всего редактировалось 1 раз.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
Обёртка, обёртка. Хоть и демон. А эти тулзовины — для управления обёрткой. Сравните вывод iptables-save при запущенном и остановленном firewalld.
shorewall
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
Поправил.
После этого iptables показался мне простым и понятным.
Добавлено (19:19):
Кстати, примерно в то же время, как я штудировал руководство по iptables, мне довелось настраивать на работе netsh - штуковину, решающую схожие задачи, но под windows.После этого iptables показался мне простым и понятным.
Re: Не принимается информация по UDP
СравнилBizdelnick писал: ↑13.05.2019 18:58Сравните вывод iptables-save при запущенном и остановленном firewalld.
Выдал iptables-save -- выскочила куча строк. Сохранил их в файле.
Потом снял firewalld -- iptables-save НИЧЕГО не выдал.
Затем запустил его (/usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid, так выдал pgrep). По Ctrl+c снял.
Запустил ещё раз, но без --nofork, iptables-save выдал столько же строк (сколько и до снятия, только с немного другими значениями в квадратных скобках). но pgrep -la firewal ничего не выдал.
То есть, как я понимаю, firewalld -- "прослойка" между такими программами как firewall-cmd и firewall-config и сетевым фильтром ядра.
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Не принимается информация по UDP
Не совсем так. Между ним и сетевым фильтром ядра есть ещё одна прослойка — iptables.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: Не принимается информация по UDP
firewall-cmd и firewall-config, которые интерфейсы к firewalld, который обертка для iptables, который интерфейс к netfilter, который в ядре, которое построил Линус Торвальдс.
- Evil_Genius
- Сообщения: 92
- ОС: Fedora
Re: Не принимается информация по UDP
А разве nftable не пришел на смену iptables?