lexalex

Нет, в этом я не слукавил: задача действительно в мэйлслотовых широковещательных нет-сендах. Просто bcrelay, без каких-либо доп. настроек, но на "раздельных" сетевых,- помог; подтверждения о получении конечно не возвращаются, но уже неплохо :) Спасибо. Но сокат тоже буду пробовать

Похоже bcrelay не может прицепиться к не совсем настоящей сетевой: не смотря на bcrelay -i ens160 -o ens160:0 -d bcrelay -i ens160:0 -o ens160 -d в логи попадает bcrelay[1880]: UDP_BroadCast(sp=137,dp=137) from: ens160 relayed to: т.е. "вникуда"; ну и не работает ничего конечно сделал вторую сетевую "реальнй" и что-то получилось...

Да, соурс адрес реальный у пакета... (я почему-то думал что... .255 :/

Меня в том "заде" не было, но вам виднее ;) Предпочитаю линукс: убунта 16.04, 2 ИП на сетевой, в процессах вижу bcrelay -i ens160 -o ens160:0 -d bcrelay -i ens160:0 -o ens160 -d но не работает :(

Всем добра. Посоветуйте пожалуйста... Исторически сложилось: в одной "физической" сети работает две группы адресов, скажем 192.168.1.0/24 и 172.16.0.0/16. Абоненты между собой общаются net-send-подобной прожкой (вернее - работает именно посредством нет-сендов): если не ошибаюсь, то это широковещательные/броадкаст пакеты на адрес сети. Каким способом лучше "объединить" широковещательные группы? - ТОЛЬКО бродкаст-группы! ("всё переделать по-уму" прошу не советовать... сам знаю, но... "исторически сложилось") bcrelay? - может еще какие варианты? или я совсем не туда копаю?

nuclearcat Да, отключение коннтрака помогло, спасибо! (iptables -t raw -A PREROUTING -m tos --tos 0x08/0xff -j NOTRACK) Не будет ли теперь проблем в случае однократного(!) прохождения хост2? (когда хост1 сам доставит пакет на "5.55.55.55") И всеж хотелось бы понять: что и как настроить в коннтраке чтоб он корректно обрабатывал... мой случай? - Тоже буду признателен :)

"Проблемный хост" (2) с Ubuntu x64 14.04.5 LTS (даже обновил/перегрузил) eth0 с белым ИП tap381 смотрит на хост1 tap382 смотрит на хост3 (за которым сеть 172.16.0.0/12) на хост3 ТОСятся пакеты которые надо пустить на хост1 в некоторых случаях (как в примере) хост1 возвращает пакеты обратно (только теперь без меток, для обработки правилами по-умолчанию) ("все имена вымышлены, совпадения случайны", что никак не влияет на суть) # ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:8e:33:b2 inet addr:85.7.8.200 Bcast:85.7.8.255 Mask:255.255.255.128 inet6 addr: fe80::250:56ff:fe8e:33b2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1114280 errors:0 dropped:12 overruns:0 frame:0 TX packets:1038570 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:759458219 (759.4 MB) TX bytes:766781366 (766.7 MB) tap381 Link encap:Ethernet HWaddr e6:d9:bc:11:28:0f inet addr:192.168.1.253 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::e4d9:bcff:fe11:280f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:184263 errors:0 dropped:4190 overruns:0 frame:0 TX packets:165757 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:144077020 (144.0 MB) TX bytes:72492348 (72.4 MB) tap382 Link encap:Ethernet HWaddr 36:06:88:6e:10:d1 inet addr:192.168.254.130 Bcast:192.168.254.255 Mask:255.255.255.128 inet6 addr: fe80::3406:88ff:fe6e:10d1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:328716 errors:0 dropped:0 overruns:0 frame:0 TX packets:551292 errors:0 dropped:221 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:47665921 (47.6 MB) TX bytes:593595477 (593.5 MB) хост2# iptables-save # Generated by iptables-save v1.4.21 on Tue Jun 13 13:56:38 2017 *mangle :PREROUTING ACCEPT [764209:490874488] :INPUT ACCEPT [370734:192398404] :FORWARD ACCEPT [389679:296731296] :OUTPUT ACCEPT [392886:319617251] :POSTROUTING ACCEPT [782565:616348547] -A PREROUTING -m tos --tos 0x08/0xff -j MARK --set-xmark 0x8/0xffffffff -A PREROUTING -m mark --mark 0x8 -j TOS --set-tos 0x00/0xff COMMIT # Completed on Tue Jun 13 13:56:38 2017 # Generated by iptables-save v1.4.21 on Tue Jun 13 13:56:38 2017 *filter :INPUT ACCEPT [912:218860] :FORWARD ACCEPT [1096:685248] :OUTPUT ACCEPT [968:660852] COMMIT # Completed on Tue Jun 13 13:56:38 2017 # Generated by iptables-save v1.4.21 on Tue Jun 13 13:56:38 2017 *nat :PREROUTING ACCEPT [25410:3343645] :INPUT ACCEPT [11991:852469] :OUTPUT ACCEPT [1099:75346] :POSTROUTING ACCEPT [6319:417929] -A POSTROUTING -s 192.168.254.128/28 -o eth0 -j MASQUERADE -A POSTROUTING -s 172.16.8.0/23 -o eth0 -j MASQUERADE -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE COMMIT # Completed on Tue Jun 13 13:56:38 2017 хост2# ip ro ls default via 85.7.8.129 dev eth0 172.16.0.0/12 via 192.168.254.129 dev tap382 85.7.8.128/25 dev eth0 proto kernel scope link src 85.7.8.200 192.168.1.0/24 dev tap381 proto kernel scope link src 192.168.1.253 192.168.254.128/25 dev tap382 proto kernel scope link src 192.168.254.130 хост2# ip ru ls 0: from all lookup local 32765: from all fwmark 0x8 lookup tbl1 32766: from all lookup main 32767: from all lookup default хост2# ip ro ls table tbl1 default via 192.168.1.254 dev tap381 172.16.0.0/12 via 192.168.254.129 dev tap382 хост1# ping 5.55.55.55 -c 1 хост3# ping 5.55.55.55 -c 1 хост2# tcpdump -i eth0 -n host 5.55.55.55 -v 15:21:18.580757 IP (tos 0x0, ttl 63, id 4206, offset 0, flags [DF], proto ICMP (1), length 84) 85.7.8.200 > 5.55.55.55: ICMP echo request, id 37926, seq 0, length 64 15:21:18.581689 IP (tos 0x0, ttl 60, id 59255, offset 0, flags [none], proto ICMP (1), length 84) 5.55.55.55 > 85.7.8.200: ICMP echo reply, id 37926, seq 0, length 64 15:21:29.630214 IP (tos 0x0, ttl 61, id 49683, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.254.129 > 5.55.55.55: ICMP echo request, id 1522, seq 1, length 64 хост2# tcpdump -i tap381 -n host 5.55.55.55 -v 15:21:18.580708 IP (tos 0x0, ttl 64, id 4206, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.254 > 5.55.55.55: ICMP echo request, id 37926, seq 0, length 64 15:21:18.581708 IP (tos 0x0, ttl 59, id 59255, offset 0, flags [none], proto ICMP (1), length 84) 5.55.55.55 > 192.168.1.254: ICMP echo reply, id 37926, seq 0, length 64 15:21:29.613981 IP (tos 0x0, ttl 63, id 49683, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.254.129 > 5.55.55.55: ICMP echo request, id 1522, seq 1, length 64 15:21:29.630205 IP (tos 0x0, ttl 62, id 49683, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.254.129 > 5.55.55.55: ICMP echo request, id 1522, seq 1, length 64 т.е. пинг с хост1 проходит и ответ возвращается пинг с хост3 (после захода на хост1) уходит мимо МАСКАРАДа net.ipv4.conf.*.send_redirects было 1, теперь 0 (дефолтный и для каждого интерфейса) - без изменений

Согласен. Постараюсь... Насколько я знаю, (построутинг)снат/маскарад работает ПОСЛЕ маршрутизации. - Нет? ("почему-то_не_СНАТченый" пакет ловится тисипидамноп на ВЫХОДЕ нужного/правильного интерфейса)

Столкнулся вот... моих знаний не хватает - прошу подсказать и научить. Вкратце: каким образом пакеты могут НЕ SNATиться на выходе, при безусловном указании правила? Как это продиагностировать и поподробнее отследить? Чуть подробнее. (сеть1) (сеть2) I I хост1 -(сеть12)- хост2 -(сеть23)- хост3 -(сеть34)- хост4 всё давно настроено и работает, но вот недавно пришлось "заплатку на заплатку" сделать: пакет(пинг) от хост4 идет в сеть2 ЧЕРЗ(!!) хост1 (да, так и надо) и на выходе из хост2 в сеть2 СНАТ/МАСКАРАД НЕ(!) отрабатывает но если без захода на хост1 (маршрутизация по условиям), то те-же самые правила СНАТа/МАСКАРАДа работают. Наблюдал с помощью тисипидампа. (Изменеия в заголовки на хост1 не вносятся). "Схему" прошу не критиковать - так исторически сложилось. Более подробно... сложно объяснить; чтоб всё и сразу. хост1, 2 и 3 - линуксы; хост2 (на котором трабл) - конкретно убунта 14.04 Прошу помочь/подсказать/направить. upd: rp_filter = 0

То, что искал! Спасибо! :)

ДХЦП уже настроен, но на него нужно ПЛАВНО переехать,- для этого и "танцы". На пальцах. Имеется сеть "старых" компов, всё работает: ПК1: 192.168.0.1/24 (броадкаст 192.168.0.255) ПК2: 192.168.0.2/24 (броадкаст 192.168.0.255) ПК3: 192.168.0.3/24 (броадкаст 192.168.0.255) Нужно добавить "новый" ПК9: ПК1: 192.168.0.1/24 (броадкаст 192.168.0.255) ПК2: 192.168.0.2/24 (броадкаст 192.168.0.255) ПК3: 192.168.0.3/23 (броадкаст 192.168.1.255) ПК9: 192.168.1.1/23 (броадкаст 192.168.1.255) и если при этом немного изменить (см выше) настройки ПК3, который станет "средним" компом, то получим: сеть между 1 и 2 - работает без изменений (1-2) и 3 - ИП работает, сетевое окружение теперь не рабтает 3 и 9 - работает ИП и сетевое окружение Если как-то сделать переброску пакетов между бродкаст-группами 192.168.0.255 и 192.168.1.255, то "сеть между (1-2) и 3" тоже будет работать с сетевым окружением - чего и пытаюсь добиться для этого есть ПК99: 192.168.0.254/24 (броадкаст 192.168.0.255) и 192.168.1.254/23 (броадкаст 192.168.1.255) - он видит всех и по ИП в окружении Как?

Пытался избежать этого :) Есть сеть мс-виндовс, ИП статикой, маска /24 Возникла необходимость расширить... до /23 и добавить компов (кому нужна "вся сеть" - там поменять маску на /23 "по требованию") всё нормально, но "сетевое окружение" не работет (но по ИП на комп зайти можно) вот для этого и надо "объединить бродкасты" (или я ошибаюсь?) а под виндовсом нет возможности вручную задать этот адрес (формируется сам из ИП/МАСКИ) надесь... понятно? :) (только не надо пожалуйста писать, что это "через ОПУ" - сам знаю :) )

Да. Но бриджевать надо ТОЛЬКО бродкасты. Остальное отфильтровывать? (ебтаблес?) - Я тоже именно до этого додумался, но решил спросить... может есть более простое и "специализированное" решение.

Подскажите пожалуйста Убунта. 2 сетевых интерфейса - у каждого свой бродкаст адрес. Нужно сделать "общую" бродкаст-группу (средствами этой убунты) Т.е. (насколько я понимаю) просто "натить" (ТОЛЬКО!) широковещательные пакеты. Есть какое-то "готовое" решение? Или ткните ссылочкой пожалуйста если это уже обсуждалось где-то