Перейти к содержимому
Калькуляторы

Два провайдера, две сети и микротик

Добрый вечер!

Посоветуйте, пожалуйста, как верно разрулить такую ситуацию.

Имеется два провайдера. Оба дают адрес по dhcp.

Есть микротик.

Есть две отдельные подсети в двух отдельных интерфейсах. Допустим это 192.168.1.0/24 и 192.168.2.0/24

Задача состоит в том, чтобы один провайдер натился на одну сеть а другой - на другую.

При этом при пропадании какого либо из провайдеров второй должен начинать работать на обе подсети. Нетвотч с командой на гашения маршрута я знаю.

Если поставить обоим маршрутам по-умолчанию одинаковую метрику, создать 2 отдельных НАТ с указанием, мол, 192.168.1.0/24 натим на адрес 111.222.333.444 а сеть 192.168.2.0/24 натим на 555.666.777.888 ясен пень оно не работает.

То бишь работает лишь один из маршрутов по-умолчанию.

Догадываюсь, что нужно сделать две отдельные таблицы маршрутизации.

Как выйти из положения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скажу так: задача решаемая (было сделано на одном объекте), но делать так не надо:

 

- невозможно пользоваться сервисами самого роутера. Даже встроенный DNS-сервер не мог работать нормально.

- для нетвотча надо выбирать адрес, из сети другого провайдера недоступный, например адрес DNS-сервера. Провайдеру постоянный пинг на DNS-сервер нравится не всегда, бывает, что засунут в игнор.

- при отвале одного из ISP сессии сбрасываются (так уж устроен маскарадинг). Протупка у клиентов пострадавшей подсети может достигать минут.

- еще круче, когда линк возвращается - тут тупят уже ВСЕ клиенты (с обеих сетей), и гораздо дольше.

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

- конфигурация ну очень просто выглядит и правится

- отладка вызывает леденящий душу восторг, т.к. на утилиты самого роутера оказывают влияние те же спецэффекты, что препятствуют п.1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 часов назад, jffulcrum сказал:

- невозможно пользоваться сервисами самого роутера. Даже встроенный DNS-сервер не мог работать нормально.

почему?

8 часов назад, jffulcrum сказал:

- еще круче, когда линк возвращается - тут тупят уже ВСЕ клиенты (с обеих сетей), и гораздо дольше.

почему?   по моему опыту никакой затупки нету вообще. уже открытые подключения работают до их окончания по тому пути по которому были открыты.

новые идут по новому. может вы не маркируете соединения просто?

8 часов назад, jffulcrum сказал:

- отладка вызывает леденящий душу восторг, т.к. на утилиты самого роутера оказывают влияние те же спецэффекты, что препятствуют п.1

нет вообще никаких спецэффектов если понимать как оно работает в линукс . все предсказуемо понятно и ожидаемо.

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

26 минут назад, LostSoul сказал:

по моему опыту никакой затупки нету вообще. уже открытые подключения работают до их окончания по тому пути по которому были открыты.

новые идут по новому.

 

С src-nat - да, contrack при обновлении топологии не сбрасывается. А при masquerade (неизбежном в случае тс) - сбрасывается. При этом есть "приятный" период, когда nat вообще не работает.

 

32 минуты назад, LostSoul сказал:

почему?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ок. А если без резервирования?

Просто организовать схему - 2 провайдера - 2 локалки - каждый провайдер в свою локалку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сделайте для каждой локалки свой NAT и не грейте голову. Одну локалку отправлять по одному маршруту, вторую по другому. Только зачем? Весь правильнее сделать автоматический режим, если рухнет один провайдер, чтобы все плавно перетекли в другой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

chain srcnat source 192.168.1.0/24 action src-nat ШЛЮЗ провайдера 1

chain srcnat source 192.168.2.0/24 action src-nat ШЛЮЗ провайдера 2

 

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

разве нет? с метриками никогда не прыгал, все работало, а вот если пропадает инет на одном из двух то делайте планировщик, в интернете подобных мануалов хоть лопатой.

Изменено пользователем korsakik

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день!
Дабы не создавать подобную тему, задам похожий вопрос здесь.

Снова же, имеется микротик. Два провайдера.

Теперь задача выпустить через второй провайдер один порт (предположим это будет порт 777 ТСР)

Когда-то давно я это делал и работало. Но подзабыл наверное.

Делаю так:

/ip firewall mangle
add action=mark-routing chain=prerouting dst-port=777 new-routing-mark=mark1 passthrough=yes protocol=tcp

/ip route
add distance=3 gateway=111.111.111.111 routing-mark=mark1

 

И оно не работает.

При этом если в правиле маркировки вместо маркировки по порту 777 указать маркировку, допустим, по src-address - тогда работает.

 

Насколько помнят мои мутные воспоминания, надо маркировать не роутинг, а то ли пакет, то ли соединение.

Напомните, пожалуйста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

On 9/7/2019 at 10:03 AM, jffulcrum said:

С src-nat - да, contrack при обновлении топологии не сбрасывается. А при masquerade (неизбежном в случае тс) - сбрасывается. При этом есть "приятный" период, когда nat вообще не работает.

Причем тут нат вообще? Он просто меняет адреса пофакту выхода с интерфейса. Сначало нужно настроить роутинг. В таблицах должен быть менее приоритетный дефолт icmp net unreach чтобы уже промаркированые соединения уничтожались при падении линка и устанавливались снова уже с другой меткой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 10.09.2019 в 17:39, user71 сказал:

таблицах должен быть менее приоритетный дефолт icmp net unreach чтобы уже промаркированые соединения уничтожались при падении линка и устанавливались снова уже с другой меткой.

Прошу разъяснить чуть более подробно. Идею я, наверное, уловил - добавить нужно в именованные таблицы? Я правильно понял вашу мысль?  Не понимаю, что вы подразумеваете под "icmp net"? Дайте, пожалуйста, пример.

 

P.S. В моём практическом случае всё, вроде, и так работает, но соединения "висят" до истечения тайм-аутов... Извините за нубский вопрос.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Достаточно поставить 2 микротика, на каждом обслуживать свою сеть и у каждого свой провайдер, при отвале одного провайдера пропадает дефолтный маршрут и он автоматом попадает на оставшийся микротик с каналом. И никакие скрипты не нужны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.