Святой Грааль для Failover 2 WANs без написания скриптов.

Привет, заработает ли это на роутере с RouterOS 6.42.x? Кстати, возможно ли добавить дополнительную метку маршрутизации с помощью PCC для управления балансировкой между провайдерами? Например, ISP1 — 2/3 от общей скорости, ISP2 — 1/3 от общей скорости, а ISP3 — только для резервного копирования.

Привет, у меня проблемы с этой конфигурацией: https://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting. Мой WAN с фиксированным IP работает, но с PPPoE он остается неизменным. Прилагаю захват. Версия 6.44.1. Спасибо.

Испанский: Hola, yo estoy teniendo problemas con esta configuración: https://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting Mi WAN con ip fija funciona pero con pppoe se queda inalcancable. adjunto captura Versión 6.44.1 Gracias

Спасибо, кажется, работает как надо.

Чрезмерно сложный механизм переключения на резервный вариант. Простые рекурсивные маршруты (выбери 1 или 2 публичных DNS) так же эффективны, никаких мучений не требуется.

Согласен, и в этом случае можно говорить о переключении (failover), когда две линии WAN используются в равной степени (требуется "изуродование"), или о переключении, где одна линия WAN является основной, а другая — резервной.

Мне совершенно не важно восстанавливать прежнее соединение при переключении на резерв. Это кажется какой-то заоблачной идеей. Старое соединение уже умерло, пропало, я ожидаю, что придется перезапустить всю свою работу. Идея переключения на резерв — это минимальное нарушение работы и чтобы мне, как админу, не приходилось вмешиваться. У нас разные ожидания.

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

Во-вторых, по поводу вашей проблемы с VPN — это пример нишевого случая. В корпоративных и средах сетевых провайдеров протоколы динамической маршрутизации (и коммутации) тихо выполняют свою работу так, как они были разработаны. В домашней сети есть проблема с NAT, которую нельзя легко преодолеть. Для "нормальных" протоколов, включая большинство VPN, нет способа изменить адрес одного из конечных точек сессии безболезненно — вам нужно завершить существующую сессию и установить новую, поскольку сессии такого рода идентифицируются только двумя парами адресов:портов, так что если смена канала связи на стороне клиента включает в себя изменение IP-адреса с точки зрения сервера, то сервер не может идентифицировать, что пакеты, поступающие с нового адреса, на самом деле принадлежат существующей сессии и предпринять соответствующие меры.

Специфично для VPN этот сценарий в настоящее время рассматривается только расширением IPsec IKEv2 под названием MOBIKE, где сервер может беспрепятственно адаптироваться к изменению IP-адреса клиента, поскольку собственные идентификаторы сессии VPN могут использоваться для идентификации входящего трафика, поскольку эти идентификаторы не зависят от IP-адреса и порта. Итак, как только Mikrotik начнет поддерживать MOBIKE, подход к избыточности канала связи может измениться таким образом, что каждое переключение не будет вызывать сбой и повторное установление текущей IPsec-сессии.

Однако для других типов VPN (и других типов сессий) всегда существует необходимость приоритизации между минимизацией количества сбоев и ограничениями учета данных/скорости резервной линии, и у каждого пользователя свои индивидуальные условия и предпочтения, приводящие к различным стратегиям отката.

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

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

Поэтому мое личное предпочтение заключается в том, чтобы группа документации Mikrotik сосредоточилась на качестве документации в ее существующей структуре, а не на описаниях сценариев, используемых тремя людьми в мире.