Перейти к содержанию

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

Брандмауэр с состояниями учитывает не только IP и порт, но и контекст сетевого соединения. В iptables это реализуется через механизм ядра conntrack и модуль -m conntrack. Понимание состояний критично для НАЙС.ОС CLOUD с политикой OUTPUT DROP: иначе легко разрешить входящий SSH и случайно запретить серверу отправить ответ.

Основные состояния

Состояние Смысл Типичное назначение
NEW Новый поток с точки зрения conntrack Разрешить начало подключения только к нужному сервису
ESTABLISHED Связь уже отслеживается, передаются пакеты Разрешить ответы на легитимные соединения
RELATED Связанный поток или сообщение об ошибке Служебные ответы, отдельные сложные протоколы
INVALID Невозможно корректно классифицировать Требует анализа, часто отбрасывается согласно политике

ESTABLISHED в conntrack — не эквивалент статуса TCP ESTABLISHED: отслеживаются также UDP и некоторые другие протоколы.

Почему важен OUTPUT

Типичная ошибка: администратор разрешает INPUT tcp dpt:22, но удаляет исходящее ESTABLISHED,RELATED из OUTPUT. В результате SYN достигает sshd, а ответ не проходит фильтрацию. Вход «снаружи» не работает, хотя правило на порт 22 видно.

Для ориентира (не готовая замена всему firewall):

iptables -S INPUT
iptables -S OUTPUT
iptables -S FORWARD
iptables -L INPUT -n -v --line-numbers
iptables -L OUTPUT -n -v --line-numbers

Типовое правило возвратного трафика использует:

-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Оно должно быть предусмотрено в соответствующей цепочке с учётом направления. Конкретный порядок выбирают после просмотра действующих правил.

Особенности UDP

UDP не имеет TCP-рукопожатия, но conntrack поддерживает временные записи для наблюдаемых потоков. При DROP OUTPUT внешний DNS-запрос не пройдёт только потому, что INPUT допускает ответы. Необходимо разрешить сам исходящий запрос к доверенному DNS-серверу и обратный связанный трафик.

При диагностике DNS отделяйте:

resolvectl status
resolvectl query niceos.ru
iptables -L OUTPUT -n -v --line-numbers
iptables -L INPUT -n -v --line-numbers

Транспорт может быть UDP или TCP, а DNS-over-TLS использует иной порт/механизм. Не открывайте «всё подряд» ради временного результата.

Как расследовать сбой

  1. Убедитесь, что служба слушает нужный адрес (ss -lntup).
  2. Проверьте маршрут входящего клиента и обратный маршрут (ip route get).
  3. Посмотрите счётчики INPUT и OUTPUT.
  4. При наличии conntrack проверьте таблицу состояний (инструмент может не входить в минимальный образ).
  5. Если есть Docker, учитывайте отдельную цепочку FORWARD и NAT.
  6. Для IPv6 выполните аналогичную проверку через ip6tables.

Осторожно с очисткой conntrack

Удаление conntrack-состояний может разорвать активные соединения (VPN, SSH, баз данных, Docker). Команды сброса таблицы не рекомендуются как базовая диагностика. Сначала зафиксируйте конкретный неисправный поток и используйте целевой подход в период обслуживания.

Источники: Core/iptables/SPECS/iptables.spec, Netfilter conntrack.