Linux из одной подсети в другую

Ну, надо смотреть, как именно шлюз настроен.

Если там, например, маскарадинг сделан - надо его отключить для пересылок между локальными сетями.

Опять же, вообще посмотреть, какие правила фаервола на всех хостах есть.

Также не забыть про вариант, что «Устройства в 172.21.12.0 сети не могут получить время с gps сервера.» может быть не сетевой проблемой.

На шлюзе Centos включен ip forward. Проблема сетевая, т.к. если выставить маску 255.255.0.0 на устройствах в 172.21.12.0 сети и шлюз 172.21.0.211, то время синхронизируется. Виртуальные бонды делаем для разграничение сети масками, после чего собственно и появилась проблема с gps временем. Устройства в .12 сети это контролеры, не компьютеры условно, firewall на них нет, только ip, маска, шлюз.

А что показывает tcpdump? Как идёт запрос туда, как ответ оттуда? То есть, это скорее намёк, как искать проблему. Сам по себе вывод tcpdump здесь, на lor, не очень интересен.

Посмотрю. Кстати в route-bond3 файлике прописаны маршруты:

1. 172.21.12.0/24 со шлюзом 172.21.12.211
2. 172.21.0.0/24 со шлюзом 172.21.0.211

Пробовал так же изменить шлюз для .12 сети на 172.21.0.211, время так же не синхронизируется.

Кстати в route-bond3 файлике прописаны маршруты:

Эти все файлики дистрибутивоспецифичны, а маршрутизация - она даже ОС-независима. Показал бы вывод «ip a» и «ip r». На самом деле никакая специальная маршрутизация на сервере не нужна: когда ты поднимаешь IP-сеть на интерфейсе, у тебя сразу образуется так называемый direct route (везде, не только в Linux) на неё через этот интерфейс. Дополнительные маршруты (например default) нужны на устройствах и сервере времени (кстати, там ещё должны и маски правильные быть). На сервере с разными интерфейсами нужен исключительно разрешённый ip forward.

Пробовал так же изменить шлюз для .12 сети на 172.21.0.211,

Так нельзя. Шлюз должен быть в одной сети с интерфейсом.

Покажи
ip -br a
ip r

А пинги-то проходят между устройствами в разных сетях?

Пинги не проходят с компьютеров, пока дополнительный ip не добавишь в той же подсети, что и пингуемое устройство, или маску 16 на компе не поставишь.

IP route: https://pastebin.com/puwyc3PU

172.21.0.212 main ip на bond3, 0.211 еще один айпи на этом интерфейсе.

Скорее всего в ip tables еще разрешить нужно, но как это сделать ?

Вот настройки Iptables: https://pastebin.com/LFBt66Ui

Скорее всего в ip tables еще разрешить нужно, но как это сделать ?

Просто удали правила iptables совсем для проверки. Вероятно в CentOS сработает «service iptables stop». На самом деле это никакой не сервис, но все правила эта команда должна убрать. Если действительно заработает после этого, то надо на постоянку разрешающее правило будет придумывать.

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

iptables -A FORWARD -i bond3.1 -o bond3 -s 172.21.12.0/24 -d 172.21.0.11//32 -p udp –dport 123 -j ACCEPT

Не помогло это правило. Не могу понять почему устройства в bond3 не видят устройства не в своей подсети.

кто сказал такую глупость :)

сижу в 3.0/24 шлюз 0.1/32

это не касаемо конкретного случая, но ведь можно, если очень хочется

а пакеты у тебя только в одну сторону ходят да? :)

Из bond3 в другие bond скорее всего да, для этого прописаны правила в iptables. Но как сделать, чтобы устройства в бонд3 нормально общались между собой между подсетями не очень понятно. Вообще устройства с 24 маской внутри одного интерфейса могут общаться друг с другом ?

ой ли? а ну марш читать. а то время он синкнуть не может

у вас нет правил, разрешающих маршрутизацию через bond3

iptables -A FORWARD -i bond3.1 -o bond3 -s 172.21.12.0/24 -d 172.21.0.11//32 -p udp –dport 123 -j ACCEPT Не помогло это правило. Не могу понять почему устройства в bond3 не видят устройства не в своей подсети.

Потому что это правило описывает трафик в одну сторону, во-первых. Во-вторых оно добавляется в конец, после -A FORWARD -j LogDrop

iptables -I FORWARD -i bond3.1 -o bond3 -j ACCEPT
iptables -I FORWARD -i bond3 -o bond3.1 -j ACCEPT

Добавит 2 правила в начало таблицы FORWARD и разрешит на bond3 хождение трафика туда-сюда. Воспользуйтесь ими для проверки, потом сможете сузить условия.

кто сказал такую глупость :)

Это не глупость, а так работает IP-маршрутизация.

сижу в 3.0/24 шлюз 0.1/32

Это частный случай, который либо не имеет отношения к ethernet вообще, либо есть ещё какие-то нюансы.

это не касаемо конкретного случая, но ведь можно, если очень хочется

Стоя и в гамаке можно, но можно упасть однажды.

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

Даже на несколько секунд? Убрать, попингать, вернуть. Секунд 10 на всё про всё выше крыши.

Нет, у него не bond3.1, а bond3:1, который просто алиас. bond3 и вход, и выход.

Вот именно, как быть в таком случае ?

Да можно хоть на 10 минут, там по-дефолту цепочки в ACCEPT, он только drop правила поубирает, трафик не остановится.

Но вообще там в фаерволе конечно наворочено-о-о…

...
# Drop AD's root dns server queries
-A FORWARD -i bond1 -s 10.6.33.8 -p udp --dport 53 -j ACCEPT
-A FORWARD -i bond1 -s 10.6.33.9 -p udp --dport 53 -j ACCEPT
...

коммент ну совсем не врет.

Вот именно, как быть в таком случае ?

Для начала убедиться, что действительно мешает iptables.

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

Ну, признаюсь, написание через точку я взял из коммента ТС, сам правила для алиасов тыщу лет не писал, не считаю верным маршрутизацию между алиасами.

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

В обычной классической ситуации нельзя, и точка.

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

сам правила для алиасов тыщу лет не писал

Кажется это даже и нельзя, в правило интерфейс подставится, а не алиас. Можно попробовать

iptables -I FORWARD -i bond3 -s 172.21.0.11 -j ACCEPT
iptables -I FORWARD -i bond3 -d 172.21.0.11 -j ACCEPT

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

ладно, офтоп уже, прекращаем перепалку

Выдает:

iptables: No chain/target/match by that name.

Эти виртуальные бонд были сделаны для того, чтобы устройства не сыпали броадкастами по всему бонд3, т.к. на устройствах была /16 маска для доступа к ним из любой подсети. Какие есть другие варианты ограничить эти устройства, кроме vlan ?

Так какие есть варианты еще ? Если поставить на устройствах в .12 подсети опять маску /16 и на компе в .0 подсети (gps в той же подсети, что и компы) тоже /16 маску, то без проблем могу заходить на устройства .12 подсети, но это ведь не совсем корректно.

iptables: No chain/target/match by that name.

Да быть не может. Покажи вывод ip link|grep bond

[root@ngw1a ~]# ip link|grep bond

2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000

3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP qlen 1000

4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond2 state UP qlen 1000

5: eth3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond3 state UP qlen 1000

6: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000

7: eth5: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP qlen 1000

8: eth6: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond2 state UP qlen 1000

9: eth7: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond3 state UP qlen 1000

10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

11: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

12: bond2: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

13: bond3: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

23: bond2.10@bond2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

24: bond2.20@bond2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

25: bond2.48@bond2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

13: bond3: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

Не понимаю. Должно правило навешиваться.

Может все таки есть еще варианты ?

IP route

С такой маршрутизацией ничего и не должно работать. Если все Ваши сети 172.21.*.* физически приходят на интерфейс bond3, то Вам придется поднимать на нем виртуальные интерфейсы для каждой из сетей.

Скорее всего в ip tables еще разрешить нужно, но как это сделать ?

Проверить, связаны ли проблемы с настройкой iptables, очень просто - достаточно полностью выключить firewall (сбросить все правила iptables и установить политики по умолчанию для input, output и forward в accept). Если все заработает, значит, проблема в настройках iptables, если же ничего не изменится, значит, iptables не причем. Но я уверен, что у Вас проблема с маршрутизацией, а не с firewall.

Может все таки есть еще варианты ?

Есть. Понять, как работает TCP/IP и настроить правильно. Проблема не стоит и выеденного яйца, но смотреть здоровенные портянки совершенно не хочется. Как должно быть, это я написал.

Ну собственно я планировал так. Все 172.21 устройства приходят в bond3. Создать для каждой подсети свой виртуальной bond3:0, bond3:1 и т.д. Для каждой подсети получится свой адрес шлюза. Все устройства сделать с 24 маской. Но собственно вылезла проблема общения между подсетями…и пока не знаю как решить. В данный момент у нас большинство устройств с 16 маской и шлюзом 172.21.0.211 (адрес на bond3).

Создать для каждой подсети свой виртуальной bond3:0, bond3:1 и т.д. Для каждой подсети получится свой адрес шлюза. Все устройства сделать с 24 маской.

При такой организации все должно заработать.

Но собственно вылезла проблема общения между подсетями

Проблема вылезла, потому что Вы не создали те самые виртуальные bond3:*.

Сами же пишете выше:

Пинги не проходят с компьютеров, пока дополнительный ip не добавишь в той же подсети, что и 
пингуемое устройство

Т. е. добавление вирт. интерфейса с соответствующим IP решает проблему.

Ну почему. Сейчас создан bond3:0 и bond3:1 для .15 и .12 подсетей соответственно. А компы с которых пингую находятся просто в bond3.Ну добавлю компы .0.0 подсети в отдельный виртуальный bond и пинг появится что ли ?

Есть какие-то еще варианты разграничения ?

А компы с которых пингую находятся просто в bond3.

С сервера (машины, где подняты интерфейсы bond3, bond3:0 и bond3:1) устройства в сетях .15 и .12 пингуются?

1. Пинга не было, потому что пинговал с ноута с включенным wi-fi, почему-то пыталось ломиться через wi-fi, а не сеть с воткнутым патчкордом.
2. Видимо эти виртуальные bond3:0, bond3:1 все таки так сказать не полноценные интерфейсы, т.к. все правила в iptables, применяемые просто к bond3 - применяются и ко всем bond3:0 и т.д.
3. Время не синхронизировалось, потому что действительно был закрыт порт все таки, открыл вот этим правилом

-A FORWARD -i bond3 -s 172.21.0.0/16 -p udp --dports 123 -j ACCEPT

Видимо эти виртуальные bond3:0, bond3:1 все таки так сказать не полноценные интерфейсы, т.к. все правила в iptables, применяемые просто к bond3 - применяются и ко всем bond3:0 и т.д.

Вам выше уже писали, что это алиас а не интерфейс. Собственно имя для данного случая не играет никакой роли, его может и не быть. Это осталось со старых времен ifconfig который не умеет добавлять дополнительные ip адреса на интерфейс без названия интерфейса.

Видимо эти виртуальные bond3:0, bond3:1 все таки так сказать не полноценные интерфейсы, т.к. все правила в iptables, применяемые просто к bond3 - применяются и ко всем bond3:0 и т.д.

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

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

IMHO, Вы сами себе придумали головную боль на несколько дней - проблемы с firewall можно (и нужно) было исключить сразу же, о чем, собственно говоря, Вам и писало несколько человек, включая меня.