Dual Wan и особенности реализации NetWatch в MikroTik

    «Если в простой конфигурации микротик не работает, значит вы не умеете его готовить… или явно что-то упустили.»

    image

    Как работают вместе failover и netwatch. Взгляд изнутри.

    Почти каждой более-менее подросшей компании начинает хотеться качества коммуникаций. Среди прочего, заказчику часто хочется отказоустойчивый «Dual WAN» и VoIP телефонию. Тоже отказоустойчивую, разумеется. Руководств и статей по каждой теме в отдельности написано много, но внезапно оказалось, что совместить первое и второе получается не у всех.

    На Хабре уже есть статья «Mikrotik. Failover. Load Balancing» от vdemchuk. Как оказалось, она послужила для многих источником копипасты кода в маршрутизаторы.

    Хорошее, рабочее решение, но SIP-клиенты из LAN, подключающиеся к внешней IP-АТС посредством NAT, при переключении теряли связь. Проблема известная. Связана она с работой Connection tracker, который запоминает имеющиеся соединения вовне, и сохраняет их состояние независимо от других условий.

    Понять почему так происходит можно посмотрев на диаграмму packet flow:

    Packet Flow v6 part

    Для транзитного трафика процедура обработки connection tracker выполняется всего в одной цепочке — prerouting, (т.е. до роутинга), до выбора маршрута и исходящего интерфейса. На этой стадии еще неизвестно, через какой интерфейс пакет пойдет в Интернет, и отследить src-ip при нескольких Wan-интерфейсах невозможно. Механизм фиксирует установленные соединения уже пост-фактум. Фиксирует и запоминает на время пока через соединение идут пакеты или пока не истечет заданный таймаут.



    Описанное поведение характерно не только для маршрутизаторов MikroTik, но и для большинства Linux-based систем выполняющих NAT.



    В результате, при обрыве связи через WAN1, поток данных послушно направляется через WAN2, только SOURCE IP прошедших через NAT пакетов остается неизменный — от интерфейса WAN1, т.к. в connection tracker уже есть соответствующая запись. Естественно, ответы на такие пакеты идут на интерфейс WAN1 уже потерявший связь с внешним миром. В итоге, связь как будто есть, но на самом деле её нет. При этом все новые соединения устанавливаются корректно.

    Hint: увидеть с каких и на какие адреса делается NAT можно в колонках «Reply Src. Address» и «Reply Dst. Address». Отображение этих колонок включается в таблице «connections» с помощью правой кнопки мыши.

    image

    На первый взгляд выход выглядит довольно простым — при переключении сбросить ранее установленные SIP-соединения, чтобы они установились заново, уже с новым SRC-IP. Благо простой скрипт по просторам интернета бродит.

    Cкрипт
    :foreach i in=[/ip firewall connection find dst-address~":5060"] do={ /ip firewall connection remove $i }


    Три шага к фейлу


    Шаг первый. Копипастеры добросовестно переносят конфиг для Failover recursive routing:

    Настройка роутинг из статьи «Mikrotik. Failover. Load Balancing»
    # Настроим сети провайдеров:
    /ip address add address=10.100.1.1/24 interface=ISP1
    /ip address add address=10.200.1.1/24 interface=ISP2
    # Настроим локальный интерфейс
    /ip address add address=10.1.1.1/24 interface=LAN
    # скроем за NAT все что выходит из локальной сети
    /ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
    ###Обеспечение failover c более глубоким анализом канала###
    #с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
    /ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
    /ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
    # укажем 2 default gateway через узлы путь к которым указан рекурсивно
    /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
    /ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping

    Шаг второй. Отследить событие переключения. Чем? "/tool netwatch", естественно! Попытка отследить падение шлюза WAN1 обычно выглядит так:

    Netwatch config
    /tool netwatch
    add comment=«Check Main Link via 8.8.8.8» host=8.8.8.8 timeout=500ms /
    down-script=":log warning («WAN1 DOWN»)
    :foreach i in=[/ip firewall connection find dst-address~":5060"] do={
    :log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
    /ip firewall connection remove $i}"
    up-script=":log warning («WAN1 UP»)
    :foreach i in=[/ip firewall connection find dst-address~":5060"] do={
    :log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
    /ip firewall connection remove $i}"

    Шаг третий. Проверка.

    Админ гасит первый аплинк WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!
    Админ включает обратно WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!

    Fail


    В реальной обстановке такой конфиг работать отказывается. Неоднократное повторение шага №3 приводит админа в состояние озлобления и мы слышим «Не работает ваш микротик!».
    image

    Разбор полётов


    Всё дело в непонимании того, как происходит работа утилиты Netwatch. Применительно в отношении именно рекурсивного роутинга, утилита просто пингует заданный хост согласно основной таблице маршрутизации, используя активные маршруты.

    Проведем эксперимент. Отключим основной канал WAN1 и посмотрим и интерфейс /tool netwatch. Мы увидим, что хост 8.8.8.8 по-прежнему имеет состояние UP.

    Для сравнения опция check-gateway=ping, работает для каждого маршрута в отдельности в т.ч. рекурсивно, и делает сам маршрут активным либо НЕактивным.

    Netwatch использует уже активные на данный момент маршруты. Когда что-либо происходит на линке до шлюза провайдера ISP1 (WAN1), маршрут до 8.8.8.8 через WAN1 становится неактивным, и netwatch игнорирует его, отправляя пакеты в новый default route. Failover играет злую шутку, и netwatch считает, что всё в порядке.

    Второй вариант поведения netwatch, это двойное срабатывание. Механизм его таков: если пинги от netwatch попадут в таймаут check-gateway, то на один цикл проверки хост будет признан DOWN. Сработает скрипт переключения канала. SIP-соединения корректно перейдут на новый линк. Работает? Не совсем.

    Скоро таблица маршрутизации перестроится, хост 8.8.8.8 получит статус UP, вновь сработает скрипт сброса SIP-соединений. Соединения второй раз переустановятся через WAN2.

    В результате, при возвращении в строй ISP1 и переходе рабочего трафика на WAN1, SIP-соединения так и останутся висеть через ISP2 (WAN2). Чревато это тем, что при проблемах у на запасном канале система этого не заметит и телефонной связи не станет.

    image

    Решение


    Для того, чтобы трафик на используемый для мониторинга хост 8.8.8.8 не заворачивался на ISP2, нам нужно иметь запасной маршрут до 8.8.8.8. На случай падения ISP1, создаем резервный маршрут с большим значением distance, например distance=10 и type=blackhole. Он и станет активным при пропадании линка до WAN1 Gateway:

    /ip route add distance=10 dst-address=8.8.8.8 type=blackhole

    В итоге имеем дополнение конфига всего лишь одной строкой:

    Исправленный роутинг
    # Настроим сети провайдеров:
    /ip address add address=10.100.1.1/24 interface=ISP1
    /ip address add address=10.200.1.1/24 interface=ISP2
    # Настроим локальный интерфейс
    /ip address add address=10.1.1.1/24 interface=LAN
    # скроем за NAT все что выходит из локальной сети
    /ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
    ###Обеспечение failover c более глубоким анализом канала###
    #с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
    /ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
    /ip route add distance=10 dst-address=8.8.8.8 type=blackhole
    /ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
    # укажем 2 default gateway через узлы путь к которым указан рекурсивно
    /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
    /ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping

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

    Надеюсь, статья поможет вам избежать подобных ошибок. Выбирайте свежие мануалы. Будьте в курсе, и всё у вас «взлетит».

    image
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 25

      0
      А ещё можно как у меня сделать — https://m.habrahabr.ru/post/271747/
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          и пинговал эти шлюзы.

          Шлюз пинговать все-таки не надежно, шлюз то может отвечать, а вот дальше маршрут сломается
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Таки пинговать Google Public DNS, как это предлагается по дефолту в OpenWRT(по крайней мере в той ревизии, что я собирал для своей домашней железки) и по условию недоступности переключать канал.
              0
              Проблема у провайдера может быть не только на последней миле.
                0
                У дефолтных маршрутов как раз указана опция check-gateway.
                /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping

                Это помогает активировать/деактивировать сам маршрут.
                Netwatch этого не понимает. Он пользутестя результатом — перестроенным на запасной маршрутом.
                Насколько знаю, в feature request к MikroTik'у давно висит запрос явно указывать интерфейс, с которого будет пинговать NetWattch. Вот, только когда они это реализуют — неизвестно.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    «Подкрашивание» пакетов фаерволом, во-первых кушает ресурсы и может требовать отдельной таблицы роутинга. Во-вторых это еще одна область настройки, что в случае смены правил может привести к неочевидным сбоям, а так всё в одном разделе "/ip route" настроено и никуда более лазать не нужно. В третьих, модификация от базовой, описанной в статье минимальна — +1 строка конфига (1 доп.маршрут).
                    • НЛО прилетело и опубликовало эту надпись здесь
                +1
                А можно еще пинговать через определенный интерфейс, т.е. я такое реализовывал через крон, раз в 5 сек запускал скрипт.
                  0
                  Можно. К сожалению, далеко не все владеют навыком написания скриптов к микротику. Постоянно встречаю деятелей, которым настройка оборудования сложнее домашнего TP-Linka создает проблемы. От микротика эти люди вообще впадают в шок или истерику. Куда уж им в скрипте результаты анализировать и обрабатывать.
                    0
                    Ну если человек взял мтик, значит он о нем наслышан. И по крайней мере сможет написать скрипт.
                    PS: Язык то легкий.
                      0
                      Ха. У нас в операторах связи такие «спецы» работают, что аж страшно за отрасль реально.
                      Чел на НАГе с 13(!) летним стажем со статусом «VIP» морозит:
                      несмешной текст вообще
                      В копилку сисадмина. Мокротик настроить нормально можно только после 5 сбросов в заводские настройки. Инет в настройке мокротика не помогает даже в типовых случаях, ибо из пяти инструкций — ни одна на другую не похожа. Если вы сумели настроить мокротик с 4-го раза — вы клон Сааба, а если с первого, то вы прадедушка Сааба :)

                      Просто на неделе притащили микротик для настройки в типовом режиме бытового роутера. Я сразу послал клиента в пешее эротическое, а техдир — закусился. Гимнастика его мозга продолжалась 3 дня, из них — два выходных дома :) Но он — победил адское поделие :)

                      Пруф на текст
                        0
                        Ну, у каждого своя узкая специализация =) но да, мтик весьма и весьма легок в настройке
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Увы, в отличие от Вас, есть граждане которые считают, что «вот сиско надо изучать, а всё остальное я и сам знаю». Потом напоровшись на грабли собственного незнания граждане кричат, что «микротик не работает, надо было брать сиско».
                            Касательно QuickSet — он предназначен исключительно для стартового, базового конфигурирования. Если в микротике уже прописана какая-то работающая сложная конфигурация, QuickSet для дополнения параметров использовать нельзя, т.к. он может тупо накатить свои параметры без учета уже имеющихся.
                            • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    А откуда вообще нужно брать информацию по настройке микротика? В русских интернетах информации мало, и «из пяти инструкций — ни одна на другую не похожа». С сетях не спец, но дома стоит микротик.
                    Как я понял в данном варианте конфигурации, если пакеты ISP1 теряет через раз, то канал подключения будет скакать туда-сюда хаотично?
                      +1
                      Оборудование MikroTik базируется на Linux. Если есть понимание того, как реализована работа Ethernet + IP в Linux-Based системах, то ничего особенно сложного в настройке MikroTik нет. Официальная вики достаточно бодро обновляется, там же есть «examples».
                      Также есть community в соцсетях и форумы. На том же forum.nag.ru есть целых два раздела посвященных исключительно mikrotik.

                      Как я понял в данном варианте конфигурации, если пакеты ISP1 теряет через раз, то канал подключения будет скакать туда-сюда хаотично?

                      Не слишком хаотично. Есть чёткий критерий, по которому оценивается доступность канала. Этот критерий используется при «легком конфигурировании одним крыжиком»:
                      If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable.

                      Если хочется оценивать доступность канала по-другому — никто не мешает написать скрипт.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          «Ну нельзя же делать такой простой и наглядный интерфейс к iptables! Его же любой тупица освоит и мы без работы останемся!»
                          То есть да, надо просто представлять себе, как работает линуксовый iptables и стек IP (маршрутизация, NAT и всё такое)

                          Я Вам больше скажу. Шапочно знаком с несколькими админами в небольших предприятиях, которые начинали с роутеров на винде [+керио | +иса] и переходили на линукс через микротик, ибо там логика уже линуксовая, а интерфейс наглядно-виндовый. У тех из них, с кем общался главная претензия оказывалась как раз к линуксовой консоли, за «отсутствие наглядности как в винбоксе». Бывает и такое, да…
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              С asterisk, вроде упростили. Для прохода через nat сделали pjsip. Но я его еще не пробовал применять пока. Небыло необходимости.
                              • НЛО прилетело и опубликовало эту надпись здесь

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое