Home » Mikrotik » Перевод презентации по Mikrotik - My "holy war" against masquerade

Перевод презентации по Mikrotik - My "holy war" against masquerade

Недавно я проходил обучение по MikroTik, на котором узнал про презентацию под названием My "holy war" against masquerade. Я не смог найти точную информацию о том, кто выступал с этой презентацией. Знаю только, что это было на одном из MUM (MikroTik User Meeting) в 2017 году. Информация в этой презентации мне показалась полезной, поэтому я решил ее перевести и прокомментировать.

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Курс стоящий, все подробности читайте по ссылке.

Введение

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

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

В презентации рассмотрены 9 самых популярных ошибок в MikroTik, с которыми обращаются в техническую поддержку. Цель выступления - сократить количество этих обращений. Форма подачи материала - сначала показано неправильное решение, потом объяснение ошибки и правильное решение. Начнем разбирать эти ошибки по порядку.

Большая нагрузка от использования фильтра Layer 7

У меня есть статья про блокировку сайтов микротиком. В ней показана ошибочная настройка, которую как раз разбирает автор презентации.

High layer 7 load

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

Действовать нужно по-другому. Layer 7 protocol задуман как способ поиска определенных шаблонов в подключениях для маркировки трафика на основе этих шаблонов. А дальше уже маркированный трафик обрабатывается фаерволом. Фильтр с Layer 7 protocol не должен проверять абсолютно весь трафик. Он должен брать первые 10 пакетов или 2KB данных подключения и анализировать только их.

Корректное использование Layer 7 protocol показано на следующем примере.

/ip firewall mangle 
add action=mark-connection chain=prerouting protocol=udp dst-port=53 connection-mark=no-mark layer7-protocol=youtube new-connection-mark=youtube_conn passthrough=yes
add action=mark-packet chain=prerouting connectionmark=youtube_conn new-packet-mark=youtube_packet
/ip firewall filter
add action=drop chain=forward packet-mark=youtube_packet
add action=drop chain=input packet-mark=youtube_packet

Очереди работают неправильно

Mikrotik simple queue

При такой настройке очереди будут работать, только когда запущена утилита Torch, или выключен fasttrack. При этом обрабатывается только download трафик. Между локальными сетями так же срабатывает ограничение. Обнаружить ошибку можно по счетчикам в очередях. Они покажут, когда правило работает, а когда нет.

Причина этой ошибки в том, что режим Fasttrack работает для всего трафика, а он работу с очередями не поддерживает. Ускорение обработки трафика в режиме fasttrack как раз и достигается за счет того, что трафик не проходит по всем цепочкам обработки трафика фаерволом и очередями. Так же в правилах очередей не установлен параметр target.

В данном случае правильно simple queue должны быть настроены следующим образом.

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related in-interface=local-one out-interface=local-two
add chain=forward action=fasttrack-connection connection-state=established,related in-interface=local-two out-interface=local-one
add chain=forward action=accept connection state=established,related
/queue simple
add max-limit=10M/10M target=10.0.0.2/32
add max-limit=10M/10M target=10.0.0.3/32
add max-limit=10M/10M target=10.0.0.4/32

Мы включили fasttrack только для трафика между указанными локальными сетями. Остальной трафик идет в обычном режиме. Плюс, корректно настроили очереди, указав target.

Высокая нагрузка CPU на PPPoE server

cpu load on pppoe mikrotik

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

Во время диагностики видно, что процесс routing полностью загружает одно ядро на 100%. На остальных ядрах периодически появляется максимальная нагрузка процессов ppp и networking.

Причина данной ошибки в том, что динамическая маршрутизация OSPF спамит обновлением маршрутов с сеткой /32 от клиентов. При этом, все протоколы динамической маршрутизации в микротиках ограничены одним ядром. То есть параллелить свою работу не умеют. В итоге, при каждом подключении или отключении абонента по pppoe, начинается обновление маршрутов. Когда их много, они загружают полностью ядро процессора и все начинает тормозить.

Если я правильно понял, в данном случае решением будет использовать тип Area для ospf - stub (тупиковая), который можно указать в настройках. Предлагается такое решение (умничать не буду, почти ничего не понял :)

/routing ospf area
add area-id=0.0.0.1 authentication=none name=pppoe1 type=stub
/routing ospf network
add area=pppoe1 network=10.0.0.0/20
/routing ospf area range
add advertise=yes area=pppoe1 range=10.0.0.0/20
/routing ospf interface
add interface=all passive=yes

High CPU load on PPPoE server

Высокая нагрузка CPU на pppoe сервере в микротике

Еще одна проблема с похожими симптомами. Есть PPPoE сервер и куча клиентов. Все это в какой-то момент начинает тормозить. Максимальную нагрузку дает процесс firewall. Для клиентов используется NAT с правилом Masquerade.

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

В данном случае правильно будет использовать srcnat.

/ip firewall nat
add action=src-nat chain=srcnat outinterface=<Public> to-addresses=<Public_IP>

Как я понял из описания проблемы и варианта решения, нужно всегда использовать srcnat, когда у вас постоянный ip адрес. Masquerade только для не постоянного ip адреса.

Локальный ip адрес виден в публичной сети

Локальный ip адрес виден в публичной сети

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

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

Причина ошибки в том, что при переключении каналов все соединения сбрасываются. После этого сброшенные подключения приходят на firewall с состоянием new и отправляются во вне по другому маршруту. Когда основной линк поднимается и восстанавливается исходный маршрут, все установленные соединения по альтернативному маршруту уходят во вне мимо NAT, без преобразования серых адресов.

Решение проблемы простое - использовать srcnat, вместо masquerade, как это было показано в предыдущих примерах. Так же добавить в firewall правила на drop пакетов в состоянии invalid. Обычно это и так делается. На внешних интерфейсах настроить drop пакетов с состоянием new идущих не из цепочки dstnat. Это в целом я тоже чаще всего делаю.

Drop connection-state=invalid packets
Drop connection-state=new connection-natstate=!dstnat packets from public interface

Так же в презентации предлагается сделать маршрут заглушку blackhole для каждого routing-mark. Я не понял, что это такое.

VRRP и проблемы маршрутизации

VRRP и проблемы маршрутизации

Симптомы ошибки следующие. Маршрутизация работает неправильно. Fastpath/fasttrack тоже не работает. Сетевые процессы создают высокую нагрузку на процессор.

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

/ip address add address=192.168.1.1/24 interface=ether1
/interface vrrp add interface=ether1 vrid=49 priority=254
/ip address add address=192.168.1.254/32 interface=vrrp1

DNS Cache

Неправильная настройка dns в mikrotik

Симптомом проблемы с dns cache будет высокая нагрузка на CPU роутера и большой трафик на внешнем интерфейсе. Заметить проблему можно будет через torch или profile.

Проблема давно известная. Я сам с ней сталкивался, когда забывал фаерволом закрыть доступ к dns микротика из интернета. Существует известный тип атаки DNS Amplification. Подробнее о нем можно почитать в интернете. Суть в том, что на dns сервер поступает запрос с поддельным адресом отправителя. В качестве ответа dns отправляет большой объем данных на поддельный ip адрес. Таким образом на этот адрес устраивается ddos атака.

Защита тут простая - необходимо запретить с помощью firewall запросы к dns из интернета.

/ip firewall filter
add action=reject chain=input dst-port=53 protocol=udp reject-with=icmp-port-unreachable
add action=reject chain=input dst-port=53 protocol=tcp reject-with=icmp-port-unreachable

IPSec туннель не работает

ipsec не работает

Суть проблемы в том, что не удается создать туннель, потому что пакеты ipsec дропаются. Причина тут в том, что правила NAT подменяют src-address в шифрованных пакетах. В итоге измененный адрес источника не принимается на второй стороне.

Решить эту проблему можно с помощью raw table. Смысл этой таблицы в том, что с ее помощью можно обходить механизм трекинга соединений (connection tracker), пропуская напрямую или дропая пакеты. Это в целом снижает нагрузку на CPU, если у вас сильно нагруженная железка.

В данном случае нужно добавить действие notrack для ipsec пакетов, для того, чтобы:

  • не было дефрагментации пакетов
  • они шли мимо NAT
  • они шли мимо правил fasttrack, маркировки пакетов, и т.д.

Реализация следующая.

/ip firewall raw
add action=notrack chain=prerouting srcaddress=10.1.101.0/24 dst-address=10.1.202.0/24
add action=notrack chain=prerouting srcaddress=10.1.202.0/24 dst-address=10.1.101.0/24

Шифрованный Bridge для двух локальных сетей через интернет

eoip туннель не работает

Проблема данной схемы в том, что все тормозит и работает нестабильно. Как я понял, используется EoIP поверх l2tp для того, чтобы построить единое адресное пространство для двух удаленных сетей. Причина тормозов в огромных накладных расходах двух туннелей, сильной фрагментации пакетов.

Решением в данном случае будет просто не использовать такую схему построения vpn в Mikrotik. Достаточно использовать шифрованный EoIP туннель.

Правильная настройка eoip tunnel

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте . Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:
  • Знания, ориентированные на практику;
  • Реальные ситуации и задачи;
  • Лучшее из международных программ.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

27 комментариев

  1. Привет!
    Пытаюсь соединить по EoIP 2 микротика, вроде линк есть, трафик идет, маки видит с обоих сторон, даже dhcp получает с удаленного роутера, а вот пинги и просто открыть ПК ну никак, уже 2 дня перечитываю кучу сайтов, везде одно и тоже пишут, что не дает результата.

  2. "Ошибка возникает, когда у вас используется несколько каналов в интернет и автоматическое переключение между ними на основе смены дефолтного маршрута. Ip адреса постоянные, но при этом используется Masquerade."

    Не совсем понял, если у меня 2 WAN в автоматическом резервировании и я не хочу постоянно менять ручками to-addresses= при падении одного из них, как тогда отказаться от masquerade? Скрипты костылить?

    • Тогда не надо отказываться от masquerade. Он как раз для вашего случая.

    • Можно использовать для каждого канала свою таблицу маршрутов и использовать правило по типу этого
      chain=srcnat action=src-nat to-addresses=ip_on_wan_iface routing-mark=Next-Hop/wan_gw_ip src-address-list=via/wan_ip log=no log-prefix=""
      Правда при условии, что ip у вас статические.

  3. Я вот проблему одну побороть не могу, это роутинг. ICPM пакеты хотя быстро, но при подключении по ssh идет задержка примерно 5 секунд. пробовал фиксить через UseDNS=no в sshd не помогло :(

  4. Дмитрий

    Спасибо за инфу, тоже не знал про маскарад, возьму на вооружение статью )

  5. DNS Cache
    Пояснишь, как тогда будут работать клиенты внутри сети?

    • Так без проблем. Блокируются именно входящие обращения к dns серверу микротика со стороны интернета. Для локальных пользователей доступ должен быть открыт.

      • Нет, эти строчки блокируют любые входящие
        /ip firewall filter
        add action=reject chain=input dst-port=53 protocol=udp reject-with=icmp-port-unreachable
        add action=reject chain=input dst-port=53 protocol=tcp reject-with=icmp-port-unreachable

        И чем не устраивает дефолтный дроп всех внешних подключений?
        add action=drop chain=forward comment=\
        "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
        connection-state=new in-interface-list=WAN

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

          • И тем не менее, блокировать 53й, предварительно разрешая его же из локалки - не правильно.

            • Даже скорее не красиво)

            • Можете написать это автору презентации - Janis Megis из Mikrotik.

            • Почему же не правильно? В целом DNS блокируется, а разрешающее правило уточняющее для кого DNS блокироваться не должен! Пакеты летят сверху вниз по правилам и на разрешающем правиле отрабатывают и дальше уже не идут, а те пакеты которым не разрешено летят дальше и блокируются! Нормальный принцип работы фаервола!

        • Александр

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

  6. Дмитрий

    IoIP конечно хорошо, но он требует public IP c обоих сторон...а "костыли" в виде EoIP через L2TP как раз вынужденная мера когда publik IP только с одно стороны.

    • А зачем вообще делать EoIP? Только для того, чтобы засунуть подсети в один широковещательный домен? По идее, l2tp + ipsec закрывает большинство потребностей в объединении сетей через интернет.

      • Аноним

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

      • Ну я бы тут поспорил! Долбанное виндовое сетевое окружение в локальной сети не хотело работать, то есть компы обеих подсетей друг друга не видели при любых раскладах и только при EoIP все корректно заработало.
        Между прочим из практики пример.

        • А с чем тут спорить? Для того, чтобы сетевое окружение нормально работало а разных подсетях, необходимо настраивать wins сервер. Протокол NetBIOS, который использует винда для работы сетевого окружения, работает только в одном широковещательном домене. Настроив EoIP, вы просто гоняете по туннелю весь широковещательный трафик. В небольших сетках это может нормально работать. Но в целом, такой режим работы явно не оптимальный. Гонять широковещательный трафик по vpn плохая идея, если можно обойтись без этого.

          А зачем виндовое сетевое окружение вообще нужно? Можно через dns записи все настроить и работать будет стабильнее.

      • Согласен! Но связка l2tp + ipsec сильно грузит сами микроты и канал за счет шифрования, так что на слабом канале и с относительно слабой железкой это не вариант!

  7. По IPsec есть крутая статья где все выше сказанное сказано https://wiki.mikrotik.com/wiki/Manual:IP/IPsec 99,9% - процентов ошибок решает.
    Вообще в Mikrotik очень сильно любят менять логику IPsec. Но принцип везде один за пару минут можно понять где что изменилось.

  8. Спасибо!

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.