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

 

 

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

 

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

 

 

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

 

 

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

 

 

При такой настройке очереди будут работать, только когда запущена утилита 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.

 

 

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

 

 

Проблема данной конфигурации в том, что возникает огромная нагрузка на 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

 

 

4, High CPU load on PPPoE server

 

 

Еще одна проблема с похожими симптомами. Есть 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 адреса.

 

5. Локальный 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

 

 

6. 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

 

 

7. DNS Cache

 

 

Симптомом проблемы с 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

 

 

8. 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

 

 

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

 

 

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

 

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