Comments 60
UFO just landed and posted this here
Указывать гейт провайдера плохая идея. Бывают провайдеры с несколькими гейтами. Использую рекурсивную маршрутизацию для резервирования через 3г модем. Поставил клиенту, а у провайдера оказалось множество гейтов. Поймал 3 разных, после этого в маршруте пришлось указывать интерфейс, а не гейт.
MikroTik чрезвычайно гибкий инструмент, на мой взгляд, так что все зависит от задачи.
Failover можно и скриптом сделать (я делал вот так https://habrahabr.ru/post/271747/)
В моем случае (и я уверен, что для многих других этот вариант тоже подойдет) это вполне решение (я про указание гейта провайдера).
Failover можно и скриптом сделать (я делал вот так https://habrahabr.ru/post/271747/)
В моем случае (и я уверен, что для многих других этот вариант тоже подойдет) это вполне решение (я про указание гейта провайдера).
Тут в другом проблема. Пример из вашего конфига. Указываем у первого провайдер гейт 95.11.29.254, а у него (о чем мы не знаем) есть второй гейт 95.11.29.253. Следовательно первый провайдер будет считаться недоступным, т.к. гейт не виден. Тут два варианта — либо указывать интерфейс, либо узнавать все возможные гейты. Второй вариант конечно предпочтительней, но в техподдержке иногда работают не очень умные люди, которые не знают что это и к чему.
Это не проблема конфига. Это проблема упоротых провайдеров не умеющих нормально обеспечить отказоустойчивость для основных типов клиентских устройств.
Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.
Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.
Это проблема клиента этого провайдера, а следовательно и моя. И её надо решать. Гейт меняется при реконнекте pppoe. Как и почему — дело десятое. Задача — переход на резерв и возврат обратно. Если указан гейт, то обратно маршрут не переключится.
И что криминального указывать маршрут через интерфейс, а не гейт? Речь идет конкретно о МТ.
И что криминального указывать маршрут через интерфейс, а не гейт? Речь идет конкретно о МТ.
Я уже писал — здесь Failover скриптом бы обеспечил.
Вы не знает разницы между соединениями точка-точка и подключением через обычный ethernet при наличии broadcast-домена. Это разные случаи и методики маршрутизации и адресации будут разные.
Подумайте как следует над строчками
Посмотрите как строится адресация на вашем PPPoE. Сравните.
/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 соединения, то конечно же не какой проблемы не возникнет, поскольку в этом случае, речь будет идти о среде без множественного доступа и все кадры будут содержать канальный адрес установленный в значение широковещательного адреса.
Не претендую на истину в последней инстанции, если где-то ошибся, буду рад услышать где. :)
Но, если вы указываете в качестве выходного интерфейса, интерфейс 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
Вместо того что-бы маркировать (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:
не обойтись. В этом случае CONNECTION TRACKING и пригодится.
ip route add from 192.168.1.2 lookup ISP1
не обойтись. В этом случае CONNECTION TRACKING и пригодится.
В данном случае не имеет значения куда и что пробрасывать, совершенно.
Мы просто меняем механизм маршрутизации с управления на файрволе в таблице mangle, на управление в помощью ip rule.
Так же как в линукс-е.
Конечно, в некоторых исключительных случаях не обойтись без mangle, но в данном случае он абсолютно не нужен.
Мы просто меняем механизм маршрутизации с управления на файрволе в таблице mangle, на управление в помощью ip rule.
Так же как в линукс-е.
Конечно, в некоторых исключительных случаях не обойтись без mangle, но в данном случае он абсолютно не нужен.
fix: * ip rule add from 192.168.1.2 lookup ISP1_table
Ну и да, правила выбора таблицы маршрутизации позволяют выбирать таблицу на основе маркера пакета. В linux так:
Значит и в mikrotik можно
Ну и да, правила выбора таблицы маршрутизации позволяют выбирать таблицу на основе маркера пакета. В linux так:
ip rule add from all fwmark 0x1 lookup ISP1_table
Значит и в mikrotik можно
Вместо того что-бы маркировать (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)
(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 и обломится.
Если взять сеть автора и есть, к примеру, правило
соединение установлено через ISP2
Каким образом вы предлагаете, используя ip route rules, отправлять пакеты через тот же интерфейс?
/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-ы или на худой конец просто 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-сервер доступен на всех внешних адресах.
На 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 катит, имхо
Хотя в микроте это не сложно посмотреть, если история не нужна.
4. меньшая нагрузка точно, микроты до/включая 1100ah2 на гигабитных скоростях очень маркировку любят превращать в пожирание cpu, в ccr это получше выглядит
Но сирано конфига — жесть :)
Как решали без подмены днс доступность сайта а-ля hairpin nat? Тут вроде только conn mark катит, имхо
А что делать с UPnP для узлов из LAN в вашем сценарии?
Вариант, но с манглом не проще разве?
Еще и на web-сервере алиасы настраивать, зачем?
А если нам нужно еще почту прокинуть, SIP, еще 50 портов, мы что, тоже будем везде алиасы вешать?
Еще и на web-сервере алиасы настраивать, зачем?
А если нам нужно еще почту прокинуть, SIP, еще 50 портов, мы что, тоже будем везде алиасы вешать?
Я выше описал плюсы своего подхода, но да, у него есть и минусы.
Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.
Если же все на одном сервере, имхо, мой подход проще.
Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.
Если же все на одном сервере, имхо, мой подход проще.
Как написали в одном паблике в ВК, после данной публикации, — «Каждый готовит MikroTik по своему»
По этому, считаю, нам не стоит продолжать полемику в поиске единственно верного решения
зачем? Не совсем понял вашу мысль.
Есть внутри web-сервер, почтовый, телефония, каждый должен иметь по несколько IP?
По этому, считаю, нам не стоит продолжать полемику в поиске единственно верного решения
Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.
зачем? Не совсем понял вашу мысль.
Есть внутри web-сервер, почтовый, телефония, каждый должен иметь по несколько IP?
Возможно, я немного поспешил с выводами.
Как показали комментарии, есть много сценариев, где ваш подход выручает (UPnP, пару сотен серверов).
Возьму на заметку, спасибо.
Как показали комментарии, есть много сценариев, где ваш подход выручает (UPnP, пару сотен серверов).
Возьму на заметку, спасибо.
Да не, автор в теме ;)
рулсами мы не раскрасим транзитный трафик, если я ошибаюсь, то дайте конфиг.
рулсами мы не раскрасим транзитный трафик, если я ошибаюсь, то дайте конфиг.
rules lookup не рассмотрели, количество правил бы уменьшилось
решил не городить огороды и сделать все в мангл
когда конфига будет страниц в 12-50, в мангл страшно будет заглядывать
казалось бы дел на секунду, надо добавить какое-нить одно правило, а сидишь с умным лицом полчаса. В особенности ежели наличествует дикий qos ;)
казалось бы дел на секунду, надо добавить какое-нить одно правило, а сидишь с умным лицом полчаса. В особенности ежели наличествует дикий qos ;)
забыли нарисовать аналог hairpin nat для нескольких wan, я делал через mangle, тож развесисто получается
Более элегантно это выглядело с помощью PBR(Policy Based Routing).
Если не знаете этот метод — посмотрите статью Чудина за прошлый год(в гугле «Чудин Mikrotik»)
Если не знаете этот метод — посмотрите статью Чудина за прошлый год(в гугле «Чудин Mikrotik»)
ему доступны не напрямую, а рекурсивно через данные статические маршруты. По одному IP на брата-провайдера.
А где мы указываем статические маршруты, если они у нас имеют routing-mark, согласно вашим правилам?
Т.е. нам надо создать ещё и такие правила?
add distance=1 gateway=95.11.29.254
add distance=1 gateway=5.35.59.161Просто если всё сделать как указано в статье, то из локальной сети ничего работать не будет, т.к. роутер будет отвечать что
[192.168.88.1] сообщает: Заданная сеть недоступна.
Пробовали hairpin nat делать?
Да, для меня это обязательное условие.
А с этой проблемой разобрался.
Очень краткая выжимка
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.
Вопрос, если есть два провайдера, и по качеству они более-менее одинаковые, и хочется их чередовать, например, каждую полночь меняя местами основной и вторичный? Можно ли это реализовать как-то через вызов какого-то скрипта в планировщике?
Можно.
Просто меняйте default gw.
Просто меняйте default gw.
а можно по-другому, например пусть маршруты:
имеют соответственно номера 4 и 5, и тогда в скрипте планировщика делать такую команду:
при этом у них местами поменяются номера, и не надо будет через день менять команду, команда будет одна на каждый день. Я тут игрался со своим микротиком, вроде работает, прошивка последняя стабильная, 6.43.12.
/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.
MikroTik. Правильный dst nat при использовании 2-х и более провайдеров