Dual Wan, переключение и очередность правил

sarge · 08 янв 2018, 15:42

Всем доброго здоровья после праздников :-)

Недавно сменил шлюзы в офисах на Mikrotik, полет нормальный, но когда умер(по закону подлости на праздники) основной канал и я переключил все вручную на ISP2, то появились вопросы.
Каналы должны переключаються через netwatch, т.е. по отсутствию пинга на 8.8.4.4 включается(автопереключение я не активировал пока) маршрут:
/ip route enable [find comment="ISP2"]
Вообще основные маршруты выглядят так:
/ip route add dst-address=0.0.0.0/0 gateway=XX.XX.XX.XX distance=1 comment=ISP1
/ip route add dst-address=0.0.0.0/0 gateway=YY.YY.YY.YY distance=2 comment=ISP2

Основной провайдер выдал пул белых адресов, через которые работают некоторые сервисы(через src-nat), но при переключении на другого провайдера, останется один белый IP и обычный маскарадинг.
Вот как правила выглядят сейчас:
ip firewall nat add action=masquerade chain=srcnat to-addresses=YY.YY.YY.YY comment=ISP2
::;IN
ip firewall nat add chain=dstnat dst-address=YY.YY.YY.YY action=dst-nat to-addresses=192.168.1.10 comment=VOIP-in
ip firewall nat add chain=dstnat dst-address=IP.IP.IP.IP action=dst-nat to-addresses=192.168.1.20 comment=MAIL-in
::;OUT
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.10 to-addresses=IP.IP.IP.IP comment=VOIP-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.20 to-addresses=IP.IP.IP.IP comment=MAIL-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.0/24 to-addresses=XX.XX.XX.XX comment=LOCAL-net
ip firewall nat add action=src-nat chain=srcnat to-addresses=XX.XX.XX.XX comment=ISP1

Так вот вопрос, если маскарадинг через ISP2 поставлен вначале, то не будет ли это мешать работе основного канала(сейчас все идет через ISP2)?
И если этот маскарад поставить в конце, то при переключении маршрута на ISP2, будет ли работать например сервис VoIP если правило src-nat через белый IP стоит перед этим маскарадом?

Также остался вопрос по правилам NAT, изначально я думал что правильно так:
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.10 to-addresses=IP.IP.IP.IP out-interface=eth1-wan comment=VOIP-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.20 to-addresses=IP.IP.IP.IP out-interface=eth1-wan comment=MAIL-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.0/24 to-addresses=XX.XX.XX.XX out-interface=eth1-wan comment=LOCAL-net
На самом деле заработало вот так:
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.10 to-addresses=IP.IP.IP.IP comment=VOIP-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.20 to-addresses=IP.IP.IP.IP comment=MAIL-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.0/24 to-addresses=XX.XX.XX.XX comment=LOCAL-net

P.S. RouterBOARD 750G r3
XX.XX.XX.XX - ISP1
YY.YY.YY.YY - ISP2
IP.IP.IP.IP - пул адресов от ISP1

KARaS'b · 08 янв 2018, 18:46

Упростите себе жизнь, создайте интерфейс лист и в правилах маскарада и пробросах укажите этот лист, как минимум у вас поубавится кол-во правил маскарада и пробросов.
А по поводу нетвоча, найдите тему по поводу "двух провайдеров, балансировки и отказоустойчивости", там много интересного и полезного и я там описывал свой опыт, нетвоч не очень пикольная штука, она устроит вам переключение как только выпадет первый же пакет при проверке. Лично я, что бы этого избежать, писал скрипты которые и проверяли доступность и переключали маршруты. В общем полистайте тему, там много полезного.

08 янв 2018, 20:25

Ни фига не понял про интерфейс-лист. Зачем он ТС при существующих правилах? Там и так одно правило маскарада, и опирается оно отнюдь не на интерфейсы. Да и в остальных интерфейсы не указываются.

KARaS'b · 08 янв 2018, 20:56

podarok66 писал(а):Ни фига не понял про интерфейс-лист. Зачем он ТС при существующих правилах? Там и так одно правило маскарада, и опирается оно отнюдь не на интерфейсы. Да и в остальных интерфейсы не указываются.

ну какбэ я понял, что тс пока тупо переправил все ручьями на второго прова, а спрашивает с заделом на будущее:

Так вот вопрос, если маскарадинг через ISP2 поставлен вначале, то не будет ли это мешать работе основного канала(сейчас все идет через ISP2)?

08 янв 2018, 21:00

Тогда, видимо, нужно задать ТС вопрос - а что он понимает под маскарадингом через ISP2? Если в наборе его правил первое как раз маскарадинг с комментарием ISP2... Что его не устраивает?

sarge · 08 янв 2018, 21:28

Также не понял про интерфейс-лист и зачем он?
По нетвочу вопросов нет пока, там я сделал так, что для проверки канала, пингуется адрес 8.8.4.4 причем только через ISP1.
И это более надежный вариант чем простой check-gateway

Главный вопрос заключается в очередности. Вот допустим включился маршрут с distance 1 (наладили основной ISP1) и что дальше?
Все так-же будет маскарадиться через ISP2 согласно очередности правил в NAT или нет?

Если да, то надо поставить маскарадинг через ISP2 в конце, но тогда возникает обратный вопрос, а будут ли работать сервисы VoIP после переключения на ISP2?
Они ведь будут натиться первыми, через мертвый маршрут согласно очередности...

08 янв 2018, 23:04

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

Код: Выделить всё

ip firewall nat add action=masquerade chain=srcnat out-interface=ether1

или

Код: Выделить всё

ip firewall nat add action=masquerade chain=srcnat src-address=192.168.88.0/24

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

08 янв 2018, 23:56

Мои коллеги Вам всё правильно ответили, лишь соберу в кучу и от себя как бы добавлю:

1) Сначала делается маршрутизация, ибо роутер решает куда идти пакету, и решение идёт от DST-адреса,
а уже потом при выходе пакета с внешнего интерфейса, перед этим идёт НАТ/Маскарайдинг.

Поэтому у Вас два правила НАТа должно быть,
а) правило НАТ для выхода локальной сети через ISP1
б) привило НАТ для выхода локальной сети через ISP2
порядок их не особо важен в таком контексте, ибо если пакету суждено пойти через
нужного провайдера, оно и пойдёт как надо и проНАТиться через того, кого надо.
(в обычном режиме настроек..., ибо есть режим, когда сразу используется 2-4 канала,
и часть клиентов локальной сети работают ТОЛЬКО через 2й канал, соответственно,
кого определили работать через второй канал, будут НАТиться только через НАТ-правила ISP2)

2) про списки интерфейсов, к этому надо прийти со временем, но даже имея 1-2 провайдера или
просто даже одно подключение, очень удобно создать список(и) интерфейсов и уже весь
файрвол в едином стиле будет красиво оформлен, а самое главное, что такой файрвол
переносим, его можно перенести другу/на другой микротик, задача лишь поправить
что на другом роутере переменные WAN1 и WAN2 будут уже скажем не ether1 и ether2,
а pppoe-out1-ISP1 и pppoe-out1-ISP2.
Это гибкий инструмент и не позволяет в будущем ошибаться.

3) Также и про правила НАТа хочу добавиться, их надо делать правильнее, узко-направленными,
или более точными.

4) если у Вас голая натуральная статика и нет динамических адресов и рррое, то может проще
один раз сделать рекурсивную маршрутизацию и не использовать NetWatch ?

sarge · 09 янв 2018, 10:09

Огромное спасибо за ответы,
1) Хорошо если NAT идет после роутинга, тогда файловер-схема работает.
Хочу извиниться, я конечно же привязал правила НАТ к интерфейсам, просто делал это через winbox, а когда писал здесь забыл.
Вот как оно выглядит сейчас(выделено):
ip firewall nat add action=masquerade chain=srcnat out-interface=eth2-wan comment=ISP2
::;IN
ip firewall nat add chain=dstnat dst-address=YY.YY.YY.YY action=dst-nat to-addresses=192.168.1.10 comment=VOIP-in
ip firewall nat add chain=dstnat dst-address=IP.IP.IP.IP action=dst-nat to-addresses=192.168.1.20 comment=MAIL-in
::;OUT
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.10 to-addresses=IP.IP.IP.IP comment=VOIP-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.20 to-addresses=IP.IP.IP.IP comment=MAIL-out
ip firewall nat add action=src-nat chain=srcnat src-address=192.168.1.0/24 to-addresses=XX.XX.XX.XX comment=LOCAL-net
ip firewall nat add action=src-nat chain=srcnat to-addresses=XX.XX.XX.XX out-interface=eth1-wan comment=ISP1

Собственно это и есть выход локалки, просто в случае ISP1 нужно присвоить разные белые IP сервисам и остальной локалке, а в случае ISP2(там один IP) простой маскарад.
Или, если я правильно вас понял, все же нужно добавить вот это:
ip firewall nat add action=masquerade chain=srcnat src-address=192.168.1.0/24 out-interface=eth2-wan comment=ISP2 (мне кажется это лишнее)?
Повторюсь, пока нужен только файловер, т.е. переключение на резерв ISP2 в случае падения основного ISP1.

2) Сделаю.
3) Да, все правильно, поэтому я и задал вопрос в конце, почему я не смог привязать правила выхода к определенному интерфейсу.
Но пока работает и хорошо :-)

4) Именно натуральная статика и есть, никакой динамики и ppoe. Однако у меня в netwatch, кроме скрипта смены шлюза забит еще и скрипт удаления старых соединений из «Connection tracking»:
:foreach i in=[/ip firewall connection find dst-address~":5060"] do={ /ip firewall connection remove $i }
Это нужно для Asterisk. Как выполнить скрипт в рекурсивной маршрутизации, я не нашел.

sarge · 09 янв 2018, 14:20

Сегодня восстановили ISP1, все сработало как и полагается.
Поднял маршрут основного провайдера и все пошло через него.
Далее буду тестировать netwatch, если нет более простых альтернатив.

Dual Wan, переключение и очередность правил

Вход • Регистрация