Pull to refresh

Comments 60

UFO just landed and posted this here
Указывать гейт провайдера плохая идея. Бывают провайдеры с несколькими гейтами. Использую рекурсивную маршрутизацию для резервирования через 3г модем. Поставил клиенту, а у провайдера оказалось множество гейтов. Поймал 3 разных, после этого в маршруте пришлось указывать интерфейс, а не гейт.
MikroTik чрезвычайно гибкий инструмент, на мой взгляд, так что все зависит от задачи.
Failover можно и скриптом сделать (я делал вот так https://habrahabr.ru/post/271747/)
В моем случае (и я уверен, что для многих других этот вариант тоже подойдет) это вполне решение (я про указание гейта провайдера).
Тут в другом проблема. Пример из вашего конфига. Указываем у первого провайдер гейт 95.11.29.254, а у него (о чем мы не знаем) есть второй гейт 95.11.29.253. Следовательно первый провайдер будет считаться недоступным, т.к. гейт не виден. Тут два варианта — либо указывать интерфейс, либо узнавать все возможные гейты. Второй вариант конечно предпочтительней, но в техподдержке иногда работают не очень умные люди, которые не знают что это и к чему.
Это не проблема конфига. Это проблема упоротых провайдеров не умеющих нормально обеспечить отказоустойчивость для основных типов клиентских устройств.
Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.

Это проблема клиента этого провайдера, а следовательно и моя. И её надо решать. Гейт меняется при реконнекте pppoe. Как и почему — дело десятое. Задача — переход на резерв и возврат обратно. Если указан гейт, то обратно маршрут не переключится.
И что криминального указывать маршрут через интерфейс, а не гейт? Речь идет конкретно о МТ.
Я уже писал — здесь Failover скриптом бы обеспечил.
Вы не знает разницы между соединениями точка-точка и подключением через обычный ethernet при наличии broadcast-домена. Это разные случаи и методики маршрутизации и адресации будут разные.
Подумайте как следует над строчками
/ip address
add address=95.11.29.240/24 interface=ISP1 network=95.11.29.0
add address=5.35.59.162/27 interface=ISP2 network=5.35.59.160

Посмотрите как строится адресация на вашем PPPoE. Сравните.
Если позволите, то коллеги имеют ввиду следующее, для сред с множественным доступом, а Ethernet одна из таких, это приведёт к тому, что маршрутизатор будет считать, что адрес напрямую подключен к интерфейсу. Что приведёт к отправке ARP запросов для определения соответствия сетевого адреса, канальному. Если у вашего ISP не будет активирована функция Proxy ARP, то на ARP запрос не кому будет ответить.

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

Не претендую на истину в последней инстанции, если где-то ошибся, буду рад услышать где. :)
Автор, я так понимаю, не совсем в теме.
Вместо того что-бы маркировать (routing-mark=) в данном случае запросто можно обойтись:
/ip route rules
раскидав по таблицам маршрутизации.

Так как описано в статье делалось на микротиках очень давно.

как пример, чтоб пакеты уходи с того интерфейса, на который пришли:
/ip route rule
add interface=vlan2 src-address=192.168.1.1 table=RES
add interface=vlan3 src-address=172.16.1.1 table=OFC

/ip route
add check-gateway=arp distance=8 gateway= 192.168.1.2 routing-mark=RES
add check-gateway=arp distance=9 gateway=172.16.1.2 routing-mark=OFC

я имею ввиду, что вместо того чтоб городить кучу правил в mangle, достаточно направить в отдельную таблицу маршрутизации.
Вообще, может понадобиться сделать пробросы портов с двух каналов на один сервер во внутренней сети (например, почтовый). В таком случае, насколько мне известно, правилами в стиле iproute2:
ip route add from 192.168.1.2 lookup ISP1

не обойтись. В этом случае CONNECTION TRACKING и пригодится.
В данном случае не имеет значения куда и что пробрасывать, совершенно.
Мы просто меняем механизм маршрутизации с управления на файрволе в таблице mangle, на управление в помощью ip rule.
Так же как в линукс-е.

Конечно, в некоторых исключительных случаях не обойтись без mangle, но в данном случае он абсолютно не нужен.
fix: * ip rule add from 192.168.1.2 lookup ISP1_table

Ну и да, правила выбора таблицы маршрутизации позволяют выбирать таблицу на основе маркера пакета. В linux так:
ip rule add from all fwmark 0x1 lookup ISP1_table

Значит и в mikrotik можно
ну так а я о чём «с утра» написал?
а вот когда речь пойдет о полноценном PBR, вот тогда без mangle не обойтись.
Вместо того что-бы маркировать (routing-mark=) в данном случае запросто можно обойтись:
/ip route rules
раскидав по таблицам маршрутизации.

Давайте представим нормальную ситуацию, когда все внешние шлюзы считаются доступными.
Обратите внимание — сеть маскарадится в три направления, т.е. web-сервер не имеет своего белого IP. Это важно, т.к. в ответе web-сервера src-ip меняется в зависимости от направления.
Поскольку маршрутизация тогда будет идти попакетно, на основе src-ip, все ответы web-сервера пойдут через один и тот же шлюз, первым указанный в таблице, куда его приведет /ip route rule (при src=192.168.0.83 адрес web-сервера). Пусть это будет как у автора «95.11.29.254»
Тогда клиент обратившийся ко второму внешнему IP, через второго провайдера (5.35.59.162/27 interface=ISP2 ) всё равно будет получать ответы WEB-сервера через ISP1 с IP 95.11.29.254 и соединение не установится.

Установка соединения при предложенном /ip route rule
Tcp-Запрос клиента:
(src-ip: 1.1.1.1:52000, dst-ip:5.35.59.162:80) -> dst-nat -> routing -> (src-ip: 1.1.1.1:52000, dst-ip:192.168.0.83:80)

Ответ web-сервера:
(src-ip: 192.168.0.83:80, dst-ip:1.1.1.1:52000) -> routing-> src-nat -> (src-ip: 95.11.29.254:80, dst-ip:1.1.1.1:52000)

Клиент запросивший соединение с 5.35.59.162:80, получит ответ с 95.11.29.254:80 и обломится.
Если взять сеть автора и есть, к примеру, правило
/ip firewall nat
add action=dst-nat chain=dstnat dst-address-list=self-ext dst-port=80,443 protocol=tcp to-addresses=192.168.0.11

соединение установлено через ISP2
Каким образом вы предлагаете, используя ip route rules, отправлять пакеты через тот же интерфейс?
Я этого и не предлагаю. Это предложил shadowalone. Вы не тому отвечаете.
Возможно вы были не внимательны, это как раз ответ на сообщение shadowalone, а не ваше.
Все немного не так, в вашем примере вы используете vlan-ы, чтобы понимать по какому каналу пришел запрос на web-сервер, чтобы отправить ответ по нему-же.
У автора же, сервер принимает на и отвечает с одного и того-же адреса, если я все верно понял.

Однако, это не отменяет того, что автор сильно перемудрил, используя vlan-ы или на худой конец просто alias-ы можно было бы обойтись 3-мя route rule и 3-мя роутами.
Автор поста как раз vlan-ы НЕ использует, у него всё здраво. Это shadowalone что-то про интерфейсы с именами «vlan» написал.
Не можно было бы обойтись.
Дайте конфиг, где вы достигаете ровно той же цели, что и я только за счет роутрулов.
Смотрите, объясню, как это всегда работало у меня.
На web-server добавляете ip alias -ы (как я выше написал, можно vlan-ами, но для упрощения объясню с алиасами).
В результате ваш сервер доступен на N внутренних адресах.
На роутере настраиваете DNAT, где каждый внешний ip меняете на свой внутренний ip:
1.2.3.4 -> 192.168.0.2
4.3.2.1 -> 192.168.0.3
5.4.3.2 -> 192.168.0.4
Теперь с помощью ip rule на роутере добавляете:
from 192.168.0.2 lookup ISP1_TABLE
from 192.168.0.3 lookup ISP2_TABLE
from 192.168.0.4 lookup ISP3_TABLE
В таблицах роуты для специфического провайдера.
Вот и все, теперь ваш web-сервер доступен на всех внешних адресах.
коллега, прошу прощения, но вы показали, как не надо делать
у меня правило ната выглядит одной строкой, в которой можно указать либо лист с интерфейсами, либо лист с внешними пипишками.
лукапом можно убрать мангловый марк, т.к. остальное сделает контрак, быть может оно и сработает, даже если есть балансировка (не использую, т.к. возникают специфические проблемы).
хотя велосипед прикольный %)
Чем конкретно этот подход хуже 12 правил мангла для тех-же 3-х провайдеров?
дык это надо ещё lookup на линупсах лепить, ещё по 2 строки в networks на каждый ип :)
Все верно, давайте я попробую описать плюсы своего подхода (субъективно, конечно).
Опять же, не настаиваю, что это серебряная пуля, просто минусов данного решения я за много лет не нашел.
  • виден траффик конкретного провайдера и можно определить перекос балансировки (это если у вас на интерфейсе не только сервер)
  • сервер видит через какой провайдер идут запросы, что тоже, иногда, бывает необходимо
  • используя vlan-ы можно убрать траффик сервера из локальной сети (это можно сделать и с подходом автора, но тут это вписывается в модель :) )
  • теоретически, меньшая нагрузка на роутер при большом траффике (с удовольствием бы проверил, но свободной железки нет :( )
1-2. Даже не думал об этом, но да :)
Хотя в микроте это не сложно посмотреть, если история не нужна.
4. меньшая нагрузка точно, микроты до/включая 1100ah2 на гигабитных скоростях очень маркировку любят превращать в пожирание cpu, в ccr это получше выглядит
Но сирано конфига — жесть :)
Как решали без подмены днс доступность сайта а-ля hairpin nat? Тут вроде только conn mark катит, имхо
Я лично использовал DNS подход, вы знаете какие-то случаи, когда это плохо работает?
если машин для форварда много и порты для них разные — кучка dns A/AAAA записей?
А что делать с UPnP для узлов из LAN в вашем сценарии?
Как сами понимаете — никак, я UPnP не использую (старовер).
Если вам нужен UPnP — то остается вариант автора.
Вариант, но с манглом не проще разве?
Еще и на web-сервере алиасы настраивать, зачем?

А если нам нужно еще почту прокинуть, SIP, еще 50 портов, мы что, тоже будем везде алиасы вешать?
Я выше описал плюсы своего подхода, но да, у него есть и минусы.
Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.
Если же все на одном сервере, имхо, мой подход проще.
Как написали в одном паблике в ВК, после данной публикации, — «Каждый готовит MikroTik по своему»
По этому, считаю, нам не стоит продолжать полемику в поиске единственно верного решения

Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.

зачем? Не совсем понял вашу мысль.
Есть внутри web-сервер, почтовый, телефония, каждый должен иметь по несколько IP?
Возможно, я немного поспешил с выводами.
Как показали комментарии, есть много сценариев, где ваш подход выручает (UPnP, пару сотен серверов).
Возьму на заметку, спасибо.
Рад, если статья окажется полезной.
Да не, автор в теме ;)
рулсами мы не раскрасим транзитный трафик, если я ошибаюсь, то дайте конфиг.
rules lookup не рассмотрели, количество правил бы уменьшилось
решил не городить огороды и сделать все в мангл
когда конфига будет страниц в 12-50, в мангл страшно будет заглядывать
казалось бы дел на секунду, надо добавить какое-нить одно правило, а сидишь с умным лицом полчаса. В особенности ежели наличествует дикий qos ;)
забыли нарисовать аналог hairpin nat для нескольких wan, я делал через mangle, тож развесисто получается
Более элегантно это выглядело с помощью PBR(Policy Based Routing).

Если не знаете этот метод — посмотрите статью Чудина за прошлый год(в гугле «Чудин Mikrotik»)
vrf lite в комментах присутствует :)
ему доступны не напрямую, а рекурсивно через данные статические маршруты. По одному IP на брата-провайдера.

А где мы указываем статические маршруты, если они у нас имеют routing-mark, согласно вашим правилам?
Т.е. нам надо создать ещё и такие правила?


add distance=1 gateway=95.11.29.254
add distance=1 gateway=5.35.59.161

Просто если всё сделать как указано в статье, то из локальной сети ничего работать не будет, т.к. роутер будет отвечать что


[192.168.88.1] сообщает: Заданная сеть недоступна.

Да, для меня это обязательное условие.
А с этой проблемой разобрался.


Очень краткая выжимка
in-interface=ISP1 - первый провайдер (основной)
in-interface=ISP2 - второй провайдер (резервный)
in-interface=ISP3 - третий провайдер (резервный резервного)
in-interface=bridge - интерфейс локальной сети

/interface list add name=WAN

/interface list member add interface=ISP1 list=WAN
/interface list member add interface=ISP2 list=WAN
/interface list member add interface=ISP3 list=WAN

/ip route add distance=1 gateway=11.11.11.11 routing-mark=ISP1-route comment="https://habrahabr.ru/post/313342/"
/ip route add distance=1 gateway=22.22.22.22 routing-mark=ISP2-route comment="https://habrahabr.ru/post/313342/"
/ip route add distance=1 gateway=33.33.33.33 routing-mark=ISP3-route comment="https://habrahabr.ru/post/313342/"

/ip route add check-gateway=ping distance=1 gateway=8.8.8.8 comment="https://habrahabr.ru/post/313342/"
/ip route add check-gateway=ping distance=2 gateway=8.8.4.4 comment="https://habrahabr.ru/post/313342/"
/ip route add check-gateway=ping distance=3 gateway=1.1.1.1 comment="https://habrahabr.ru/post/313342/"

/ip route add distance=1 dst-address=8.8.8.8/32 gateway=11.11.11.11 scope=10 comment="https://habrahabr.ru/post/313342/"
/ip route add distance=1 dst-address=8.8.4.4/32 gateway=22.22.22.22 scope=10 comment="https://habrahabr.ru/post/313342/"
/ip route add distance=1 dst-address=1.1.1.1/32 gateway=33.33.33.33 scope=10 comment="https://habrahabr.ru/post/313342/"

/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=ISP1-conn passthrough=yes comment="https://habrahabr.ru/post/313342/"
/ip firewall mangle add action=mark-routing chain=output connection-mark=ISP1-conn new-routing-mark=ISP1-route passthrough=no comment="https://habrahabr.ru/post/313342/"

/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=ISP2-conn passthrough=yes comment="https://habrahabr.ru/post/313342/"
/ip firewall mangle add action=mark-routing chain=output connection-mark=ISP2-conn new-routing-mark=ISP2-route passthrough=no comment="https://habrahabr.ru/post/313342/"

/ip firewall mangle add action=mark-connection chain=input in-interface=ISP3 new-connection-mark=ISP3-conn passthrough=yes comment="https://habrahabr.ru/post/313342/"
/ip firewall mangle add action=mark-routing chain=output connection-mark=ISP3-conn new-routing-mark=ISP3-route passthrough=no comment="https://habrahabr.ru/post/313342/"

/ip firewall mangle add action=mark-connection chain=forward in-interface=ISP1 new-connection-mark=ISP1-conn-f passthrough=no comment="https://habrahabr.ru/post/313342/"
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=ISP1-conn-f in-interface=bridge new-routing-mark=ISP1-route comment="https://habrahabr.ru/post/313342/"

/ip firewall mangle add action=mark-connection chain=forward in-interface=ISP2 new-connection-mark=ISP2-conn-f passthrough=no comment="https://habrahabr.ru/post/313342/"
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=ISP2-conn-f in-interface=bridge new-routing-mark=ISP2-route comment="https://habrahabr.ru/post/313342/"

/ip firewall mangle add action=mark-connection chain=forward in-interface=ISP3 new-connection-mark=ISP3-conn-f passthrough=no comment="https://habrahabr.ru/post/313342/"
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=ISP3-conn-f in-interface=bridge new-routing-mark=ISP3-route comment="https://habrahabr.ru/post/313342/"
Спасибо за выжимку! А с исходящим с LAN интернетом нет проблем, при падении провайдера? Вообще, исходящий интернет как работает? Тоже в режиме резерва второго, третьего… провайдера? Или делит поровну?

Исходящий и входящий будут идти через первого по порядку рабочего провайдера и будет работать через него до тех пор, пока established соединение не будет разорвано и new connection не пойдёт через рабочего.
Удобно для торрента, если анонсирование прошло через резервного и потом основной восстановился, то соединения будут идти через основной и резерный, суммируя скорости.

Спасибо Вам, помогли с решением похожей задачи!
Спасибо за статью! У меня в mungle вместо input работает с prerouting.
Вопрос, если есть два провайдера, и по качеству они более-менее одинаковые, и хочется их чередовать, например, каждую полночь меняя местами основной и вторичный? Можно ли это реализовать как-то через вызов какого-то скрипта в планировщике?
а можно по-другому, например пусть маршруты:
/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8
add check-gateway=ping distance=2 gateway=8.8.4.4

имеют соответственно номера 4 и 5, и тогда в скрипте планировщика делать такую команду:
/ip route
set distance=1 number=5
set distance=2 number=4

при этом у них местами поменяются номера, и не надо будет через день менять команду, команда будет одна на каждый день. Я тут игрался со своим микротиком, вроде работает, прошивка последняя стабильная, 6.43.12.
можно сетить указывая на коммент, чтобы не промахнуться правилом, или еще как-то
Спасибо добрый человек, статья очень помогла.
Сколько не пытался осознать как будет работать роутинг из локальной сети так и не понял в какую таблицу будут попадать пакеты, если нет таблицы main. В итоге веб сервер за маршрутизатором ответит на обоих внешних адресах, но у локальной сети не будет интернета, ведь пакеты из локальной сети не будут промаркированы?
Sign up to leave a comment.

Articles