+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Резервирование Mikrotik с двумя WAN-интерфейсами

Резервирование Mikrotik с двумя WAN-интерфейсами, RouterOS

draid

Guest

03.09.2018 16:43:00

Всем привет! Недавно я купил роутер Mikrotik, и модель, которую я выбрал в качестве своего «учебного» роутера (спасибо коллегам с форума за помощь), — hAP ac2. Если кому-то интересно что-то насчёт необходимости этого роутера, вот тема, которую я создал: http://forum.mikrotik.com/t/mikrotik-routers-question/122624/1

Одно из самых важных для меня — поддержка dual WAN. Мне нужна она только для резервирования, без балансировки нагрузки. В эти выходные у меня было пару часов поиграться с новым роутером и попытаться сделать простую настройку.

Вот текущая ситуация с провайдерами:

Основная линия — 100 Мбит PPPoE напрямую на hAP
Резерв — 50 Мбит ADSL — телефонная линия -> Модем -> hAP
Статические локальные IP от обоих провайдеров.

Что я сделал на данный момент:
Я начал с дефолтной конфигурации hAP и от неё пытался построить нужную мне схему.
Сначала поменял IP роутера на 192.168.0.1, создал новый DHCP-сервер с первичным DNS 192.168.0.1 и вторичным 8.8.8.8, добавил пул в нужном диапазоне.
Исключил порт ether2 из бриджа и добавил его в список WAN, чтобы к нему применялись другие правила.

Создал PPPoE клиент на port1 с нужным логином и паролем, использовал peer DNS, default route/pppoe-out тоже добавил в список WAN.
Статический IP на port2 — 192.168.x.x, добавил маршрут с gateway (ADSL-модемом).
Статический DNS такой же, как у модема ADSL.
Distance основного линка — 1, резервного — 2.

В этой конфигурации пока всё вроде работает, хотя я не уверен, не упустил ли чего, и тестировал только вручную, отключая WAN-порты.
Впрочем, эта конфигурация отличается от туториала по PCC, и я не уверен, можно ли применить PCC при ситуации с одним статическим IP и одним PPPoE? Могу ли я использовать в качестве gateway весь pppoe-out в сценарии из PCC wiki?

Я читал разные посты и вики про dual WAN, но, кажется, большинство делают балансировку нагрузки, и это в основном для статических адресов. Там еще есть правила mangle, которые я пока не успел тщательно изучить. Видел, что предпочтительный способ для резервирования dual WAN — это PCC, но как насчёт mangle? Они вроде тоже используют его.

Как лучше всего настроить dual WAN fail-over в моём случае и стоит ли моя текущая конфигурация хоть что-то?
Я использую дефолтные настройки firewall, применённые к обоим WAN-портам через WAN-лист, так же как и NAT.

Спасибо всем заранее за помощь! Это отличный девайс с кучей настроек, и мне он нравится. Было бы здорово, если бы добавили что-то вроде быстрого конфига для dual WAN — сейчас это распространённая вещь. Пока роутер будет использоваться для экспериментов, пока я не почувствую себя увереннее с этой ОС и не соберу свои знания воедино.

sindy

Guest

20.09.2018 14:20:00

Нет смысла мониторить удалённый IP, он может даже вообще не быть активным на удалённой стороне. Чтобы определить локальный PPPoE туннель по IP-адресу шлюза, можно назначить локальный псевдоним удалённому адресу туннеля, как предложил @Sob. Для мониторинга прозрачности WAN-соединения адреса для проверки должны быть «вечными» в интернете, то есть вместо проверки только шага между вашим маршрутизатором и PPPoE-сервером провайдера вы проверяете весь путь через провайдера до интернета.

Что касается IP-шлюза, выданного DHCP на втором WAN-интерфейсе, снова нет смысла мониторить этот адрес напрямую, но его нужно использовать как шлюз к проверяемому месту назначения в схеме рекурсивного поиска следующего хопа. И назначить псевдоним этому адресу не так просто (хотя в некоторых случаях можно, но именно в таких случаях это бессмысленно). Если DHCP-сервер работает на модеме+маршрутизаторе от провайдера, вероятность того, что адрес шлюза когда-либо поменяется, крайне мала — около 0,001%. Если же это устройство работает как мост, а DHCP-сервер физически находится на другой стороне WAN-соединения, шанс, что адрес шлюза изменится, значительно выше.

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

draid

Guest

21.09.2018 20:03:00

Всем привет, спасибо всем за ценную помощь. Сегодня вечером у меня было немного времени проверить всё, и в целом всё работает хорошо, за одним исключением. Удалённый адрес PPPoE меняется. Похоже, что это либо 5, либо 12, но он постоянно меняется.

Что я сделал на данный момент:
/ip route add check-gateway=ping distance=1 gateway=8.8.8.8
add check-gateway=ping distance=2 gateway=8.8.4.4
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.x.x scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=x.x.x.x scope=10

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

Вы упоминали какой-то скрипт, но нет ли более простого способа всегда брать текущий удалённый адрес и ставить его как GW без скриптов? Очень жаль, что это не работает с PPPoE-интерфейсом. Мне удалось увидеть адрес GW на панели статуса PPPoE-интерфейса.

Я не до конца понял предложенный метод от @Sob. Также нашёл в одной статье, что у рекурсивного метода есть такое ограничение: IP-адрес, который вы используете как цель, доступен только через основной маршрут. Если основной маршрут недоступен, то этот IP тоже становится недостижимым. Если вы используете 8.8.8.8 для разрешения DNS, то DNS-сервис будет недоступен при падении основного маршрута. Поэтому, если используете Google DNS и 8.8.8.8 как целевой IP для маршрутизации, лучше использовать другой сервер Google DNS, например 8.8.4.4 для DNS.

PPPoE использует 1.1.1.1 и 8.8.8.8 в качестве DNS, а для ADSL мне нужно проверить, потому что сейчас я использую адрес ADSL в качестве DNS.

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

sindy

Guest

21.09.2018 20:55:00

Ты путаешь ситуацию с DHCP и PPPoE. Для DHCP (который используется на WAN2) другого способа, кроме как скрипта, чтобы получить назначенный IP адрес шлюза по умолчанию и установить его в качестве шлюза в отдельных маршрутах к адресам-якорям для мониторинга, нет. Но тебе это, очевидно, не нужно, потому что IP шлюза, предоставляемый DHCP на WAN2, не меняется.

Для PPPoE (используемого на WAN1) есть способ без скрипта, который описал @Sob: ты создаёшь копию профиля /ppp с именем default, называешь её, например, my-pppoe-profile и в этом новом профиле задаёшь remote-address – приватный адрес, который не пересекается с другими частными подсетями в твоей сети, например, 10.22.33.44. В конфигурации /interface pppoe-client указываешь профиль my-pppoe-profile. В отдельных маршрутах к IP-адресам-якорям, используемым для мониторинга доступности PPPoE, в качестве шлюза ставишь 10.22.33.44.

Так параметр remote-address из профиля /ppp my-pppoe-profile перекрывает значение, которое приходит от PPPoE-сервера, и остаётся постоянным, даже если сервер каждый раз присылает разные адреса. Это нормально – маршруты выбираются исходя из наибольшей длины префикса dst-address, то есть максимально точно совпадающего. Если есть хотя бы один маршрут с dst-address=8.8.8.8/32 и он активен, маршруты с более широкими префиксами, например 8.8.8.0/24 или 0.0.0.0/0, не используются для доставки пакетов на 8.8.8.8.

Отсюда два последствия:

1. Не ставь check-gateway=ping для отдельных маршрутов к мониторинговым адресам-якорям, потому что если шлюз станет недоступен, маршрут станет неактивен, и проверка шлюза по ping у маршрутов уровня выше в иерархии начнёт выбирать другой маршрут, нарушая идею использования недоступности адреса-якоря как сигнала о сбое сетевого пути.

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

draid

Guest

22.09.2018 08:09:00

Да, у меня нет проблем с WAN2, так как его шлюз постоянный. Я использую ADSL-модем как шлюз, и он не меняется. Маршрут до WAN2 статический. Единственное, что меняется — это удалённый адрес PPPoE, который я использую как WAN1 (основной канал). Текущая конфигурация такая: WAN1 — оптика → медиаконвертер → Mikrotik на eth1; WAN2 — телефонная линия → ADSL-модем → Mikrotik на eth2. У меня есть полный доступ к ADSL-модему. Единственное, в чём я не уверен — какой DNS он использует, но сейчас на Mikrotik я настроил использование модема как DNS. Поэтому считаю, что единственная проблема — это PPPoE с меняющимся шлюзом. Попробую предложенный способ обхода и напишу, если будет какой-то результат, так как пока всё не до конца понятно. Было бы гораздо проще, если бы можно было использовать интерфейс PPPoE вместо точного шлюза… Мне действительно интересно, как сейчас реализован failover на TP-Link за этими настройками мастера.

sindy

Guest

22.09.2018 10:08:00

PPPoE создаёт интерфейс "точка-точка". Для всех интерфейсов такого типа нет реальной необходимости использовать какой-то адрес удалённого устройства, потому что «удалённый конец туннеля» — это единственный адрес, который вам нужен: всё, что вы отправляете через этот интерфейс, окажется именно на одном удалённом устройстве. Это отличие от интерфейса "точка-многоточка", где помимо имени интерфейса нужен ещё адрес конкретного устройства.

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

Рекурсивный поиск следующего хопа требует IP-адресов шлюзов — с этим приходится смириться. Но поскольку «удалённый» адрес PPP-интерфейса не играет другой роли, кроме как псевдонима имени интерфейса, он имеет смысл только в локальном контексте отправляющего устройства. Поэтому можно назначить PPP-интерфейсу любой «удалённый» адрес, какой угодно. И хотя у /interface pppoe-client нет прямого параметра remote-address, он принимает этот параметр, если он задан через профиль, и использует его, чтобы переопределить значение, предоставленное сервером.

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

Кстати, сам механизм поиска следующего хопа изначально не задумывался для организации резервирования (failover). Что, к слову, означает, что переключение на резервный путь может занять до 10 секунд после разрыва активного WAN-соединения, потому что именно так часто отправляются пинги check-gateway.

draid Guest	#7 0 22.09.2018 17:08:00 Для PPPoE (который используется на вашем WAN1) есть способ без скриптов, который описал @Sob: вы создаёте копию профиля /ppp с именем default, даёте ей название, например, my-pppoe-profile и устанавливаете параметр remote-address в новом профиле на какой-то приватный адрес, который не пересекается с другими приватными подсетями в вашей сети — скажем, 10.22.33.44. В настройках /interface pppoe-client указываете в профиле my-pppoe-profile. А в отдельных маршрутах к IP якорям, которые используются для мониторинга доступности PPPoE, в качестве шлюза ставите 10.22.33.44. Таким образом, параметр remote-address из профиля /ppp my-pppoe-profile перекрывает адрес, который приходит от PPPoE-сервера, и остаётся стабильным, хоть сервер и присылает новый адрес каждый раз. Я попробовал так сделать, но, к сожалению, при попытке подключения пишет, что соединение прервано, и не удаётся подключиться при использовании случайного remote-address.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры