Как настроить маршрутизацию между двумя сетями в роутер

Всем привет! Статическая маршрутизация – это по сути специальный выделенный путь, по которому должен пройти пакет информации из пункта А в пункт Б. Напомню, что у нас в сети чаще всего встречаются два устройства: маршрутизаторы и коммутаторы. Напомню, что коммутаторы работают на канальном уровне, а маршрутизаторе на сетевом. Далее я коротко расскажу, про Static Route и как это настроить на домашнем устройстве.

Содержание

  1. Коротко про маршрутизацию
  2. ШАГ 1: Заходим в настройки роутера
  3. ШАГ 2: Настройка
  4. TP-Link
  5. D-Link
  6. ASUS
  7. ZyXEL Keenetic
  8. Netis
  9. Tenda
  10. Задать вопрос автору статьи

Коротко про маршрутизацию

Маршрутизатор, исходя из названия, имеет у себя таблицу маршрутизации, а коммутатор коммутации. Все логично, не правда ли. Но есть небольшая проблема коммутации. Представим, что у нас есть две сети по 250 машин и между ними стоят 2 свича.

Статический маршрут на примере домашних роутеров

Если вы помните в таблице коммутации содержатся MAC-адреса. Да они уникальны, поэтому для работы сети нужно, чтобы каждый свич знал, как минимум 500 таких адресов, что не так мало. И тут встает проблема масштабируемости сети, при добавлении новых машин.

Статический маршрут на примере домашних роутеров

А что если установить вместо коммутаторов маршрутизаторы. В итоге у нас есть две сети:

  • 192.168.1.0/24
  • 192.168.2.0./24

И чтобы пакету добраться из одной сети в другую, нужна одна запись в таблице маршрутизации, а именно о соседнем роутере, который уже в свою очередь знает компьютеры «из своего района». Это и удобно, и экономично в плане хранения нужной информации, так как не нужно хранить таблицу из MAC-адресов всех участников сети.

СОВЕТ! Для большей картины понимания самой темы, советую почитать дополнительные материалы про то, что такое маршрутизатор, коммутатор и про модель OSI.

И тут у нас появляются два понятия:

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

Далее я расскажу, как вводить эти статические маршруты для использования их в домашних роутерах.

Статический маршрут на примере домашних роутеров

Смотрим на картинку выше. У нас есть второй роутер (router 2), который имеет доступ к интернету (он же является основным шлюзом). У нас есть компьютер (PC), который подключен сначала к коммутатору. Коммутатор подключен к двум роутерам.

Проблема в том, что ПК должен иметь доступ к серверу (172.30.30.1), но при запросе на router 2, у него в таблице маршрутизации нет данных об этих серверах. Теперь давайте попробуем вписать эти настройки в маршрутизатор.

ШАГ 1: Заходим в настройки роутера

Вот мы и перешли непосредственно к настройке статической маршрутизации. Подключаемся к сети интернет-центра через кабель или по Wi-Fi. Далее нужно ввести DNS или IP-адрес роутера в адресную строку любого браузера. Настройку мы будем делать через Web-интерфейс. Подсказка: адрес можно подсмотреть на этикетке под корпусом аппарата. Чаще всего используют адреса:

  • 192.168.1.1
  • 192.168.0.1

Если вы ранее его настраивали, вводим логин и пароль – их также можно подсмотреть на той же самой бумажке. Чаще всего используют комбинации:

  • adminadmin
  • admin – *Пустая строка*

Если есть проблемы со входом в роутер, то смотрим инструкцию тут.

ШАГ 2: Настройка

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

  • IP адрес назначения – у нас это IP нашего конкретного сервера, к которому мы хотим пробиться через наш 1-ый роутер (172.30.30.1).
  • Маска подсети – указываем 255.255.255.0.
  • Шлюз – это IP того роутера, который имеет доступ к серверу. В примере это 192.168.0.2 (Второй маршрутизатор).
  • Интерфейс – в некоторых настройках нужно будет указывать еще и его. Если доступ к шлюзу идет через интернет, то указываем WAN. Если же вы подключены к нему через LAN порт (как в нашем примере), то указываем его.

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

TP-Link

Старая прошивка

Слева находим раздел «Дополнительные настройки маршрутизации», и в открывшемся списке нажимаем по пункту «Список статических маршрутов». Нажимаем по кнопке «Добавить».

Статический маршрут на примере домашних роутеров

Вписываем данные.

Статический маршрут на примере домашних роутеров

Новая прошивка

«Дополнительные настройки» – «Сеть» – «Расширенные настройки маршрутизации». Нажимаем по плюсику и вписываем нужную информацию.

Статический маршрут на примере домашних роутеров

D-Link

В классическом светлом интерфейсе нужно перейти в «Дополнительно» и нажать по «Маршрутизации».

Статический маршрут на примере домашних роутеров

В темной прошивке все делается также, только сначала нужно перейти в «Расширенные настройки».

Статический маршрут на примере домашних роутеров

Добавляем правило.

Статический маршрут на примере домашних роутеров

ASUS

Переходим в раздел «Локальная сеть», открываем вкладку «Маршруты» и вписываем наши данные. В конце не забудьте нажать на плюсик, правее таблички и нажать на кнопку «Применить».

Статический маршрут на примере домашних роутеров

ZyXEL Keenetic

Новая прошивка

Переходим на страницу «Маршрутизации» и нажимаем по кнопке добавления правила.

Статический маршрут на примере домашних роутеров

Теперь вводим данные:

Статический маршрут на примере домашних роутеров

  • Тип маршрута – тут нужно указывать тот тип, который вам нужен. Если исходить из задачи, которую указал я, то мы указываем «Маршрут узла».
  • Адрес сети назначения – указываем адрес сервера. В нашем случае это 30.30.1.
  • Маска подсети – 255.255.255.0.
  • Адрес шлюза – адрес роутера, который подключен к нашему серверу. 192.168.0.2.
  • Интерфейс – указываем тот интерфейс, который мы будем использовать для связи. В нашем примере пакеты пойдут локально через LAN порт, поэтому указываем LAN.

Старая прошивка

Нажимаем по значку плакетки в самом низу и переходим на вкладку «Маршруты». Нажимаем по кнопке добавления и вводим нужные вам данные.

Статический маршрут на примере домашних роутеров

Добавление целого списка маршрутов

Кстати тут вы можете загрузить сразу целую таблицу маршрутизации. Для этого выбираем в том же разделе другую кнопку.

Статический маршрут на примере домашних роутеров

Статический маршрут на примере домашних роутеров

Файлик должен иметь расширение типа BAT. И иметь вид как на скрине ниже. Его спокойно можно создать в блокноте.

Статический маршрут на примере домашних роутеров

Вид достаточно простой:

route ADD IP-адрес назначения MASK указываем маску указываем адрес шлюза

Пример:

route ADD 172.30.30.1 MASK 255.255.255.0 192.168.0.2

ПРИМЕЧАНИЕ! Каждый новый адрес должен начинаться с новой строки, а после последнего указанного IP не должен стоять пробел.

Netis

Переходим в раздел «Advanced» (кнопкам в правом верхнем углу) – «Расширенные» – «Статический маршрут.» – вводим каждый пункт и нажимаем по кнопке «Добавить».

Статический маршрут на примере домашних роутеров

Tenda

Нужный нам пункт находится в разделе «Расширенные настройки».

Статический маршрут на примере домашних роутеров

Статический маршрут на примере домашних роутеров

Как настроить статическую маршрутизацию на беспроводном роутере?

Требования к использованию

Дата последнего обновления: 05-28-2019 08:15:03 AM

555523

Эта статья подходит для: 

TL-WR841ND , TL-WR842ND , TL-WR843ND , Archer C5( V1.20 ) , Archer C2( V1 ) , Archer C50( V1 ) , TL-WDR3500 , TL-WR720N , TL-WR841N , TL-WDR3600 , TL-WR710N , TL-WR740N , Archer C20i , TL-WR741ND , TL-WR940N , TL-WR743ND , TL-WR1043ND , Archer C7( V1 V2 V3 ) , TL-WR1042ND , TL-WR542G , TL-WR702N , TL-WR700N , TL-WR843N , TL-WR340G , TL-WDR4300 , TL-WR340GD , Archer C20( V1 ) , TL-MR3220 , TL-WR842N , TL-WR2543ND , TL-MR3020 , TL-WR840N , TL-MR3040 , TL-WR841HP , TL-WDR4900 , TL-WR941ND , TL-WR543G , TL-WR541G , TL-WR810N , TL-MR3420

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

Вот два типичных сценария, в качестве примеров, когда требуется статический маршрут, рассмотрим их.

Сценарий 1:

Проблема:
Шлюзом ПК-является роутер 2, который предоставляет доступ в интернет.
Когда ПК хочет подключиться к серверам сервер 1 и сервер 2, сначала запрос будет отправлен на роутер 2. Поскольку к сервер 1 и сервер 2 нет маршрута в таблице маршрутов роутера 2, запрос будет отклонен.

Решение: Добавление статического маршрута на роутере 2

Сетевые параметры: Серверы в сетевом сегменте: 172.30.30.0. Маска подсети IP для этого сегмента: 255.255.255.0

Сценарий 2:

Проблема: Шлюзом сети LAN является роутер 1, роутер 2 подключен по WDS к роутеру 1. В таблице маршрутизации роутера 2 нет записи маршрута от роутера 2 к NTP-серверу, поэтому роутер 2 не может синхронизировать время с NTP сервером.

Разрешение: Добавление статического маршрута на роутере 2

Сетевые параметры: IP-адрес сервера в Интернете — 132.163.4.101. Маска подсети IP для этого адреса 255.255.255.255

Шаги настройки:

Шаг 1.

Зайдите на web – страницу настройки роутера.

Для этого в адресной строке браузера наберите 192.168.0.1

Шаг 2. Введите имя пользователя и пароль на странице входа. Имя пользователя и пароль по умолчанию — admin.

Шаг 3. В меню с левой стороны выберите раздел Настройки маршрутизацииСписок статических маршрутов.

Шаг 4.

Нажмите Добавить ….

       В первом поле введите IP-адрес назначения.

       В втором поле введите маску подсети.

       В третьем поле IP-адрес шлюза, который должен находиться в том же сегменте локальной сети, что и роутер.

Пример ввода параметров для Сценария 1:

Пример ввода параметров для Сценария 2:

Если у Вас возникнуть какие либо сложности с настройкой, обратитесь в техническую поддержку TP-Link

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

Был ли этот FAQ полезен?

Ваш отзыв поможет нам улучшить работу сайта.

Что вам не понравилось в этой статье?

  • Недоволен продуктом
  • Слишком сложно
  • Неверный заголовок
  • Не относится к моей проблеме
  • Слишком туманное объяснение
  • Другое

Как мы можем это улучшить?

Спасибо

Спасибо за обращение
Нажмите здесь, чтобы связаться с технической поддержкой TP-Link.

From DD-WRT Wiki

Jump to: navigation, search

Объединение сегментов сети статическими маршрутами

Contents

  • 1 Введение
  • 2 Создание подсетей
  • 3 Пример
  • 4 Настройка статических маршрутов
  • 5 Готово

[edit] Введение

Цель этого руководства — объяснить, как объединить разные сегменты сети (подсети) вместе, используя статические маршруты для пересылки трафика в нужную подсеть другого маршрутизатора. Не будем вдаваться в подробности подсетей в целом, хотя скажем, что использование подсетей имеет такие преимущества, как уменьшение сетевого трафика (меньше широковещательных кадров) и улучшение контроля доступа между узлами. Важно отметить, что связывание подсетей называется маршрутизацией, а используемые для этого интерфейсы не должны быть объединены в сетевой мост с любыми другими для правильной работы.

[edit] Создание подсетей

Существует множество способов создания подсетей в DD-WRT. По умолчанию только порт WAN не объединен в сетевой мост с другими интерфейсами, а коммутатор LAN (который является аппаратным мостом) и беспроводные интерфейсы объединены друг с другом программным обеспечением.

Способы создания дополнительных подсетей включают в себя:

  • Задайте для беспроводного интерфейса значение «Unbridged», чтобы он не был объединен в сетевой мост с интерфейсами LAN коммутатора.
  • Настройте VLAN, если коммутатор поддерживает их.
  • Добавьте виртуальные интерфейсы к любому существующему интерфейсу, который может преодолеть аппаратные ограничения, такие как коммутаторы без поддержки VLAN.
ifconfig eth0:1 [IP-адрес_маршрутизатора_в_новой_подсети] netmask [Маска_подсети] broadcast [Широковещательный_адрес]

[edit] Пример

Теперь предположим, что у вас есть три маршрутизатора Router1..3, соединенных вместе. Порт WAN маршрутизатора Router1 подключен к Интернету, что делает его шлюзом всей локальной сети, а маршрутизаторы Router2 и 3 имеют порты WAN, подключенные к портам LAN Router1. Маршрутизатор Router2 и/или 3 также может использовать режим клиента (Client mode) или повторителя (Repeater mode) (без сетевого моста!).

Image:Static_Routes_1.png

По умолчанию все эти маршрутизаторы будут работать в режиме маршрутизации ‘Gateway’ («Шлюз»), что означает, что они выполняют преобразование сетевых адресов (Network Address Translation, NAT), что делает компьютеры в подсети LAN невидимыми со стороны интерфейса WAN. Поскольку каждый маршрутизатор имеет интерфейс, подключенный к подсети 192.168.1.0/24, все они имеют маршруты к этой подсети. Однако маршрутизатор Router1 не имеет маршрута к 192.168.2.0/24 или 192.168.3.0/24, Router2 не имеет маршрута к 192.168.3.0/24, а Router3 не имеет маршрута к 192.168.2.0/24.

[edit] Настройка статических маршрутов

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

Статические маршруты настраиваются со следуюшими параметрами на странице Setup → Advanced Routing веб-интерфейса DD-WRT:

  • Destination LAN NET — удаленная подсеть, для которой вы создаете маршрут.
  • Subnet Mask — маска подсети удаленной подсети. Как правило, используется маска подсети класса C 255.255.255.0, которая в нотации CIDR равна /24, как показано на изображении выше.
  • Gateway — адрес шлюза по умолчанию, который должен быть задан как IP-адрес следующего перехода к подсети назначения. В нашем случае это IP-адрес интерфейса WAN маршрутизаторов Router2 и Router3. В сетях с большим количеством устройств следующим переходом может не быть устройство, напрямую подключенное к целевой подсети, на пути к ней могут быть еще несколько сегментов сети с маршрутизаторами.
  • Interface — это должен быть интерфейс, к которому подключен следующий переход. В нашем примере маршрутизаторы Router2 и Router3 подключены к интерфейсу LAN/WLAN (br0) маршрутизатора Router1.

Настройте маршрутизатор Router1 так, как указано на следующих изображениях:

Image:Static_Routes_2.png

Image:Static_Routes_3.png

С настроенными статическими маршрутами теперь можно безопасно отключить преобразование сетевых адресов NAT на маршрутизаторах Router2 и Router3, переключив их режим работы Operating Mode с «Gateway» на «Router» на странице Setup → Advanced Routing веб-интерфейса.

Также понадобится использовать команды Iptables, чтобы разрешить трафик через брандмауэры маршрутизаторов Router2 и Router3, чтобы обеспечить полноценную связь между подсетями. Команды Iptables необходимо сохранить в сценарии брандмауэра (firewall script) на странице Administration → Commands веб-интерфейса. Вот несколько примеров того, как это можно сделать:

# Разрешить любой трафик через маршрутизатор (просто, но не безопасно, нельзя использовать на маршрутизаторах, напрямую подключенных к Интернету)
iptables -I FORWARD -j ACCEPT
# Для маршрутизатора Router2: Разрешить трафик из подсетей Router1 и Router3
iptables -I FORWARD -s 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -s 192.168.3.0/24 -j ACCEPT
# Для маршрутизатора Router3: Разрешить трафик из подсетей Router1 и Router2
iptables -I FORWARD -s 192.168.1.0/24 -j ACCEPT
iptables -I FORWARD -s 192.168.2.0/24 -j ACCEPT
# Разрешить пересылку всего блока 192.168.0.0/16 через маршрутизатор
iptables -I FORWARD -s 192.168.0.0/16 -j ACCEPT

[edit] Готово

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

Если вы хотите, чтобы компьютеры отображались в сетевом окружении Windows, необходимо настроить сервер WINS и настроить DHCP-сервер для объявления сервера WINS.

В прошлой статье мы с вами обсудили процесс маршрутизации между сетями, подключенными к интерфейсами одного единственного маршрутизатора (рекомендую ознакомиться с ней), сегодня же мы разберем, как осуществляется маршрутизация между сетями, подключенными к разным маршрутизаторам, связанным между собой. Пока что мы не будим лезть в дебри протоколов динамической маршрутизации, а разберемся, как пользоваться статической маршрутизацией. В качестве примеров, для демонстрации настройки будим использовать маршрутизаторы фирмы Cisco,  доступные в Packet Tracer.

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

Объединение сетей с помощью маршрутизаторов

Как мы и обсуждали ранее сети, подключенные к интерфейсам одного маршрутизатора, будут видеть друг друга. Так сети «левого » маршрутизатора 192.168.1.0/24, 172.20.0.0/16 и 192.168.100.0/30 будут видеть друг друга. Аналогично обстоят дела с «правым» маршрутизатором. Но вот как будут обстоять дела с взаимодействием сетей данных маршрутизаторов между собой? Например, компьютеры сети 10.0.0.0/8 не будут доступны из сети 192.168.1.0/24.  Данный принцип, для всех сетей, проиллюстрирован на «жестком» рисунке ниже:

Карта доступности сетей

Почему же некоторые сети не видят друг друга. Все очень просто, соседние маршрутизаторы не содержат записей о сетях подключенных, только к другому маршрутизатору. Например, маршрутизатор «левый» не знает о существование сети 10.0.0.0/8, подключенной к «правому» маршрутизатору.



Давайте сымитируем данную ситуацию в Cisco Packet Tracer, а заодно поищем пути ее решения. Для начала соберем в Packet Tracer следующую схему (как это сделать смотрите в предыдущей статье):

Начинаем собирать нашу сеть

На данной схеме компьютер PC0 имеет IP адрес – 192.168.1.100, PC1 – 172.20.20.100, PC2 – 192.168.2.100, PC3 – 10.10.10.100. Интерфейсы маршрутизатора, к которым подключены компьютеры, имеют такие же адреса, как и сами компьютеры, только в четвертом октете стоит 1. Например, для интерфейса к которому подключен ПК с адресом 192.168.1.100 зададим IP адрес 192.168.1.1. В качестве шлюза по умолчанию у каждого компьютера указан интерфейс маршрутизатора, к которому он подключен. После настройке интерфейсов маршрутизаторов, сохраните их конфигурации, выполнив wr mem. Далее соединим маршрутизаторы между собой. Чтобы это сделать, нам потребуется добавить к маршрутизатору интерфейсную плату. В данном случае добавим к маршрутизатору плату  NM-1FE-TX (NMNetwork module, 1FE – содержит один порт FastEthernet, TX – поддерживает 10/100MBase-TX).Чтобы это сделать перейдите к окну конфигурации маршрутизатора, выключите его, щелкнув по кнопке питания изображенной на нем.

Кнопка выключения маршрутизатора в Packet Tracer

После этого перетяните необходимую интерфейсную плату в разъем маршрутизатора.

Вставляем интерфейсную плату в маршрутизатор

После того как карта добавлена, еще раз щелкните по тумблеру маршрутизатора, чтобы включить его. Посмотрите его интерфейсы, должен добавиться еще один – FastEthernet1/0. Повторите аналогичные действия со вторым маршрутизатором. Задайте интерфейсу FastEthernet1/0 «левого» маршрутизатора IP адрес 192.168.100.1 c с маской 255.255.255.252, а «правому маршрутизатору» 192.168.100.2 с аналогичной маской. После этого соедините интерфейсы FastEthernet1/0  этих маршрутизаторов между собой.

Маршрутизатору, соединенные между собой

Проверим доступность компьютеров одной сети из других. Если все сделано верно, то картина доступности должна соответствовать второму рисунку данной статьи. Если вы внимательно посмотрите на данный рисунок, то заметите что на данном рисунке не все стрелки двунаправленные. С двунаправленными стрелками все понятно, если вы будите пинговать в данном направлении, то компьютеры будут отвечать вам на ваши ICMP запросы (так как происходит маршрутизация в пределах одного маршрутизатора). Намного интереснее  обстоит дело с однонаправленными зелеными стрелками. Хотя пинги в данном направлении не проходят, на самом деле ICMP пакеты доходят до места назначения, но вот вернуться обратно уже не могут. Рассмотрим как это происходит на конкретном примере. Допустим, с компьютера с IP адресом 172.20.20.100 вы пытаетесь пропинговать интерфейс с IP адресом 192.168.100.2, «правого» маршрутизатора. Картина будет выглядеть следующим образом:

Интерфейс «правого» маршрутизатора не отвечает

Попробуем отследить путь ICMP пакетов. Для этого включим дебаги  (режим отладки определенных параметров) на маршрутизаторах, через которые предположительно должны пройти ICMP пакеты. Выполним команду debug ip packet, на обоих маршрутизаторах. После чего опять попытаемся пропинговать с адреса  172.20.20.100 адрес 192.168.100.2. Посмотрим, что появилось на «левом маршрутизаторе»:

IP: tableid=0, s=172.20.20.100 (FastEthernet0/1), d=192.168.100.2 (FastEthernet1/0), routed via RIB

IP: s=172.20.20.100 (FastEthernet0/1), d=192.168.100.2 (FastEthernet1/0), g=192.168.100.2, len 128, forward

Первая строка говорит о том, что на маршрутизатор прибыл пакет с адреса 172.20.20.100, направляемый на адрес 192.168.100.2. Во второй строчке говорится о том, что данный пакеты был передан дальше, ключевое слово здесь «forward».

Теперь посмотри, что творится в это же время на «правом» маршрутизаторе:

IP: tableid=0, s=172.20.20.100 (FastEthernet1/0), d=192.168.100.2 (FastEthernet1/0), routed via RIB

IP: s=172.20.20.100 (FastEthernet1/0), d=192.168.100.2 (FastEthernet1/0), len 128, rcvd 3

IP: s=192.168.100.2 (local), d=172.20.20.100 len 128, unroutable

Как видно из первых двух строчек, наш ICMP пакет все таки дошел до «правого» маршрутизатора.  А что должен сделать интерфейс, на который направлялся ping? Правильно, ответить на него послав ICMP пакеты в обратном направлении  с адреса 192.168.100.2 на 172.20.20.100. Вот тут то и начинаются проблемы. «Правый» маршрутизатор не имеет в своей таблице маршрутизации информации о сети 172.20.20.0/16. Шлюз по умолчанию мы еще не прописывали, поэтому маршрутизатор просто не может отослать ответы, в результате чего появляется третья строка дебага, ключевое слово в которой «unroutable».

После того как мы разобрались с тем, как в нашей сети, в данный момент, ходят пакеты. Отключим дебаги (no debug ip packet – отключает включенный ранее дебаг, show debugging – позволяет посмотреть включенные дебаги), и перейдем к настройке маршрутизации.

В нашей маленькой сети, самым простым способом настроить маршрутизацию, является добавление маршрута по умолчанию. Для того чтобы это сделать выполните на «левом» маршрутизаторе в режиме конфигурирования следующую команду:

   ip route 0.0.0.0 0.0.0.0 192.168.100.2

На «правом» маршрутизаторе:

   ip route 0.0.0.0 0.0.0.0 192.168.100.1

В следующих командах первые 4 цифры обозначают IP адрес сети назначения, следующие  4 цифры обозначают её маску, а последние 4 цифры – это IP адрес интерфейса, на который необходимо передать пакеты, чтобы попасть в данную сеть. Если мы указываем в качестве адреса сети 0.0.0.0 с маской 0.0.0.0, то данный маршрут становится маршрутом по умолчанию, и все пакеты, адреса назначения которых, прямо не указаны в таблице маршрутизации будут отправлены на адрес, указанный в нем.

Посмотрим как это выглядит на конкретном примере. Допустим, мы хотим пропинговать с компьютера с адресом 192.168.1.100 компьютер с IP адресом 10.10.10.100.  В качестве шлюза по умолчанию на компьютере с адресом 192.168.1.100 установлен адрес интерфейса маршрутизатора 192.168.1.1. Сначала компьютер будет искать в свой таблице маршрутизации (да у обычного компьютера она тоже есть) непосредственно адрес 10.10.10.100, после того как он его не найдет, он начнет искать в таблице маршрутизации маршрут к сети 10.0.0.0/8. После того, как данный маршрут так же не будет обнаружен. ICMP пакеты будут отправлены на адрес по умолчанию, то есть на интерфейс маршрутизатора с адресом 192.168.1.1. Получив пакет, маршрутизатор просмотрит адрес его назначения – 10.10.10.100 и также попытается обнаружить его в свой таблице маршрутизации. Когда это не увенчается успехом, маршрутизатор попробует найти в свой таблице маршрутизации маршрут к сети 10.0.0.0/8. Когда он не обнаружит и его, пакет будет отправлен используя, только что заданный нами, маршрут по умолчанию. И ICMP пакет будет передан на интерфейс, с адресом 192.168.100.2, «правого» маршрутизатора. Правый маршрутизатор попробует обнаружить в свой таблице маршрутизации маршрут к адресу 10.10.10.100. Когда это не увенчается успехом, «правый» маршрутизатор будет искать маршрут к сети 10.0.0.0/8. Информация о данной сети содержится в таблице маршрутизации, и маршрутизатор знает, что для того чтобы попасть в данную сеть необходимо отправить пакеты на интерфейс FastEthernet0/1, непосредственно к которому подключена данная сеть. Так как в нашем примере вся сеть 10.0.0.0/8, представляет из себя всего 1 компьютер, то пакеты сразу же попадают в место назначения, компьютер с IP адресом 10.10.10.100. При отсылке ответных ICMP пакетов, все происходит аналогичным образом, только адресом назначения уже будет являться 192.168.1.100/24.

К сожалению далеко не всегда можно обойтись указанием только маршрутов по умолчанию. В более сложных сетевых конфигурациях может потребоваться прописывать маршрут для каждой из сетей в отдельности. Давайте сразу рассмотрим как же это делается.  Для этого, сначала удалим из таблицы маршрутизации все статически добавленные маршруты, используя команду no ip route xxxx(адрес сети) yyyy(маска) zzzz(адрес интерфейса). В конечном итоге таблицы маршрутизации должны содержать только информацию о непосредственно подключенных  к ним сетях. Для «левого» маршрутизатора таблица будет примерно такой:

Содержимое таблицы маршрутизации

Теперь нам необходимо добавить к каждому из маршрутизаторов маршруты к двум сетям, которые ему неизвестны (к сетям, подключенным к соседнему маршрутизатору). На «левом» маршрутизаторе выполним:

   ip route 192.168.2.0 255.255.255.0 192.168.100.2

   ip route 10.0.0.0 255.0.0.0 192.168.100.2

На правом маршрутизаторе выполним:

   ip route 192.168.1.0 255.255.255.0 192.168.100.1

   ip route 172.20.0.0 255.255.0.0 192.168.100.1

Если все сделано верно, то ваши сети должны будут взаимодействовать согласно рисунку:

Карта сети

Как вы видите нам пришлось добавить довольно много маршрутной информации, даже  в такой простой сетевой конфигурации. А представьте сколько их придется прописывать, если у вас сеть имеющая десятки маршрутизаторов… Это будет адский труд. Поэтому в больших сетях обычно используют динамическую маршрутизацию, которая кроме облегчения составления таблиц маршрутизации имеет и другие плюсы. О динамической маршрутизации, мы поговорим с вами в следующих статьях.

Адаптировано под ROS6 и ROS7. Редакция от 28.12.2021

Введение

Статья ориентирована на начинающих администраторов Mikrotik RouterOS (далее ROS). В ней рассматривается маршрутизация с резервированием для нескольких не связанных multihomed AS каналов интернет, работающих по протоколу IPv4. Так же есть настройки для обеспечения базовой безопасности. «Автоматическая» балансировка исходящего трафика по каналам в данной статье не описана по причине того, что ее реализация на таких исходных данных — это череда компромиссов и ограничений, требующая отдельного рассмотрения. Инструментарий для «ручной» балансировки в статье содержится и приведенные настройки являются хорошей базой для добавления «автоматической» балансировки, как минимум полудюжиной способов.

Исходные данные

В качестве подопытного, выбран пятипортовый маршрутизатор Mikrotik с ROS версии 6.45+. Он будет маршрутизировать трафик между двумя локальными сетями (LAN1 и LAN2) и тремя провайдерами (ISP1, ISP2, ISP3). Канал к ISP1 имеет статический “серый” адрес, ISP2 — “белый”, получаемый по DHCP, ISP3 — “белый” с PPPoE авторизацией. Схема подключения представлена на рисунке:

Задача настроить роутер “МТК” на основе схемы так, чтобы:

  1. Обеспечить автоматическое переключение на резервного провайдера.
    Основной провайдер — ISP2, первый резерв — ISP1, второй резерв — ISP3.
  2. Организовать выход сети LAN1 в Интернет только через ISP1.
  3. Предусмотреть возможность приоритетно маршрутизировать трафик из локальных сетей в Интернет через выбранного провайдера на основе address-list.
  4. Предусмотреть возможность публикации сервисов из локальной сети в Интернет (DSTNAT)
  5. Настроить фильтр файервола для обеспечения минимально достаточной безопасности со стороны Интернет.
  6. Роутер мог выпускать собственный трафик через любого из трех провайдеров в зависимости от выбранного адреса источника.
  7. Обеспечить маршрутизацию ответных пакетов в канал, с которого они пришли (включая LAN).

Замечание. Настраивать роутер будем “с чистого листа”, дабы гарантировать отсутствие сюрпризов в меняющихся от версии к версии стартовых конфигурациях “из коробки”. Настройки будут задаваться командами в терминале Winbox. Физическое подключение для настройки осуществляется прямым соединением с интерфейсом ether5.

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

Пытливый и внимательный админ, самостоятельно настраивая такую или подобную схему, вдруг неожиданно осознает, что оно и так нормально работает. Да-да, без этих ваших пользовательских таблиц маршрутизации и прочих route rules, коими пестрят большинство статей на эту тему. Проверим?

Адресацию на интерфейсах и шлюзы по умолчанию настроить можем? Да:

На ISP1 прописали адрес и шлюз с distance=2 и check-gateway=ping.
На ISP2 настройка dhcp клиента по умолчанию — соответственно distance будет равен единице.
На ISP3 в настройках pppoe клиента при add-default-route=yes ставим default-route-distance=3.

NAT на выход прописать не забываем:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

По итогу, у пользователей локалок котики весело грузятся через основного провайдера ISP2 и есть резервирование канала при помощи механизма check gateway.

Пункт 1 задачи реализован. Где же мультиван со своими метками? Нет…

Дальше. Нужно выпустить конкретных клиентов из LAN через ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS \
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS \
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Пункты 2 и 3 задачи реализованы. Метки, марки, route rules, где вы?!

Нужно дать доступ к любимому OpenVPN серверу с адресом 172.17.17.17 для клиентов из Интернет? Пожалуйста:

/ip cloud set ddns-enabled=yes

Клиентам в качестве пира даем результат вывода: “:put [ip cloud get dns-name]

Прописываем проброс порта из инета:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194 \
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Пункт 4 готов.

Настраиваем фаервол и прочую безопасность для пункта 5, параллельно радуемся тому, что у пользователей уже все работает и тянемся к емкости с любимым напитком…
А! Туннели же еще забыли.

l2tp-клиент, настроенный по нагугленной статье, до любимого голландского VDS поднялся? Да.
l2tp-сервер с IPsec поднялся и клиенты по ДНС-имени из IP Cloud(см выше.) цепляются? Да.
Откинувшись на спинку стула, прихлебывая напиток, лениво рассматриваем пункты 6 и 7 задачи. Думаем — а оно нам надо? Все ж и так работает (с)… Так вот если оно таки не надо, то на этом все. Мультиван реализован.

Что такое мультиван? Это подключение нескольких каналов Интернет к одному роутеру.

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

С теми, кто остался, кто заинтересован пунктами 6 и 7 задачи, а также ощущает зуд перфекционизма, погружаемся глубже.

Важнейшей задачей реализации мультиван является корректная маршрутизация трафика. А именно: независимо от того, в какой (или в какие)Примечание 3 канал(ы) провайдера смотрит маршрут по умолчанию на нашем роутере, он должен возвращать ответ именно в тот канал, с которого пакет пришел. Задача понятна. Проблема-то где? Ведь в простой локальной сети задача та же, но никто дополнительными настройками не заморачивается и беды не ощущает. Отличие в том, что любой маршрутизируемый узел в Интернет доступен через каждый из наших каналов, а не через строго конкретный, как в простой локалке. А “беда” заключается в том, что если к нам пришел запрос на IP адрес ISP3, то в нашем случае ответ уйдет через канал ISP2, поскольку туда направлен шлюз по умолчанию. Уйдет и будет отброшен провайдером, как некорректный. С проблемой определились. Как ее решать?

Решение разделим на три этапа:

  1. Предварительная настройка. На этом этапе будут заданы базовые настройки маршрутизатора: локальная сеть, фаервол, address lists, hairpin NAT и пр.
  2. Мультиван. На этом этапе будут промаркированы и рассортированы по таблицам маршрутизации нужные соединения.
  3. Подключение к ISP. На этом этапе будут настроены интерфейсы, обеспечивающие подключение к Интернет, задействована маршрутизация и механизм резервирования каналов Интернет.

Замечание. Три разных типа подключения к ISP выбраны специально для того, чтобы показать — ничего неразрешимого в настройке мультиван с динамическими адресами нет и продемонстрировать один из вариантов решения.

Важно!

Для переключения каналов по алгоритму заданному при помощи стоимости маршрутов distance используется механизм check gateway. Скрипты, приведенные в статье, к резервированию каналов отношения не имеют и призваны автоматизировать решение проблемы динамических IP на каналах ISP2 и ISP3.

1. Предварительная настройка

1.1. Очищаем конфигурацию роутера командой:

/system reset-configuration skip-backup=yes no-defaults=yes

соглашаемся с “Dangerous! Reset anyway? [y/N]:” и, после перезагрузки, подключаемся Winbox-ом по MAC. На данном этапе конфигурация и база пользователей очищены.

1.2. В ROS 6.49+ отказываемся от смены пароля на дефолтном пользователе («Cancel» в Winbox и «Ctrl+C» в терминале) Создаем нового пользователя:

/user add group=full name=knight password=ultrasecret comment="Not horse"

логинимся под ним и удаляем дефолтного:

/user remove admin

Замечание. Именно удаление а не отключение дефолтного пользователя автор считает более безопасным и рекомендует к применению.

1.3. Создаем базовые interface lists для удобства оперирования в фаерволе, настройках discovery и прочих MAC серверах:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Подписываем комментариями интерфейсы

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

и заполняем interface lists:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN comment=LAN1
/interface list member add interface=ether5 list=LAN comment=LAN2

Замечание. Писать понятные комментарии стоит потраченного на это времени и сильно облегчает понимание конфигурации. Автор считает необходимым, в целях безопасности, добавить в interface list “WAN” интерфейс ether3, не смотря на то, что по нему не будет ходить протокол ip. Не забываем, что после того, как на ether3 будет поднят интерфейс PPP, его тоже нужно будет добавить в interface list “WAN”

1.4. Скрываем роутер от обнаружения соседства и управления из сетей провайдеров по МАС:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Создаем минимально достаточный набор правил фильтра файрволла для защиты роутера:

/ip firewall filter add action=accept chain=input \
comment="Related Established Untracked Allow" \
connection-state=established,related,untracked

(правило обеспечивает разрешение для установившихся и родственных соединений, которые инициированы как из подключенных сетей, так и самим роутером)

/ip firewall filter add action=accept chain=input \
comment="ICMP from ALL" protocol=icmp

(пинг и не только пинг. Разрешен весь icmp на вход. Весьма полезно для нахождения проблем с MTU)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" \
in-interface-list=WAN

(закрывающее цепочку input правило запрещает все остальное, что прилетает из Интернет)

/ip firewall filter add action=accept chain=forward \
comment="Established, Related, Untracked allow" \
connection-state=established,related,untracked

(правило разрешает установившиеся и родственные соединения, которые проходят сквозь роутер)

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

(правило сбрасывает соединения, с connection-state=invalid, проходящие сквозь роутер. Оно настоятельно рекомендовано Mikrotik, но в некоторых ситуациях, например при несимметричной маршрутизации может вызывать блокировку полезного трафика)

/ip firewall filter add action=drop chain=forward \
comment="Drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN

(правило запрещает проходить сквозь роутер пакетам, которые идут из Интернет и не прошли процедуру dstnat. Это убережет локальные сети от злоумышленников, которые, находясь в одном широковещательном домене с нашими внешними сетями, пропишут в качестве шлюза наши внешние IP и, таким образом, попытаются “исследовать” наши локальные сети. )

Замечание. Примем за условие, что сети LAN1 и LAN2 являются доверенными и трафик между ними и с них не фильтруется.

1.6. Создаем список с перечнем не маршрутизируемых сетей:

/ip firewall address-list
add address=0.0.0.0/8 comment="\"This\" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"\
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(Это список адресов и сетей, которые не маршрутизируются в Интернет и, соответственно, мы тоже будем этому следовать. )

Замечание. Список может изменяться, поэтому советую периодически проверять актуальность.

1.7. Настраиваем DNS для самого роутера:

/ip dns set servers=1.1.1.1,8.8.8.8

Замечание. В текущей версии ROS статически заданные серверы имен имеют приоритет перед динамическими. Запрос на разрешение имени отсылается первому серверу по порядку следования в списке. На следующий сервер переход осуществляется при недоступности текущего. Таймаут большой — более 5 сек. Возврат обратно, при возобновлении работы “упавшего сервера”, автоматически не происходит. С учетом этого алгоритма и наличия мультивана, автор рекомендует не использовать серверы, выдаваемые провайдерами.

1.8. Настраиваем локальную сеть.
1.8.1. Конфигурируем статические IP адреса на интерфейсах локальных сетей:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Задаем правила маршрутов к нашим локальным сетям через главную таблицу маршрутизации.
ROS6:

/ip route rule add dst-address=192.168.88.0/24 table=main comment="to LAN1"
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

ROS7:

/routing/rule/add action=lookup dst-address=192.168.88.0/24 table=main \
comment="to LAN1"
/routing/rule/add action=lookup dst-address=172.16.0.0/23 table=main \
comment="to LAN2"

Замечание. Это один из простых и быстрых способов получить доступ к адресам локальных сетей с соурсами внешних IP адресов интерфейсов роутера, независимо от того, в какой канал ведет маршрут по умолчанию.

1.8.3. Если необходимо включаем Hairpin NAT для LAN1 и LAN2

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" \
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" \
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Замечание. Это позволяет пользователям из LAN1 и LAN2 получать доступ через внешний IP (dstnat) к серверам, находящимся с пользователями в одном сегменте сети.

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

/routing/table/add disabled=no fib name=to_isp1
/routing/table/add disabled=no fib name=to_isp2
/routing/table/add disabled=no fib name=to_isp3

Замечание. В ROS7 переосмыслена работа с марками и таблицами маршрутов. В ROS6, к примеру, в правиле mangle action=mark-routing опция new-routing-mark позволяла непосредственно задать имя новой марки под которую в системе автоматически создавалась таблица. В ROS7, по аналогии с iproute2 в линукс, требуется предварительное создание пользовательских таблиц. Только после этого операции с ними становятся доступны в соответствующих правилах.

2. Собственно, реализация того самого корректного мультиван

Для решения задачи “отвечать туда откуда спросили” будем использовать два инструмента ROS: connection mark и routing mark. Connection mark позволяет пометить нужное соединение и в дальнейшем работать с этой меткой, как условием для применения routing mark. А уже с routing mark возможно работать в ip route и route rules. С инструментами разобрались, теперь нужно решить какие соединения метить — раз, где именно метить — два.

С первым все просто — мы должны пометить все соединения, которые приходят в роутер из Интернет по соответствующему каналу. В нашем случае это будут три метки (по количеству каналов): “conn_isp1”, “conn_isp2” и “conn_isp3”.

Нюанс со вторым заключается в том, что входящие соединения будут двух видов: транзитные и те, которые предназначены самому роутеру. Механизм connection mark работает в таблице mangle. Рассмотрим движение пакета на упрощенной диаграмме, любезно собранной специалистами ресурса mikrotik-trainings.com (не реклама):

Следуя по стрелкам, мы видим, что пакет, приходящий в “input interface”, проходит по цепочке “Prerouting” и только потом разделяется на транзитный и локальный в блоке “Routing Decision”. Поэтому, для убиения двух зайцев, задействуем Connection Mark в таблице Mangle Prerouting цепочки Prerouting.

Замечание. В ROS метки “Routing mark” указаны в разделе Ip/Routes/Rules как “Table”, а в остальных разделах, как “Routing Mark”. Сие может внести некую путаницу в понимание, но, по сути, это одно и то же, и является аналогом rt_tables в iproute2 на linux.

2.1. Метим входящие соединения от каждого из провайдеров

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1 \
new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2 \
new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3 \
new-connection-mark=conn_isp3 passthrough=no

Замечание.Те читатели, кто пробует буквально и в порядке чтения повторить настройку предложенную в статье, при вводе третьей команды столкнутся с ошибкой: «input does not match any value of interface». Это связано с отсутствием в данный момент интерфейса «pppoe-isp3», который будет сконфигурирован в п. 3.3.2. На данном этапе можно вместо «pppoe-isp3» ввести «ether3». После выполнения п. 3.3.2 следует вернуться и поставить актуальное имя интерфейса.

Для того, чтобы не метить уже помеченные соединения я использую, как более универсальное, условие connection-mark=no-mark вместо connection-state=new.

passthrough=no — потому, что в этом способе реализации перемаркировка исключена и для ускорения можно прервать перебор правил после первого же совпадения.

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

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” и попали к своему адресату в локальной сети.

Важно!

В ROS нет логического деления на внешний и внутренний интерфейсы. Если проследить путь движения ответного пакета по приведенной диаграмме, то он пройдет по тому же логическому пути, что и запрос:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” просто для запроса “Input Interface” был интерфейс ISP, а для ответа — LAN

2.2. Направляем ответный транзитный трафик по соответствующим таблицам маршрутизации

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Замечание. in-interface-list=!WAN — мы работаем только с трафиком из локальной сети и dst-address-type=!local не имеющим адрес назначения адреса интерфейсов самого роутера.

То же самое для локальных пакетов, которые пришли в роутер по пути:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”

Важно!

Ответ пойдет по следующему пути:

”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”

2.3. Направляем ответный локальный трафик по соответствующим таблицам маршрутизации

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP1" connection-mark=conn_isp1 \
dst-address-type=!local new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP2" connection-mark=conn_isp2 \
dst-address-type=!local new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP3" connection-mark=conn_isp3 \
dst-address-type=!local new-routing-mark=to_isp3 passthrough=no

На этом этапе задачу подготовки к отправке ответа в тот канал Интернет, с которого пришел запрос, можно считать решенной. Все помечено, промаркировано и готово маршрутизироваться.
Отличным “побочным” эффектом такой настройки является возможность работы проброса портов DstNAT с обоих (ISP2, ISP3) провайдеров одновременно. Не на всех, так как на ISP1 у нас не маршрутизируемый адрес. Этот эффект важен, например, для почтового сервера с двумя MХ, которые смотрят в разные каналы Интернет или для сервиса доступного через DNS имя, разрешающееся в IP адреса обоих провайдеров.

Для устранения нюансов работы локальных сетей с внешними IP роутера используем решения из пп. 1.8.2 и 3.1.2.6.

Кроме того, можно задействовать инструмент с маркировками и для решения пункта 3 задачи. Реализуем так:

2.4. Направляем трафик от локальных клиентов из списков маршрутизации в соответствующие таблицы

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 \
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 \
passthrough=no src-address-list=Via_ISP3

Замечание. Этот набор правил дан для примера. Считаю нужным обратить внимание на следующее:
— При всего двух каналах интернет разумно задать только одно правило. Для резервного канала.
— При нескольких каналах так же не имеет смысла делать правило для основного провайдера.
— Текущие настройки резервирования, при отказе «целевого» канала интернет предусматривают выход маркированного трафика через резервный канал(ы).
— Нужно помнить, что правила обрабатываются последовательно, в порядке написания. Это важно, если разные address-list содержат пересекающиеся адреса/сети. Без passthrough сработает первое встреченное правило, с passthrough – последнее. Учитывайте это при указании перекрывающихся диапазонов сетей в разных address-list.

По итогу, это выглядит приблизительно так (картинка кликабельна):

3. Настраиваем подключение к ISP и задействуем маршрутизацию по маркам

3.1. Настраиваем подключение к ISP1:
3.1.1. Конфигурируем статический IP адрес

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Настраиваем статическую маршрутизацию:
3.1.2.1. Добавляем “аварийный” маршрут по умолчанию

/interface bridge add name=br-lo comment="Loopback interface"
/ip route add distance=254 gateway=br-lo comment="Emergency route"

Замечание. Этот маршрут позволяет трафику от локальных процессов проходить этап Route Decision независимо от состояния каналов любого из провайдеров. Нюанс исходящего локального трафика заключается в том, что чтобы пакет хоть куда-то двинулся, в основной таблице маршрутизации должен присутствовать активный маршрут до шлюза по умолчанию. Если его нет, то пакет просто будет уничтожен.

В качестве расширения инструмента check gateway для более глубокого анализа состояния канала предлагаю использовать метод рекурсивных маршрутов. Суть метода заключается в том, что мы указываем маршрут через промежуточный шлюз. Соответственно check gateway будет проверять доступность именно его, а не шлюза провайдера. В качестве таких “проверочных” шлюзов будут выбраны 4.2.2.1, 4.2.2.2 и 4.2.2.3 (это публичные адреса Level3DNS) соответственно для ISP1, ISP2 и ISP3. Можете выбрать любые другие доступные адреса, исходя из собственных предпочтений.

3.1.2.2. Задаем маршрут до “проверочного” адреса

/ip route add check-gateway=ping comment="For recursion via ISP1" \
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=11

Замечание. В ROS7, относительно ROS6, несколько изменились условия построения рекурсивных маршрутов. Поэтому будем использовать универсальное решение, которое годится для обеих версий ROS. Суть его в том, что значение scope “базового маршрута” должно быть большим значения target-scope и равным target-scope рекурсивного маршрута.

3.1.2.3. Рекурсивный маршрут по умолчанию для трафика без routing mark

/ip route add check-gateway=ping comment="Unmarked via ISP1" \
distance=2 gateway=4.2.2.1 target-scope=11

Замечание. Значение distance=2 используется потому, что ISP1 по условиям задачи заявлен как первый резервный.

3.1.2.4. Рекурсивный маршрут по умолчанию для трафика c routing mark “to_isp1”
ROS6:

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 \
routing-mark=to_isp1 target-scope=11

ROS7 (в данном случае routing-mark заменяем на routing-table):

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 \
routing-table=to_isp1 target-scope=11

Замечание. Собственно, здесь мы наконец-то начинаем пользоваться плодами той подготовительной работы, что была проведена в пункте 2. По этому маршруту весь трафик, который имеет марку(таблицу) “to_isp1”, будет направлен на шлюз первого провайдера не зависимо от того, какой в данный момент активен шлюз по умолчанию для таблицы main.

3.1.2.5. Первый резервный рекурсивный маршрут по умолчанию для маркированного трафика провайдеров ISP2 и ISP3
ROS6:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 \
routing-mark=to_isp2 target-scope=11
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 \
routing-mark=to_isp3 target-scope=11

ROS7 (в данном случае routing-mark заменяем на routing-table):

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 \
routing-table=to_isp2 target-scope=11
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 \
routing-table=to_isp3 target-scope=11

Замечание. Эти маршруты нужны, в том числе, для резервирования трафика с локальных сетей, которые состоят членами address list “to_isp*”’

3.1.2.6. Прописываем маршрут для локального трафика роутера в интернет через ISP1
ROS6:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

ROS7:

/routing/rule/add action=lookup comment="From ISP1 IP to Inet" \
src-address=100.66.66.2 table=to_isp1

Замечание. В сочетании с правилами из пункта 1.8.2, обеспечивается выход в нужный канал с заданным соурсом. Это является критичным для построения туннелей, в которых задается IP адрес локальной стороны(EoIP, IP-IP, GRE, L2TP etc.). Поскольку правила в ip route rules выполняются сверху вниз, до первого совпадения условий, то данное правило должно быть после правил из пункта 1.8.2.

3.1.3. Прописываем правило NAT для исходящего трафика

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1" \
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Замечание. NATим все выходящее, кроме того, что попадает в политики IPsec. Я стараюсь не использовать action=masquerade без крайней необходимости. Оно работает медленнее и более ресурсоемко, чем src-nat, поскольку для каждого нового соединения вычисляет адрес для NAT. Однако стоит помнить о таких свойствах masquerade как очистка соединений при падении канала и нюансы выбора адреса, если их на интерфейсе несколько и они из разных сетей.

3.1.4. Отправляем клиентов из списка, которым запрещен выход через остальных провайдеров сразу на шлюз провайдера ISP1

/ip firewall mangle add action=route chain=prerouting \
comment="Address List via ISP1 only" dst-address-list=!BOGONS passthrough=no \
route-dst=100.66.66.1 src-address-list=Via_only_ISP1 place-before=0

Замечание. action=route имеет более высокий приоритет и применяется раньше остальных правил маршрутизации. place-before=0 — помещает наше правило первым в списке.

3.2. Настраиваем подключение к ISP2.

Поскольку провайдер ISP2 настройки нам выдает по DHCP, разумно настройку и вероятные изменения делать скриптом, который стартует при срабатывании DHCP клиента
ROS6:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if (\$bound=1) do={\r\
    \n   /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove [ find where \
dst-address ~\"4.2.2.2\" ]\r\
    \n   /ip route add check-gateway=ping comment=\"For recursion via ISP2\" distance=1 \
dst-address=4.2.2.2/32 gateway=\$\"gateway-address\" scope=11\r\
    \n   /ip route add check-gateway=ping comment=\"Unmarked via ISP2\" \
distance=1 gateway=4.2.2.2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP2 Main\" distance=1 gateway=4.2.2.2 \
routing-mark=to_isp2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP1 Backup1\" distance=2 gateway=4.2.2.2 \
routing-mark=to_isp1 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP3 Backup2\" distance=3 gateway=4.2.2.2 \
routing-mark=to_isp3 target-scope=11\r\
    \n   :if [:tobool ([/ip firewall nat find comment=\"NAT via ISP2\"])] do={\r\
    \n   /ip firewall nat set [find comment=\"NAT via ISP2\"] action=src-nat \
chain=srcnat ipsec-policy=out,none out-interface=\$\"interface\" \
to-addresses=\$\"lease-address\" \r\
    \n    } else={/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"lease-address\" \
    comment=\"NAT via ISP2\"}\r\
    \n   :if [:tobool ([/ip route rule find comment=\"From ISP2 IP to Inet\"])] do={\r\
    \n      /ip route rule set [find comment=\"From ISP2 IP to Inet\"] \
src-address=\$\"lease-address\" table=to_isp2\r\
    \n    } else={/ip route rule add comment=\"From ISP2 IP to Inet\" \
src-address=\$\"lease-address\" table=to_isp2}\r\
    \n} else={\r\
    \n   /ip route remove [find gateway=\"4.2.2.2\"]; /ip route remove [find where \
dst-address ~\"4.2.2.2\"]\r\
    \n   /ip firewall nat remove  [find comment=\"NAT via ISP2\"]\r\
    \n   /ip route rule remove [find comment=\"From ISP2 IP to Inet\"]\r\
    \n}\r\
    \n" use-peer-dns=no use-peer-ntp=no

ROS7:

/ip dhcp-client
add add-default-route=no dhcp-options=clientid,clientid interface=ether2 \
script=":if (\$bound=1) do={\r\
    \n   /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \
[ find where dst-address ~\"4.2.2.2\" ]\r\
    \n   /ip route add check-gateway=ping comment=\"For recursion via ISP2\" distance=1 \
dst-address=4.2.2.2/32 gateway=\$\"gateway-address\" scope=11\r\
    \n   /ip route add check-gateway=ping comment=\"Unmarked via ISP2\" \
distance=1 gateway=4.2.2.2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP2 Main\" distance=1 gateway=4.2.2.2 \
routing-table=to_isp2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP1 Backup1\" distance=2 gateway=4.2.2.2 \
routing-table=to_isp1 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP3 Backup2\" distance=3 gateway=4.2.2.2 \
routing-table=to_isp3 target-scope=11\r\
    \n   :if [:tobool ([/ip firewall/nat/ find comment=\"NAT via ISP2\"])] do={\r\
    \n   /ip firewall nat set [find comment=\"NAT via ISP2\"] action=src-nat \
chain=srcnat ipsec-policy=out,none out-interface=\$\"interface\" \
to-addresses=\$\"lease-address\" \r\
    \n    } else={/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"lease-address\" \
comment=\"NAT via ISP2\"}\r\
    \n    :if [:tobool ([/routing/rule find comment=\"From ISP2 IP to Inet\"])] do={\r\
    \n      /routing/rule/set [find comment=\"From ISP2 IP to Inet\"] \
action=lookup src-address=\$\"lease-address\" table=to_isp2\r\
    \n    } else={/routing/rule/add action=lookup comment=\"From ISP2 IP to Inet\" \
src-address=\$\"lease-address\" table=to_isp2 }\r\
    \n} else={\r\
    \n   /ip route remove [find gateway=\"4.2.2.2\"]; /ip route remove [find where \
dst-address ~\"4.2.2.2\"]\r\
    \n   /ip firewall nat remove  [find comment=\"NAT via ISP2\"]\r\
    \n   /routing/rule/remove [find comment=\"From ISP2 IP to Inet\"]\r\
    \n}\r\
    \n" use-peer-dns=no use-peer-ntp=no

Привожу содержимое только тела скрипта DHCP клиента

ROS6:

:if ($bound=1) do={
   /ip route remove [ find gateway="4.2.2.2" ]; /ip route remove [ find where \
dst-address ~"4.2.2.2" ]
   /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 \
dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=11
   /ip route add check-gateway=ping comment="Unmarked via ISP2" distance=1 \
gateway=4.2.2.2 target-scope=11
   /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 \
routing-mark=to_isp2 target-scope=11
   /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 \
routing-mark=to_isp1 target-scope=11
   /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 \
routing-mark=to_isp3 target-scope=11
   :if [:tobool ([/ip firewall nat find comment="NAT via ISP2"])] do={
    /ip firewall nat set [find comment="NAT via ISP2"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"lease-address" 
    } else={ /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2"}
   :if [:tobool ([/ip route rule find comment="From ISP2 IP to Inet"])] do={
      /ip route rule set [find comment="From ISP2 IP to Inet"] \
src-address=$"lease-address" table=to_isp2
    } else={ /ip route rule add comment="From ISP2 IP to Inet" \
src-address=$"lease-address" table=to_isp2}
} else={
   /ip route remove [find gateway="4.2.2.2"]; /ip route remove [find where \
dst-address ~"4.2.2.2"]
   /ip firewall nat remove  [find comment="NAT via ISP2"]
   /ip route rule remove [find comment="From ISP2 IP to Inet"]
}

ROS7:

:if ($bound=1) do={
   /ip route remove [ find gateway="4.2.2.2" ]; /ip route remove \
[ find where dst-address ~"4.2.2.2" ]
   /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 \
dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=11
   /ip route add check-gateway=ping comment="Unmarked via ISP2" distance=1 \
gateway=4.2.2.2 target-scope=11
   /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 \
routing-table=to_isp2 target-scope=11
   /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 \
routing-table=to_isp1 target-scope=11
   /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 \
routing-table=to_isp3 target-scope=11
   :if [:tobool ([/ip firewall/nat/ find comment="NAT via ISP2"])] do={
    /ip firewall nat set [find comment="NAT via ISP2"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"lease-address" 
    } else={ /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" }
    :if [:tobool ([/routing/rule find comment="From ISP2 IP to Inet"])] do={
      /routing/rule/set [find comment="From ISP2 IP to Inet"] action=lookup \
src-address=$"lease-address" table=to_isp2
    } else={ /routing/rule/add action=lookup comment="From ISP2 IP to Inet" \
src-address=$"lease-address" table=to_isp2 }
} else={
   /ip route remove [ find gateway="4.2.2.2" ]; /ip route remove [ find where \
dst-address ~"4.2.2.2" ]
   /ip firewall nat remove  [find comment="NAT via ISP2"]
   /routing/rule/remove [find comment="From ISP2 IP to Inet"]
}

Замечание. Первая часть скрипта срабатывает при успешном получении аренды, вторая — после освобождения аренды.Примечание 2

Важно!

В отдельных случаях шлюз может не отвечать на ICMP запросы. C этим можно встретиться на lte подключении в режиме passthrough или если провайдер фильтрует ICMP на шлюз. В такой ситуации для маршрута «For recursion via ISP(x)» вместо check-gateway=ping можно указывать check-gateway=arp.

3.3. Настраиваем подключение к провайдеру ISP3.

Поскольку провайдер настройки нам выдает динамические, то разумно необходимые изменения делать скриптами, которые стартуют после поднятия и после падения интерфейса ppp.

Замечание. Интерфейс ppp может быть указан в качестве шлюза вместо IP адреса. Однако в таком варианте рекурсивный маршрут задействовать не получится. Посему мы получаем в переменную IP адрес стороны провайдера и используем ее дальше точно так же, как и для остальных провайдеров

3.3.1. Сначала конфигурируем профиль
ROS6:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client \
on-down="/ip route remove [find gateway=\"4.2.2.3\"]\r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip firewall nat remove  [find comment=\"NAT via ISP3\"]\r\
    \n/ip route rule remove [find comment=\"From ISP3 IP to Inet\"]" \
on-up="/ip route remove [find gateway=\"4.2.2.3\"]; \r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \
dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=11\r\
    \n/ip route add check-gateway=ping comment=\"Unmarked via ISP3\" \
distance=3 gateway=4.2.2.3 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP3 Main\" distance=1 gateway=4.2.2.3 \
routing-mark=to_isp3 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP1 Backup2\" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp1 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP2 Backup2\" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp2 target-scope=11\r\
    \n/ip firewall mangle set [find comment=\"Connmark in from ISP3\"] \
in-interface=\$\"interface\"\r\
    \n:if [:tobool ([/ip firewall nat find comment=\"NAT via ISP3\"])] do={\r\
    \n  /ip firewall nat set [find comment=\"NAT via ISP3\"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=\$\"interface\" to-addresses=\$\"local-address\"} \
else={\r\
    \n  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"local-address\" \
comment=\"NAT via ISP3\"}\r\
    \n:if [:tobool ([/ip route rule find comment=\"From ISP3 IP to Inet\"])] \
do={\r\
    \n  /ip route rule set [find comment=\"From ISP3 IP to Inet\"] \
src-address=\$\"local-address\" table=to_isp3} else={\r\
    \n  /ip route rule add comment=\"From ISP3 IP to Inet\" \
src-address=\$\"local-address\" table=to_isp3 }"

ROS7:

/ppp profile
add interface-list=WAN name=isp3_client on-down=\
    "/ip route remove [find gateway=\"4.2.2.3\"]\r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip firewall nat remove  [find comment=\"NAT via ISP3\"]\r\
    \n/routing/rule/ remove [find comment=\"From ISP3 IP to Inet\"]" \
on-up="/ip route remove [find gateway=\"4.2.2.3\"]; \r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \
dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=11\r\
    \n/ip route add check-gateway=ping comment=\"Unmarked via ISP3\" \
distance=3 gateway=4.2.2.3 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP3 Main\" distance=1 gateway=4.2.2.3 \
routing-table=to_isp3 target-scope=11\r\
    \nip route add comment=\"Marked via ISP1 Backup2\" distance=3 gateway=4.2.2.3 \
routing-table=to_isp1 target-scope=11\r\
    \nip route add comment=\"Marked via ISP2 Backup2\" distance=3 gateway=4.2.2.3 \
routing-table=to_isp2 target-scope=11\r\
    \nip firewall mangle set [find comment=\"Connmark in from ISP3\"] \
in-interface=\$\"interface\"\r\
    \n:if [:tobool ([/ip firewall/nat/ find comment=\"NAT via ISP3\"])] do={\r\
    \n  /ip firewall nat set [find comment=\"NAT via ISP3\"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=\$\"interface\" to-addresses=\$\"local-address\"} \
else={\r\
    \n  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"local-address\" \
comment=\"NAT via ISP3\"}\r\
    \n:if [:tobool ([/routing/rule/ find comment=\"From ISP3 IP to Inet\"])] do={\r\
    \n  /routing/rule/ set [find comment=\"From ISP3 IP to Inet\"] action=lookup \
src-address=\$\"local-address\" table=to_isp3} else={\r\
    \n  /routing/rule/ add action=lookup comment=\"From ISP3 IP to Inet\" \
src-address=\$\"local-address\" table=to_isp3 }"

Привожу содержимое только тела скрипта PPP профиля

ROS6(On Up):

/ip route remove [find gateway="4.2.2.3"]; 
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 \
dst-address=4.2.2.3/32 gateway=$"remote-address" scope=11
/ip route add check-gateway=ping comment="Unmarked via ISP3" distance=3 \
gateway=4.2.2.3 target-scope=11
/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 \
routing-mark=to_isp3 target-scope=11
/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp1 target-scope=11
/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp2 target-scope=11
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface"
:if [:tobool ([/ip firewall nat find comment="NAT via ISP3"])] do={
  /ip firewall nat set [find comment="NAT via ISP3"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"local-address"} else={
  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3"}
:if [:tobool ([/ip route rule find comment="From ISP3 IP to Inet"])] do={
  /ip route rule set [find comment="From ISP3 IP to Inet"] \
src-address=$"local-address" table=to_isp3} else={
  /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" \
table=to_isp3 }

ROS6(On Down):

/ip route remove [find gateway="4.2.2.3"]
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip firewall nat remove  [find comment="NAT via ISP3"]
/ip route rule remove [find comment="From ISP3 IP to Inet"]

ROS7(On Up):

/ip route remove [find gateway="4.2.2.3"]; 
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 \
dst-address=4.2.2.3/32 gateway=$"remote-address" scope=11
/ip route add check-gateway=ping comment="Unmarked via ISP3" distance=3 \
gateway=4.2.2.3 target-scope=11
/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 \
routing-table=to_isp3 target-scope=11
ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 \
routing-table=to_isp1 target-scope=11
ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 \
routing-table=to_isp2 target-scope=11
ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface"
:if [:tobool ([/ip firewall/nat/ find comment="NAT via ISP3"])] do={
  /ip firewall nat set [find comment="NAT via ISP3"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"local-address"} else={
  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3"}
:if [:tobool ([/routing/rule/ find comment="From ISP3 IP to Inet"])] do={
  /routing/rule/ set [find comment="From ISP3 IP to Inet"] action=lookup \
src-address=$"local-address" table=to_isp3} else={
  /routing/rule/ add action=lookup comment="From ISP3 IP to Inet" \
src-address=$"local-address" table=to_isp3 }

ROS7(On Down):

/ip route remove [find gateway="4.2.2.3"]
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip firewall nat remove  [find comment="NAT via ISP3"]
/routing/rule/ remove [find comment="From ISP3 IP to Inet"]

Замечание. Строка
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
позволяет корректно обрабатывать переименование интерфейса, поскольку работает с его ID а не отображаемым именем.

3.3.2. Теперь, используя профиль, создаем подключение ppp

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no \
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client \
add-default-route=no user=isp3_client

Замечание. Некоторые провайдеры «забывают» отдавать параметр «remote-address». В таком случае, при подключении скрипт настройки отработает некорректно, а в логе вы увидите такую ошибку:
pppoe,ppp,info pppoe-isp3: could not determine remote address, using xxx.xxx.xxx.xxx
Для решения этой проблемы нужно отключить check-gateway для маршрута с комментарием «For recursion via ISP3» и задать в ppp профиле IP адрес(любой фиктивный):

/ip route unset [find comment="For recursion via ISP3"] check-gateway
/ppp profile set isp3_client remote-address=169.254.69.96

Строка
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
позволяет корректно обрабатывать переименование интерфейса, поскольку работает с его идентификатором в системе а не отображаемым именем.

В качестве последнего штриха настроим часы
ROS6:

/system ntp client set enabled=yes \
server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

ROS7:

/system ntp client set enabled=yes \
servers=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Для тех, кто дочитал до конца

Предложенный способ реализации мультиван — есть личное предпочтение автора и не является единственно возможным. Инструментарий ROS обширен и гибок, что с одной стороны вызывает сложности для начинающих, с другой — причина популярности. Изучайте, пробуйте, открывайте для себя новые инструменты и решения. Например, в качестве применения полученных знаний, можно в данной реализации мультиван заменить инструмент Сheck-gateway с рекурсивными маршрутами на Netwatch. Так же можно для повышения надежности использовать каскад рекурсивных маршрутов, что уменьшит количество ложных переключений при временной недоступности хоста, выбранного в качестве «базового». А такое иногда случается, даже со сверхнадежными anycast адресами.

Примечания

  1. Check-gateway — механизм, который позволяет деактивировать маршрут после двух подряд не успешных проверок шлюза на доступность. Проверка осуществляется раз в 10 секунд, плюс таймаут ответа. Итого, фактический тайминг переключения лежит в диапазоне 20-30 секунд. Если такой тайминг переключения не достаточен — есть вариант воспользоваться инструментом Netwatch, где таймер проверки можно задавать вручную и использовать пользовательские скрипты для более тонкого анализа состояния.
    Механизм Check-gateway не срабатывает при периодических потерях пакетов в канале. Важно! Деактивация/активация маршрута механизмом Check-gateway влечет за собой деактивацию/активацию всех остальных маршрутов, которые идут через тот же шлюз. Поэтому включать check-gateway для всех связанных маршрутов нет необходимости.
  2. Бывает, что в механизме работы DHСP происходит сбой, который выглядит, как клиент подвисший в состоянии renew. В таком случае вторая часть скрипта не отработает, но корректно ходить трафику не помешает, поскольку состояние отслеживает соответствующий рекурсивный маршрут.
  3. ECMP (Equal Cost Multi-Path) — в ROS есть возможность задать маршрут с несколькими шлюзами и одинаковой distance. В таком случае соединения будут распределяться по каналам, используя алгоритм round robin, пропорционально количеству указанных шлюзов.

За толчок к написанию статьи, помощь при формировании ее структуры и расстановке акцентов — личная благодарность Евгению @jscar

  • Как настроить локальную сеть через вай фай роутер
  • Как настроить модем huawei в режим роутер
  • Как настроить медиа сервер через роутер
  • Как настроить модем к роутеру для раздачи интернета
  • Как настроить маршрутизацию между двумя роутерами cisco