Два микротика в цепочке, отвод трафика манглом с первого узла на сторонний третий узел и возврат его обратно в цепочку

[sheft]

Вроде элементарная схема, но лыжи не едут...

 

На R2 навешиваю метки манглом по нужным критериям, в таблице маршрутов добавил 0.0.0.0 с IP R3 - трафик ушел как положено.

На R3 трафик был обработан и ушёл на R1, без ната и прочих манипуляций.

R1 трафик получил и выплюнул в интернет, узел из интернета ответил, пакет вернулся на R1 и спустился на R2 согласно таблице маршрутизации и далее к клиентам.. Всё работает, но трафик асимметричный.

Нужно вернуть пакеты тем же путем как они ушли в инет через R3... и вот тут какая то засада, хотя казалось бы что проще...

На R1 создаю правило на маркировку в мангле

add action=mark-routing chain=prerouting disabled=no in-interface=vlan75 new-routing-mark=route_75 passthrough=no

влан75 - это уже принудительно созданный интерфейс с ip 10.0.0.1/30

 

и два правила в роуты, метка в таблицах создана

add disabled=no distance=10 dst-address=192.168.0.0/22 gateway=10.0.0.2 pref-src="" routing-table=route_75 scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=20 dst-address=0.0.0.0/0 gateway=91.х.х.х pref-src="" routing-table=route_75 scope=30 suppress-hw-offload=no target-scope=10

но не работает как нужно, счётчик в мангле работает, количество трафика совпадает с исходящим от R3, тоесть метки навешиваются, в connections это видно, но обратный трафик убегает на R2 напрямую.

Ещё смущает что в логах на пакете есть входящий интерфейс input: in:uplink

а вот исходящий - out:(unknown 0)

 

если включить на R3 нат, то всё собственно работает, и трафик начинает бегать симметрично, но нюанс в том что этот нат мне как раз и не интересен

[DeLL]

Надо сначала делать маркировку соединений, а потом уже маркированное соединение пускать по отдельной таблице маршрутизации, иначе как микрот узнает, что трафик, который является ответом - что он это именно он и его надо послать на R3?

[sheft]

делал так сначала, сначала connmark по интерфейсу in, потом уже марк-роутинг по коннекшен-марку, поведение аналогичное, и впринципе маркировка в два этапа применяется для снижения нагрузки... потом уже упростил до прямой маркировки пакетов на роутинг, чтобы понять где грабли

 

но, кстати, при маркировке соединений объем трафика был похож на ин+аут, условно входящий от R3 20-30мбит, а в правиле мангла отображалось ~300мбит

[jffulcrum]

42 минуты назад, sheft сказал:

add action=mark-routing chain=prerouting disabled=no in-interface=vlan75

ЕМНИП In-interface сработает только на то, что привязано к этому интерфейсу. т.е. на 10.0.0.0, подсети за ним попасть совершенно необязательно должны, особенно если они есть в глобальной таблице. . И оно вообще смысла не имеет, т.к. вам-то надо завернуть трафик с интернет обратно на R3. Тут только мангл по dst-address-list, да, это ресурсобольно.

[sheft]

8 минут назад, jffulcrum сказал:

Тут только мангл по dst-address-list, да, это ресурсобольно.

пробовал самым первым вариантом, условия для маркировки коннекшен теже что на R2 при ответвлении пользовательского трафика, адрес листы на destination.. уже потом создал интерфейс отдельный, чтобы его указывать

 

И всё таки, при указании интерфейса- метки мангл навешивает на весь трафик, который приходит на интерфейс, об этом говорит и объем в правилах, который совпадает с исходящим на счётчиках на R3 и таблица connection, там соединения помечены

[jffulcrum]

1 час назад, sheft сказал:

add disabled=no distance=10 dst-address=192.168.0.0/22 gateway=10.0.0.2 pref-src="" routing-table=route_75 scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=20 dst-address=0.0.0.0/0 gateway=91.х.х.х pref-src="" routing-table=route_75 scope=30 suppress-hw-offload=no target-scope=10

Попробуйте укажите тогда тут тупо не gateway, а интерфейс

[sheft]

1 час назад, jffulcrum сказал:

Попробуйте укажите тогда тут тупо не gateway, а интерфейс

сделал, поведение не изменилось....

в мангле два правила, коннекшен марк с порта in (или по дестинейшн адрес листам) - маркирует, трафик по обоим условиям показывает одинаковый объем, трафик совпадает с трафиком уходящим с R3 в R1

второе правило - марк роутинг по условию - марк коннекшн

при включении второго правила резко падает трафик, пакетрейт с ~10000 до 2000, что то ползает, но трафик нормально ходить перестает...

 

что то закрадываются сомнения насчёт R3.. может в нём собака порылась, придётся наверное вместо него поставить ещё один микрот с зеркалированием и сниффером смотреть что происходит. Какое то абсолютно нелогичное поведение..

[sirmax]

3 часа назад, sheft сказал:

Вроде элементарная схема, но лыжи не едут...

 

На R2 навешиваю метки манглом по нужным критериям, в таблице маршрутов добавил 0.0.0.0 с IP R3 - трафик ушел как положено.

На R3 трафик был обработан и ушёл на R1, без ната и прочих манипуляций.

R1 трафик получил и выплюнул в интернет, узел из интернета ответил, пакет вернулся на R1 и спустился на R2 согласно таблице маршрутизации и далее к клиентам.. Всё работает, но трафик асимметричный.

Нужно вернуть пакеты тем же путем как они ушли в инет через R3... и вот тут какая то засада, хотя казалось бы что проще...

На R1 создаю правило на маркировку в мангле

add action=mark-routing chain=prerouting disabled=no in-interface=vlan75 new-routing-mark=route_75 passthrough=no

влан75 - это уже принудительно созданный интерфейс с ip 10.0.0.1/30

 

и два правила в роуты, метка в таблицах создана

add disabled=no distance=10 dst-address=192.168.0.0/22 gateway=10.0.0.2 pref-src="" routing-table=route_75 scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=20 dst-address=0.0.0.0/0 gateway=91.х.х.х pref-src="" routing-table=route_75 scope=30 suppress-hw-offload=no target-scope=10

но не работает как нужно, счётчик в мангле работает, количество трафика совпадает с исходящим от R3, тоесть метки навешиваются, в connections это видно, но обратный трафик убегает на R2 напрямую.

Ещё смущает что в логах на пакете есть входящий интерфейс input: in:uplink

а вот исходящий - out:(unknown 0)

 

если включить на R3 нат, то всё собственно работает, и трафик начинает бегать симметрично, но нюанс в том что этот нат мне как раз и не интересен

я прошу прощения, недопонимаю что вы хотите получить? Тут же только один выход в мир, зачем полиси раутинг?

[sheft]

нужно ответвить часть клиентского трафика для "обработки" его на R3 чтобы условно не ставить R3 в разрез между R1 и R2, и не гонять всё через R3 и не менять настроек клиента, шлюзом у клиента должен как был так и остаться R2.

На R2 прокатило, трафик завернулся на R3, а с обратным на R1 проблема, пакеты стекают напрямую в R2 и к абонентам минуя R3

[jffulcrum]

покажите полную таблицу маршрутизации с R1. И правила SRC-NAT

[sheft]

24 минуты назад, sirmax сказал:

Тут же только один выход в мир, зачем полиси раутинг?

выход в мир один, а вот выходов в лан - два

[sirmax]

39 минут назад, sheft сказал:

выход в мир один, а вот выходов в лан - два

По схеме тоже один

 

те вы хотите взять одного или группу клиентов Лан и завернуть их в r3? Как и обратный трафик? (Скажем с целью фильтрации)
 

я правильно уловил?

[sheft]

в нате два маскарада для ip r2 и r3, и нетмаппинг для локалки сеть в сеть белых адресов

 

 

3 минуты назад, sirmax сказал:

те вы хотите взять одного или группу клиентов Лан и завернуть их в r3? Как и обратный трафик? (Скажем с целью фильтрации)
 

я правильно уловил?

всё верно, и исходящий по адресам назначения завернуть получилось.

[sirmax]

36 минут назад, sheft сказал:

в нате два маскарада для ip r2 и r3, и нетмаппинг для локалки сеть в сеть белых адресов

 

 

всё верно, и исходящий по адресам назначения завернуть получилось.

Ну а входной хостроутами с /32? 

 

В линуксе можно делать более чем одну таблицу роутинга и я уверен что в микротик тоже это завезли 

и решить задачу вообще без маркировок 

[sheft]

5 минут назад, sirmax сказал:

Ну а входной хостроутами с /32? 

 

В линуксе можно делать более чем одну таблицу роутинга и я уверен что в микротик тоже это завезли 

и решить задачу вообще без маркировок 

а что дадут хостроуты /32.. они же весь трафик определённых, указаных в таблице клиентов завернут перманентно... а мне нужен, скажем трафик идущий на яндекс

[sirmax]

23 минуты назад, sheft сказал:

мне нужен, скажем трафик идущий на яндекс

Этот момент я пропустил

 

тогда вторая таблица и что то вроде

 

ip rule add from yandex to client to table2

Я завтра гляну как пбр по- микротиковски без маркировок делать но вроде можно 

[Saab95]

Включаете OSPF.

На роутере R3 создаете статические маршруты на пустой интерфейс с нужными подсетями, например подсети яндекса.

В настройках OSPF разрешаете анонсирование статических маршрутов. Теперь все на сети знают, что эти подсети находятся за роутером R3.

Далее маркировкой маршрутов заворачиваете весь трафик с роутера R3 в сторону не локальных адресов на роутер R1 и все заработает.

[sheft]

разобрался, дело не в микротике, правила всё таки отрабатываются..

пересоздал ещё раз маркировку манглом на R1, но маршрут по меткам через R3 заменил шлюзом R1 172.16.0.1 (по сути продублировал статический маршрут к внутренним сетям), трафик в графиках показался правильным, выделил тестовую машинку и добавил ещё по одному правилу в манглах, что бы по её sourceIP навешивались метки, -трафик тестовой машинке бегает как и задумано, согласно меткам и по маршрутам как указано.

Дело оказалось в R3 - это кинетик, и несмотря на статические маршруты и разрешающие правила фаервола, что то входящий транзитный трафик режет...

 

 

 

  тут уже были в соседних топиках вопросы к логике кинетика и тому что не всё можно добавить через вэбморду..

В 31.10.2017 в 10:57, alibek сказал:

Может кому пригодиться.

Чтобы все заработало, добавил такую конфигурацию:

access-list VPN_ANY
  permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
  exit
!
interface FastEthernet0/Vlan30
  ip access-group VPN_ANY out
  exit
!
interface FastEthernet0/Vlan100
  ip access-group VPN_ANY out
  exit

Для permit ip пришлось обновиться, на старых версиях можно указывать только icmp/tcp/udp.

 

адаптировал под себя, добавил, перезагрузился, но что то не работает с входящим на wan транзитом...

[DeLL]

Аааа, так все дело было в кинетике?! А что ж вы молчали

Кинетики - устаревшая технология. Выкинуть и не использовать. Просто нужно больше микротиков! *сарказм

[sirmax]

13 часов назад, sheft сказал:

разобрался, дело не в микротике, правила всё таки отрабатываются..

пересоздал ещё раз маркировку манглом на R1, но маршрут по меткам через R3 заменил шлюзом R1 172.16.0.1 (по сути продублировал статический маршрут к внутренним сетям), трафик в графиках показался правильным, выделил тестовую машинку и добавил ещё по одному правилу в манглах, что бы по её sourceIP навешивались метки, -трафик тестовой машинке бегает как и задумано, согласно меткам и по маршрутам как указано.

Дело оказалось в R3 - это кинетик, и несмотря на статические маршруты и разрешающие правила фаервола, что то входящий транзитный трафик режет...

 

 

 

  тут уже были в соседних топиках вопросы к логике кинетика и тому что не всё можно добавить через вэбморду..

 

адаптировал под себя, добавил, перезагрузился, но что то не работает с входящим на wan транзитом...

Я имел ввиду под упрощением конструкции типа
 

[sirmax@2011UAS-2HnD] /routing/rule> add src-address=1.1.1.1 dst-address=2.2.2.2 action=lookup table=table1

Я давно не делал но мне кажется это наиболее простой способ полиси-роутинга

[sheft]

1 час назад, sirmax сказал:

/routing/rule> add src-address=1.1.1.1 dst-address=2.2.2.2 action=lookup table=table1

Я давно не делал но мне кажется это наиболее простой способ полиси-роутинга

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

[sirmax]

21 минуту назад, sheft сказал:

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

Как раз нет, я в семерке не проверял, а в шестерке оно было но в другом меню