Connection state в MikroTik назначается пакету относительно записи connection tracking. Firewall различает new, established, related, invalid и untracked и использует эти состояния для ранней обработки трафика.

Правило drop invalid обычно полезно, но при асимметричной маршрутизации корректные пакеты могут выглядеть invalid. Перед применением проверьте обратный путь и особенности вашей топологии.

• new — инициирующий пакет нового соединения
• established — пакет, принадлежащий уже установленному соединению
• related — пакет, связанный с существующим соединением, но инициирующий новое
• untracked — пакет, прошедший мимо механизма отслеживания соединений
• invalid — пакет, который не удалось корректно классифицировать

UNTRACKED: когда пакет не попадает в таблицу соединений

Состояние untracked присваивается пакетам, которые не проходят через connection tracker. Это происходит в двух случаях:

1. Connection tracking отключен глобально – тогда все пакеты помечаются как untracked.
2. В цепочке raw фаервола применено правило action=notrack, которое явно исключает определённый трафик из отслеживания.

Важно: пакеты в состоянии untracked не подвергаются NAT и не могут фильтроваться по параметрам, зависящим от соединения (connection-*). Однако все остальные правила фаервола к ним применяются.

Использование notrack — это распространённый метод оптимизации производительности MikroTik, особенно в сетях с высокой нагрузкой (например, при передаче большого объема backup-трафика или трафика между доверенными зонами). Это снижает загрузку CPU, поскольку connection tracking — ресурсоёмкая операция.

ESTABLISHED: пакеты уже установленных соединений

Состояние established присваивается пакетам, входящим в уже существующее соединение. Для TCP/UDP соединения проверяются пять параметров («пять кортежей»):

• IP-адрес источника и назначения
• Порты источника и назначения
• Протокол

Для других протоколов (например, ICMP или GRE) проверяются только три параметра: два IP-адреса и тип протокола.

Рекомендация: правило с connection-state=established стоит размещать в начале цепочек, чтобы ускорить обработку и снизить нагрузку на роутер. В большинстве случаев такой трафик безопасен и должен быть разрешён.

NEW: начало нового соединения

Пакет с состоянием new — это первый пакет в новом соединении, на основании которого connection tracker создаёт запись в таблице.

Особенности по протоколам:

• TCP: пакет считается new, только если он содержит флаг SYN и не содержит других флагов (например, ACK). Именно такой пакет инициирует TCP-сессию.
• ICMP: new — это всегда Echo Request (Type=8, Code=0). Ответ (Echo Reply) будет established.
• GRE: используется, например, в PPTP-туннелях. Connection tracker сопоставляет GRE-пакеты по Call ID, ассоциируя их с управляющим TCP-соединением PPTP.

Пример практического применения:
Разрешить инициацию соединений только из VLAN 100 (управляющая сеть) в VLAN 200 (серверная), но не наоборот:

/ip firewall filter
add action=accept chain=forward connection-state=established
add action=accept chain=forward connection-state=new in-interface=ether1.100 out-interface=ether1.200
add action=drop chain=forward

Такой подход — основа асимметричной сетевой безопасности, часто используемой на курсах по MikroTik.

INVALID: когда пакет «не вписывается» в логику соединений

Состояние invalid присваивается пакетам, которые:

• Приходят без предшествующего new, но выглядят как часть соединения (например, TCP-пакет с флагом ACK, при этом самого соединения нет в таблице).
• Не могут быть обработаны из-за переполнения таблицы соединений (например, нехватка памяти в RouterOS).
• Являются артефактами асимметричной маршрутизации (например, в BGP-сетях).

Обычно такие пакеты следует блокировать. Однако в редких случаях (например, устаревшие приложения вроде IIS + 1С) может потребоваться разрешить invalid-трафик для корректного завершения соединений.

RELATED: «дочерние» соединения

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

Примеры:

1. ICMP-ошибки (например, «Destination Unreachable»): внутри ICMP-пакета содержится заголовок оригинального IP-пакета. Connection tracker распознаёт, к какому соединению он относится, и помечает ICMP как related.
2. Протоколы с динамическими портами: некоторые протоколы устанавливают управляющее соединение, а затем инициируют дополнительные сессии на других портах. Чтобы фаервол мог корректно отслеживать такие «вторичные» соединения, используются специальные модули, известные как NAT helpers или ALG (Application Layer Gateway). В MikroTik RouterOS эти функции реализованы через раздел /ip/firewall/service-port. Каждая запись в этом разделе (например, name="ftp", name="sip" и т.д.) активирует встроенный conntrack-модуль, который анализирует управляющий трафик и помогает ядру отслеживать связанные потоки данных, помечая их как related. Например, FTP в активном режиме: клиент подключается к порту 21, а сервер инициирует отдельное TCP-соединение к клиенту на динамический порт данных. Запись name="ftp" в /ip/firewall/service-port включает соответствующий NAT helper, и RouterOS заранее знает о таком соединении, помечая его как related. Аналогично работают и другие встроенные помощники — для TFTP (порт 69), SIP (порты 5060/5061), H.323, PPTP, UDPlite, DCCP, SCTP, а также (в некоторых версиях) IRC и RTSP. Все они реализованы как ALG-модули и управляются именно через /ip/firewall/service-port.

Поэтому правило connection-state=related рекомендуется размещать сразу после или вместе с established, иначе такие пакеты будут отброшены фаерволом.

Список NAT helpers (conntrack ALG-модулей) из MikroTik RouterOS и соответствующие файлы исходного кода в официальном репозитории ядра Linux (kernel.org):

• FTP
  • nf_conntrack_ftp.c
  • nf_nat_ftp.c
• TFTP
  • nf_conntrack_tftp.c
• IRC
  • nf_conntrack_irc.c
  • nf_nat_irc.c
• SIP
  • nf_conntrack_sip.c
  • nf_nat_sip.c
• H.323
  • nf_conntrack_h323_main.c
  • nf_nat_h323.c
• PPTP
  • nf_conntrack_pptp.c
  • nf_nat_pptp.c
• DCCP
  • nf_conntrack_proto_dccp.c
• SCTP
  • nf_conntrack_proto_sctp.c
• UDPLite
  • nf_conntrack_proto_udplite.c

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

Заключение

Изучение работы connection-state помогает не только правильно фильтровать трафик, но и оптимизировать производительность роутера, избегать ошибок NAT и устранять сложные сетевые проблемы.

Полезные ссылки (для углублённого изучения)

• nf_conntrack_core.c — ядро connection tracking в Linux
• nf_conntrack_proto_tcp.c — обработка TCP
• nf_conntrack_proto_icmp.c — обработка ICMP
• nf_conntrack_proto_gre.c — обработка GRE
• Официальная документация nftables по connection tracking

---

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

Как проверить результат

• Откройте одно TCP-соединение и найдите его в connection table.
• Сверьте счётчики established/related и invalid rules.
• Проверьте поведение при асимметричном пути или временно исключите такой трафик из теста.

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

• Connection tracking
• Все статьи
• Аудит MikroTik
• Настройка MikroTik

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