Васильев Кирилл

Метка: mtcna

  • Connection state в MikroTik Firewall: 5 состояний

    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):

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

    Заключение

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

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

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

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

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

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

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

  • Скрипт ping для проверки интернета на MikroTik

    Скрипт ping для MikroTik последовательно проверяет несколько адресов через указанную таблицу маршрутизации и завершает поиск после первого успешного ответа. Это простой индикатор ICMP-доступности.

    Успешный ping не подтверждает работу DNS, HTTP или нужного приложения. Для решения о переключении канала добавьте несколько независимых целей, задержки и проверку сервиса более высокого уровня.

    
### ----- start settings script ----- ### 
:local addr [:toarray "8.8.8.8,8.8.4.4,77.88.8.8,77.88.8.1,77.88.8.88,77.88.8.2"];
:local Table "ISP1";
:local CheckPingCount 3;
:local CheckPingTtl 64;
:local CheckPingInterval 1;
### ----- end settings script ----- ###

:local InternetIsset false;
:foreach ipp in $addr do={
    :if ($InternetIsset=false) do={
        :if ([/ping address=$ipp count=$CheckPingCount routing-table=$Table interval=$CheckPingInterval ttl=$CheckPingTtl] = 0) do={
            /log warning message="Internet test fail for address $ipp In table $Table";
        } else={
            /log warning message="Internet test success for $ipp In table $Table";
            :set InternetIsset true;
        }
    }
}

:if ($InternetIsset=false) do={
    #test failed
    /log warning message="Internet fail In table $Table";
}else ={
    #test success
}

    Если вам необходимо выполнять какие-либо действия по результатам проверки, в сам конце скрипта находиться два блока if/else. Первый блок отвечает за выполнение при отрицательном результате, второй блок соответственно за положительный результат.

    Пример как можно использовать блок

    :local ruleCount [/ip route rule print count-only where disabled comment="ether1-fail"]
:if ($InternetIsset=false) do={
 :if($ruleCount=0) do={
   /ip route rule enable [find comment="ether1-fail"];
  }
  /log warning message="Internet fail In table $Table";
} else={
   :if($ruleCount > 0) do={
    /ip route rule disable [find comment="ether1-fail"];
  }
}

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

    • Запустите скрипт вручную и проверьте записи журнала.
    • Заблокируйте одну тестовую цель и убедитесь, что проверка переходит к следующей.
    • Отключите канал и проверьте отрицательный результат именно в заданной routing-table.

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

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