Mikrotik и wildcard/u32

[ThreeDHead]

Необходимо с помощью Microtik'а сделать балансировку исходящих с 10-й сети пакетов, на 4 разных сервера. При этом использовать нужно последние два бита src IP-адреса.

 

На L3 коммутаторе делается с помощью wildcard, приблизительно так:

!
ip access-list extended acl-local-to-inet-gate-1
10 permit ip 10.0.0.0 0.255.255.252 any
!
ip access-list extended acl-local-to-inet-gate-2
10 permit ip 10.0.0.1 0.255.255.252 any
!
ip access-list extended acl-local-to-inet-gate-3
10 permit ip 10.0.0.2 0.255.255.252 any
!
ip access-list extended acl-local-to-inet-gate-4
10 permit ip 10.0.0.3 0.255.255.252 any

 

На Linux-based, почти так-же, только с помощью iptables -m u32 --u32 "..."

 

Как такое повторить на Mikrotik'е?

[ChargeSet]

http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Mangle

[ThreeDHead]

http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Mangle

Дык я читаю документации. Где там про wildcard или u32?

[ChargeSet]

Дык я читаю документации. Где там про wildcard или u32?

Это же микротик. Он таких слов не знает. Манглом можно промаркировать пакеты от нужных хостов и засовывать их в соответствующий порт. Теоретически;)

[tartila]

Ха, вызываю Saab95, что бы он рассказал про устаревший NOTRACK в iptables :))))

[Saab95]

Вот так можно поделить всю указанную сеть пополам, соответствующие адреса будут занесены в адрес лист.

 

/ip firewall mangle
add action=add-src-to-address-list address-list=Server1 chain=prerouting per-connection-classifier=src-address:2/1 src-address=192.168.0.0/24
add action=add-src-to-address-list address-list=Server2 chain=prerouting per-connection-classifier=src-address:2/0 src-address=192.168.0.0/24

 

Если нужно поделить на большее количество раз, просто меняете 2 в правиле на 3 или 4 и т.п., соответственно будут 4/0, 4/1, 4/2 и 4/3.

 

Дальше маркируете пакеты по нужным направлениям и готово.

[ThreeDHead]

Saab95

Спасибо за подсказку, PCC делает именно это, что мне и нужно.

 

Вы предложили использовать ipset address-lists для того чтобы их на лету пополнять, и согласно этих списков маркировать и маршрутизировать.

В документации по PCC приведен пример с connmark mark-connection.

 

В связи с этим вопросы:

1. Что будет более производительным?

2. Какое максимальное количество IP-адресов может быть в address-lists - сто, двести, десят тысяч, пятьдесят тысяч?

[Saab95]

Вы предложили использовать ipset address-lists для того чтобы их на лету пополнять, и согласно этих списков маркировать и маршрутизировать.

В документации по PCC приведен пример с connmark mark-connection.

 

В связи с этим вопросы:

1. Что будет более производительным?

2. Какое максимальное количество IP-адресов может быть в address-lists - сто, двести, десят тысяч, пятьдесят тысяч?

 

1. Производительнее будет маркировать пакеты или роуты, т.к. для маркировки соединений нужно включать Connection Tracking, который отъедает половину производительности роутера.

2. Максимальное количество адресов не нормировано, 100 тысяч точно влезает.

 

Есть еще и вариант 3 - вместо action=add-src-to-address-list попробуйте сразу выполнять нужное вам действие, например маркировать маршрут, тогда адрес листы не потребуются вовсе.

 

[ThreeDHead]

Saab95, каким образом формируется хеш для PCC?

 

По хорошему должно быть всё просто, например для 255.255.255.255:

255*(256*256*256) + 255*(256*256) + 255*(256) + 255 = 4294967295

Что соответствует документации: Denominator ::= 1..4294967295

 

Создаю правила для проверки:

[admin@MikroTik] /ip firewall mangle> print
Flags: X - disabled, I - invalid, D - dynamic 
0    chain=output action=accept dst-address=!10.0.0.0/8 per-connection-classifier=dst-address:2/0 log=no log-prefix="" 
1    chain=output action=accept dst-address=!10.0.0.0/8 per-connection-classifier=dst-address:2/1 log=no log-prefix="" 

Проверяю под какое из правил попадают пакеты:

ping 1.1.1.0	- 1
ping 1.1.1.1	- 0
ping 1.1.1.2	- 0
ping 1.1.1.3	- 1
ping 1.1.1.4	- 1
ping 1.1.1.5	- 0
ping 1.1.1.6	- 0
ping 1.1.1.7	- 1
ping 1.1.1.8	- 0
ping 1.1.1.9	- 0
ping 1.1.1.10	- 0
ping 1.1.1.11	- 1
ping 1.1.1.12	- 0
ping 1.1.1.13	- 0
ping 1.1.1.14	- 1
ping 1.1.1.15	- 0
ping 1.1.1.16	- 0

Какой-то разброд и шатание. Как понять куда попадет каждый пакет в указанной схеме?

[Saab95]

Почему же вы chain=output поставили? Обычно все с forward работает.

[ThreeDHead]

Почему же вы chain=output поставили? Обычно все с forward работает.

Это что-то кардинально меняет?

[ThreeDHead]

Короче, генерация хэша для PCC - тайна покрытая мраком

Т.е. использовать PCC могу, но знать куда какой пакет полетит - не моё собачье дело. Окей.

Теперь понимаю негодование некоторых коллег по поводу отношения разработчиков Микротика к пользователям их систем.

[Saab95]

Это что-то кардинально меняет?

 

Меняет, output и input работают по отношению к микротику, а не проходящему через него трафику. По output может применяться только адрес назначения - dst, а по input только адрес источника - src.

[ThreeDHead]

Меняет, output и input работают по отношению к микротику, а не проходящему через него трафику. По output может применяться только адрес назначения - dst, а по input только адрес источника - src.

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

 

Но мой вопрос был связан с другим - как формируется хэш для PCC? Как оказалось, никто этого не знает.

Разработчики придумали стрёмную функцию для iptables файрвола, которая не даёт мне возможности проследить, какой пакет ею будет отобран. И это плохо.

 

Ну да ладно, отложив полемику в сторону, подскажите пожалуйста - как принято в RouterOS собирать деревья для iptables файрвола?