Mikrotik firewall mangle что это

Обновлено: 25.01.2025

На одном пакете/соединении может быть только одна метка

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

Если вы хотите углубить свои знания по работе с роутерами MikroTik, то наша команда рекомендует пройти курсы которые сделаны на основе MikroTik Certified Network Associate и расширены автором на основе опыта . Подробно читайте ниже.

В сегодняшнем примере мы будем настраивать Dual WAN. Предполагается что у вас есть 2 провайдера, основной и резервный, с помощью Mangle мы сделаем правильную маркировку и выпустим клиентов через основного провайдера. Так же прикрутим скрипт, который будет проверять доступность выхода в интернет через обоих провайдеров, и в случае недоступности через основной, переключать на резервный канал.

Схема сети

Предположим, что у нас имеется:
Широковещательная плоская 192.168.1.0/24;
Два белых статических IP адреса;
Один роутер;
Два свича;
RouterOS 6.48.1.

Настройка правил NAT

Для того чтобы наши внутренние клиент выходили в интернет, нам нужно 2 правила NAT. Один под основного провайдера, другой для резервного.

Маркировка трафика

Следующая задача, промаркировать трафик для каждого провайдера, на вход и на выход. Открываем на микротике IP – Firewall – Mangle, создаём новое правило. Интересует цепочка Prerouting, входящий интерфейс первого оператора. Маркируем соединение и задаём понятное имя марки. Для оптимизации нагрузки можно выбрать только новые соединения.

Следующим правилом создаём маркировку роутинга для нашей ранее созданной метки соединения.

Теперь займемся output. На основе коннекшен марки создаём правило роутинга.

Последним правилом маркировки для ISP1 будет цепочка output.

Для первого оператора метки заданы. По аналогии создаём и для второго, только придумываем другие имена меткам и в последнем правиле указываем соответствующий адрес.

Задаём соответствующий входящий интерфейс.

Создаём маркировку роутинга на основе connection mark.

И 2 правила на output.

В итоге вся маркировка трафика у нас будет выглядеть таким образов.

Настройка Routing Rules

Следующий этап, это настройка правил и таблиц маршрутизации. Следует разнести трафик по соответствующим провайдерам. Создаём Rule с src address первого оператора, впишем вручную новую table.

По аналогии и для второго провайдера.

Порядок имеет значение. Необходимо указать все наши локальные сети, трафик к ним будет идти через табличку main.

А теперь все наши mark routing выпустим через соответствующие таблички.

Создание таблиц маршрутизации

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

У второго метрика 20.

Открываем table-ISP1 и создаём default route с любой метрикой через шлюз провайдера.

Аналогично и для table-ISP2. Не перепутайте шлюзы.

Чуть не забыл, обязательно дадим комментарии записям в main. Общий вид Route List следующий.

Настройка переключения интернет-каналов

Есть несколько способов отслеживания состояния. Один из них — это проверка провайдерского шлюза arp или ping запросами в самой настройке маршрута. Но он не эффективен, т.к. gateway может быть и доступен, а доступ в инет за ним нет. Как один из вариантов, проверять доступность на основе пинг запросов каких-либо крупных сервисов, которые доступны круглосуточно. Встроенных средств у Mikrotik нет, и по этой причине будем использовать простенький скрипт ниже.

:global MainIf ether1 – основной интерфейс;
:global RsrvIf ether2 – резервный интерфейс;
:local PingTargets – таргеты, которые будите мониторить;
:local MainGWDistance – переменная метрики для ISP1;
:local RsrvGWDistance – переменная метрики для ISP2;
Комментарий маршрут.

Добавляем данный скрипт в хранилище, даем имя check-internet.

Тестируем работу через консоль.

Как мы видим все отлично.

Добавляем задание в планировщик. Обязательно указываем интервал. В данном случае раз в 15 сек. Это самый минимальный рекомендуемый интервал, ниже ставить не советую.

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

Проверка работоспособности

Итак, мы все настроили и ждём чуда. Т.к. запросы у нас ICMP, для ускорения результата, на вышестоящем оборудовании включу блокировку данного трафика.

Если отключу блокировку, то все встаёт на свои места.

89 вопросов по настройке MikroTik

Вы хорошо разбираетесь в Микротиках? Или впервые недавно столкнулись с этим оборудованием и не знаете, с какой стороны к нему подступиться? В обоих случаях вы найдёте для себя полезную информацию в курсе «Настройка оборудования MikroTik». 162 видеоурока, большая лабораторная работа и 89 вопросов, на каждый из которых вы будете знать ответ. Подробности и доступ к началу курса бесплатно тут.

Mangle - это своего рода «маркер», который помечает пакеты для дальнейшей обработки специальными метками. Многие другие средства в RouterOS используют эти метки, например деревья очередей, NAT, маршрутизация. Они идентифицируют пакет по его метке и обрабатывают его соответствующим образом. Метки есть только внутри маршрутизатора, они не передаются по сети.

Кроме того, функция mangle используется для изменения некоторых полей в заголовке IP, таких как поля TOS (DSCP) и TTL.

Свойства

action

по умолчанию: accept)

address-list

( строка ; По умолчанию:)

address-list-timeout

Значение non-dynamic ( 00:00:00) оставит адрес в списке адресов до перезагрузки
Значение none-static навсегда оставит адрес в списке адресов навсегда и будет включено в экспорт при резервном копировании конфигурации.

( имя ; По умолчанию:)

( строка ; По умолчанию:)

connection-bytes

( целое-целое ; по умолчанию:)

connection-limit

( целое число, сетевая маска ;

connection-mark

( без метки | строка ;

connection-nat-state

connection-rate

( целое число 0..4294967295 ;

connection-state

estabilished - пакет, принадлежащий существующему соединению
invalid - пакет, состояние которого не определено при отслеживании соединения (обычно - отдельные неупорядоченные пакеты, пакеты с неправильной последовательностью / номером подтверждения или в случае чрезмерного использования ресурсов на маршрутизаторе), по этой причине недопустимый пакет не будет участвовать в NAT (как это делают только пакеты connection-state = new) и по-прежнему будет содержать исходный IP-адрес источника при маршрутизации. Мы настоятельно рекомендуем отбросить все пакеты connection-state = invalid в цепях пересылки и ввода брандмауэра.
new - пакет начал новое соединение или иным образом связан с соединением, которое не видел пакетов в обоих направлениях
related - пакет, который относится к существующему соединению, но не является его частью, например, ошибки ICMP или пакет, который начинает соединение для передачи данных FTP
untracked - пакет, который был настроен на обход отслеживания соединений в таблицах RAW межсетевого экрана.

connection-type

pptp | quake3 | sip |

tftp ; по умолчанию :)

content

( целое число: 0..63 ;

dst-address-list

( имя ; По умолчанию:)

dst-address-type

unicast - IP-адрес, используемый для передачи точка-точка
local - если одному из интерфейсов роутера назначен dst-адрес
broadcast - пакет отправляется на все устройства в подсети
multicast - пакет пересылается определенной группе устройств

dst-limit

count - максимальная средняя скорость пакетов, измеренная в пакетах за timeинтервал
time - указывает временной интервал, в котором измеряется скорость передачи пакетов (необязательно)
burst - количество пакетов, которые не учитываются по скорости передачи пакетов
mode - классификатор ограничения скорости пакетов
expire - указывает интервал, по истечении которого записанный IP-адрес / порт будет удален (необязательно)

dst-port

( целое [-integer]: 0..65535 ;

( да | нет ; по умолчанию:)

icmp-options

in-bridge-port

( имя ; По умолчанию:)

in-interface

( имя ; По умолчанию:)

ingress-priority

(входящий приоритет)

( целое число: 0..63 ;

ipsec-policy

( in | out, ipsec | none;

in - действует в цепочках PREROUTING, INPUT и FORWARD
out - действует в цепочках POSTROUTING, OUTPUT и FORWARD

ipsec - соответствует, если пакет подлежит обработке IpSec;
none - соответствует пакету, который не подлежит обработке IpSec (например, транспортный пакет IpSec).

Например, если маршрутизатор получает пакет Gre, инкапсулированный в Ipsec, то правило ipsec-policy=in,ipsecбудет соответствовать пакету Gre, но правило ipsec-policy=in,noneбудет соответствовать пакету ESP.

Файрвол, как и многое другое в RouterOS, пришел из Linux и представляет собой доработанный iptables. Поэтому многие мануалы по настройке iptables легко можно сконвертировать в формат RouterOS. Файрвол состоит из следующих таблиц:

Filter — занимается фильтрацией трафика — определяет, пропустить пакет в сеть или отбросить его. Мы будем рассматривать работу только этой таблицы;
NAT — Network Address Translation. Изменяет проходящие пакеты. Поменять адрес источника или порт назначения — дело именно этой таблицы. В основном она используется для обеспечения доступа в интернет из локалки и обратно. Иногда без NAT невозможно работать в плохо спроектированных сетях, а еще его, бывает, используют в качестве «костыля»;
Mangle — классифицирует и маркирует трафик и может менять некоторые поля в заголовке (TTL, ToS, DF). Применяется для построения сложных путей трафика (например, когда подключено два провайдера или нужны разные пути трафика для RDP и VoIP);
Raw — обрабатывает пакеты до их попадания в Connection Tracking. Пригодится для защиты от DoS или при работе с большими объемами трафика.

Таблицы состоят из цепочек. Цепочки в разных таблицах могут отличаться. Чуть позже станет ясно почему. В нашей таблице Filter три цепочки:

input — трафик к самому роутеру. Обязательное условие попадания в input — адресом назначения пакета должен быть один из адресов роутера, широковещательный адрес сети или широковещательный адрес работающей на роутере службы. Сюда попадает WinBox, SSH, WebFig, ping, VPN и другой трафик, предназначенный роутеру. Полный список можешь посмотреть в вики. В этой цепочке мы должны защищать сам роутер;
output — трафик от роутера. Ответы на прилетевшее в input или новые пакеты от роутера (пинг, VPN, SSH-сессия с самого роутера). Эта цепочка редко используется, так как часто роутер считается доверенным звеном и пакеты, генерируемые им, по умолчанию легитимны. Но, как показывает история взломов, контроль исходящего трафика может выявить заражение на начальных этапах;
forward — трафик, проходящий через роутер (когда пакет прилетел в один интерфейс и вылетел с другого или того же самого). Трафик из локалки в интернет, из интернета в локалку, из одного VLAN локалки в другой;
user chains — пользовательские цепочки. Админ может создавать цепочки правил по своему усмотрению. Это бывает полезно для декомпозиции больших конфигураций. К примеру, можно весь трафик на порты 80 и 443 завернуть в отдельную цепочку WEB и в ней уже делать десятки правил для фильтрации — это визуально упростит настройку, хотя качественно на прохождение трафика не повлияет.

Два важных момента, о которых нужно помнить.

Момент первый. У трафика в forward всегда есть входящий и исходящий интерфейсы — трафик влетел в input, обработался процессом маршрутизации и должен вылететь в output. У входного трафика не может быть исходящего интерфейса — он обработается внутри роутера и никуда дальше не полетит. Также у выходного трафика не может быть входящего интерфейса — этот трафик генерируется самим роутером (это либо новый трафик, либо созданный роутером ответ на трафик, пришедший в input).

Момент второй. У трафика не существует «внешнего» или «внутреннего» интерфейсов. Роутеру плевать, что ты считаешь внешним, — для него есть интерфейс, в который трафик вошел, и интерфейс, с которого трафик уйдет.

Правила образуют цепочки. У каждого правила может быть только одна цепочка. По умолчанию политика у всех цепочек — все разрешено. Правила срабатывают в таблицах в зависимости от их порядка: сначала пакет обработается первым правилом, затем вторым и так далее. Хорошим тоном считается упорядочивать правила внутри таблиц по цепочкам: сначала — пачка правил input, затем — forward, в конце — output.

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

table_chain_rule

Connection Tracking

Еще одна важная вещь для понимания работы файрвола — механизм определения состояния соединений — Connection Tracking (или просто ConnTrack). У RouterOS есть специальная таблица, в которой хранятся данные о состоянии соединений. Благодаря ей работает NAT и многие другие части файрвола.

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

Для ConnTrack существуют четыре состояния пакетов:

new — новый пакет, не принадлежащий ни одному из известных потоков. Это может быть первый пакет для коннекта к серверу RDP, или первый пакет в потоке WinBox, или запрос к DNS. Система запоминает Source IP, Source Port, Destination IP, Destination Port и некоторые другие параметры и записывает эти данные в таблицу. Следующий пакет с такими же данными будет относиться к записанному потоку;
established — пакет, принадлежащий существующему потоку. То есть пакет, у которого Source IP, Source Port, Destination IP, Destination Port подходят под одну из записей таблицы ConnTrack (или обратный пакет);
related — пакет, порожденный другим потоком. Некоторые протоколы, такие как FTP, SIP, PPTP, используют для работы несколько потоков. Например, управляющие команды FTP ходят по порту TCP 21, но данные передаются с порта TCP 20. При попытке получения или отправки данных на FTP в потоке на порт 21 сервер сообщает: «А сейчас я открою 20-й порт, и ты забирай данные с него», после этого клиент посылает пакет на 20-й порт сервера. Этот пакет будет считаться related, так как он порожден потоком 21-го порта;
invalid — все, что не относится к перечисленным выше состояниям. Пример: сессия корректно закрылась, но из-за ошибок маршрутизации часть пакетов из середины сессии улетела другим путем. Когда они пришли, их сессия уже закрыта и роутер о них ничего не знает. Они не new и не относятся к существующим соединениям, поэтому считаем их invalid.

Состояние потока не связано с флагами TCP: SYN, ACK, FIN. Для UDP и других stateless-протоколов в таблице ConnTrack тоже содержатся все возможные состояния.

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

Нажав кнопку Tracking, можно отключить механизм ConnTrack или подкрутить таймеры. В большинстве случаев тебе не понадобится заходить в эти настройки, но знать о них нужно. Режима ConnTrack три: что такое yes и no , думаю, понятно, а в режиме auto ConnTrack выключен до тех пор, пока хотя бы один пакет не попадет в существующие правила таблицы NAT или Filter.

WARNING

Выключенный ConnTrack ломает NAT и фичи файрвола, основанные на трекинге потоков: connection-bytes, connection-mark, connection-type, connection-state, connection-limit, connection-rate, layer7-protocol, new-connection-mark, tarpit.

Траблшутинг

Когда файрвол не работает или работает не так, как подразумевалось при настройке, виноват админ. Магии не бывает. Первое, на что стоит обратить внимание при траблшутинге, — счетчики пакетов. Если счетчик не увеличивается, значит, трафик в него не попадает. А если трафик не попадает, значит, либо этого трафика просто нет, либо он был обработан стоящим выше правилом.

Ты же помнишь, что правила файрвола работают по принципу «кто первый встал — того и тапки»? Если пакет попал под действие правила, то дальше он уже не пойдет. Значит, нужно искать проблему выше. Просто копируем наше правило, action ставим accept (для траблшутинга не делай дроп — так при проверке можно сломать себе доступ или нарушить работу сети) и постепенно двигаем его наверх до первого увеличения счетчиков в этом правиле. Если через это правило уже проходил трафик, то счетчики будут ненулевые и можно пропустить нужные нам пакеты, — просто сбрось счетчики в этом правиле или во всех кнопками Reset Counters.

Reset Counters

Предположим, мы нашли правило, в которое попадает наш трафик, а попадать не должен. Нужно понять, почему так происходит. В этом нам поможет опция Log. Во вкладке Action ставим галочку Log (можно написать префикс для правила, чтобы было проще отлавливать его в логах) и смотрим логи, где написаны все характеристики пакетов, попадающих под правило. Среди характеристик: цепочка, входящий и исходящий интерфейсы, адреса и порты источника и получателя, протокол, флаги, размер пакета, действия NAT.

Если даже в самом верху в правиле не будут увеличиваться счетчики, убирай правила из условия по одному. Начинай с интерфейсов — админы часто путаются в своих представлениях о том, откуда или куда должен идти трафик (например, при коннекте к провайдеру через PPPoE или в туннелях между филиалами или сложном роутинге). Счетчики пошли? Включаем лог и смотрим интерфейсы и другие параметры.

Если и это не помогает — пришло время тяжелой артиллерии. Идем в Tools → Torch и изучаем трафик на роутере. Может, ожидаемого трафика вовсе нет. Еще один крутой инструмент — аналог tcpdump — Tools → Packet Sniffer. Разбор работы этих инструментов тянет на отдельную статью (если она тебе интересна — сообщи об этом в комментариях к статье).

Чтобы упростить траблшутинг, можно использовать функцию комментирования. Если из-за комментов окно становится слишком большим и это мешает смотреть на правила, воспользуйся инлайновыми комментариями (Inline Comments). Так комменты встанут с правилом в одну строку и в окно будет умещаться больше правил.

Inline Comments

Также рекомендую распределять правила по порядку, следуя какой-то определенной логике. И старайся ее поддерживать на всех роутерах.

Итоги

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

Сюда вошли наиболее типичные проблемы микротик и их решения.

Теперь они собраны в одном месте, а не разбросаны по крупицам по всему интернету.

6.1. Как ходит трафик в Микротик?

Представьте компьютер с двумя сетевыми картами. Будем называть его ШЛЮЗ.

В одну карту входит интернет. Со второй выходит к свитчу.

А к свитчу подключены другие компы.

За этими компьютерами люди в интернете выходят.

Это левая диаграмма. Как раз наш случай с Микротик.

А если на самом шлюзе запускаются браузер, почта и пр.

Это левая и правая диаграмма, только без центрального блока FORWARD.

В Микротике правая практически никогда не задействована.

Так что про INPUT-OUTPUT забудьте.

Только для блокировки входящих пакетов.

Никаких локальных адресов в пакете нет, только внешний адрес Микротика!

Происходит подмена (из таблицы NAT) для входящих пакетов внешнего IP на локальный.

или DstNat (это для тех, кто пытается достучаться до локальных IP-адресов из интернета)

3. Теперь срабатывают правила в цепочках Mangle Forward и Filter Forward.

Тут уже можно фильтровать клиентов вашей сети.

4.Далее снова срабатывает NAT.

Здесь создаются записи в таблице NAT для исходящих пакетов. Т.е. срабатывает SRC-NAT.

По этим записям будет происходить обратная замена IP, когда придут ответные пакеты.

И для исходящих пакетов происходит подмена локального IP 192.168.0.2 на IP Микротика 80.80.80.1.

Никаких локальных адресов в пакете нет, только внешний адрес Микротика!

Далее все это направляется в шейпер. Queue Tree и Simple Queue.

Для Транзитного трафика:
сеть -> mangle PREROUTING -> nat PREROUTING -> mangle FORWARD -> filter FORWARD -> mangle POSTROUTING -> nat POSTROUTING -> сеть

6.2. Firewall Filter — блокируем и разрешаем.

Здесь создаются блокирующие и разрешающие правила.

Порядок записей имеет значение.

Проверка правил происходит сверху вниз.

Если пакет соответствует правилу, то дальнейшая проверка не происходит, если конечно не стоит галка PassTrugh

Есть 2 варианта.

Блокируется или входящие пакеты или исходящие.

Важно!

1. Никогда не пытайтесь одним правилом блокировать входящие и исходящие пакеты одновременно.

Да и Роутер разгрузится от лишнего входящего трафика.

Важно! Src.Address и Dst.Address в правилах меняются местами. В зависимости от направления движения пакета.

3. В правилах всегда указывайте Out. Interface или In. Interface.

Это очень важно!

То же самое (п. 1 и 2) касается и Mangle.

6.3. NAT. Проброс портов.

6.4. Маркировщик Mangle. Следим и помечаем трафик.

Это очень мощное средство. Позволяет маркировать пакеты по любым правилам. Подчиняется тем же правилам, что описаны в разделе 6.2. FireWall Filter. Но Мангле ничего не запрещает и не разрешает. Он просто помечает трафик: соединения, пакеты, маршруты и пр. Умеет также добавлять в AddressList, Менять TTL пакетов, приоритет, порядок цепочек и пр. пр. Это для дальнейшей обработки в фаерволе или шейпере.

6.5. Address List. Для чего он?

Это в основном для того, чтоб не указывать кучу однотипных правил для разных IP, а кинуть эти IP в один Address List. И затем создать только одно правило на этот Address List.

Чрезвычайно удобная штука!

6.6. Нарезаем скорость. Simple Queues.

Важно! Проверка правил шейпера происходит сверху вниз. Если какое-то правило шейпа сработало, то дальнейшая проверка уже не производится!

Добавляем IP или список IP, для которых в сумме можно выставить максимальную скорость Max Limit.

Отдельно входящую и исходящую скорость.

А также потребленный входящий и исходящий трафик. (Rx Avg. Rate и Tx Avg. Rate )

Начиная с момента последней перезагрузки роутера.

Можно скорости писать в виде 500K, 2M, а также можно указать скорости Burst Limit (с Burst TreshHold, Burst Time)

Это взрывная кратковременная скорость.

Очень эффективно при низко скоростных тарифах и если Вас качальщики задрали.

Веб сайты открываются тогда моментом на Burst скорости, а закачки идут на обычной скорости.

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

Эту запись нужно поставить выше основной записи клиента.

Если Вы скорость на локальные ресурсы не хотите подрезать вообще, то

и поместить ее на самый верх.

Важно! Очень советую в самый конец добавлять правило END.

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

Ну например Вы по невнимательности забыли кого-то добавить в шейпер.

И человек получит всю доступную скорость без любых огранечиний! Тем самым может положить канал!

Правило END для учета и подрезки неучтенного траффика:

add interface=all max-limit=100k/100k name=END target-addresses=192.168.0.0/16

По функциональности он гораздо шире. Этот шейпер срабатывает раньше Simple Queue.

Эффективен особенно при методе PCQ.

И большом количестве клиентов 100 и более.

В нем входящая и исходящая скорости нарезаются отдельными правилами.

Он работает только в связке с Мангле.

Это тарифные планы.

2. Далее в IP-Firewall-Mangle маркируем Connection-ы.

Эти два правила будут будут нарезать трафик всем клиентам.

Достаточно адрес IP клиента добавить в нужный Adrress List.

Все остальное аналогично.

А как же смотреть, кто сколько скачал и на какой скорости и кто качает?

Эти записи ставим ниже записей mark-connection и mark-packet.

6.8. Включаем Графики.

Графики трафика доступны для всех интерфейсов, и Simple Queue. А также доступны графики загрузки процессора, памяти, flash-памяти. За сутки, за неделю, за месяц, за год.

Просто добавьте нужные позиции.

Посмотреть графики можно на Веб-странице Микротика.

При перезагрузке графики сохраняются.

При прошивки графики сбрасываются.

6.9. IPTV настройка.

Скачиваем версию пакетов под ваш Микротик

Важно! Версия пакета должна совпадать с версией вашей Router OS!

Далее идем в System-Packages. Там должен быть multicast пакет.

6.10. Резервирование 2 и более каналов.

По умолчанию пакеты идут через WAN1.

6.11. Балансировка 2+ каналов.

Балансировка через маршруты. Соединения вперемешку будут идти через WAN1 или WAN2

Метод хорошо работает при каналах приблизительно равных по скорости.

Разница по скорости каналов не должна отличаться более чем в 2 раза.

Можно добавить еще маршрут без маркировки на всякий пожарный:

Важно! При каналах сильно отличающихся по скорости он мало эффективен.

В таком случае советую использовать резервирование каналов по п. 6.10.

Слабый канал погоды все-равно не сделает. А скоростному мешать будет.

6.12. Запрет определенных сайтов по имени.

Открываем New Terminal. И вставляем наше правило. Не забудьте поднять его наверх.

Можете также вручную кнопкой [+] создать это правило.

Тем самым Вы блокируете только исходящие запросы еще на взлете.

Роутеру уже на нужно фильтровать входящие пакеты от этого сайта,

А исходящий трафик обычно в 10-20 раз меньше входящего.

Да и фильтруются только исходящие TCP запросы.

Что есть очень хорошо.

Если нужно блокировать доступ к сайту для всех компов, убираем эту строчку src-address.

6.13. Определяем у кого стоят роутеры по TTL.

Все IP адреса, которы сидят за роутерами, попадут в Address-List Router

И наоборот, можно спрятать вашу сеть от фильтра TTL провайдера.

Это правило поднимите на самый верх.

6.14.Блокируем порты спамеров.

1. Блокируем порты спамеров и зараженных троянами-вирусами компов.

2. Добавляем в address-list=spammer наших спамеров на 30 дней :

Вы же не хотите, что бы Ваш провайдер Вам закрывал порты? Или хотите?

6.15. Настройка Static DNS.

Static DNS
нужен чтобы к любому компу в сети обращаться не по IP адресу, а по придуманному имени. Что очень удобно.

6.16.Кешируем с помощью Web-Proxy.

Кеширование используется для:

1. Ускорения интернет. Особенно Эффективно при медленном интернете.

Часто запрашиваемые файлы хранятся на флеш-памяти или винте.

2. Для экономии траффика. Хорошо при платном траффике.

Весь трафик проходит через прокси микротика.

На прокси ставиться порт 8080.

И затем включается прозрачный прокси.

6.17. Редирект на страницу-напоминалку.

К примеру у Вас есть комп в сети 192.168.0.10. Там находится Веб-сервер и страница-напоминалка-пополнялка-личный кабинет. Она доступна по адресу 192.168.0.10

Это правило кинуть выше правила srcnat!

Все. редирект работает.

Эти правила кинуть вниз.

Это для полной блокировки любой активности (а не только ВЕБ-серфиннг) юзеров, которые не в ALLOW.

Один клик и готово.

4. На вебсервере в корне страницы-напоминалки добавляем файл .htaccess с редиректом :

RewriteEngine on
RewriteCond % !-d
RewriteCond % !-f
RewriteRule .* /index.html [L,QSA,NC,R=302]

А в 404.php сделать include вашей страницы напоминалки.

Или просто скопировать ее содержимое.

Вот так все просто.

6.18. Шейпим торренты.

Данный метод режет все торренты. И шифрованные в том числе. И он не ресурсоёмкий для Микротика.

Маркируем входящие торрент-пакеты по размерам, портам и протоколам:

В Simple Queue можно каждому указать скорость на торрент в отдельности.

Т.е. для каждого IP создать дополнительную запись.

Эта запись должна быть выше основной записи IP клиента.

Или уже решайте на свое усмотрение, что с этими маркированными пакетами делать.

Читайте также: