Мониторинг сетевого трафика игрового сервера — на что смотреть

MAATRIX GAMES

Сервер лагает, RCON не отвечает, а в панели хостера нагрузка на CPU в норме — знакомая ситуация. В девяти случаях из десяти дело не в процессоре и не в диске, а в сети: либо канал забит атакой, либо просто вырос онлайн, и трафик уже не помещается в тариф. Разница между этими двумя сценариями видна за тридцать секунд, если у вас установлен нормальный мониторинг трафика. Ниже — какие инструменты ставить, как выглядит здоровый график для разных игр и на какие паттерны реагировать сразу, а не после третьей жалобы в Discord.

Зачем вообще смотреть на трафик отдельно от CPU и RAM

Панели вроде htop, панели хостинга или even Pterodactyl честно показывают загрузку процессора и память, но почти никогда — что происходит на сетевом интерфейсе в реальном времени, по протоколам и по подключениям. А для игрового сервера сеть — это часто первое узкое место: движок игры может держать 100 TPS при полной нагрузке CPU, но если UDP-пакеты с сервера не успевают доходить до игроков или входящий трафик забивает канал, играть станет невозможно ещё до того, как процессор упрётся в потолок.

Отдельная причина смотреть на сеть — это единственный способ отличить "у нас реально стало больше игроков" от "нас атакуют". Оба сценария дают рост трафика, оба могут сопровождаться лагами, но решения кардинально разные: в одном случае нужно апгрейдить тариф, в другом — включать защиту и резать паразитные подключения. Без графика вы это различите только на глаз по симптомам, что медленно и ненадёжно.

vnstat — долгоиграющая статистика без нагрузки на сервер

vnstat — это демон, который тихо считает трафик по интерфейсам и хранит историю: по часам, дням, месяцам. Он не показывает, что происходит прямо сейчас с точностью до подключения, зато даёт то, чего не даёт ни одна панель хостинга — долгую память о том, как обычно выглядит ваш трафик.

Установка на Debian/Ubuntu:

sudo apt update
sudo apt install vnstat
sudo systemctl enable --now vnstat

Первую пару дней база будет пустой — демон накапливает историю с момента запуска. Дальше смотрите так:

vnstat -i eth0            # общая сводка по интерфейсу
vnstat -h                 # почасовая статистика за последние 24 часа
vnstat -d                 # по дням
vnstat -l                 # live-режим, счётчик в реальном времени

Флаг -l (live) — то, что нужно в момент инцидента: он показывает текущую скорость приёма/отдачи прямо в терминале, обновляясь каждую секунду, без нужды разворачивать графический дашборд. Если у вас несколько игровых процессов на разных портах одного сервера, vnstat считает по интерфейсу в целом — он не разложит трафик по портам, для этого нужен другой инструмент (ниже про iftop и nethogs).

Важный нюанс: если сервер стоит за vDS/контейнером с виртуальным сетевым интерфейсом (venet, veth, virbr), убедитесь, что vnstat слушает именно тот интерфейс, через который реально идёт трафик игроков, — ip -br addr покажет список интерфейсов и их состояние. На виртуалках с NAT счётчики иногда весят на другом имени интерфейса, чем ожидается.

Для веб-дашборда без консоли есть vnstat-php-frontend или готовые Docker-образы — оправдано, если вы администрируете несколько серверов и хотите визуальную сводку в браузере, а не по одному интерфейсу за раз.

iftop и nethogs — кто именно ест канал прямо сейчас

vnstat отвечает на вопрос "сколько трафика было час назад". iftop и nethogs отвечают на вопрос "кто прямо сейчас качает мой канал" — по IP или по процессу соответственно.

iftop показывает трафик построчно по парам "источник → назначение", с сортировкой по объёму:

sudo apt install iftop
sudo iftop -i eth0 -n

Флаг -n отключает резолвинг DNS для адресов — с ним включённым iftop будет заметно тормозить и сам грузить сеть DNS-запросами, что контрпродуктивно в момент, когда вы разбираетесь с атакой. Полезные горячие клавиши внутри iftop: p — показать порты, s/d — сортировка по source/destination, T — суммарная статистика по трафику. Если в верхних строчках вы видите один-два IP-адреса, которые качают в разы больше, чем весь остальной трафик суммарно, — это уже подозрительно, особенно если это не адрес вашего игрока с плохим NAT, а что-то незнакомое.

nethogs смотрит с другой стороны — не по IP, а по процессам:

sudo apt install nethogs
sudo nethogs eth0

Это спасает, когда на сервере крутится несколько игровых процессов (например, несколько инстансов Minecraft за прокси-сетью BungeeCord или Velocity) и нужно понять, какой конкретно инстанс генерирует аномальный трафик, а не просто "интерфейс перегружен".

Третий инструмент, который стоит держать под рукой — ss -tunap для быстрого списка активных сокетов с PID процесса, полезен, когда iftop и nethogs недоступны и нужен моментальный снимок без установки пакетов.

Как выглядит нормальный трафик для разных типов игровых серверов

Профиль трафика сильно зависит от движка. Ориентировочные диапазоны ниже — не измеренные бенчмарки, а грубый ориентир по порядку величины, чтобы вы понимали, где норма, а где явная аномалия для вашего конкретного случая; точные цифры всегда зависят от версии игры, модов и настроек тикрейта.

Общее правило: UDP-игры (Rust, ARK, большинство Source-серверов, CS2) держат заметный фоновый трафик даже при небольшом онлайне — это нормально, движок постоянно синхронизирует состояние мира с клиентами. Минекрафт на TCP обычно куда экономнее по трафику, но чувствителен к view-distance и числу загруженных чанков — если вы недавно поднимали дальность прорисовки или другие anti-lag настройки, рост исходящего трафика — ожидаемое следствие, а не аномалия.

Полезно завести привычку: раз в неделю смотреть vnstat -m (помесячная статистика) и держать в голове примерный «нормальный» диапазон для вашего конкретного онлайна. Без этой базовой линии любой график — просто цифры без контекста.

Признаки аномалии: что должно насторожить на графике

Не любой всплеск трафика — это атака. Патч-день у Rust, ивент с большим онлайном, релиз нового мода с крупным ресурс-паком — всё это законно поднимает график. Разница в характере всплеска:

• Резкий вертикальный скачок без роста онлайна. Если по данным RCON или query-протокола (см. также работу с A2S-запросами статуса сервера) число игроков не изменилось, а трафик вырос в разы — это не игроки, это что-то ещё.
• Сильная асимметрия входящего трафика. Игровой сервер обычно отдаёт данных больше, чем принимает (мир, позиции, чат) — это нормальная асимметрия исходящего трафика над входящим. Если наоборот, входящий трафик резко превысил исходящий и растёт — похоже на флуд-атаку, когда на сервер льют пакеты извне.
• Множество источников с одинаковым паттерном пакетов. В iftop это видно как десятки строк с разными IP, каждая из которых шлёт похожий по размеру и частоте трафик, — классическая картина DDoS с ботнета, в отличие от одного-двух легитимных, но прожорливых игроков.
• Плато на максимуме канала. Если график в vnstat упирается в потолок вашей полосы и держится там ровной линией, а не колеблется, как обычно колеблется живой игровой трафик, — это почти всегда означает, что канал забит целиком, а не используется игроками органически.
• Всплеск на нестандартных портах или протоколах. Если ваш сервер держит только один игровой порт, а iftop показывает активность на десятках случайных портов — это может быть сканирование или попытка эксплуатации, а не игровой трафик.

Отдельно стоит поднять логи файрвола: если вы уже настраивали порты и файрвол для игрового сервера, проверьте счётчики отброшенных пакетов по правилам — резкий рост DROP-счётчика на конкретном порту виден часто раньше, чем меняется общий график трафика.

Что делать, если похоже на DDoS

Первое — не паниковать и не перезагружать сервер вслепую, это обычно не помогает и обнуляет статистику, которая нужна для диагностики. Порядок действий:

1. Зафиксируйте картину: vnstat -l и iftop -n в отдельных окнах tmux или screen, чтобы не потерять состояние при разрыве SSH-сессии.
2. Определите топ IP-источников через iftop или ss -tunap | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 — быстрый способ увидеть, кто генерирует больше всего подключений.
3. Если источники сконцентрированы в конкретных подсетях или странах, которые точно не входят в вашу аудиторию, временная гео-блокировка регионов на уровне файрвола снимает часть нагрузки почти мгновенно.
4. Проверьте, есть ли у вашего хостинга встроенная DDoS-защита на уровне сети — большинство современных провайдеров фильтруют объёмные атаки до того, как трафик доходит до вашего сервера, но защита обычно активируется по порогу, а не работает всегда в полную силу, и порог стоит уточнить у хостера заранее, а не в момент атаки.
5. Если атака точечная и по конкретным IP, временный iptables -A INPUT -s <IP> -j DROP резким блокирует источник — но это тушение симптома, а не решение, если атака распределённая с сотен адресов.

Держите под рукой контакт поддержки хостинга — при серьёзной объёмной атаке локальный файрвол уже не спасает, канал забивается до сервера, и помочь может только фильтрация на стороне провайдера.

Автоматизация: алерты вместо постоянного взгляда на терминал

Смотреть в iftop круглосуточно никто не будет, поэтому мониторинг стоит превратить в алерты. Рабочие варианты по нарастающей сложности:

• Простой cron-скрипт на базе vnstat, который раз в 5 минут сравнивает текущий трафик со средним за предыдущую неделю и шлёт уведомление в Discord через webhook при превышении порога в 2-3 раза.
• vnstat + Zabbix/Prometheus + Grafana, если у вас уже есть стек мониторинга для нескольких серверов — vnstat умеет отдавать данные в JSON (vnstat --json), что легко парсится любым экспортером.
• Discord-бот статуса сервера — если у вас уже есть бот для мониторинга онлайна и пинга, логично расширить его алертом по сетевой аномалии, а не заводить отдельный инструмент только под трафик.

Порог для алерта лучше ставить не в абсолютных цифрах, а относительно вашей же истории — норма для сервера на 100 игроков может быть аномалией для сервера на 20, и наоборот.

Частые вопросы