[alibek]

Есть RB3011, версия 6.43.11.

В порт 1 подключен аплинк1, дающий доступ по выделенной линии (IP-адреса прописаны статикой), интерфейс называется eth1-pri. В порт 2 подключен аплинк2, дающий доступ по PPPoE (IP-адрес динамический, может быть серым), физический интерфейс называется eth2-alt, PPPoE-интерфейс называется pppoe-alt. Оба интерфейса включены в группу inet. Локальные интерфейсы объединены в два моста, bridge-lan и bridge-vpn.

Есть два address-list: acl-internet (содержит 192.168.xxx.0/24) и acl-alt (содержит отдельные хосты из 192.168.xxx.0/24).

acl-internet должен ходить в интернет через аплинк1, acl-alt должен ходить в интернет через аплинк2.

Сейчас задана следующая конфигурация:

...
/ip firewall filter add action=accept chain=forward connection-state=established
/ip firewall filter add action=accept chain=forward connection-state=related
/ip firewall filter add action=accept chain=forward protocol=icmp
/ip firewall filter add action=accept chain=forward out-interface-list=inet src-address-list=acl-internet
...
/ip firewall mangle add action=mark-routing chain=prerouting new-routing-mark=alt passthrough=yes src-address-list=acl-alt
...
/ip firewall nat add action=masquerade chain=srcnat out-interface=pppoe-alt src-address-list=acl-alt
/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri protocol=icmp src-address-list=acl-internet to-addresses=A.B.C.D
/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri protocol=tcp src-address-list=acl-internet to-addresses=A.B.C.D to-ports=1024-49151
/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri protocol=udp src-address-list=acl-internet to-addresses=A.B.C.D to-ports=1024-49151
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=inet src-address-list=acl-internet
...
/ip route add distance=1 gateway=pppoe-alt routing-mark=alt
/ip route add distance=2 gateway=A.B.C.X
/ip route add distance=5 gateway=pppoe-alt
...

По моей задумке должно получится следующее:

1. В firewall разрешается форвардинг наружу.
2. В таблицу маршрутов добавляется три маршрута: альтернативный для помеченных пакетов, основной для всего остального и альтернативный в качестве резервного (если вдруг основной аплинк упадет).
3. Для пакетов из acl-alt проставляется routing-mark=alt.
4. Для пакетов из acl-alt, ходящих через аплинк2 (в соответствии с таблицей маршрутизации) делается маскарадинг. Для icmp/tcp/udp делается src-nat через аплинк1. Для остального (которого в нормальном случае быть не должно) делается маскарадинг через какой-нибудь внешний интерфейс.

Все верно?

[.None]

IMHO

1,2,3 верно

4 работать будет, но не имеет смысла фильтровать в правилах src-nat/masquerade по каким либо критериям, кроме указания out-interface. любой пакет вылетевший с интерфейса аплинка должен иметь ip адрес этого интерфейса, независимо от протокола и адреса источника, поэтому правила 

/ip firewall nat add action=masquerade chain=srcnat out-interface=pppoe-alt src-address-list=acl-alt
/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri protocol=icmp src-address-list=acl-internet to-addresses=A.B.C.D
/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri protocol=tcp src-address-list=acl-internet to-addresses=A.B.C.D to-ports=1024-49151
/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri protocol=udp src-address-list=acl-internet to-addresses=A.B.C.D to-ports=1024-49151
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=inet src-address-list=acl-internet

можно заменить 1 правилом

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=inet

а любую фильтрацию необходимо делать в firewall filter

 

[alibek]

Я слышал, что маскарадинг в микротиках работает очень загадочно и его при любой возможности нужно заменять на src-nat. А для src-nat нужно задавать протоколы и порты.

[.None]

нормально работает, и особой разницы по производительности между маскарадом и src-nat, в вашем случае не заметите

[McSea]

7 hours ago, alibek said:

Я слышал, что маскарадинг в микротиках работает очень загадочно и его при любой возможности нужно заменять на src-nat. А для src-nat нужно задавать протоколы и порты.

Не загадочно, а есть рекомендации при возможности (постоянные IP) использовать src-nat вместо маскарадинга.

(См. https://mum.mikrotik.com/presentations/EU17/presentation_4058_1490948376.pdf)

 

Т.е.  

/ip firewall nat add action=src-nat chain=srcnat out-interface=eth1-pri to-addresses=<Public_IP>

+ одно правило маскарадинга для PPPoE

/ip firewall nat add action=masquerade chain=srcnat out-interface=pppoe-alt

 

[Saab95]

Там в этими правилами в интернете много чего указано. Просто каждая настройка подходит для своих нужд, а вот работа с out-interface как раз и не рекомендуется. Если взять пример выше, то статический IP можно делать через SRCNAT, а вот зачем у него указывать out-interface, если уже есть привязка к IP и микротик сам знает на каком интерфейсе он установлен? Аналогично и второму правилу с PPPoE - там достаточно указать маскард, не привязывая к интерфейсу. И все распределение трафика какие абоненты куда ходят делать в манглах, отправляя нужный на белый IP, а все остальное пойдет через маршрут по умолчанию.

[McSea]

12 hours ago, Saab95 said:

Просто каждая настройка подходит для своих нужд, а вот работа с out-interface как раз и не рекомендуется.

Кем и где не рекомендуется ? Я привел пример не "в интернете", а из презентации на MUM. 

А маскарад без указания интерфейса приводит к NAT-у между внутренними подсетями, когда там обычно нужен простой роутинг.

 

 

Edited February 8, 2019 by McSea

[Saab95]

В 08.02.2019 в 15:55, McSea сказал:

Кем и где не рекомендуется ? Я привел пример не "в интернете", а из презентации на MUM. 

На этих презентациях многие делятся рассказами вида "как я провел это лето".

 

В 08.02.2019 в 15:55, McSea сказал:

А маскарад без указания интерфейса приводит к NAT-у между внутренними подсетями, когда там обычно нужен простой роутинг.

Что бы такого не случалось, достаточно указать исключения вида src адрес такой, то, dst адрес - не локалка. Если адресов много - создать списки для каждого направления.

[McSea]

1 hour ago, Saab95 said:

На этих презентациях многие делятся рассказами вида "как я провел это лето".

Данная презентация от самого микротика, иначе я бы не стал на нее ссылаться.

1 hour ago, Saab95 said:

Что бы такого не случалось, достаточно указать исключения вида src адрес такой, то, dst адрес - не локалка. Если адресов много - создать списки для каждого направления.

И чем это лучше указания выходного интернет интерфейса(ов) ?  Когда точно известно, что весь трафик выходящий из него надо натить.

 

Edited February 10, 2019 by McSea

[Saab95]

2 часа назад, McSea сказал:

И чем это лучше указания выходного интернет интерфейса(ов) ?  Когда точно известно, что весь трафик выходящий из него надо натить. 

Все прелести начнутся, когда поверх этого интерфейса какой-то туннель поднимут.

Тут можно бесконечно обсуждать лучше или хуже, только надо понимать одну вещь - всегда отсутствие каких-то привязок лучше. И там, где этого можно избежать, работать только с IP протоколами.

[LostSoul]

2 часа назад, McSea сказал:

Данная презентация от самого микротика, иначе я бы не стал на нее ссылаться.

И чем это лучше указания выходного интернет интерфейса(ов) ?  Когда точно известно, что весь трафик выходящий из него надо натить.

 

 

тем , что микротик может начать NAT-ить и локально порожденный им трафик неожиданным  и противоестественным образом.

 

[McSea]

23 minutes ago, LostSoul said:

тем , что микротик может начать NAT-ить и локально порожденный им трафик неожиданным  и противоестественным образом.

Отсутствие прописанного выходного интерфейса в правиле маскарадинга никак не поможет исключить такой трафик.

 

В любом случае, чтобы исключить какой-то конкретный трафик, понадобятся дополнительные условия в правиле.

Убрав выходной интерфейс из правила, мы никаких доп. условий не добавляем, а наоборот, расширяем действие правила.

 

37 minutes ago, Saab95 said:

Все прелести начнутся, когда поверх этого интерфейса какой-то туннель поднимут.

Для исключения туннельного трафика просто добавляется соответствующее условие, например для ipsec это будет 

ipsec-policy=out,none

Прописывая внешний интерфейс в правило маскарадинга, не делается никаких привязок. 

А добавляется дополнительный критерий, который повышает эффективность работы файрвола, т.к. под такое правило

маскарадинга будет попадать меньше трафика.

 

 

[LostSoul]

41 минуту назад, McSea сказал:

ipsec-policy=out,none

А добавляется дополнительный критерий, который повышает эффективность работы файрвола, т.к. под такое правило

маскарадинга будет попадать меньше трафика.

 

 

Кривовато вы свой тезис обьясняете

Понятнее будет сказать так:

операция сравнения "входит ли IP-адрес в подсеть" стоит дороже ( в процессорном времени ) , чем операция "совпадение интерефейса по порядковому номеру".

При наличии в правиле и того и другого критерия, сначала будет выполнено самое "дешевое" сравнение, и уже только при его совпадении - более ресурсоемкое.

 

Поэтому, если у нас через роутер проходит 90% трафика который не нужно NAT-ить ( например локальный ) и 10% который натить нужно, то "выгоднее" интерфейс указать, чтоб 90% нагрузки по проверке данного правила было срублено на "дешевой" стадии проверки.

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

( разумеется, если вы четко понимаете что делаете )

 

 

[Saab95]

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

Для исключения туннельного трафика просто добавляется соответствующее условие, например для ipsec это будет 

А если другие типы туннелей, разные и много?

 

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

Поэтому, если у нас через роутер проходит 90% трафика который не нужно NAT-ить ( например локальный ) и 10% который натить нужно, то "выгоднее" интерфейс указать, чтоб 90% нагрузки по проверке данного правила было срублено на "дешевой" стадии проверки.

А если это роутер, у которого нет четкого выходного интерфейса, как быть? Например при работе на BGP?

[LostSoul]

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

А если это роутер, у которого нет четкого выходного интерфейса, как быть? Например при работе на BGP?

Ну что значит "нету"?

Если на одном( нескольких )  из интерфейсов данного роутера висит какая-то внутренняя подсеть , которую нужно "маскарадить" ( натить )   - то это будут внутренние интерфейсы.   А все те интерфейсы , которые связаны по bgp  с внешними сетями - будут внешние.

 

То есть что-то вроде

 

/ip firewall nat add chain=srcnat out-interface-list=WANS src-address=192.168.0.0/24 action=src-nat to-addresses=185.246.1.1  

Не знаю , честно говоря, что в микротике "дешевле"  - два отдельных правила с interface-out или одно с interface list на 2 интерфейса.

 

если же это просто обычный bgp роутер  без клиентской сети , то зачем на нем что-либо NAT-ить?

 

 

[McSea]

6 hours ago, Saab95 said:

А если другие типы туннелей, разные и много?

Что-то я сходу не могу вспомнить другой тип туннеля без своего интерфейса, кроме ipsec.

Не подскажете, какой ?

 

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

если для какой-то конфигурации нужны дополнительные условия, пусть они будут.

 

Edited February 11, 2019 by McSea