Stateful firewall: как работают conntrack, established/related и правила доступа
Почему ответ на исходящее соединение проходит обратно без отдельного разрешения каждого порта, чем stateful firewall отличается от обычного ACL, что означают NEW, ESTABLISHED, RELATED и INVALID, как связаны firewall, NAT и VLAN и почему в IPv6 фильтрация важнее привычки полагаться на NAT.
Он решает, какой трафик разрешить, запретить, отклонить или дополнительно обработать.
Ответный пакет можно сопоставить с уже известным flow, а не оценивать как совершенно независимый пакет.
NAT изменяет адреса и порты. Firewall отвечает за разрешение и запрет трафика по правилам.
Что такое firewall
Firewall, или межсетевой экран, применяет правила к сетевому трафику. Он может учитывать интерфейс, направление, IP-адреса, протокол, TCP/UDP-порты, состояние соединения и другие признаки.
В домашнем роутере firewall обычно совмещён с routing, NAT, DHCP, DNS proxy и VPN, поэтому эти функции легко перепутать. Но назначение у них разное.
| Функция | Главный вопрос |
|---|---|
| Routing | Куда отправить пакет дальше? |
| NAT | Нужно ли изменить адрес или порт? |
| Firewall | Разрешён ли этот трафик политикой? |
| DNS | Какие данные соответствуют имени? |
| DHCP | Какие сетевые параметры выдать клиенту? |
Routing подробно разобран в статье про таблицу маршрутизации, а NAT - в материале NAT и PAT: SNAT, DNAT и проброс портов.
Что такое stateless ACL
Stateless filter оценивает каждый пакет по его собственным полям и набору правил, не опираясь на историю предыдущих пакетов flow.
192.168.10.0/24192.168.30.10TCP443Такое правило может разрешать TCP 443 из одной подсети к конкретному серверу. Но само по себе оно не говорит, относится ли очередной пакет к уже начатому соединению или это новая попытка связи.
ACL не обязательно является «простым firewall»
Access Control List - общий механизм правил доступа. На разных платформах ACL может применяться на L2, L3, интерфейсах, VLAN и management plane. Некоторые реализации умеют сложную обработку, но классическое сравнение «stateless ACL vs stateful firewall» полезно для понимания модели состояния.
Что значит stateful firewall
Stateful packet filtering использует таблицу состояния и принимает решение не только по текущему пакету, но и по информации о flow/connection, которую firewall уже видел.
RFC 2647 определяет stateful packet filtering как forwarding или rejection трафика на основе state table, которую поддерживает firewall. Для домашней сети именно эта идея объясняет привычное поведение: клиент открыл HTTPS-сайт, а ответ сервера вернулся без отдельного ручного правила «разрешить входящий ephemeral port».
Что такое connection tracking
Connection tracking, часто сокращённо conntrack, хранит метаданные о наблюдаемых сетевых flows. В Linux Netfilter conntrack используется nftables и другими компонентами для stateful filtering и NAT.
192.168.10.50:53122 → 203.0.113.20:443203.0.113.20:443 → 192.168.10.50:53122TCPESTABLISHEDNetfilter документирует conntrack metadata отдельно: L3/L4 protocol, original/reply direction, source/destination addresses and ports, timeout, state, NAT status и другие признаки.
Очень большое число flows, DDoS, неправильные таймауты или слабое оборудование могут привести к исчерпанию таблицы состояния и проблемам с новыми соединениями.
NEW, ESTABLISHED, RELATED, INVALID и UNTRACKED
| State | Практический смысл в Netfilter conntrack |
|---|---|
NEW | Conntrack видит новый flow, для которого ещё не подтверждён двусторонний обмен. Для TCP типичный пример - начальная часть установления соединения. |
ESTABLISHED | Conntrack видел корректный трафик в обоих направлениях. Для TCP соединение прошло установление. |
RELATED | Новый flow связан с уже существующим connection. Примером могут быть ожидаемые дополнительные соединения или некоторые ICMP errors. |
INVALID | Пакет не соответствует ожидаемому поведению отслеживаемого connection или не может быть корректно классифицирован. |
UNTRACKED | Пакет явно исключён из conntrack. |
Актуальная документация nftables перечисляет именно эти основные conntrack states и показывает типичный stateful pattern: разрешить established,related, а остальные новые потоки обрабатывать отдельными правилами.
Как stateful firewall видит TCP
TCP имеет явное установление соединения и флаги SYN, ACK, FIN, RST, поэтому firewall может довольно подробно отслеживать жизненный цикл flow.
Однако firewall не должен заменять полноценную реализацию TCP endpoint. Он использует достаточно информации, чтобы классифицировать flow и применять policy.
Сам TCP подробно разобран в статье TCP и UDP: порты и сокеты.
Как firewall отслеживает UDP без handshake
UDP не устанавливает соединение как TCP, но stateful firewall всё равно может создавать flow record по адресам, портам и протоколу и ожидать обратный трафик.
Есть явная state machine транспорта, SYN/ACK/FIN/RST.
Firewall опирается на наблюдаемые datagrams, направления и timers.
Поэтому timeout особенно важен для UDP VPN, VoIP, игр и P2P. Если state истёк, поздний ответ может восприниматься как новый или неожиданный трафик.
Почему RELATED не означает «разрешить всё похожее»
RELATED - техническое состояние conntrack. Оно применяется, когда новый flow ожидаемо связан с уже отслеживаемым connection.
Исторический пример - FTP helper: управляющее соединение согласует отдельный data connection, и helper может создать expectation, благодаря которому новый поток классифицируется как related.
Другой важный пример - ICMP/ICMPv6 error, который относится к существующему flow. Firewall должен корректно пропускать необходимые ошибки, иначе диагностика и Path MTU могут ломаться.
Современные правила не должны автоматически доверять любому helper-трафику. На конкретной платформе проверяют, какие helpers вообще активны и зачем они нужны.
Input, Forward и Output - разные пути
Одна из частых ошибок - считать, что «firewall роутера» имеет одно глобальное правило на весь трафик. На самом деле пакет может быть предназначен самому устройству, проходить через него или создаваться самим устройством.
| Логический путь | Пример |
|---|---|
| Input | Клиент открывает web-интерфейс самого роутера |
| Forward | ПК из Main VLAN идёт к NAS в Servers VLAN |
| Output | Сам роутер делает DNS/NTP/VPN-запрос наружу |
Почему порядок правил имеет значение
На большинстве firewall-платформ правила оцениваются в определённом порядке. Широкое правило выше узкого способно сделать нижнее правило бесполезным.
ESTABLISHED, RELATED → ACCEPTMain → NAS TCP 443 → ACCEPTGuest → LAN → DROPостальной FORWARD → DROPЭто только логический пример, а не готовый ruleset для конкретного роутера. У Keenetic, UniFi, MikroTik, OpenWrt, Windows и nftables отличаются интерфейсы, chains и внутренний pipeline.
Shadowed rules
Если более раннее правило уже совпадает со всем трафиком, который мог бы попасть под позднее, позднее правило никогда не сработает. При аудите firewall важно искать такие перекрытия.
Default allow и default deny
Всё разрешено, кроме явно запрещённого. Просто на старте, но легко пропустить нежелательный доступ.
Разрешаются только необходимые связи. Безопаснее и предсказуемее, но требует понимания зависимостей сервисов.
Для Guest, CCTV, IoT и Management сегментов обычно полезнее мыслить от необходимых flows: кто инициатор, куда идёт, какой protocol/port нужен и требуется ли обратное состояние.
DNS, DHCP relay, NTP, mDNS reflector, Home Assistant integrations, cloud APIs, printing, casting и backup могут зависеть от дополнительных flows.
Чем DROP отличается от REJECT
Пакет молча отбрасывается. Клиент обычно ждёт timeout или повторяет попытки.
Firewall явно сообщает, что трафик не принят, например ICMP error или TCP RST в подходящем сценарии.
Что лучше, зависит от политики и протокола. В локальной управляемой сети REJECT часто ускоряет диагностику, потому что клиент сразу получает отрицательный результат. На внешнем периметре политика может быть иной.
Не нужно механически считать DROP «более безопасным»: сокрытие факта существования хоста не является полноценной защитой.
Как stateful firewall связан с NAT
NAT и firewall часто используют одну connection-tracking инфраструктуру. Но translation и filtering остаются разными операциями.
Точный порядок hooks зависит от платформы. Главное для пользователя: наличие NAT mapping не означает автоматического разрешения firewall, а разрешённый firewall flow не обязан использовать NAT.
Port forwarding
DNAT/port forwarding говорит, куда перенаправить входящий трафик. Firewall всё равно должен разрешить соответствующий flow. Именно поэтому на некоторых системах «проброс порта» автоматически создаёт связанное firewall rule, а на других эти шаги настраиваются отдельно.
Подробная схема translation уже есть в статье NAT и PAT.
VLAN разделяет сеть, firewall определяет доступ между сегментами
VLAN создаёт отдельный L2 broadcast domain. Чтобы устройства из разных VLAN общались, трафик должен пройти через L3 routing. Именно на этой границе firewall может разрешить или запретить конкретные flows.
Разделение VLAN подробно разобрано в статье VLAN простыми словами.
Гостевая сеть как простой пример stateful policy
Типичная политика Guest выглядит так:
- разрешить клиенту DHCP/DNS по выбранной архитектуре;
- разрешить инициировать интернет-трафик;
- разрешить обратный ESTABLISHED/RELATED трафик;
- запретить новые соединения к Main, Management, CCTV и Servers;
- при необходимости включить client isolation внутри самого Guest Wi-Fi.
Это пример того, почему одного VLAN недостаточно. VLAN создаёт сегмент, а firewall задаёт реальную политику доступа.
Почему IoT-сеть нельзя просто «закрыть от всего»
Умные устройства могут использовать DNS, NTP, HTTPS cloud APIs, MQTT, mDNS, Matter/Thread border router, Home Assistant и vendor-specific flows. Поэтому безопасная политика начинается с наблюдения и списка реально нужных связей.
IoT → local DNSIoT → allowed NTPIoT ↔ Home Assistant по нужным портамnew IoT → Main = denyДля discovery между VLAN отдельно требуется mDNS reflector/repeater или другая архитектура. Это разобрано в материале mDNS между VLAN.
Управление роутером и коммутатором нужно защищать отдельно
Management plane - web UI, SSH, API, controller adoption и другие административные сервисы - не должен автоматически быть доступен из Guest, CCTV или IoT только потому, что эти VLAN маршрутизируются через тот же gateway.
Ограничьте управление доверенными сегментами, используйте сильную аутентификацию и не публикуйте management interface напрямую в интернет без отдельной обоснованной архитектуры.
IPv6 показывает разницу между NAT и firewall особенно наглядно
В IPv6 домашним устройствам могут назначаться глобально маршрутизируемые адреса без привычного NAPT44. Это не означает, что все входящие соединения должны быть разрешены.
RFC 6092 описывает «simple security» для residential IPv6 gateways: state обычно активируется исходящим трафиком внутренних узлов, ответный matching traffic разрешается, а unsolicited inbound flows могут блокироваться политикой.
Это важный контраргумент против идеи «без NAT нет защиты». Фильтрация может работать независимо от address translation.
Адресация IPv6 разобрана в статье IPv6 дома: SLAAC, DHCPv6, RA и Prefix Delegation.
Почему нельзя просто заблокировать весь ICMP и ICMPv6
ICMP используется не только ping. Он переносит ошибки и управляющую информацию, необходимую для нормальной работы IP.
IPv4
Полная блокировка ICMP может мешать Path MTU Discovery и диагностике. Политика должна учитывать типы сообщений, а не сводиться к «ICMP = ping».
IPv6
ICMPv6 ещё важнее: на нём основаны Neighbor Discovery, Router Solicitation/Advertisement, Packet Too Big и другие критические функции. RFC 6092 отдельно ссылается на рекомендации RFC 4890 по фильтрации ICMPv6.
Подробно тема разобрана в статье ICMP, ping, traceroute, TTL и MTU.
Firewall может ломать базовые сетевые сервисы
После включения строгой межсегментной фильтрации часто первым делом перестают работать DNS, DHCP relay, NTP или management.
| Сервис | Что проверить |
|---|---|
| DNS | Какой resolver используют клиенты, UDP/TCP 53 или encrypted DNS |
| DHCP | Local broadcast или relay, интерфейс DHCP server |
| NTP | К какому серверу разрешён исходящий UDP |
| mDNS | Reflector/repeater плюс реальные service ports |
| VPN | Handshake port, routes и firewall внутри tunnel |
DNS подробно разобран в статье Как работает DNS.
VPN создаёт путь, а firewall всё равно решает, что по нему разрешено
После установления WireGuard, OpenVPN или Tailscale tunnel трафик получает новый логический интерфейс/маршрут. Но сам факт существования туннеля не означает полного доступа ко всем внутренним сегментам.
Знает, как добраться до внутренней подсети через VPN.
Определяет, разрешено ли VPN-клиенту обращаться к NAS, CCTV, Main или Management.
Для удалённого доступа это позволяет выдавать минимум необходимых прав. Практический пример есть в статье Tailscale без белого IP.
Firewall на роутере не отменяет firewall на компьютере или сервере
Perimeter firewall защищает границы сегментов, но угрозы могут находиться внутри той же сети. Host firewall Windows/Linux/macOS ограничивает доступ непосредственно к конкретному endpoint.
Поэтому защита сети строится слоями: segmentation, gateway firewall, host firewall, обновления, authentication и минимальные privileges.
Windows Defender Firewall тоже stateful
Windows использует Windows Filtering Platform и Windows Defender Firewall для host-based filtering. Правила могут учитывать profile, direction, program/service, protocol, ports, addresses и другие условия.
Для диагностики полезно не отключать firewall целиком, а проверить:
- какой network profile активен;
- есть ли inbound rule для нужного приложения;
- слушает ли приложение нужный port;
- не ограничено ли правило конкретной подсетью;
- создано ли правило для IPv4 и IPv6 в нужном сценарии.
Get-NetFirewallProfile
Get-NetFirewallRule -Enabled True
Get-NetTCPConnection -State ListenВременное отключение может быть диагностическим тестом на контролируемом устройстве, но конечное исправление должно быть точным правилом, а не постоянным снятием защиты.
Как stateful filtering выглядит в nftables
В nftables состояние connection доступно через выражения ct state. Типовой принцип выглядит так:
ct state established,related accept
ct state invalid drop
# Новые соединения разрешаются отдельными правилами
# в зависимости от интерфейса, адреса, протокола и порта.Это не готовый production ruleset. У реального router/firewall нужно отдельно учитывать input, forward, output, loopback, ICMP/ICMPv6, DHCP, VPN, management, NAT hooks и правила конкретных VLAN.
Официальная документация nftables показывает именно такой stateful pattern и определяет состояния new, established, related, invalid и untracked.
Как посмотреть таблицу conntrack в Linux
conntrack -LНа router/firewall с установленным conntrack-tools команда показывает отслеживаемые flows и их метаданные. На загруженном шлюзе вывод может быть очень большим.
Что полезно искать
- source/destination address и ports;
- protocol;
- original и reply direction;
- state;
- timeout;
- SNAT/DNAT status;
- подозрительно большое число однотипных entries.
Почему firewall logging нужно включать дозированно
Логирование помогает понять, какое правило сработало, что именно блокируется и откуда приходит трафик. Но логировать каждый пакет опасно для производительности и объёма журналов.
Новые denied flows, неожиданный inter-VLAN traffic, management attempts, troubleshooting rule.
ESTABLISHED traffic, массовые broadcasts, каждую повторную попытку известного scan без rate limit.
Хорошая практика - log prefix/rule ID + counters + rate limit, чтобы событие можно было связать с конкретной policy.
Счётчики часто полезнее самого списка правил
Если у правила ноль packets/bytes, оно либо не совпадает с трафиком, либо до него не доходят из-за более раннего правила. Counters помогают находить shadowed rules и реальную точку принятия решения.
Почему «порт открыт», но сервис всё равно недоступен
Проверка порта должна учитывать всю цепочку:
Сервис слушает порт? Проверить на самом хосте.
Host firewall разрешает? Windows/Linux firewall может блокировать локально.
Есть маршрут? Между source и destination должен существовать корректный L3 path.
Gateway firewall разрешает NEW? ESTABLISHED rule не открывает новые соединения.
Нужен NAT? Для внешнего доступа проверить DNAT/CGNAT, для inter-VLAN NAT обычно не требуется.
Ответ возвращается тем же путём? Асимметричная маршрутизация может ломать stateful filtering.
Почему asymmetric routing может мешать stateful firewall
Если firewall видит только одно направление flow, его state table может не получить ожидаемую reply-часть. Это особенно важно при нескольких WAN, нескольких routers, policy routing и сложных VPN-схемах.
Если outbound packet прошёл через Firewall A, а reply вернулся через Firewall B, один из них может считать трафик неожиданным или invalid.
Поэтому при Multi-WAN и policy routing нужно анализировать не только route до destination, но и обратный path.
Пошаговая диагностика firewall-проблемы
Source IP/VLAN, destination IP, protocol и port.
Слушает ли destination нужный port и работает ли локально.
Пакет вообще идёт через тот firewall, который вы редактируете?
Main, Guest, IoT, VPN, WAN и direction.
Смотреть порядок, counters и logs.
NEW, ESTABLISHED, RELATED, INVALID, timeout и original/reply tuple.
Не смешивать translation и filtering.
На ingress и egress интерфейсах, если проблема остаётся.
Особенно при VPN/Multi-WAN/policy routing.
Не заменять точечное разрешение глобальным allow any.
Что даёт Wireshark или tcpdump
Захват пакетов позволяет отделить четыре разных случая:
Проблема выше по пути: source, route, VLAN, предыдущий firewall.
Проверять local firewall decision, NAT, route и policy.
Проверять destination, remote firewall, обратный route.
Проверять conntrack, reverse path, local firewall и NAT.
Одного «ping не идёт» для таких выводов недостаточно. ICMP может быть разрешён или запрещён отдельно от TCP/UDP.
Типичные ошибки в правилах firewall
- Разрешать
any → anyпосле первой проблемы. - Считать NAT полноценной политикой безопасности.
- Путать input к роутеру и forward через роутер.
- Открывать весь IoT VLAN ради одного Home Assistant flow.
- Блокировать весь ICMP/ICMPv6.
- Игнорировать порядок правил.
- Не смотреть counters и logs.
- Считать ESTABLISHED правилом, разрешающим новые соединения.
- Не учитывать host firewall на сервере.
- Забывать про IPv6, настроив policy только для IPv4.
- Не проверять обратный маршрут при Multi-WAN/VPN.
- Постоянно отключать firewall вместо создания точного правила.
Как строить правила для дома и малого офиса
Какие сегменты, серверы и сервисы реально есть.
Кто должен инициировать соединение и куда.
Ответы разрешаются по ESTABLISHED/RELATED.
Лишние межсегментные связи не разрешаются по умолчанию.
Управление сетью только из доверенной зоны.
Правила должны быть проверяемыми, а не магическими.
Где firewall находится в общей сетевой архитектуре
На что опирается материал
Терминология firewall performance и определение stateful packet filtering.
Рекомендации для stateful filtering в residential IPv6 gateways.
Рекомендации по фильтрации ICMPv6.
Актуальная базовая спецификация TCP.
Conntrack states, stateful expressions, original/reply direction и rule processing.
Основа фильтрации Windows и Windows Defender Firewall.
Частые вопросы про firewall и conntrack
Что такое stateful firewall простыми словами?
Это firewall, который хранит состояние flows и может отличить ответ на уже известное соединение от новой попытки установить связь.
Чем stateful firewall отличается от ACL?
Классический stateless ACL оценивает поля каждого пакета без истории flow. Stateful firewall дополнительно использует connection state.
Что означает ESTABLISHED?
В conntrack это состояние flow, для которого был увиден корректный двусторонний обмен. Для TCP это связано с успешно установленным TCP connection.
Что означает RELATED?
Новый flow или управляющее сообщение связано с уже отслеживаемым connection, например ожидаемый дополнительный flow или подходящий ICMP error.
Что означает INVALID?
Пакет не соответствует ожидаемому connection state или не может быть корректно классифицирован conntrack.
NAT и firewall - одно и то же?
Нет. NAT изменяет addresses/ports, firewall применяет policy разрешения или запрета. Они часто используют общий conntrack, но выполняют разные функции.
Почему ответы из интернета проходят, хотя inbound закрыт?
Потому что stateful firewall видит, что ответ относится к соединению, которое было инициировано изнутри и уже имеет разрешённый state.
Нужно ли разрешать ESTABLISHED/RELATED между VLAN?
Обычно это часть stateful policy, но конкретное правило зависит от архитектуры. Оно разрешает обратный трафик уже разрешённых flows и не должно подменять правила для новых соединений.
Почему нельзя заблокировать весь ICMP?
ICMP и особенно ICMPv6 нужны не только для ping, но и для ошибок, Path MTU и базовых IPv6-механизмов.
Нужен ли firewall при IPv6 без NAT?
Да, если политика сети должна ограничивать unsolicited inbound traffic. Глобальный IPv6 address сам по себе не означает, что host обязан принимать входящие соединения.
Почему firewall может ломать VPN?
Он может блокировать handshake, tunnel traffic или доступ из VPN-интерфейса к внутренним сегментам. Также возможна проблема обратного маршрута.
Что лучше: DROP или REJECT?
Зависит от политики. REJECT быстрее сообщает о запрете и удобен в управляемой LAN, DROP молча отбрасывает packet. Ни один вариант сам по себе не является полной стратегией безопасности.
Можно ли просто выключить firewall для проверки?
Краткий контролируемый тест возможен, но лучше использовать logs, counters, packet capture и точечное временное правило. Постоянно оставлять firewall отключённым не нужно.
Когда правила доступа уже сложнее одной галочки
Если в сети есть Main, Guest, CCTV, IoT, NAS, Home Assistant, VPN и несколько VLAN, правила лучше строить как понятную матрицу flows: кто инициирует соединение, к какому сервису, через какой interface и какой state должен возвращаться обратно.
Для настройки и диагностики сети в Туле и Тульской области можно посмотреть услугу домашней и локальной сети.