Сегодня мы решили обсудить вопросы сетевого мониторинга и рассмотреть несколько утилит, позволяющих заглянуть под капот процессов обмена фреймами в ядре Linux. Далее, говорим про pwru, dropwatch и KGDBoE.
Зачем нужны такие решения
Проверка статуса отброшенных пакетов в ядре может вызывать сложности. Приходится отсматривать файл /proc/net/snmp, изучать вывод таких утилит, как netstat, tc и ethtools. Сисадмин должен знать каждый из этих инструментов, чтобы видеть связь между конкретными событиями.
В то же время причины, почему тот или иной пакет был отброшен, не всегда очевидны. Так, UDPInError может означать как переполнение принимающего буфера, так и ошибку в чек-сумме. Рассмотрим пару не самых известных инструментов, которые помогают сделать процесс сетевого мониторинга более прозрачным.
pwru
Это — open source инструмент с продвинутыми механизмами фильтрации. Он помогает отслеживать проблемы подключений в Linux kernel. Утилита построена на базе технологии eBPF, позволяющей запускать произвольный код пользователя в рамках kernel. Так, можно безопасно расширить возможности ядра без необходимости вносить изменения в исходный код или загружать дополнительные модули.
Что касается конкретных настроек, то pwru умеет фильтровать по IP-адресу принимающей стороны, по портам отправителя и получателя, по протоколам L4 [tcp, udp, icmp, icmp6] и многим другим параметрам.
--filter-dst-ip string // фильтрация по IP-адресу приёмника
--filter-port uint16 // фильтрация по портам отправителя и получателя
--filter-proto string // фильтрация по протоколам L4 (tcp, udp, icmp, icmp6)Если установлены несколько фильтров, то пакет отслеживается, когда его параметры удовлетворяют каждому требованию. Так, gif-изображение в репозитории показывает, какие фреймы были отброшены после установки правил в IP tables.
Docker-образ pwru лежит в соответствующем репозитории. Развернуть его можно как на Kubernetes, так и Vagrant.
Сам по себе проект достаточно молодой и существует около двух лет. Но за это время он успел обрасти компактным сообществом энтузиастов, собрав более 1,6 тыс. звезд на GitHub. Разработчики продолжают поддерживать инструмент (в том числе с помощью комьюнити) и вносят изменения, улучшающие quality of life пользователей. Одно из последних обновлений связано с читабельностью ошибок. В Linux kernel десятки причин, по которым пакеты оказываются отброшены. И теперь pwru автоматически выводит причину из kfree_skb_reason в консоль. Так, пользователям не приходится возвращаться к релевантному куску исходного кода ядра.
dropwatch
Dropwatch — еще один проект, который помогает разработчикам и системным администраторам диагностировать проблемы в сетевом стеке Linux. Его даже использовали инженеры Google для детекции отброшенных DNS-пакетов.
Утилита записывает фреймы в файл пользовательского пространства с помощью одноименного протокола. В итоге для мониторинга можно применить tcpdump.
Автор dropwatch утверждает, что делал упор на производительности — например, он реализовал асинхронные нотификации об отброшенных пакетах. С другой стороны, резиденты HN в тематическом треде отмечают, что существуют и другие быстрые решения — например, perf и skb:kfree_skb tracepoint. Такой подход не требует специфической настройки конфигов ядра (NET_DROP_MONITOR).
KGDBoE
Это — инструмент, который позволяет производить отладку в Linux kernel по сети. Он достаточно старый [даже на GitHub можно найти репозитории с форками восьмилетней давности], так как существовал еще в виде набора патчей для дебаггера KGDB, когда тот не был интегрирован в kernel. Но эти патчи были несовместимы с новыми ядрами и плохо работали на multi-core системах.
Но обновленная версия инструмента вполне подходит для ядер 3.8.0–5.15.0, 5.19.0 и 6.3.x. Исходный код доступен по лицензии GPL, поэтому его можно подкорректировать под собственные нужды.
Что касается процесса настройки, то он довольно прост — даже адреса IP или MAC прописывать необязательно. На официальном сайте есть краткое руководство для быстрого старта. В то же время KGDBoE имеет несколько ограничений, связанных с брейкпоинтами. Их установка в сетевом коде или функции mod_timer() может приводить к дедлоку отладочной сессии.
О чем еще мы пишем в нашем корпоративном блоге: