Классическая ситуация: приложение "висит", соединения отваливаются по таймауту, а в логах самого сервиса - тишина. Ты лезешь в код, в базу, в нагрузку на диск - и ничего. А виновата сеть. Точнее, не провод и не свитч, а то, что происходит с пакетом внутри ядра Linux: его может тихо съесть фаервол, может не хватить места в таблице соединений, или пакет не пролезает по размеру и фрагментируется. Самое подлое тут - дропы (drop, отброшенные пакеты) почти всегда молчаливые. Никто тебе не напишет в лог "я выкинул твой SYN". Просто клиент будет ретраить и упираться в таймаут.
Этот урок - про базовую сетевую диагностику без погружения в дебри netfilter. Разберём три самых частых источника боли на шлюзах, прокси и обычных серверах: фаервол (nftables и iptables), таблицу отслеживания соединений conntrack linux, и счётчики дропов. Новичку важно понять одно: прежде чем чинить, надо доказать, что теряются именно пакеты, и найти место потери. Гадать тут нельзя - в сети слишком много слоёв, и наугад ты будешь крутить не те ручки.
Как пакет идёт через ядро и где его теряют
Представь конвейер. Пакет приходит на сетевую карту, попадает в кольцевой буфер (ring buffer) и очередь ядра, проходит через netfilter (это и есть фаервол - набор правил nftables или iptables), по пути ядро отмечает его в таблице соединений conntrack, и только потом он доходит до сокета приложения. На каждом этапе пакет может быть потерян, и для каждого этапа есть свой счётчик.
- Буфер карты/очередь переполнены - приложение или ядро не успевают разгребать. Видно в drop на интерфейсе.
- Правило фаервола явно дропает пакет. Видно по счётчику конкретного правила.
- Таблица conntrack заполнена - новые соединения некуда записать. Видно в dmesg и в статистике conntrack.
- Очередь сокета (backlog) переполнена - приложение принимает слишком медленно. Видно по overflow в статистике TCP.
- MTU и фрагментация - пакет слишком большой для пути, его режут или отбрасывают. Видно по таймаутам на больших передачах при живых пингах.
Практика: смотрим правила, conntrack и счётчики
Шаг 1. Что вообще дропает фаервол. На современных дистрибутивах с systemd (включая Astra Linux и RED OS) бэкенд по умолчанию - nftables, а iptables там обычно лишь обёртка iptables-nft поверх него. Сначала смотрим правила целиком:
Код: Выделить всё
sudo nft list rulesetКод: Выделить всё
sudo nft -a list rulesetКод: Выделить всё
counter packets 8841 bytes 530112Код: Выделить всё
watch -n 2 "nft list ruleset | grep -A1 drop"Код: Выделить всё
sudo iptables -L -n -vКод: Выделить всё
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1532 92K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
8841 530K DROP all -- eth0 * 10.0.0.0/8 0.0.0.0/0Шаг 2. Таблица соединений. Сначала самое важное - заполненность. Это первое, что надо проверять при странных дропах под нагрузкой:
Код: Выделить всё
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxКод: Выделить всё
/proc/sys/net/netfilter/Код: Выделить всё
sudo conntrack -SКод: Выделить всё
sudo conntrack -LКод: Выделить всё
tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=93.184.216.34 sport=51614 dport=443 src=93.184.216.34 dst=10.0.0.5 sport=443 dport=51614 [ASSURED] mark=0 use=1Код: Выделить всё
sudo conntrack -L | awk "{print \$4}" | sort | uniq -c | sort -rnШаг 3. Счётчики дропов. Дропы на интерфейсе:
Код: Выделить всё
ip -s link show eth0Код: Выделить всё
nstat -az | grep -iE "Retrans|Drop|Overflow|Prune|ListenDrops"Код: Выделить всё
netstat -s | grep -iE "retrans|drop|overflow"Код: Выделить всё
ss -ltnConntrack table full и MTU: две классические засады
Если на шлюзе под нагрузкой рвутся соединения - первым делом ищи в журнале ядра. На systemd это journalctl, но dmesg тоже работает:
Код: Выделить всё
sudo journalctl -k --grep="conntrack"
sudo dmesg | grep -i conntrackКод: Выделить всё
nf_conntrack: table full, dropping packetКод: Выделить всё
sudo sysctl -w net.netfilter.nf_conntrack_max=262144Код: Выделить всё
/etc/sysctl.d/10-conntrack.confКод: Выделить всё
sysctl --systemВторая засада - MTU и фрагментация. MTU это максимальный размер полезной нагрузки на интерфейсе (обычно 1500 байт). Если где-то на пути MTU меньше (VPN/WireGuard, туннель GRE/IPsec, PPPoE), большой пакет либо режется на фрагменты, либо отбрасывается, если выставлен флаг DF ("не фрагментировать"). Симптом коварный: пинг ходит (маленькие пакеты), а SSH-сессия виснет на длинном выводе или большой файл не качается - типичная картина MTU blackhole. Проверка - пинг с запретом фрагментации и ростом размера:
Код: Выделить всё
ping -M do -s 1472 8.8.8.8Типичные грабли и заблуждения
- "В логах сервиса пусто, значит сеть ни при чём". Наоборот. Дроп пакета - это событие ядра, а не приложения. Сервис просто не дождётся данных.
- "REJECT и DROP - одно и то же". Нет. REJECT шлёт отлуп (RST или ICMP unreachable), и клиент сразу понимает отказ. DROP молчит, и клиент висит до таймаута. По симптому "долгие таймауты" часто виноват именно DROP.
- "Подниму nf_conntrack_max побольше и забуду". Это отложит проблему, а не решит. Каждая запись ест память, буфер бакетов сам не растёт, и при реальной утечке соединений ты упрёшься снова.
- "ping проходит - сеть в порядке". ping проверяет только маленькие ICMP-пакеты. MTU, conntrack и TCP-фаервол он не покрывает.
- "Достаточно посмотреть заполненность count/max". Запас может быть, а соединения всё равно теряться из-за гонок вставки - смотри conntrack -S, поля insert_failed и early_drop.
- "netstat - наше всё". На 2026 он устарел; привыкай к nstat, ss и ip -s, они точнее и есть в iproute2 из коробки.
Счётчики говорят "сколько" и "на каком слое", но не всегда "почему именно тут". На 2026 зрелый инструмент для точечной охоты за дропами - eBPF: ядро экспортирует tracepoint skb:kfree_skb с причиной удаления пакета (поле reason появилось в ядре 5.17+ и стало по-настоящему информативным). Готовые утилиты, которые стоит знать: классический dropwatch (показывает место в коде ядра, где умер пакет), pwru от Cilium (трассирует путь конкретного пакета по стеку) и retis от netfilter. Самый быстрый разовый срез - через bpftrace:
Код: Выделить всё
sudo bpftrace -e "tracepoint:skb:kfree_skb { @[args->reason] = count(); }"Мини-лаба: повтори руками прямо сейчас
- Глянь свои правила: или
Код: Выделить всё
sudo nft -a list ruleset. Найди строки с DROP и запомни их счётчики.Код: Выделить всё
sudo iptables -L -n -v - Повтори команду через 10 секунд. Сравни packets/pkts у дроп-правил - что-нибудь растёт?
- Проверь conntrack по двум осям: заполненность и ошибки
Код: Выделить всё
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max.Код: Выделить всё
sudo conntrack -S | grep -E "insert_failed|early_drop|drop" - Посмотри и найди в строках state, sport, dport, флаг [ASSURED].
Код: Выделить всё
sudo conntrack -L | head - Сними дропы интерфейса: и статистику TCP
Код: Выделить всё
ip -s link show.Код: Выделить всё
nstat -az | grep -iE "Retrans|Overflow" - Глянь backlog слушателей: (колонки Recv-Q/Send-Q).
Код: Выделить всё
ss -ltn - Проверь MTU пути: . Подними размер до 1473 и посмотри на разницу.
Код: Выделить всё
ping -M do -s 1472 8.8.8.8
- Чем отличается DROP от REJECT и почему по симптому "долгий таймаут" подозревают именно DROP?
- Какие команды/поля сравнить, чтобы понять, что таблица conntrack близка к переполнению, и почему одной заполненности count/max мало (что добавляет conntrack -S)?
- Какое сообщение в журнале ядра прямо указывает на conntrack table full и что оно означает для новых соединений? Какой нюанс ядра 5.15+ важен при подъёме лимита?
- Почему ping может проходить, а большая передача по TCP - виснуть, и при чём тут MTU и флаг DF?
Сеть рвётся тихо: дропы не пишут в лог приложения, их надо искать по счётчикам. Алгоритм короткий: правила фаервола (nft -a list ruleset / iptables -L -n -v, ищем растущий DROP) - состояние conntrack (count против max плюс conntrack -S на insert_failed/early_drop, journalctl на table full) - счётчики дропов и ретрансмитов (ip -s, nstat, ss) - проверка MTU пингом с запретом фрагментации. Где счётчиков не хватает - eBPF (bpftrace по skb:kfree_skb, dropwatch, pwru). На 2026 привыкай к iproute2-стеку вместо устаревшего netstat. И главное правило: не гадай и не крути лимиты вслепую - сначала докажи место потери цифрами, потом чини причину, а не симптом.
