Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting
Проще, быстрее, надежнее.
Проще, быстрее, надежнее.
Аналогичные скрипты уже не раз выкладывались под микротик. Тем не менее спасибо)
А вот вам задача актуальная, но менее «боян». Резервный канал в «мирное» время, вполне можно утилизировать и пустить через него часть клиентов.
Задача расширить маршруты и скрипт с таким условием, чтобы:
— в обычных условиях часть клиентов (пусть будет некий диапазон ip адресов нашей сети) ходили в интернет через основной канал, а другие (следующий диапазон) через резервный.
— Но, при падении, какого либо канала, обеспечить доступность всем))
А вот вам задача актуальная, но менее «боян». Резервный канал в «мирное» время, вполне можно утилизировать и пустить через него часть клиентов.
Задача расширить маршруты и скрипт с таким условием, чтобы:
— в обычных условиях часть клиентов (пусть будет некий диапазон ip адресов нашей сети) ходили в интернет через основной канал, а другие (следующий диапазон) через резервный.
— Но, при падении, какого либо канала, обеспечить доступность всем))
Спасибо за подробную инструкцию!
Вопрос в тему: можно ли на Микротике обеспечить постоянную доступность резервного канала извне? Т.е. чтобы я мог подключиться к роутеру извне через канал с большим distance, который в данный момент не используется для выхода в интернет?
Причина: например, бывает удобно часть VPN-клиентов пустить через второй канал для балансировки.
Кроме того, пинг от 8.8.8.8 не всегда означает полную работоспособность. Роутер может думать, что основной канал работает, а я даже не смогу подключиться удаленно, чтобы его переубедить.
Вопрос в тему: можно ли на Микротике обеспечить постоянную доступность резервного канала извне? Т.е. чтобы я мог подключиться к роутеру извне через канал с большим distance, который в данный момент не используется для выхода в интернет?
Причина: например, бывает удобно часть VPN-клиентов пустить через второй канал для балансировки.
Кроме того, пинг от 8.8.8.8 не всегда означает полную работоспособность. Роутер может думать, что основной канал работает, а я даже не смогу подключиться удаленно, чтобы его переубедить.
Можно. Я для этого настроил себе доступ так:
IP -> Firewall -> NAT
Вкладка «General»:
Chain: dstnat
Protocol: 6 (tcp)
Dst. Port: 3389
Вкладка «Advanced»:
Src. Address List: (указал список IP-адресов, с которых я разрешаю заходить)
Вкладка «Action»:
Action: dst-nat
To Address: 192.168.1.1
To Ports: 3389
И все, после этого на какой бы я IP-адрес (из указанных на вкладке «Advanced») ни зашел — меня пускает :)
IP -> Firewall -> NAT
Вкладка «General»:
Chain: dstnat
Protocol: 6 (tcp)
Dst. Port: 3389
Вкладка «Advanced»:
Src. Address List: (указал список IP-адресов, с которых я разрешаю заходить)
Вкладка «Action»:
Action: dst-nat
To Address: 192.168.1.1
To Ports: 3389
И все, после этого на какой бы я IP-адрес (из указанных на вкладке «Advanced») ни зашел — меня пускает :)
По поводу «Причины». У меня ситуация следующая: на основном канале отключили Инет за неуплату. Все браузеры, при попытках открыть сайт, выходят на страницу провайдера, где написано что у меня не оплачено. Если пустить пинг на DNS Гугла, то скрипт работает.
Возможно, мой способ можно назвать «костылем», но для конторы данного уровня это терпимо, так как основной канал впервые за 4 года «упал» не по причине проблем провайдера. А вообще максимум раз в год он падает ненадолго.
Это сейчас 3-и сутки начинают идти как канал не работает :)
К чему я это. Ах да! Возможно решение пинать IP 8.8.8.8 было неверно, зато действенно. Разумеется, если я найду более лучший способ написания скрипта, то приложу ссылку на него, а пока довольствуюсь этим :)
Возможно, мой способ можно назвать «костылем», но для конторы данного уровня это терпимо, так как основной канал впервые за 4 года «упал» не по причине проблем провайдера. А вообще максимум раз в год он падает ненадолго.
Это сейчас 3-и сутки начинают идти как канал не работает :)
К чему я это. Ах да! Возможно решение пинать IP 8.8.8.8 было неверно, зато действенно. Разумеется, если я найду более лучший способ написания скрипта, то приложу ссылку на него, а пока довольствуюсь этим :)
дёргайте wget-ом www.google.com/robots.txt — он всегда будет там, покуда стоит Гугль.
да, нужно маркировать инпут на тот интерфейс и давать ему марк-роутинга через него же. Тоесть то что вошло в ВАН2 через него должно и выйти
/ip firewall mangle
add action=mark-connection chain=input comment=Ukrtelecom connection-mark=no-mark in-interface=Ukrtelecom new-connection-mark=ukrtelecom
add action=mark-routing chain=output connection-mark=ukrtelecom new-routing-mark=ukrtelecom passthrough=no
Как то так приблизительно. Взял с одного роутера где Укртелеком это резервный канал
/ip firewall mangle
add action=mark-connection chain=input comment=Ukrtelecom connection-mark=no-mark in-interface=Ukrtelecom new-connection-mark=ukrtelecom
add action=mark-routing chain=output connection-mark=ukrtelecom new-routing-mark=ukrtelecom passthrough=no
Как то так приблизительно. Взял с одного роутера где Укртелеком это резервный канал
еще, кстати, на эту же тему — можно почитать вот тут на русском ;)
http://podarok66.livejournal.com/4939.html
Тоже без всякого участия скриптов :) и немного затронута тему распределения нагрузки)
http://podarok66.livejournal.com/4939.html
Тоже без всякого участия скриптов :) и немного затронута тему распределения нагрузки)
Скажите, вы эту схему проверяли в работе?
Мне кажется, что минута это много для проверки, за пинги раз в 15 секунд не накажут.
Если убирается маршрут, то не нужно ли чистить трансляции NAT?
Можно ли сразу два маршрута по умолчанию иметь?
Мне кажется, что минута это много для проверки, за пинги раз в 15 секунд не накажут.
Если убирается маршрут, то не нужно ли чистить трансляции NAT?
Можно ли сразу два маршрута по умолчанию иметь?
У меня эта схема даже заработала (правда, слегка адоптированная под свои реалии).
в моем случае: 1ый ISP (основной — static), 2ой ISP (резерв — PPPoE) failover происходит совсем незаметно для пользователей.
На тему двух маршрутов — в той же статье описан вариант параллельной работы двух провайдеров для разных целей. У меня такой нужды не было — так что вот за это ручаться совсем не могу.
в моем случае: 1ый ISP (основной — static), 2ой ISP (резерв — PPPoE) failover происходит совсем незаметно для пользователей.
На тему двух маршрутов — в той же статье описан вариант параллельной работы двух провайдеров для разных целей. У меня такой нужды не было — так что вот за это ручаться совсем не могу.
Не могут пользователи не заметить переход на другого провайдера — порвутся же сессии все. Конечно, если они не пользуются онлайн-мессенджерами всякими, а просто браузерят интернет, то у них могут недогрузиться картинки большие.
А можете проверить что происходит с правилами сетевой трансляции при удалении маршрута?
Получается, что если не удалить правила, то сессии будут висеть «в никуда» и заработает только все когда у сессий кончится время жизни?
А можете проверить что происходит с правилами сетевой трансляции при удалении маршрута?
Получается, что если не удалить правила, то сессии будут висеть «в никуда» и заработает только все когда у сессий кончится время жизни?
После Вашего комментария код был обновлен, а именно, убран второй маршрут и схема работает по принципу смены шлюза в записи.
Обновление записи происходит динамически. Например, открыл юзер страницу в браузере, а в этот момент сменился провайдер. Юзер по ссылке кликает и у него вновь открывается, а о смене он и не заподозрит.
Обновление записи происходит динамически. Например, открыл юзер страницу в браузере, а в этот момент сменился провайдер. Юзер по ссылке кликает и у него вновь открывается, а о смене он и не заподозрит.
У меня эта схема сейчас работает. Вот прямо сейчас :)
Я ее отладил, после этого на хабре написал как один из вариантов.
Я трансляции не очищаю — и так работает :)
По-умолчанию сразу два? Разве что распределить клиентов по группам чуть выше в комментариях ссылка есть на распределение нагрузки по нескольким провайдерам.
Я ее отладил, после этого на хабре написал как один из вариантов.
Я трансляции не очищаю — и так работает :)
По-умолчанию сразу два? Разве что распределить клиентов по группам чуть выше в комментариях ссылка есть на распределение нагрузки по нескольким провайдерам.
А что будет с вашей схемой, если сломается DNS гугла и на ваши пинги, что по первому, что по второму каналу не будет ответа?
Не так ли? instagram.com/p/rB8fzSO61G/
Не так ли? instagram.com/p/rB8fzSO61G/
Это всё хорошо, но при переключении роутов не мешало бы конекштрекинг ресетить, что бы старые конекты пошли по новому каналу.
Есть еще вариант не отключать роуты а переписывать шлюз в маршруте. При таком подходе не надо ресетить контрекинг, так как роут останется прежним, а гетвей будет уже «акутуальным»
Есть еще вариант не отключать роуты а переписывать шлюз в маршруте. При таком подходе не надо ресетить контрекинг, так как роут останется прежним, а гетвей будет уже «акутуальным»
Если основной провайдер раздает настройки через DHCP, предложенная схема не сработает.
Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Присваивает проверочному маршруту найденный шлюз.
Пример такого скрипта.
3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up: ip dhcp-client set default-route-distance=1 [find comment=«Default Route»]
On Down: ip dhcp-client set default-route-distance=10 [find comment=«Default Route»]
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Присваивает проверочному маршруту найденный шлюз.
Пример такого скрипта.
3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up: ip dhcp-client set default-route-distance=1 [find comment=«Default Route»]
On Down: ip dhcp-client set default-route-distance=10 [find comment=«Default Route»]
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Может этот скрипт подойдет? habrahabr.ru/post/243071/ Только функционал netwatch реализован скриптом.
Если основной провайдер раздает настройки через DHCP, предложенная схема не сработает.
Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить маршрут для проверки основного канала. gateway=любой, address=8.8.4.4, comment=«Check Gateway»
3. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Ищет route с пометкой «Check Gateway»
--c. Присваивает проверочному маршруту найденный шлюз.
3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up:
On Down:
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить маршрут для проверки основного канала. gateway=любой, address=8.8.4.4, comment=«Check Gateway»
3. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Ищет route с пометкой «Check Gateway»
--c. Присваивает проверочному маршруту найденный шлюз.
ip route set [find comment="Check Route"] gateway=[/ip dhcp-client get [find comment="Default Route"] value-name=gateway]3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up:
ip dhcp-client set default-route-distance=1 [find comment="Default Route"]On Down:
ip dhcp-client set default-route-distance=10 [find comment="Default Route"]
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Хорошая статья. Единственное когда я попытался ее реализовать без PPP подключений(у обоих провайдеров статика) возникла следующая проблема:
есть маршрут 8.8.8.8 через провайдера 1.
Ситуация 1 — у провайдера отпадает шлюз. Все ок, маршрут активен и все переключается.
Ситуация 2 — физический линк между микротиком и провайдером 1 разрывается. Т.к. интерфейс не активен — маршрут тоже становится неактивен. Это приводит к переключению на резерв, потом начинает пинговаться 8.8.8.8 (маршрут то не работает), скрипт кидает на основной канал, инета нет, кидает обратно. И так постоянно.
После вариантов переписывания скриптов решил проблему очень просто — создал bridge, и в него засунул ether1 с основным провайдером. Все! Маршрут доступен через bridge, и даже в случае обрыва линка — маршрут на 8.8.8.8 все равно активен, т.к. bridge тоже активен.
есть маршрут 8.8.8.8 через провайдера 1.
Ситуация 1 — у провайдера отпадает шлюз. Все ок, маршрут активен и все переключается.
Ситуация 2 — физический линк между микротиком и провайдером 1 разрывается. Т.к. интерфейс не активен — маршрут тоже становится неактивен. Это приводит к переключению на резерв, потом начинает пинговаться 8.8.8.8 (маршрут то не работает), скрипт кидает на основной канал, инета нет, кидает обратно. И так постоянно.
После вариантов переписывания скриптов решил проблему очень просто — создал bridge, и в него засунул ether1 с основным провайдером. Все! Маршрут доступен через bridge, и даже в случае обрыва линка — маршрут на 8.8.8.8 все равно активен, т.к. bridge тоже активен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mikrotik: автоматическое переключение канала на резервный и обратно