Коротко — последовательность диагностических шагов, инструменты и возможные исправления.
1) Воспроизведение и сбор метрик при пике
- Запустить нагрузочный тест (чтобы повторить потерю пакетов): `iperf3 -c -P -t `; варьировать число потоков и длительность.
- Проверить потерю/задержки от пользователей: `ping`, `mtr` (или `tracepath`) к внешним адресам и до NAT-шлюза.
Инструменты: iperf3, ping, mtr.
2) Мониторинг состояния NAT/маршрутизатора в момент пика
- CPU/Memory: `top` / `htop` / `vmstat` / `dstat`.
- Интерфейсы: `ip -s link show dev eth0`, `ethtool -S eth0`, `ifconfig` — смотреть errors, dropped, overruns.
- Очереди/пакетные дропы: `tc -s qdisc show dev eth0` (проверить drops в qdisc).
Инструменты: top/htop, vmstat, ifstat, sar, ethtool, tc.
3) Проверить таблицу соединений (conntrack / NAT)
- Текущее число трансляций: `conntrack -S` и `conntrack -L | wc -l` (или `cat /proc/net/nf_conntrack`).
- Максимум/порог: `sysctl net.netfilter.nf_conntrack_max` (или `ip_conntrack_max` в старых системах).
- Возможная исчерпаемость портов PAT: максимальное число портов на «публичный» IP = $65535-1024+1=64512$. Если нужно одновременно $N$ соединений, то число публичных IP минимум $\lceil \frac{N}{64512}\rceil$.
- Осмотреть частоту создания/удаления соединений: `conntrack -S` (events/sec).
Инструменты: conntrack-tools, sysctl.
4) Сетевые счётчики и логи
- `netstat -s` или `ss -s` — посмотреть резкий рост retransmits, reset, establish failures.
- `dmesg` и системные логи (`/var/log/syslog`, `/var/log/messages`) на наличие ошибок ядра (oom, nf_conntrack exhausted, NIC driver warnings).
Инструменты: ss, netstat, dmesg, журнал.
5) Пакетный захват для локализации точки падения
- Захват на обеих сторонах NAT (внутри подсети и на внешнем интерфейсе): `tcpdump -i eth0 -s0 -w /tmp/cap_eth0.pcap` и аналогично на внутреннем интерфейсе.
- Отключать TCP/UDP offloading при сборе, чтобы не получить ложные ошибки: `ethtool -K eth0 gro off gso off tso off`.
- Проанализировать pcap в Wireshark/tshark: где теряются сегменты, есть ли RST, retransmits, ICMP unreachable.
Инструменты: tcpdump, tshark, Wireshark, ethtool.
6) Проверить правила NAT/файрвола и их производительность
- Сложность правил iptables/nftables: количество правил, цепочек, использования conntrack в каждом пакете. `iptables -L -v -n`, `nft list ruleset`. Правила с `-m conntrack --ctstate` обходятся быстрее, но очень длинные таблицы повышают CPU.
- Счётчики правил: посмотреть какие правила матчатся чаще (в iptables выводе есть счётчики).
Инструменты: iptables/nft, nftables counters.
7) Диагностика по скорости пакетов (pps) и через сеть
- Узнать pps на интерфейсах: `sar -n DEV` или `ifstat` и `ethtool -S` (некоторые NIC дают pps). Если устройство не выдерживает pps — даже при невысоком Mbps будут потери.
Инструменты: sar, ifstat, bmon, ethtool.
8) Быстрая локализация: где теряются пакеты
- Если пакеты теряются до NAT (на внутреннем сегменте) — смотреть коммутаторы, duplex/MTU mismatch, перегрузку uplink.
- Если теряются после NAT — проблема NAT/шлюза (CPU/conntrack/queue).
- Если только под пиковую нагрузку — вероятнее таблица conntrack/портовая исчерпаемость или CPU/pps лимит.
9) Исправление и рекомендации
- Увеличить `nf_conntrack_max` и соответствующий hashsize при необходимости, но мониторить память.
- Увеличить диапазон исходных портов: `sysctl -w net.ipv4.ip_local_port_range="1024 65535"` (увеличивает доступные порты для PAT).
- Добавить публичные IP и использовать SNAT pool (умножает число доступных портов).
- Снизить время жизни неактивных UDP/ICMP трансляций (conntrack timeouts) для быстрого освобождения слотов.
- Упростить/оптимизировать правила firewall/NAT, перенос CPU-intense проверок в более ранние фильтры или аппаратный offload.
- Ввести QoS/traffic-shaping (tc, fq_codel) чтобы уменьшить потери и буферблоббинг; установить лимиты на агрессивные потоки.
- Шардировать NAT (multiple NAT devices или load balancer) либо использовать маршрутизацию без NAT (если возможно).
- Если проблема в pps — заменить/апгрейдить устройство/карты или включить hardware NAT/accelerations.
- Рассмотреть TCP offloading/segmentation/large receive если влияет на CPU (и правильно настроить).
10) Проверка эффективности исправлений
- Повторить нагрузочный тесты и capture, сравнить метрики: pps, conntrack utilization, interface errors, tcp retransmits и latency (mtr).
Метрики для контрольного сравнения: число conntrack, CPU %, interface drops, tcp retransmits, ping loss/latency.
Короткий чек-лист команд (полезные примеры)
- `ss -s`
- `conntrack -S` / `conntrack -L | wc -l`
- `sysctl net.netfilter.nf_conntrack_max`
- `ip -s link show dev eth0`
- `ethtool -S eth0`
- `tc -s qdisc show dev eth0`
- `tcpdump -i eth0 -s0 -w /tmp/cap.pcap`
- `dmesg | grep -i conntrack` / `grep -i nf_conntrack /var/log/syslog`
- `iptables -L -v -n` или `nft list ruleset`
Если нужно, пришлите выводы `ss -s`, `conntrack -S` и `ip -s link` в момент пика — подскажу, где именно узкое место.