Страница 4 из 14

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 02 июл 2013, 20:58
Barvinok
Фильтр
Источники:
Manual:IP/Firewall/Filter
Сергей Лаговский: MikroTik - Начальная настройка
How to configure a home router: State
Механизм определения состояний

В довершение всех настроек полагаю нелишним будет защитить свой многотрудный маршрутизатор, верно? Или вы думаете иначе?
Скорее всего вы включили NAT и на том успокоились со словами "да кому я нужен, всё равно у меня ничего интересного нет".
Вы даже не представляете какими неожиданными способами вас могут использовать.
Самое безобидное - рассылать через вас спам.
Менее безобидное - сделать из вас зомби для участия в распределённых сетевых атаках на разные банки и госучереждения. Короче, однажды к вам могут прийти люди в чёрном и вежливо, но настойчиво попросить объяснений.

Определим условия задачи.
С одной стороны у нас есть внешняя сеть, полная прыщавых сумрачных гениев, ищущих возможности самоутвердиться хотя бы в виртуальном мире. Начитавшись на ночь журнала "Хакер" они неустанно сканируют порты чувствуя себя то рыцарями плаща и кинжала, то зловещими порождениями тьмы.
От них как раз таки защититься легко: достаточно запретить все входящие подключения.

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

/ip firewall filter add chain=input action=drop


Но в достатке так же вполне рассудочных и трезвомыслящих сетевых дел мастеров, которые хотят использовать вас как средство для получения денег.
Они не погнушаются и открытым портом. Но скорее они напишут такую простенькую программку, которую вы захотите сами скачать с сиюминутно понравившегося сайта, на который вы случайно зашли. После чего ваш компьютер будет принадлежать уже не только вам.
Т.е. будут атаковать вашу сеть изнутри! А это гораздо хуже. Ведь это же ваша локальная сеть. Здесь обитают люди близкие, а может даже родные...
Ведь им же нужно многое позволить, что бы они на вас не дулись. Всякие асечки-контактики-скайпики.
К тому же они используют многие службы, работающие на самом маршрутизаторе: DHCP, DNS, NTP, TFTP, Proxy...
Внутри сети предприятия так же может оказаться начинающий или даже опытный взломщик.
Вот тут и нужно так всё тонко предусмотреть, что бы и работе не мешать, и безопасность соблюсти, и свою работу не превратить в ад бесконечным наступанием на собственные правила.

Значит мы можем разделить нашу задачу на две части, которые в свою очередь распадаются так же на две части:
1. доступ к самому маршрутизатору
1.1. Снаружи
1.2. Изнутри

2. Взаимодействие между локальной и глобальной сетью
2.1. Из внешней во внутреннюю
2.2. Изнутри наружу

Т.е. мы управляем теми самыми потоками, которые обозначили на Рис.1 (IPTables):
  • восходящий/нисходящий - взаимодействие с маршрутизатором
  • проходящий - обмен между сетями.

Бывают случаи, когда сетей много. Т.е. нет такого явного деления на внешнюю и внутреннюю. К примеру, если маршрутизатор провайдера стоит на границе двух или более "автономных систем". Но мне это не надо и я буду рассматривать просто случай подключения к интернету из дома или офиса (через двух провайдеров - согласно названию темы!).

Как человек ленивый я постараюсь создавать как можно меньше правил, а значит я буду стараться работать не с пакетами, а с понятиями более высокого уровня - с соединениями:
Механизм определения состояния позволяет строить чрезвычайно мощную и эффективную защиту. Раньше приходилось открывать все порты выше 1024, чтобы пропустить обратный трафик в локальную сеть, теперь же, при наличии механизма определения состояния, необходимость в этом отпала, поскольку появилась возможность "открывать" доступ только для обратного (ответного) трафика, пресекая попытки установления соединений извне.
[...]
Как видите, трассировщик, с точки зрения пользователя, фактически не следит за ходом установления соединения. Просто, как только трассировщик "увидел" первый (SYN) пакет, то присваивает ему статус NEW. Как только через трассировщика проходит второй пакет (SYN/ACK), то соединению присваивается статус ESTABLISHED. Почму именно второй пакет? Сейчас разберемся. Строя свой набор правил, вы можете позволить покидать локальную сеть пакетам со статусом NEW и ESTABLISHED, а во входящем трафике пропускать пакеты только со статусом ESTABLISHED и все будет работать прекрасно. И наоборот, если бы трассировщик продолжал считать соединение как NEW, то фактически вам никогда не удалось бы установить соединение с "внешним миром", либо пришлось бы позволить прохождение NEW пакетов в локальную сеть.
На этих основаниях я буду создавать наборы правил. Кроме того, работая с соединениями я значительно снижаю нагрузку на ЦП маршрутизатора.

Итак наша цель - безопасность.
Но обеспечение безопасности похоже на рычажные весы: на одной чаше безопасность, на второй - удобство работы.
Полная безопасность подразумевает собой невозможность работы. Что мы и показали в самом начале включив полный запрет на доступ к роутеру.
А как вы будете им управлять, позвольте спросить?
Ах, ну да - WinBox позволяет подключаться по MAC-адресу. Но только из того же сегмента локальной сети!
А для доступа извне хорошо бы оставить для себя дырочку в этом заборе.
Значит выражение "полная безопасность" достаточно условно. Я будут подразумевать под ним лишь одно: мы запрещаем то, что явно не разрешаем.
Другими словами я хочу быть хозяином положения и явно определять, что можно, а что нельзя - что бы без моего ведома тут ни одна мышь не скребла!
Это же относится и к паролям. Слишком простой могут подобрать. Слишком сложный я не смогу запомнить и его придётся записывать на бумажечке (очень распространённая дыра!). Значит здесь (к впрочем и везде) важно соблюсти равновесие, меру.

Можно сработать на уровне пакетов:

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

/ip firewall filter add chain=input comment="Accept WinBox" dst-port=8291 protocol=tcp action=accept

Но можно и на уровне соединений:
/ip firewall filter>
add chain=input comment="Accept WinBox" connection-state=new dst-port=8291 protocol=tcp action=accept
add chain=input comment="Accept established connections" connection-state=established action=accept
Вместо одного правила получилось два. Вот те на!
Однако давайте вспомним задачу в полном виде. Кроме WinBox нам нужно ещё открыть доступ для FTP и L2TP-подключений, а так же ответов от внешних DNS и NTP-серверов. При этом наш маршрутизатор весьма деятельно обслуживает локальную сеть: DNS, NTP, TFTP, DHCP, Proxy. Но к этим службам доступ извне давать не желательно.
Тогда для ответов от серверов DNS пришлось бы писать отдельное правило:

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

add chain=input comment="DNS answer" protocol=udp src-port=53

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

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

add chain=input comment="Accept established connections" connection-state=established action=accept

Более того, это правило так же работает и для NTP и будет работать для любого ответа на запросы, отправленные нашим маршрутизатором!
По русски его можно выразить так: "Разрешаю принимать все ответы".

Напомню, как работает машина определения состояний соединений. Сначала наш маршрутизатор шлёт запрос к серверу DNS.
Этот запрос проходит через цепочку OUTPUT, в которой никаких правил у нас нет. Но при этом у нас создаётся соединение пометкой NEW.
Когда же к нам приходит ответ от DNS-сервера, соединение (а наблюдение за соединениями происходит в цепочке PREROUTING) становится ESTABLISHED. И наше правило, которое находит в цепочке INPUT и разрешающее установленные (ESTABLISHED) соединения срабатывает!

Кроме того, оно будет работать и для соединений из локальной сети - ведь мы не делали привязки к интерфейсу. Достаточно разрешить все входящие по UDP:

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

chain=input action=accept connection-state=new protocol=udp in-interface=Local_Net


Таким образом мы можем полностью обезопасить себя как снаружи так и изнутри буквально десятком правил:

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

/ip firewall filter
add action=accept chain=input comment="Accept WinBox" connection-state=new dst-port=8291 protocol=tcp
add action=accept chain=input comment="Accept L2TP protocol" connection-state=new port=1701 protocol=udp
add action=accept chain=input comment="Accept ICMP" protocol=icmp
add action=accept chain=input comment="Accept established connections" connection-state=established
add action=accept chain=input comment="Accept related connections" connection-state=related
add action=accept chain=input comment="Accept UDP access for Local Network" protocol=udp src-address=192.168.1.0/24
add action=drop chain=input comment="Drop Invalid connections" connection-state=invalid
add action=drop chain=input comment="Drop all Mikrotik input connection"


Теперь перейдём ко второй части нашего мерлезонского балета: взаимодействие локальной и глобальной сети.
Если мы говорим о защите от бэкофисной программки, внедрённой на одном или нескольких компьютерах локальной сети, и держащей связь с хозяином, то, боюсь, полумер здесь нет: либо мы по драконовски перекрываем вообще всё, кроме одной-двух служб (HTTP, POP3), которым разрешён доступ на строго определённые сервера, либо можно вообще ничего не делать. Здесь задача сходна с запретом Скайпа: он ведь запросто может работать и по 80 порту, если прочие закрыты. Так же и любой руткит не будет перед вами отчитываться, на какие адреса и порты он собирается стучать.
Если руки уж очень чешутся сделать хоть что-то, можно сбрасывать подключения с неопределённым состоянием:

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

/ip firewall filter add action=drop chain=forward comment="Drop Invalid connections" connection-state=invalid


Пожалуй, единственная внятная причина писать правила в цепочке FORWARD - это наличие DMZ. Т.е. такого компьютера (или нескольких компьютеров), которые предоставляют свои службы в интернет, а значит предположительно уязвимы. Нам нужно разрешить доступ к ним из локальной сети, но при этом они сами не должны иметь возможности обращаться в локальную сеть по собственному почину.
Тогда так:

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

/ip firewall filter
add chain=forward connection-state=established action=accept
add chain=forward connection-state=related action=accept
add chain=forward connection-state=invalid action=drop
add chain=forward in-interface=inside action=accept
add chain=forward in-interface=dmz out-interface=outside action=accept
add chain=forward dst-address=10.2.0.10 protocol=tcp dst-port=80,443 action=accept
add chain=forward action=drop


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

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

/ip firewall filter>
add chain=forward connection-state=invalid action=drop comment="Drop invalid connection packets"
add chain=forward connection-state=established action=accept comment="Allow established connections"
add chain=forward connection-state=related action=accept comment="Allow related connections"
add chain=forward protocol=udp action=accept comment="Allow UDP"
add chain forward protocol=icmp action=accept comment="Allow ICMP Ping"


Далее:

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

Дальше добавляем правила для машины PC4.
/ip firewall filter>
add chain=forward dst-address=192.168.0.10/32 action=accept comment="Allow all for admin"
add chain=forward src-address=192.168.0.10/32 action=accept comment="Allow all for admin"

Разрешить админу делать всё, что угодно - не тоже самое, что разрешить делать всё, что угодно с админом!
А Сергей первым правилом позволил именно это: совершенно любой трафик из любого источника!
Я бы сделал иначе:

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

/ip firewall filter add chain=forward src-address=192.168.0.10/32 connection-state=new action=accept 

А правила, позволяющие установленные и связанные соединения у нас уже есть. И они применяются для все сети, в том числе и для компьютера админа!
Другими словами, я разрешаю зачинать с админского компьютера любые соединения по любым протоколам, а прохождение ответов уже разрешено для все нашей сети.
Полагаю, Сергей просто не связывает правила для соединений и правила для пакетов и рассматривает их как нечто, независимое друг от друга.
Между тем любой пакет можно и нужно рассматривать как событие в пределах соединения.
Для примера сравним два правила, которые мы только что использовали:

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

/ip firewall filter add chain=forward src-address=192.168.0.10/32 action=accept
 и
/ip firewall filter add chain=forward src-address=192.168.0.10/32 connection-state=new action=accept

При прохождении первого пакета из соединения они работают совершенно одинаково.
Но для последующих пакетов разница существенная: первое правило их не различает - для него каждый пакет сам по себе. Но это так же значит, что маршрутизатору придётся обрабатывать каждый пакет в пределах IPTables сравнивая его с этим правилом, что увеличивает нагрузку на CPU. Я не хочу, что бы это происходило, поэтому явно указываю, что работаю с соединением используя ключ connection-state=new.
А вот второе правило уже не пропустит второй и последующие пакеты из соединения, в силу того, что состояние соединения изменилось на "established".
Значит нам необходимо ещё одно правило для работы любого установленного (established) соединения. Но это даёт нам огромное облегчение: единожды его создав нам больше никогда не придётся писать правила, разрешающие ответные пакеты!


Что же происходит дальше?

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

Разрешаем работу сервера до протоколу http, smtp, pop.
ip firewall filter>
add chain=forward dst-address=192.168.0.2/32 protocol=tcp src-port=80 action=accept comment="Allow http for server (in)"
add chain=forward src-address=192.168.0.2/32 protocol=tcp dst-port=80 action=accept comment="Allow http for server (out)"
add chain=forward dst-address=192.168.0.2/32 protocol=tcp src-port=25 action=accept comment="Allow smtp for server (in)" 
add chain=forward src-address=192.168.0.2/32 protocol=tcp dst-port=25 action=accept comment="Allow smtp for server (out)"
add chain=forward dst-address=192.168.0.2/32 protocol=tcp src-port=110 action=accept comment="Allow pop for server (in)" 
add chain=forward src-address=192.168.0.2/32 protocol=tcp dst-port=110 action=accept comment="Allow pop for server (out)"

Очевидно, Сергей не осознаёт, что его обратные правила не работают - до них дело просто не доходит. Вместо них работает правило "add chain=forward connection-state=established action=accept", которое он создал в самом начале.
Если мы работаем на уровне соединений, любое разрешающее правило будет действенно лишь для первого пакета - пока соединение находится в состоянии NEW. Как только на него приходит ответ, соединение становится ESTABLISHED и работает через единое для всех вышеозначенное правило для установленных соединений.
Т.е. все правила, помеченные как (in) можно смело убирать.
Кроме того, номера портов можно писать через запятую. Вот как можно сделать:

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

/ip firewall filter>
add chain=forward src-address=192.168.0.2/32 protocol=tcp dst-port=25,80,110 connection-state=new action=accept"
add chain=forward src-address=192.168.0.2/32 action=drop"

С другой стороны, если мы говорим о севере, то подразумевается возможность подключения к нему извне. Я ожидал бы увидеть что-то вроде
add chain=forward dst-address=192.168.0.2/32 protocol=tcp dst-port=110 action=accept comment="Allow pop for server (in)"
А у Сергея этих правил вообще нет.
Для таких входящих подключений можно сделать единое общее правило
add chain=forward dst-address=192.168.0.2/32 protocol=tcp dst-port=25,80,110 connection-state=new action=accept"


Дальше - хуже:

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

Таким же образом задаем правила для остальных машин, разрешая им http, https, ftp, icq, jabber.
ip firewall filter >
add chain=forward dst-address=192.168.0.20/32 protocol=tcp src-port=80 action=accept comment="Allow http for pc1 (in)"   
add chain=forward src-address=192.168.0.20/32 protocol=tcp dst-port=80 action=accept comment="Allow http for pc1 (out)"
add chain=forward dst-address=192.168.0.20/32 protocol=tcp src-port=443 action=accept comment="Allow https for pc1 (in)"   
add chain=forward src-address=192.168.0.20/32 protocol=tcp dst-port=443 action=accept comment="Allow https for pc1 (out)"
add chain=forward dst-address=192.168.0.20/32 protocol=tcp src-port=21 action=accept comment="Allow ftp for pc1 (in)"   
add chain=forward src-address=192.168.0.20/32 protocol=tcp dst-port=21 action=accept comment="Allow ftp for pc1 (out)"
add chain=forward dst-address=192.168.0.20/32 protocol=tcp src-port=5190 action=accept comment="Allow icq for pc1 (in)"   
add chain=forward src-address=192.168.0.20/32 protocol=tcp dst-port=5190 action=accept comment="Allow icq for pc1 (out)"
add chain=forward dst-address=192.168.0.20/32 protocol=tcp src-port=5222 action=accept comment="Allow jabber for pc1 (in)"   
add chain=forward src-address=192.168.0.20/32 protocol=tcp dst-port=5222 action=accept comment="Allow jabber for pc1 (out)"
Повторяем эти правила для каждой машины, если необходимо разрешить дополнительные порты, то шаблон написания, я думаю, понятен.

Удивляюсь, что подвигло Сергея писать такие списки для каждой машины, вместо того, что бы использовать маску подсети.
Для десяти компьютеров сети это уже сотня правил! Совершенное безумие.
Тогда как, вместо сотни (или даже сотен) правил достаточно одного:

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

/ip firewall filter add chain=forward src-address=192.168.0.0/24 protocol=tcp dst-port=21,80,443,5190,5222 connection-state=new action=accept"
Ну и в завершение, разумеется, запрещаем всё, что явно не разрешено выше:

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

/ip firewall filter add chain=forward action=drop comment="Drop all"

Я не совсем понимаю, чего можно добиться этими запретами, кроме озлобления пользователей, у которых не будут работать некоторые предположительно нужные и удобные для них программы. Безопасности? Разумеется, нет. По FTP и HTTP можно сливать корпоративные тайны терабайтами. Единственное, что приходит на ум - сокращение объёма потребляемого трафика. Что в нашу эпоху безлимита уже на столь насущно. К сожалению, Сергей никак не обозначил своих целей и нам остаётся лишь гадать.

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

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 05 авг 2013, 16:16
Katran
Спасибо большое за статьи! Пол дня сижу читаю, очень понравилось! Я по микротикам совсем еще зеленый, так что для меня весьма полезен ваш труд! Будет возможность/желание, пишите ещё! :)

P.S. В самом начале, когда пошли примеры первых команд для терминала, вы забыли упаминуть про изменение имен интерфейсов! С ether1 на wlan1 и с ether2 на wlan2. И далее по тексту встречалась команда с именем интерфейса inside...

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 13 авг 2013, 21:15
Barvinok
Интерфейсы wlan1, wlan2 и inside встречаются в выдержках из MikroTik Wiki.
Я не использую такие имена и в разделе "Настройка роутера с нуля" я особое внимание уделял неизменности имен интерфейсов, адресов подсетей и другим мелочам, способным внести путаницу по ходу повествования.

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 15 авг 2013, 14:15
Katran
/ ip firewall mangle
add chain=input in-interface=wlan1 action=mark-connection new-connection-mark=wlan1_conn
add chain=input in-interface=wlan2 action=mark-connection new-connection-mark=wlan2_conn


Это с первый страницы данной темы! И еще была команда в теме с интерфейсом inside! Я вот про что. :)

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 15 авг 2013, 19:51
Barvinok
Верно. А руководство по настройке с нуля (собственно, прикладную часть), я начал писать со второй страницы.
То, о чём ты говоришь - цитата отсюда.

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 авг 2013, 11:01
Orleon
Добрый день, настраиваю балансировку нагрузки по 2-ум каналом по вашим указаниям в первой статье. Имеется 2 РРРоЕ соединения, ширина канала на обоих по 10МБИт работают в отдельности прекрасно. Но вот при объединении начинаются проблемы. Делаю все как по инструкции, но при включении механизма ЕСМР

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

/ ip route
add dst-address=0.0.0.0/0 gateway=10.111.0.1,10.112.0.1 check-gateway=ping

интернет начинает жутко тормозить, долго думать, а некоторые страницы вообще не загружаются и роутер выдает сообщение о таймауте. Как только выключаю(disable) - все работает снова прекрасно, но как вы понимаете балансировки никакой при этом нет. В чем может быть проблема?

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 авг 2013, 15:20
Barvinok
Я думаю, нужно в значении gateway перечислить не адреса, а имена интерфейсов PPPoE.

Во-вторых, обязательно отключи назначение маршрутов по умолчанию в обоих подключениях (add-default-route=no)

Так же затык может быть связан с DNS: если у тебя не прописаны маршруты к DNS-серверам, то маршрутизатор может пытаться обратиться к DNS-серверу одного провайдера через второго, а это не всегда возможно. Отключи назначаемые DNS (use-peer-dns=no) и назначать вручную, например, гугловские (8.8.8.8, 8.8.4.4)

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 авг 2013, 16:16
Katran
Или попробуй другой способ:

 Mikrotik 4 WAN Load Balancing using PCC method.
/ip address
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=Local
add address=192.168.1.2/24 network=192.168.1.0 broadcast=192.168.1.255 interface=WAN1
add address=192.168.2.2/24 network=192.168.2.0 broadcast=192.168.2.255 interface=WAN2
add address=192.168.3.2/24 network=192.168.3.0 broadcast=192.168.3.255 interface=WAN3
add address=192.168.4.2/24 network=192.168.4.0 broadcast=192.168.4.255 interface=WAN4

/ip firewall mangle
add chain=input in-interface=WAN1 action=mark-connection new-connection-mark=WAN1_conn
add chain=input in-interface=WAN2 action=mark-connection new-connection-mark=WAN2_conn
add chain=input in-interface=WAN3 action=mark-connection new-connection-mark=WAN3_conn
add chain=input in-interface=WAN4 action=mark-connection new-connection-mark=WAN4_conn

add chain=output connection-mark=WAN1_conn action=mark-routing new-routing-mark=to_WAN1
add chain=output connection-mark=WAN2_conn action=mark-routing new-routing-mark=to_WAN2
add chain=output connection-mark=WAN3_conn action=mark-routing new-routing-mark=to_WAN3
add chain=output connection-mark=WAN4_conn action=mark-routing new-routing-mark=to_WAN4

add chain=prerouting dst-address=192.168.1.0/24 action=accept in-interface=Local
add chain=prerouting dst-address=192.168.2.0/24 action=accept in-interface=Local
add chain=prerouting dst-address=192.168.3.0/24 action=accept in-interface=Local
add chain=prerouting dst-address=192.168.4.0/24 action=accept in-interface=Local

add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses-and-ports:4/0 action=mark-connection new-connection-mark=WAN1_conn passthrough=yes
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses-and-ports:4/1 action=mark-connection new-connection-mark=WAN2_conn passthrough=yes
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses-and-ports:4/2 action=mark-connection new-connection-mark=WAN3_conn passthrough=yes
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses-and-ports:4/3 action=mark-connection new-connection-mark=WAN4_conn passthrough=yes
add chain=prerouting connection-mark=WAN1_conn in-interface=Local action=mark-routing new-routing-mark=to_WAN1
add chain=prerouting connection-mark=WAN2_conn in-interface=Local action=mark-routing new-routing-mark=to_WAN2
add chain=prerouting connection-mark=WAN3_conn in-interface=Local action=mark-routing new-routing-mark=to_WAN3
add chain=prerouting connection-mark=WAN4_conn in-interface=Local action=mark-routing new-routing-mark=to_WAN4

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.1.1 routing-mark=to_WAN1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=192.168.2.1 routing-mark=to_WAN2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=192.168.3.1 routing-mark=to_WAN3 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=192.168.4.1 routing-mark=to_WAN4 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=192.168.1.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=192.168.2.1 distance=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=192.168.3.1 distance=3 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=192.168.4.1 distance=4 check-gateway=ping

/ip firewall nat
add chain=srcnat out-interface=WAN1 action=masquerade
add chain=srcnat out-interface=WAN2 action=masquerade
add chain=srcnat out-interface=WAN3 action=masquerade
add chain=srcnat out-interface=WAN4 action=masquerade

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 07 сен 2013, 23:19
aabbyr
"gateway=10.111.0.1,10.112.0.1 check-gateway=ping" - хорошая штука.

Но некоторые провайдеры используют страницы-заглушки, на которые пользователь попадает, если вдруг забыл закинуть деньги на счет. Предположим, на счету первого провайдера закончились деньги и сработала страница-заглушка (второй провайдер доступен). Шлюз первого провайдера пингуется, нагрузки нет, переключения на второго провайдера не происходит. В итоге Интернет отсутствует.

Как быть в таком случае?

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 08 сен 2013, 12:35
simpl3x
Использовать скрипт проверки какого нибудь стороннего узла и переключение между двумя аплинками.