Connection Tracking на MikroTik — детальный разбор

Connection Tracking (conntrack) — фундаментальный механизм stateful firewall в MikroTik RouterOS. Именно благодаря conntrack маршрутизатор «помнит» каждое активное соединение, отличает легитимные ответы от нежелательного трафика и обеспечивает работу NAT. Без понимания Connection Tracking невозможно грамотно настроить firewall, диагностировать проблемы с производительностью и защитить сеть от атак.

В этой статье мы подробно разберём состояния соединений, параметры таймаутов, взаимодействие conntrack с FastTrack и RAW, а также типичные проблемы и их решения.

Описание

Что такое Connection Tracking

Connection Tracking — это подсистема ядра Linux (netfilter conntrack), интегрированная в RouterOS, которая отслеживает все сетевые соединения, проходящие через маршрутизатор. Каждый пакет ассоциируется с конкретным соединением, а каждому соединению присваивается состояние.

Благодаря conntrack маршрутизатор может:

• Различать новые и уже установленные соединения
• Автоматически пропускать ответные пакеты (established)
• Связывать вспомогательные соединения с основными (related) — например, FTP-DATA с FTP-CONTROL
• Выполнять NAT (трансляцию адресов)
• Определять и отбрасывать некорректные пакеты (invalid)

Состояния соединений

Каждое соединение в conntrack-таблице имеет одно из следующих состояний:

new — первый пакет соединения, который ещё не имеет ответа. Для TCP это SYN-пакет. Для UDP — первый пакет в данном направлении (UDP не имеет формального handshake, поэтому conntrack создаёт виртуальное соединение).

established — соединение, по которому прошли пакеты в обоих направлениях. Для TCP это означает завершённый three-way handshake (SYN → SYN-ACK → ACK). Для UDP — наличие ответного пакета от получателя.

related — пакет, связанный с уже существующим соединением, но не являющийся его частью. Классические примеры:

• ICMP Destination Unreachable в ответ на TCP/UDP пакет
• FTP-DATA соединение (порт 20), связанное с FTP-CONTROL (порт 21)
• SIP-медиапоток (RTP), связанный с SIP-сигнализацией

invalid — пакет, который не принадлежит ни одному известному соединению и не может быть идентифицирован как new. Причины:

• Пакет с неправильными TCP-флагами
• ICMP-ответ без соответствующего запроса
• Пакет с несуществующим sequence number
• Повреждённый пакет

untracked — пакет, помеченный действием notrack в таблице RAW. Conntrack полностью игнорирует такие пакеты — они не создают записей и не расходуют ресурсы.

Таблица соединений

Все активные соединения хранятся в таблице /ip/firewall/connection. Каждая запись содержит:

• Source/Destination IP и порт
• Протокол (TCP, UDP, ICMP и т.д.)
• Текущее состояние
• Таймер до удаления
• Счётчики пакетов/байт
• Информация о NAT (если применяется)
• Флаги (assured, seen-reply, fasttrack и т.д.)

Настройка

Просмотр текущей конфигурации conntrack

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/print

Вывод покажет текущие параметры: включён ли conntrack, таймауты для различных протоколов, максимальное количество записей.

Основные параметры conntrack

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/set \
    enabled=yes \
    tcp-syn-sent-timeout=5s \
    tcp-syn-received-timeout=5s \
    tcp-established-timeout=1d \
    tcp-fin-wait-timeout=10s \
    tcp-close-wait-timeout=10s \
    tcp-last-ack-timeout=10s \
    tcp-time-wait-timeout=10s \
    tcp-close-timeout=10s \
    tcp-max-retrans-timeout=5m \
    tcp-unacked-timeout=5m \
    udp-timeout=10s \
    udp-stream-timeout=3m \
    icmp-timeout=10s \
    generic-timeout=10m \
    max-entries=32768 \
    loose-tcp-tracking=yes

Рассмотрим каждый параметр подробно.

TCP таймауты

tcp-established-timeout (по умолчанию 1d) — время, через которое established TCP-соединение удаляется из таблицы при отсутствии активности. Это самый важный таймаут, так как established-соединения составляют большинство записей.

Для ISP с большим количеством клиентов рекомендуется уменьшить до 2–4 часов:

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/set tcp-established-timeout=4h

tcp-syn-sent-timeout (по умолчанию 5s) — время ожидания ответа на SYN. Если SYN-ACK не пришёл за это время, запись удаляется. При SYN flood увеличение этого значения приведёт к быстрому заполнению таблицы.

tcp-fin-wait-timeout и tcp-time-wait-timeout — таймауты для завершающих стадий TCP. Обычно не требуют изменений.

UDP таймауты

udp-timeout (по умолчанию 10s) — таймаут для единичных UDP-пакетов (нет ответа). Подходит для DNS-запросов.

udp-stream-timeout (по умолчанию 3m) — таймаут для UDP-потоков (двусторонний обмен). Важен для VoIP, видеозвонков, онлайн-игр.

Для VoIP-нагрузки может потребоваться увеличение:

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/set udp-stream-timeout=5m

Max-entries — максимальное количество соединений

Параметр max-entries определяет, сколько одновременных соединений может отслеживать маршрутизатор. По умолчанию значение зависит от модели:

• SOHO-устройства (hAP, hEX): 16384–32768
• Mid-range (RB4011, RB5009): 65536
• Carrier-grade (CCR): 262144–1048576

Каждая запись conntrack занимает примерно 300–400 байт RAM. Расчёт потребления памяти:

• 32,768 записей × 400 байт ≈ 12.5 MB
• 262,144 записей × 400 байт ≈ 100 MB
• 1,048,576 записей × 400 байт ≈ 400 MB

[admin@MikroTik] >
Копировать
# Просмотр текущего количества соединений
/ip/firewall/connection/print count-only

# Просмотр максимума и текущего использования
/ip/firewall/connection/tracking/print

Настройка для ISP (10000+ подключений)

Для провайдерских маршрутизаторов с большим количеством клиентов требуется тонкая настройка:

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/set \
    max-entries=262144 \
    tcp-established-timeout=2h \
    tcp-syn-sent-timeout=3s \
    tcp-syn-received-timeout=3s \
    tcp-fin-wait-timeout=5s \
    tcp-close-wait-timeout=5s \
    tcp-time-wait-timeout=5s \
    tcp-close-timeout=5s \
    udp-timeout=10s \
    udp-stream-timeout=2m \
    generic-timeout=5m

Ключевые отличия от стандартных настроек:

1. max-entries=262144 — увеличен до 256K записей
2. tcp-established-timeout=2h — уменьшен с 1 дня до 2 часов (неактивные TCP-соединения удаляются быстрее)
3. Уменьшены все промежуточные таймауты — быстрее освобождаем ресурсы

Loose TCP Tracking

Параметр loose-tcp-tracking (по умолчанию yes) определяет, как строго conntrack проверяет TCP sequence numbers.

• yes — мягкий режим. Conntrack принимает пакеты даже с неожиданными sequence numbers. Подходит для асимметричной маршрутизации.
• no — строгий режим. Пакеты с неправильными sequence numbers помечаются как invalid. Более безопасно, но может вызвать проблемы при асимметричной маршрутизации.

[admin@MikroTik] >
Копировать
# Включение строгого режима (рекомендуется при симметричной маршрутизации)
/ip/firewall/connection/tracking/set loose-tcp-tracking=no

Проблема: переполнение conntrack-таблицы

Симптомы

• Новые соединения не устанавливаются (сайты не открываются)
• В логах появляется сообщение nf_conntrack: table full, dropping packet
• Существующие соединения продолжают работать
• CPU загружен на 100%

Диагностика

[admin@MikroTik] >
Копировать
# Текущее количество соединений
/ip/firewall/connection/print count-only

# Сравниваем с максимумом
/ip/firewall/connection/tracking/print

# Анализ по протоколам
/ip/firewall/connection/print where protocol=tcp count-only
/ip/firewall/connection/print where protocol=udp count-only

# Поиск IP с наибольшим количеством соединений
/ip/firewall/connection/print where src-address~"^192.168" \
    file=conntrack-dump

Решения

Решение 1: Увеличение max-entries (быстрое, но не устраняет причину):

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/set max-entries=65536

Решение 2: Уменьшение таймаутов (эффективное):

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking/set \
    tcp-established-timeout=4h \
    tcp-syn-sent-timeout=3s \
    udp-timeout=10s \
    generic-timeout=5m

Решение 3: Использование RAW для блокировки нежелательного трафика до conntrack:

[admin@MikroTik] >
Копировать
/ip/firewall/raw
add chain=prerouting in-interface=ether1 src-address-list=bogons action=drop
add chain=prerouting in-interface=ether1 src-address-list=attackers action=drop

Решение 4: Notrack для доверенного трафика:

[admin@MikroTik] >
Копировать
/ip/firewall/raw
add chain=prerouting src-address=10.0.0.0/24 dst-address=10.0.1.0/24 \
    action=notrack comment="Skip conntrack for trusted inter-VLAN"

Connection Tracking и FastTrack

FastTrack — механизм ускорения обработки пакетов, тесно связанный с conntrack. Когда соединение маркируется как FastTrack, его пакеты обходят большинство правил firewall, mangle и queue, проходя по сокращённому пути.

Как FastTrack работает с conntrack

1. Пакет проходит через conntrack и определяется как established или related
2. Правило FastTrack маркирует соединение
3. Последующие пакеты этого соединения обходят firewall/mangle/queue
4. Conntrack продолжает отслеживать соединение (обновляет таймеры, счётчики)

[admin@MikroTik] >
Копировать
/ip/firewall/filter
add chain=forward connection-state=established,related action=fasttrack-connection \
    comment="FastTrack established/related"
add chain=forward connection-state=established,related action=accept \
    comment="Accept established/related"

FastTrack + Conntrack: что важно знать

• FastTrack требует Connection Tracking (без conntrack нет состояний)
• FastTrack-соединения не проходят через mangle и queue → невозможно QoS
• FastTrack снижает нагрузку CPU на 30–50% для транзитного трафика
• Счётчики firewall не обновляются для FastTrack-пакетов

[admin@MikroTik] >
Копировать
# Проверка FastTrack-соединений
/ip/firewall/connection/print where fasttrack=yes

NAT и Connection Tracking

NAT (Network Address Translation) полностью зависит от Connection Tracking. Без conntrack NAT невозможен.

Почему NAT требует conntrack

Когда пакет проходит через srcnat (masquerade), conntrack запоминает:

• Оригинальный source IP:port
• Транслированный source IP:port
• Destination IP:port

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

Следствие: если вы используете action=notrack в RAW для трафика, проходящего через NAT, NAT перестанет работать.

[admin@MikroTik] >
Копировать
# НЕПРАВИЛЬНО — notrack ломает NAT для WAN-трафика
/ip/firewall/raw
add chain=prerouting in-interface=ether1 action=notrack

# ПРАВИЛЬНО — notrack только для внутреннего трафика без NAT
/ip/firewall/raw
add chain=prerouting src-address=192.168.1.0/24 dst-address=192.168.2.0/24 \
    action=notrack

Notrack: использование и ограничения

Действие notrack в таблице RAW исключает пакеты из Connection Tracking. Это мощный инструмент оптимизации, но с серьёзными ограничениями.

Когда использовать notrack

1. Высоконагруженный транзитный трафик между доверенными сетями
2. DNS-серверы с огромным количеством запросов (каждый DNS-запрос создаёт conntrack-запись)
3. Мониторинг/SNMP трафик между серверами

[admin@MikroTik] >
Копировать
/ip/firewall/raw
# Notrack для DNS-сервера (если он не за NAT)
add chain=prerouting dst-address=10.0.0.53 dst-port=53 protocol=udp \
    action=notrack comment="Notrack DNS server traffic"
add chain=output dst-address=10.0.0.53 dst-port=53 protocol=udp \
    action=notrack comment="Notrack DNS from router"

Ограничения notrack

• NAT не работает для untracked-трафика
• В Filter такой трафик имеет connection-state=untracked — нужно явно разрешить
• FastTrack не работает с untracked (FastTrack требует established)
• Connection-based rate limiting не работает

[admin@MikroTik] >
Копировать
# Не забудьте разрешить untracked в Filter!
/ip/firewall/filter
add chain=forward connection-state=untracked action=accept \
    comment="Accept untracked traffic from RAW notrack"

Мониторинг

Текущее состояние conntrack

[admin@MikroTik] >
Копировать
# Общая статистика
/ip/firewall/connection/tracking/print

# Количество активных соединений
/ip/firewall/connection/print count-only

# Соединения конкретного хоста
/ip/firewall/connection/print where src-address=192.168.88.100

# Соединения по конкретному порту
/ip/firewall/connection/print where dst-port=443

# TCP-соединения в состоянии established
/ip/firewall/connection/print where protocol=tcp tcp-state=established

Мониторинг через SNMP/Prometheus

Для долгосрочного мониторинга рекомендуется собирать метрики:

[admin@MikroTik] >
Копировать
# Скрипт для записи количества соединений в комментарий (для мониторинга)
/system/script
add name=conntrack-monitor source={
    :local count [/ip/firewall/connection/print count-only]
    :local max [/ip/firewall/connection/tracking/get max-entries]
    :local pct (($count * 100) / $max)
    :if ($pct > 80) do={
        :log warning "Conntrack usage: $pct% ($count/$max)"
    }
}

/system/scheduler
add name=conntrack-check interval=5m on-event=conntrack-monitor

Очистка таблицы соединений

В экстренной ситуации можно очистить conntrack-таблицу:

[admin@MikroTik] >
Копировать
# Удалить все соединения (ОСТОРОЖНО — разорвёт все текущие сессии!)
/ip/firewall/connection/remove [find]

# Удалить соединения конкретного хоста
/ip/firewall/connection/remove [find where src-address=192.168.88.100]

# Удалить только TCP-соединения в состоянии time-wait
/ip/firewall/connection/remove [find where tcp-state=time-wait]

Проверка

Тест: проверяем что conntrack работает

[admin@MikroTik] >
Копировать
# Создаём тестовое соединение (ping на 8.8.8.8)
/ping 8.8.8.8 count=3

# Проверяем запись в conntrack
/ip/firewall/connection/print where dst-address=8.8.8.8

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

Тест: проверяем таймауты

[admin@MikroTik] >
Копировать
# Установим короткий UDP-таймаут для теста
/ip/firewall/connection/tracking/set udp-timeout=5s

# Отправим один UDP-пакет (DNS-запрос)
/tool/dns-query name=example.com server=8.8.8.8

# Сразу проверяем — запись должна быть
/ip/firewall/connection/print where dst-address=8.8.8.8 protocol=udp

# Подождём 10 секунд и проверим снова — запись должна исчезнуть
:delay 10s
/ip/firewall/connection/print where dst-address=8.8.8.8 protocol=udp

Тест: проверяем FastTrack

[admin@MikroTik] >
Копировать
# Проверяем наличие FastTrack-правила
/ip/firewall/filter/print where action=fasttrack-connection

# Проверяем FastTrack-соединения
/ip/firewall/connection/print where fasttrack=yes count-only

Типичные ошибки

Ошибка 1: tcp-established-timeout слишком большой

По умолчанию tcp-established-timeout=1d (24 часа). Для домашнего роутера это приемлемо, но для провайдерского маршрутизатора с тысячами клиентов каждое неактивное TCP-соединение будет занимать запись в таблице целые сутки.

Симптом: conntrack-таблица постоянно заполнена на 80%+, хотя реальная нагрузка умеренная.

Решение:

[admin@MikroTik] >
Копировать
# Для ISP: 2-4 часа вместо 24
/ip/firewall/connection/tracking/set tcp-established-timeout=2h

Ошибка 2: tcp-established-timeout слишком маленький

Если установить tcp-established-timeout=5m, то долгоживущие соединения (SSH, RDP, базы данных) будут разрываться при паузах более 5 минут.

Симптом: SSH-сессии отваливаются после нескольких минут бездействия, long-polling WebSocket перестаёт работать.

Решение: найдите баланс. Для большинства сетей оптимально 1–4 часа. SSH-клиенты можно настроить на отправку keepalive-пакетов.

Ошибка 3: Отключение conntrack

Некоторые администраторы отключают Connection Tracking для «максимальной производительности»:

[admin@MikroTik] >
Копировать
# ОПАСНО!
/ip/firewall/connection/tracking/set enabled=no

Последствия:

• Firewall rules с connection-state перестают работать
• NAT полностью перестаёт работать
• FastTrack перестаёт работать
• Невозможно различить новые и established соединения

Решение: не отключайте conntrack. Вместо этого оптимизируйте таймауты и используйте notrack для конкретного трафика.

Ошибка 4: Забытые connection-state=invalid

Многие конфигурации firewall не содержат правила для invalid-пакетов:

[admin@MikroTik] >
Копировать
# НЕПОЛНАЯ конфигурация — нет обработки invalid
/ip/firewall/filter
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=new action=accept  # слишком свободно!

Invalid-пакеты могут быть результатом сканирования, атак или багов. Их нужно отбрасывать:

[admin@MikroTik] >
Копировать
/ip/firewall/filter
add chain=forward connection-state=invalid action=drop comment="Drop invalid"
add chain=forward connection-state=established,related action=fasttrack-connection
add chain=forward connection-state=established,related action=accept

Ошибка 5: Не учитывается conntrack при миграции с Router OS 6 на 7

В RouterOS 7 изменился синтаксис управления conntrack. Старые команды:

[admin@MikroTik] >
Копировать
# RouterOS 6 (УСТАРЕВШИЙ СИНТАКСИС)
/ip firewall connection tracking set enabled=yes

Новый синтаксис:

[admin@MikroTik] >
Копировать
# RouterOS 7.20+
/ip/firewall/connection/tracking/set enabled=yes

При миграции убедитесь, что все скрипты, использующие conntrack-команды, обновлены.

Ошибка 6: Игнорирование conntrack при настройке VPN

VPN-протоколы (IPsec, WireGuard, L2TP) создают дополнительные conntrack-записи. Один VPN-клиент генерирует минимум 2 записи (encapsulated + inner), а при активном использовании — десятки.

Для VPN-серверов с большим количеством клиентов обязательно увеличьте max-entries:

[admin@MikroTik] >
Копировать
# 200 VPN-клиентов × ~50 соединений каждый = 10000 записей только для VPN
/ip/firewall/connection/tracking/set max-entries=65536

Заключение

Connection Tracking — это сердце stateful firewall в MikroTik RouterOS. Правильная настройка conntrack включает:

• Оптимизацию таймаутов под вашу нагрузку (ISP vs домашний роутер)
• Мониторинг заполненности conntrack-таблицы
• Использование RAW + notrack для разгрузки conntrack
• FastTrack для ускорения established-трафика
• Обязательный drop invalid-пакетов
• Расчёт max-entries с учётом NAT, VPN и реального количества клиентов

/ip/firewall/connection/tracking/print
/ip/firewall/connection/tracking/set \
    enabled=yes \
    tcp-syn-sent-timeout=5s \
    tcp-syn-received-timeout=5s \
    tcp-established-timeout=1d \
    tcp-fin-wait-timeout=10s \
    tcp-close-wait-timeout=10s \
    tcp-last-ack-timeout=10s \
    tcp-time-wait-timeout=10s \
    tcp-close-timeout=10s \
    tcp-max-retrans-timeout=5m \
    tcp-unacked-timeout=5m \
    udp-timeout=10s \
    udp-stream-timeout=3m \
    icmp-timeout=10s \
    generic-timeout=10m \
    max-entries=32768 \
    loose-tcp-tracking=yes
/ip/firewall/connection/tracking/set tcp-established-timeout=4h
/ip/firewall/connection/tracking/set udp-stream-timeout=5m
# Просмотр текущего количества соединений
/ip/firewall/connection/print count-only

# Просмотр максимума и текущего использования
/ip/firewall/connection/tracking/print
/ip/firewall/connection/tracking/set \
    max-entries=262144 \
    tcp-established-timeout=2h \
    tcp-syn-sent-timeout=3s \
    tcp-syn-received-timeout=3s \
    tcp-fin-wait-timeout=5s \
    tcp-close-wait-timeout=5s \
    tcp-time-wait-timeout=5s \
    tcp-close-timeout=5s \
    udp-timeout=10s \
    udp-stream-timeout=2m \
    generic-timeout=5m
# Включение строгого режима (рекомендуется при симметричной маршрутизации)
/ip/firewall/connection/tracking/set loose-tcp-tracking=no
# Текущее количество соединений
/ip/firewall/connection/print count-only

# Сравниваем с максимумом
/ip/firewall/connection/tracking/print

# Анализ по протоколам
/ip/firewall/connection/print where protocol=tcp count-only
/ip/firewall/connection/print where protocol=udp count-only

# Поиск IP с наибольшим количеством соединений
/ip/firewall/connection/print where src-address~"^192.168" \
    file=conntrack-dump
/ip/firewall/connection/tracking/set max-entries=65536
/ip/firewall/connection/tracking/set \
    tcp-established-timeout=4h \
    tcp-syn-sent-timeout=3s \
    udp-timeout=10s \
    generic-timeout=5m
/ip/firewall/raw
add chain=prerouting in-interface=ether1 src-address-list=bogons action=drop
add chain=prerouting in-interface=ether1 src-address-list=attackers action=drop
/ip/firewall/raw
add chain=prerouting src-address=10.0.0.0/24 dst-address=10.0.1.0/24 \
    action=notrack comment="Skip conntrack for trusted inter-VLAN"
/ip/firewall/filter
add chain=forward connection-state=established,related action=fasttrack-connection \
    comment="FastTrack established/related"
add chain=forward connection-state=established,related action=accept \
    comment="Accept established/related"
# Проверка FastTrack-соединений
/ip/firewall/connection/print where fasttrack=yes
# НЕПРАВИЛЬНО — notrack ломает NAT для WAN-трафика
/ip/firewall/raw
add chain=prerouting in-interface=ether1 action=notrack

# ПРАВИЛЬНО — notrack только для внутреннего трафика без NAT
/ip/firewall/raw
add chain=prerouting src-address=192.168.1.0/24 dst-address=192.168.2.0/24 \
    action=notrack
/ip/firewall/raw
# Notrack для DNS-сервера (если он не за NAT)
add chain=prerouting dst-address=10.0.0.53 dst-port=53 protocol=udp \
    action=notrack comment="Notrack DNS server traffic"
add chain=output dst-address=10.0.0.53 dst-port=53 protocol=udp \
    action=notrack comment="Notrack DNS from router"
# Не забудьте разрешить untracked в Filter!
/ip/firewall/filter
add chain=forward connection-state=untracked action=accept \
    comment="Accept untracked traffic from RAW notrack"
# Общая статистика
/ip/firewall/connection/tracking/print

# Количество активных соединений
/ip/firewall/connection/print count-only

# Соединения конкретного хоста
/ip/firewall/connection/print where src-address=192.168.88.100

# Соединения по конкретному порту
/ip/firewall/connection/print where dst-port=443

# TCP-соединения в состоянии established
/ip/firewall/connection/print where protocol=tcp tcp-state=established
# Скрипт для записи количества соединений в комментарий (для мониторинга)
/system/script
add name=conntrack-monitor source={
    :local count [/ip/firewall/connection/print count-only]
    :local max [/ip/firewall/connection/tracking/get max-entries]
    :local pct (($count * 100) / $max)
    :if ($pct > 80) do={
        :log warning "Conntrack usage: $pct% ($count/$max)"
    }
}

/system/scheduler
add name=conntrack-check interval=5m on-event=conntrack-monitor
# Удалить все соединения (ОСТОРОЖНО — разорвёт все текущие сессии!)
/ip/firewall/connection/remove [find]

# Удалить соединения конкретного хоста
/ip/firewall/connection/remove [find where src-address=192.168.88.100]

# Удалить только TCP-соединения в состоянии time-wait
/ip/firewall/connection/remove [find where tcp-state=time-wait]
# Создаём тестовое соединение (ping на 8.8.8.8)
/ping 8.8.8.8 count=3

# Проверяем запись в conntrack
/ip/firewall/connection/print where dst-address=8.8.8.8
# Установим короткий UDP-таймаут для теста
/ip/firewall/connection/tracking/set udp-timeout=5s

# Отправим один UDP-пакет (DNS-запрос)
/tool/dns-query name=example.com server=8.8.8.8

# Сразу проверяем — запись должна быть
/ip/firewall/connection/print where dst-address=8.8.8.8 protocol=udp

# Подождём 10 секунд и проверим снова — запись должна исчезнуть
:delay 10s
/ip/firewall/connection/print where dst-address=8.8.8.8 protocol=udp
# Проверяем наличие FastTrack-правила
/ip/firewall/filter/print where action=fasttrack-connection

# Проверяем FastTrack-соединения
/ip/firewall/connection/print where fasttrack=yes count-only
# Для ISP: 2-4 часа вместо 24
/ip/firewall/connection/tracking/set tcp-established-timeout=2h
# ОПАСНО!
/ip/firewall/connection/tracking/set enabled=no
# НЕПОЛНАЯ конфигурация — нет обработки invalid
/ip/firewall/filter
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=new action=accept  # слишком свободно!
/ip/firewall/filter
add chain=forward connection-state=invalid action=drop comment="Drop invalid"
add chain=forward connection-state=established,related action=fasttrack-connection
add chain=forward connection-state=established,related action=accept
# RouterOS 6 (УСТАРЕВШИЙ СИНТАКСИС)
/ip firewall connection tracking set enabled=yes
# RouterOS 7.20+
/ip/firewall/connection/tracking/set enabled=yes
# 200 VPN-клиентов × ~50 соединений каждый = 10000 записей только для VPN
/ip/firewall/connection/tracking/set max-entries=65536