Обмен трафика между хостами с разной маской

[Ilya Karcev]

Всем доброго дня. Прошу помощи более опытных коллег, т.к. свои идеи иссякли. Имеем следующую конфигурацию:
Камера - адрес 192.168.2.114/21
Сервер видео - 192.168.2.250/21
ПК - 192.168.6.22/22
Шлюз во всех случаях 192.168.5.10
На микротике адрес на ether3 -192.168.5.10/21
Физически устройства в одной сети, подключены к одному коммутатору, отличия только в маске, следовательно напрямую друг друга не видят. Общение между ними должно идти через микротик, в main указан полный диапазон адресов.
Пинги между устройствами есть, tracert идет через микротик как положено.
На веб-интерфейс камеры попадаю, но работе очень медленно и с глюками...и что самое важное не могу попасть на видеосервер и посмотреть изображение с камеры на порту 7000, пакеты микротик отбрасывает как инвалидные

Получается большое недопонимание, раз пинги идут, значит связь между устройствами есть микротик трафик передает, web- интерфейс опять же, криво, но работает, а поток видео не идет..
На текущий момент восстановил работу видео посредством отдельного правила, где указано, что трафик на 7000 порту не считать инвалидным и пропускать (считаю что костыль) + работа web интерфейса также оставляет желать лучшего

Помимо этого пробовал заводить на интерфейсе еще один шлюз 192.168.2.1, и указывал его на камере и на веб сервере, все равно обмена нет.
Маркировки соединения mangle для данных групп адресов нет
Firewal исключил

По такому же принципе настроена работа с терминальным сервером. Находится он в сети 10.10.10.0. Подключен к микротику на ether4, все прекрасно работает, все ПК из подсети 192.168.5.0 его видят и подключаются по rdp

Прошу помощи

[xvo]

От компа к серверу трафик идет через микротик потому что у компа маска уже и адрес сервера в нее не попадает.

Обратно трафик идет напрямую (с более широкой маской сервер видит, что комп в его же подсети).

Не уверен, что именно происходит, но вероятно, так как через микротик соединения проходят только в одну строну, то он не считает TCP соединения установившимися и сбрасывает.
Или что-то в этом роде.

Либо делайте NAT на микротике, либо лучше уберите эту ерунду с разными масками в одной сети, и сделайте везде /21.

[Ilya Karcev]

От компа к серверу трафик идет через микротик потому что у компа маска уже и адрес сервера в нее не попадает.

Обратно трафик идет напрямую (с более широкой маской сервер видит, что комп в его же подсети).

Не уверен, что именно происходит, но вероятно, так как через микротик соединения проходят только в одну строну, то он не считает TCP соединения установившимися и сбрасывает.
Или что-то в этом роде.

Либо делайте NAT на микротике, либо лучше уберите эту ерунду с разными масками в одной сети, и сделайте везде /21.

Данная теория посетила меня в первую очередь. Отбросил я ее двумя аргументами. На микротике через torch отслеживал ip адреса, и получал следующее
При запросе видео в src- адрес мой комп в dst- адрес ip сервера
В ответном соединении в src-адрес сервер, в dst- адрес мой комп, раз эти данные отобразились, значит и туда и обратно пакеты шли через ether 3 на микротике.
И если бы ответ от сервера шел мимо микротика, то пинги и web- интерфейс тоже бы не смогли работать, отбрасывались бы все пакеты, а не только на порту 7000. Это и выводит из коллеи, потому что работает ...Но частично

Второй аргумент. Описывал в теле темы. На Ether3 на микротике добавил еще один адрес 192.168.2.1 и сделал его шлюзом для камеры и сервера, маску выставил на обоих устройствах также как и на ПК, чтобы напрямую ни сервер ни комп друг друга не видели.. Результат аналогичный..

[mafijs]

Если тут правильно на писано -- ПК - 192.168.6.22/22
Тогда
Usable Host IP Range: 192.168.4.1 - 192.168.7.254
Что никак не попадает в
Камера - адрес 192.168.2.114
Сервер видео - 192.168.2.250

https://www.calculator.net/ip-subnet-ca ... &x=63&y=18

[Ilya Karcev]

Если тут правильно на писано -- ПК - 192.168.6.22/22
Тогда
Usable Host IP Range: 192.168.4.1 - 192.168.7.254
Что никак не попадает в
Камера - адрес 192.168.2.114
Сервер видео - 192.168.2.250

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

[xvo]

В ответном соединении в src-адрес сервер, в dst- адрес мой комп, раз эти данные отобразились, значит и туда и обратно пакеты шли через ether 3 на микротике.

Физически то он может и шел, я топологии вашей сети не знаю. И не на IP адреса тут надо смотреть, а на мак-адреса: в одну сторону будут фигурировать адреса компа и роутера, а во втором - сервера и компа.

У ICMP нет как такового состояния соединения, в отличие от TCP - трафик ходит, микротик считает, что соединение есть.

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

[xvo]

Но вообще, судя по инфе, что пакеты отваливаются на микротике как invalid - все именно так, как я и сказал - syn микротик видит (проц, не физически порт), ack - нет.

Почему вся эта история продолжает не работать, если у камеры/сервера сузить маску я так сходу не могу придумать - возможно кто-то из них вообще не умеет работать с маской отличной от /24 - что-то такое про китайцев когда-то проскакивало.

[Erik_U]

У камеры, сервера и микротика подсеть 192.168.0.0/21 хосты 192.168.0.1-192.168.7.254
У ПК подсеть 192.168.4.0/22 хосты 192.168.4.1 - 192.168.7.254

А почему так подсети нарезаны?
Что заставило сделать пересекающиеся?

Камера и сервер считают, что ПК с ними в одной подсети, и шлют пакеты напрямую (через коммутатор)
А ПК считает, что камера и сервер в другой подсети, и шлет пакеты через микротик.

Сделайте одну подсеть, или разделите корректно.

[Inner]

Подробите сеть на несколько vlan. Тогда и проблем с разными масками не будет. В логике микрота это уже будет восприниматься как разные физические порты. Так и маршруты проще построить