Потоки Пакетов в MikroTik(RouterOS)

Обзор Потока Пакетов в RouterOS

Для обеспечения ясности и эффективного контроля над сетевым трафиком, поток пакетов в RouterOS разделен на три основные части: общая схема, подробная схема для мостовых, маршрутизируемых и MPLS-пакетов, а также детализированная схема, иллюстрирующая порядок работы различных компонентов в цепочках Firewall. Такое модульное деление позволяет сетевым администраторам более точно настраивать и отлаживать поведение маршрутизатора, локализуя потенциальные проблемы до конкретного этапа обработки, будь то маршрутизация, NAT или управление очередями.

В центре общей схемы обработки пакетов расположены четыре ключевых блока принятия решений: Bridging (мост), Routing (маршрутизация), MPLS decisions (решения MPLS) и Local router processes (локальные процессы маршрутизатора). Эти дискретные, но взаимосвязанные механизмы определяют основной путь пакета через систему, что является фундаментальным для понимания логики его обработки.

Ключевые Точки Входа и Выхода Пакетов Для полного понимания потока пакетов важно различать различные точки, через которые пакеты входят в маршрутизатор и покидают его:

• Физический входящий интерфейс (physical in-interface): Это начальная точка, где пакет, полученный маршрутизатором, впервые попадает в систему непосредственно с сетевого оборудования.

• Логический входящий интерфейс (logical in-interface): Эта точка входа предназначена для пакетов после их декапсуляции, например, из туннелей (IPIP, EoIP) или после дешифрования IPsec.

• Локальный вход (local in): Эта точка представляет собой конечный пункт назначения для пакетов, которые адресованы непосредственно самому маршрутизатору, например, для доступа к его веб-интерфейсу, SSH-сессиям или DNS-запросам.

• Локальный выход (local out): Это точка отправления для пакетов, которые были сгенерированы самим маршрутизатором, таких как ответы DNS-сервера, исходящие SSH-сессии или трафик мониторинга.

• Физический исходящий интерфейс (physical out-interface): Это конечная точка пакета перед его фактической отправкой из маршрутизатора через физический сетевой порт.

• Логический исходящий интерфейс (logical out-interface): Это конечная точка пакета перед его инкапсуляцией (например, в туннели или для шифрования IPsec) перед отправкой.

Различие между "физическими" и "логическими" интерфейсами для входящего и исходящего трафика является ключевым. Упоминание "логического входящего интерфейса" как точки входа декапсулированного пакета указывает на активную обработку инкапсулированного трафика (туннели, IPsec) как отдельного этапа. После декапсуляции пакет "снова поступает в обработку PREROUTING и начинает новый цикл обработки". Эта "двойная" обработка означает, что пакет может пройти через RouterOS дважды, что имеет существенные последствия для размещения правил Firewall, NAT и Mangle, а также для производительности. Например, правила фильтрации могут потребоваться как для внешнего (инкапсулированного), так и для внутреннего (декапсулированного) пакета. Понимание этого механизма объясняет, почему туннелирование и IPsec могут значительно увеличивать нагрузку на ЦП и почему для высокопроизводительных сценариев требуются специальные оптимизации.

Основные Этапы Принятия Решений об Обработке Пакетов

Решение о Маршрутизации (Routing Decision)

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

Решение MPLS (MPLS Decision)

Для пакетов, помеченных метками MPLS, RouterOS определяет дальнейшие действия на основе таблиц пересылки MPLS. Этот механизм позволяет эффективно пересылать пакеты в сетях MPLS, минуя традиционные IP-маршрутизаторы на промежуточных узлах.

Решение о Мосте (Bridging Decision)

Мост просматривает свою таблицу MAC-адресов (таблицу хостов моста), чтобы найти соответствие MAC-адресу назначения пакета. Если соответствие найдено, пакет пересылается на соответствующий порт. Если MAC-адрес назначения неизвестен, мост создает множественные копии пакета и рассылает их (флудит) по всем портам моста, кроме входящего.

Важно отметить, что при использовании опции vlan-filtering=yes в настройках моста, пакеты, которые не разрешены таблицей /interface bridge vlan, отбрасываются на этом этапе. Это значительно расширяет роль моста за пределы простой пересылки MAC-адресов, делая его активной точкой применения политик безопасности Layer 2. Фильтрация VLAN на мосту действует как ранний этап файрвола Layer 2, даже до того, как могут быть применены IP-файрвол правила (особенно если use-ip-firewall отключен или пакет не является IP). Это мощный инструмент для сегментации сети и предотвращения несанкционированного доступа между VLAN.

Роль use-ip-firewall и ipsec-policy

• use-ip-firewall: Эта опция проверяет, включена ли функция IP-файрвола для трафика, проходящего через мост. Если она включена, мостовой трафик будет дополнительно обрабатываться IP-файрволом, что позволяет применять правила Layer 3 к Layer 2 трафику. Эта опция является критическим переходом, где трафик моста Layer 2 может быть "поднят" для обработки IP-файрволом Layer 3. Без нее IP-файрвол правила не будут применяться к мостовому трафику, потенциально создавая уязвимости. Это демонстрирует гибкость RouterOS, позволяя администраторам выбирать, обрабатывать ли мостовой трафик чисто на Layer 2 или подвергать его более гранулированным IP-файрвол правилам. Этот выбор имеет значительные последствия для производительности, поскольку включение use-ip-firewall увеличивает нагрузку на ЦП для мостовых пакетов и может повлиять на возможность использования FastPath для мостового трафика.

• ipsec-policy: На этом этапе RouterOS проверяет, соответствует ли пакет какой-либо из настроенных политик IPsec. Если совпадение найдено, пакет может быть отправлен на дешифрование или инкапсуляцию, в зависимости от направления и типа политики.

Цепочки Firewall и их Компоненты

Стандартные Цепочки Firewall

• PREROUTING: Правила в этой цепочке применяются к пакетам сразу после их поступления на сетевой интерфейс, до принятия решения о маршрутизации. Эта цепочка присутствует в таблицах nat, mangle и raw.

• INPUT: Правила в этой цепочке применяются к пакетам, предназначенным непосредственно для самого маршрутизатора (локальный вход). Она присутствует в таблицах mangle и filter.

• OUTPUT: Правила здесь применяются к пакетам, сгенерированным самим маршрутизатором (локальный выход), перед их отправкой. Эта цепочка присутствует в таблицах raw, mangle, nat и filter.

• FORWARD: Правила здесь применяются к любым пакетам, которые маршрутизируются через текущий хост (т.е., пакеты, которые не предназначены для самого маршрутизатора и не сгенерированы им). Эта цепочка присутствует только в таблицах mangle и filter.

• POSTROUTING: Правила в этой цепочке применяются к пакетам сразу после того, как они прошли через все этапы маршрутизации и готовы к выходу из сетевого интерфейса. Она присутствует в таблицах nat и mangle.

Ключевые Компоненты в Цепочках

Внутри каждой цепочки Firewall пакеты взаимодействуют с различными компонентами, каждый из которых выполняет свою специфическую функцию:

• Connection Tracking (Отслеживание Соединений): Этот компонент обрабатывает пакеты для отслеживания состояния сетевых соединений. Он является основой для работы stateful firewall, NAT и других функций, зависящих от контекста трафика. Его стратегическое размещение в prerouting определяет состояние соединения до большинства других операций, позволяя последующим правилам действовать на основе этого состояния. Однако Connection Tracking потребляет ресурсы ЦП, и его обход (как в FastPath/FastTrack) является ключевой стратегией оптимизации производительности.

• Mangle: Цепочки Mangle (Mangle Prerouting, Mangle Input, Mangle Forward, Mangle Output, Mangle Postrouting) используются для модификации различных атрибутов пакетов, таких как метки маршрутизации (routing-mark), метки соединений (connection-mark), метки пакетов (packet-mark), TTL и QoS-поля (DSCP). Присутствие правил Mangle во всех пяти основных цепочках Firewall и их применимость к различным типам пакетов указывает на то, что Mangle является основным инструментом для манипуляций с пакетами практически на любом этапе их обработки. Его широкое применение означает, что сложные задачи, такие как управление трафиком (QoS), политика маршрутизации и даже некоторые продвинутые функции безопасности, в значительной степени зависят от Mangle.

• Filter: Цепочки Filter (Filter Input, Filter Forward, Filter Output) используются для фильтрации пакетов, то есть для разрешения или запрета их прохождения на основе заданных правил.

• NAT (Network Address Translation): Включает Dst Nat (Destination NAT), применяемый в цепочке prerouting для изменения IP-адреса назначения пакета (например, для проброса портов), и Src Nat (Source NAT), применяемый в цепочке postrouting для изменения IP-адреса источника пакета (например, для доступа к Интернету из локальной сети). Детальный поток для маршрутизируемых пакетов показывает, что NAT dst-nat происходит в prerouting до "Решения о маршрутизации". Этот порядок абсолютно необходим для проброса портов, поскольку DNAT изменяет IP-адрес назначения входящего пакета до того, как будет принято решение о маршрутизации.

• Queues (Очереди): Включают HTB Global (Hierarchical Token Bucket Global) – дерево очередей для комплексного управления полосой пропускания, и Simple Queues – для простого ограничения трафика для определенных целей. Эти компоненты управляют приоритетом и скоростью передачи пакетов.

• TTL (Time To Live): Точное место, где значение TTL маршрутизируемого пакета уменьшается на 1. Если TTL достигает 0, пакет отбрасывается, предотвращая бесконечные циклы в сети. Это происходит после решения о маршрутизации, но до правил Mangle/Filter в цепочке forward. Если TTL пакета обнуляется в этой точке, он будет отброшен до того, как любые правила forward смогут явно его зарегистрировать или обработать.

• Accounting (Учет): Обрабатывает функции аутентификации, авторизации и учета трафика, позволяя собирать статистику использования сети.

• Hotspot: Компоненты Hotspot-in и Hotspot-out позволяют управлять трафиком для клиентов Hotspot, перехватывая его и отменяя модификации.

• RAW: Цепочки RAW (RAW Prerouting, RAW Output) позволяют обрабатывать пакеты на очень ранних этапах, до отслеживания соединений, что полезно для защиты от DoS-атак или для специфических задач.

• Routing Adjustment: Этот компонент позволяет настраивать политику маршрутизации (например, через routing-mark) в цепочке mangle output, влияя на то, как пакеты, генерируемые самим маршрутизатором, будут маршрутизироваться.

Механизмы Оптимизации Производительности

Hardware Offloading (Аппаратное Ускорение)

Большинство устройств MikroTik оснащены специализированным коммутационным оборудованием (чипом коммутатора или ASIC), которое позволяет переносить некоторые функции моста, такие как пересылка пакетов между портами моста, фильтрация пакетов, изучение хостов, тегирование/снятие тегов VLAN, на этот специализированный аппаратный чип. Это значительно снижает нагрузку на центральный процессор маршрутизатора. Блок switching decision, зависящий от модели коммутатора, управляет всеми задачами, связанными с коммутацией. switch-cpu port является специальным портом коммутатора, используемым для связи между основным ЦП маршрутизатора и другими портами коммутатора, позволяя ЦП взаимодействовать с аппаратным коммутатором.

Fast Path (Быстрый Путь)

FastPath был представлен в RouterOS v6 как механизм для ускорения обработки пакетов путем обхода значительной части обработки в ядре Linux. Это достигается за счет прямого взаимодействия драйвера интерфейса с определенными функциями RouterOS, минуя остальные. Обработчики FastPath включают IPv4, IPv4 FastTrack, Traffic Generator, MPLS и Bridge.

Для того чтобы FastPath был активен, должны быть соблюдены определенные условия, которые демонстрируют фундаментальный компромисс между производительностью и функциональностью. Для достижения высокой пропускной способности и снижения загрузки ЦП RouterOS обходит многие основные функции, такие как правила файрвола, отслеживание соединений, очереди и IP-учет.

• Условия для IPv4 FastPath: Отсутствие правил firewall, простых очередей или деревьев очередей с parent=global, конфигурации mesh или metarouter, не запущены sniffer или torch, неактивно отслеживание соединений (Connection Tracking), отключен IP accounting, не настроены VRF, не используется Hotspot, не настроены политики IPSec, не используются /tool mac-scan или /tool ip-scan.

• Условия для Bridge FastPath: Отсутствие правил bridge Calea, filter, NAT; отключена опция use-ip-firewall; отсутствие конфигурации mesh или MetaRouter; не запущены sniffer, torch и traffic generator; опция bridge vlan-filtering должна быть отключена (это условие было удалено начиная с RouterOS 7.2); отключен bridge dhcp-snooping.

FastTrack

FastTrack можно рассматривать как расширение Fast Path, объединяющее его с Connection Tracking. Он позволяет помечать установленные соединения как "fast-tracked", в результате чего пакеты, принадлежащие к этим соединениям, будут обрабатываться по быстрому пути. Пакеты, помеченные как FastTrack, обходят значительную часть обычного потока обработки, включая firewall, connection tracking, simple queues, queue tree с parent=global, ip traffic-flow, IP accounting, IPSec, hotspot universal client и VRF assignment. Это значительно снижает нагрузку на ЦП. Для пометки соединения как "fast-tracked" используется специальное действие fasttrack-connection в правилах firewall filter и mangle.

FastTrack — это сложная оптимизация для долгоживущих, высокообъемных соединений (например, больших передач файлов, видеопотоков). Он позволяет первым пакетам соединения быть полностью инспектированными, но как только соединение считается "безопасным" и установленным, последующие пакеты этого соединения могут обходить большую часть ресурсоемкой обработки ЦП. Это предлагает баланс между безопасностью/контролем и производительностью, позволяя администраторам применять глубокую инспекцию только к начальной установке соединения, а затем ускорять передачу основного объема данных.

• Требования FastTrack: Отсутствие конфигурации mesh или metarouter; не запущены sniffer, torch и traffic generator; не используются /tool mac-scan или /tool ip-scan; FastPath и Route cache должны быть включены в IP/Settings (условие route cache не применяется к RouterOS v7 или новее); FastPath моста должен быть включен, если соединение проходит через интерфейс моста.

Особые Сценарии Обработки Пакетов

MPLS IP VPN

В контексте VPNv4, пакет, поступающий на PE-маршрутизатор и предназначенный для перенаправления на CE-маршрутизатор, не проходит через типичный процесс "пересылки" (forwarding) IP-пакетов. Если входящая метка MPLS и назначение пакета привязаны к определенному VRF (Virtual Routing and Forwarding), то после извлечения метки MPLS происходит следующее:

• Если адрес назначения локален для PE-маршрутизатора, пакет перемещается в LOCAL_IN для обработки самим маршрутизатором.

• Если адрес назначения находится в сети CE, пакет перемещается в LOCAL_OUT для отправки в сеть CE.

Ключевой момент заключается в том, что перенаправляемые пакеты из облака MPLS в сеть CE не будут отображаться в стандартной цепочке forward IP-файрвола. Это является критическим исключением из общего потока IP-пакетов и имеет значительные последствия для безопасности и устранения неполадок. Если администратор ожидает фильтровать или мониторить трафик MPLS VPN с использованием стандартных правил IP forward, он потерпит неудачу. Политики безопасности для такого трафика должны быть реализованы на уровне MPLS, например, с использованием политик маршрутизации, специфичных для VRF, или входных/выходных цепочек на самом PE-маршрутизаторе, если пакет предназначен для маршрутизатора или генерируется им.

Логические Интерфейсы (Туннели)

Когда маршрутизатор получает инкапсулированные пакеты (например, через туннели IPIP, EoIP), они изначально обрабатываются как обычные IPv4-пакеты. Маршрутизатор определяет, требуется ли декапсуляция. После декапсуляции внутренний пакет проходит еще один полный цикл обработки через все те же компоненты потока пакетов, но уже как декапсулированный IPv4-пакет. Это означает, что пакет фактически проходит через Firewall дважды – один раз как инкапсулированный пакет, и второй раз как декапсулированный.

IPSec Policies

Хотя IPSec не использует концепцию "логических интерфейсов" в том же смысле, что туннели, его обработка аналогична. После принятия решения о маршрутизации и обработки входящего Firewall, маршрутизатор пытается сопоставить источник и назначение пакета с настроенными политиками IPsec. При совпадении политики, пакет отправляется на дешифрование. После успешного дешифрования дешифрованный пакет снова поступает в обработку PREROUTING и начинает новый цикл обработки уже как обычный, открытый пакет. Процесс инкапсуляции и шифрования происходит в обратном порядке на исходящем пути.

Разделы "Логические интерфейсы" и "IPSec Policies" описывают процесс, при котором после декапсуляции/дешифрования пакет "снова поступает в обработку PREROUTING и начинает новый цикл обработки". Это фактически "сброс" пути пакета через поток RouterOS. Этот "сброс" означает, что все правила файрвола, правила NAT, правила Mangle и другие шаги обработки, которые применяются к "нормальным" IP-пакетам, будут переоцениваться для декапсулированной/дешифрованной полезной нагрузки. Это мощная функция для применения гранулированных политик к внутреннему трафику туннелей/VPN, но это также означает, что один и тот же пакет потребляет значительно больше циклов ЦП и проходит больше этапов обработки. Это усиливает необходимость тщательного размещения правил и понимания того, что путь пакета не всегда линеен, особенно при использовании сложных оверлеев.

Заключение

Анализ потока пакетов в RouterOS выявляет сложную, многоэтапную систему, где порядок обработки компонентов имеет решающее значение для функциональности и производительности сети. Существуют фундаментальные различия в обработке маршрутизируемых и мостовых пакетов, а также особые сценарии для MPLS, туннелей и IPsec, требующие глубокого понимания. Механизмы оптимизации производительности, такие как Hardware Offloading, Fast Path и FastTrack, предлагают значительное ускорение, но всегда сопряжены с компромиссами в отношении доступности функций и гранулированного контроля.

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

Рекомендации

На основе проведенного анализа можно сформулировать следующие рекомендации для администраторов RouterOS:

• Холистический Подход: Для эффективного администрирования и устранения неполадок в RouterOS необходимо иметь целостное представление обо всем потоке пакетов, а не только об отдельных компонентах. Проблема в одной области может проявиться как сбой в другой, если не учитывать взаимосвязи.

• Внимательное Размещение Правил: Порядок правил в цепочках Firewall и их принадлежность к различным таблицам (filter, nat, mangle, raw) критически важны. Неправильное размещение может привести к нежелательному поведению или уязвимостям.

• Осознанный Выбор Оптимизаций: При использовании Fast Path, FastTrack или Hardware Offloading, администраторы должны четко понимать, какие функции будут обойдены или отключены. Оптимизации производительности в RouterOS мощны, но имеют значительные оговорки. Это не функции "включил и забыл", которые универсально ускоряют весь трафик. Администраторы должны тщательно взвешивать преимущества увеличенной пропускной способности по сравнению с потерей гранулированного контроля, видимости (например, обход учета) и функциональности конкретных функций. Оптимизации должны применяться избирательно, исходя из конкретных требований к производительности и безопасности для каждого типа трафика.

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