👁 Conntrack в Linux: как stateful firewall может стать узким местом

Когда на linux работает NAT или stateful firewall, почти всегда где-то рядом есть conntrack. Conntrack - это механизм ядра, который отслеживает сетевые соединения. Он нужен, чтобы firewall понимал не только отдельный пакет, но и его состояние:

• это новое соединение;
• это ответ на уже разрешенное соединение;
• это часть существующей сессии;
• это странный или неожиданный пакет.

Именно поэтому в iptables/nftables часто встречается логика:


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

или в nftables:


ct state established,related accept

Смысл простой: если соединение уже разрешено, ответы по нему пропускаем автоматически. Без conntrack не было бы привычного NAT, нормального stateful firewall и многих схем с masquerade. Но у conntrack есть цена. Каждое отслеживаемое соединение попадает в таблицу conntrack. Если соединений много, таблица растет. Если таблица переполнена, начинаются неприятности.

▪️ Типичные симптомы:

• новые подключения отваливаются;
• NAT начинает работать нестабильно;
• часть клиентов не может открыть сайт;
• DNS-запросы теряются;
• в логах появляются сообщения про переполнение conntrack;
• снаружи кажется, что "сеть иногда моргает".

▪️ Проверить текущий лимит:


sysctl net.netfilter.nf_conntrack_max

Посмотреть текущее количество записей:


cat /proc/sys/net/netfilter/nf_conntrack_count

Если значение nf_conntrack_count регулярно подходит к nf_conntrack_max, система близка к проблемам.

Еще можно посмотреть события в kernel log:


dmesg | grep -i conntrack

Типичная ошибка: nf_conntrack: table full, dropping packet. Это уже прямой сигнал: таблица заполнена, новые пакеты начинают отбрасываться.

▪️ Посмотреть записи conntrack можно так:


conntrack -L

Но на нагруженных серверах с этим осторожно: вывод может быть огромным. Для общей статистики лучше:


conntrack -S

Где conntrack часто становится узким местом:

• NAT-шлюзы
• Kubernetes-ноды
• Docker-хосты
• DNS-рекурсоры
• reverse proxy под большой нагрузкой
• серверы с большим количеством коротких соединений

▪️ Самый очевидный способ лечения - это увеличить лимит:


sysctl -w net.netfilter.nf_conntrack_max=262144

Для постоянной настройки:


echo "net.netfilter.nf_conntrack_max=262144" > /etc/sysctl.d/99-conntrack.conf
sysctl --system

Но просто поднять лимит не всегда решение. Нужно понимать, почему таблица растет: слишком много коротких соединений, DDoS или сканирование, долгие таймауты или что-то другое. Иногда помогает настройка timeout’ов. Например, для TCP established:


sysctl net.netfilter.nf_conntrack_tcp_timeout_established

Для UDP:


sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream

Но менять таймауты нужно аккуратно. Слишком короткие значения могут ломать нормальные долгоживущие соединения.

#linux #network #conntrack

🧑‍💻 NetworkAdmin