Отладка сети в Linux: tcpdump, mtr и ss от и до

Жалоба «интернет не работает» почти никогда не бывает однозначной: приложение сообщает о таймауте, браузер открывает сайты через раз, а роутер уверяет, что всё в порядке. Чтобы не гадать, в Linux есть три инструмента для разных уровней диагностики: ss показывает состояние сокетов, mtr — маршрут и потери на каждом узле, tcpdump — что реально уходит в кабель. Ниже — рабочий порядок действий, с которого начинаю разбор сетевой проблемы и на рабочей станции, и на сервере.

Первый шаг: локальная машина и сокеты

Прежде чем ловить пакеты, убеждаемся, что сервис слушает нужный порт и что до адреса вообще есть маршрут. Три команды дают полную картину:

ss -tulpn
ip -br addr show
ip route get 93.184.216.34

Первый вывод — таблица сокетов. Ключ -t оставляет TCP, -u — UDP, -l показывает только слушающие сокеты, -p добавляет процесс и его владельца (без прав root поле может быть пустым), -n запрещает преобразование имён, чтобы вывод не зависел от сломанного DNS. Состояния читаются так: LISTEN — сервис ждёт подключений, ESTAB — соединение установлено и обмен данными идёт, TIME-WAIT — сокет недавно закрыт и удерживается ядром ради финальных пакетов, SYN-RECV — приходит волна незавершённых подключений, что часто указывает на атаку или перегруженный сервис. Если нужного порта нет в списке, приложение не запущено или слушает только 127.0.0.1 — самая частая причина, когда сервис «работает», а со стороны сети до него не добраться.

Фильтры ss экономят время: ss -tn state established '( dport = :443 )' покажет только активные сессии к нужному порту, а ss -s выдаст сводку по количеству соединений в каждом состоянии. Команда ip route get показывает, через какой интерфейс и какой шлюз уйдёт пакет к указанному адресу: это быстро ловит пропавший маршрут по умолчанию или неверно выставленную метрику. Проверить DNS-цепочку помогут resolvectl status — активный резолвер и серверы для каждого интерфейса — и cat /etc/resolv.conf, файл, который читают старые программы вроде скриптов на Perl.

Маршрут и потери: mtr

Если локально всё в порядке, смотрим, где именно рвётся пакет. mtr объединяет traceroute и ping: он проходит все узлы маршрута и по каждому считает количество потерь и среднюю задержку. Отчёт строится так:

mtr -rw 93.184.216.34
mtr --tcp -P 443 example.com
mtr -rw -c 20 example.com

Флаг -r включает режим отчёта, -w даёт более читаемый вывод, -c 20 ограничивает число циклов. Интерпретация требует аккуратности: потери на первом хопе почти всегда ложные, потому что маршрутизатор ограничивает частоту ответов на ICMP. Потери 100 процентов на промежуточном узле при нулевых на следующем означают, что узел просто глушит трассировку, а трафик проходит нормально. Настоящей проблемой считается участок, где потери растут и сохраняются до конечной точки. Если файрвол режет ICMP, полезен режим --tcp: пакеты уйдут к нужному порту, и сработает именно тот узел, который отвечает на TCP-соединение. Сравните результат с маршрутом из ip route: несовпадение первого хопа часто объясняется политикой маршрутизации на роутере.

Перехват трафика: tcpdump

Когда нужно увидеть сами пакеты, подключаем tcpdump. Его сила — фильтры, которые отсекают шум ещё до записи на диск:

tcpdump -i any -nn -c 100 port 53
tcpdump -i eth0 -nn 'host 192.168.1.10 and port 22'
tcpdump -i eth0 -nn 'tcp[tcpflags] = 2'
tcpdump -i eth0 -nn -s 0 -w /tmp/capture.pcap

Ключ -i any слушает все интерфейсы сразу, -nn отключает преобразование имён и портов, -c 100 останавливается после сотни пакетов — удобно для быстрой проверки. Выражение tcp[tcpflags] = 2 отбирает чистые SYN-пакеты, то есть попытки установить соединение, а значение 4 отберёт RST — отказы. Режим -w пишет трафик в файл формата pcap, который затем открывается в Wireshark: так удобно разбирать длинные сессии и прикладывать результат к заявке. Запускать перехват нужно до воспроизведения проблемы, в отдельном терминале и с правами root. Список доступных интерфейсов покажет tcpdump -D, а чтобы не потерять консоль на быстром канале, ограничивайте вывод через -c или записывайте сразу в файл.

Типичные сценарии диагностики

• Сайт не открывается, но пинг есть. Проверяем DNS-имя: dig @192.168.1.1 example.com. Если запрос виснет, запускаем tcpdump -i any -nn port 53 и смотрим, уходит ли пакет и приходит ли ответ.
• Соединение зависает на этапе подключения. В перехвате видны SYN без SYN-ACK: дальше пакет не идёт, виноват файрвол на принимающей стороне или промежуточный маршрутизатор.
• Мелкие пакеты проходят, крупные обрываются. Проверяем MTU командой ping -M do -s 1472 8.8.8.8. Если при 1472 байтах тишина, а при меньшем размере ответ есть, где-то на пути застревает фрагментированный пакет — классическая проблема PPPoE и туннелей.
• Тысячи строк в состоянии TIME-WAIT. Сводка ss -s покажет масштаб: обычно это программа, которая переподключается на каждом запросе вместо переиспользования соединения.
• Служба падает после подключения клиента. Смотрим journalctl -u nginx -n 50 одновременно с перехватом: корреляция времени пакета и записи в журнале быстро выводит на причину.
• Высокая нагрузка сети без видимых причин. Быстро оценим поток командой ss -tni — она покажет ретрансмиссии и окно у каждого соединения, а nstat -az добавит счётчики ошибок ядра, включая переполнение буферов.

Итог

Отладка сети в Linux — это последовательность, а не набор случайных команд: сначала ss и ip отвечают на вопрос, что видит локальная машина, затем mtr локализует участок с потерями, и только после этого tcpdump показывает сами пакеты. Фильтры по адресу, порту и TCP-флагам удерживают перехват компактным, а запись в pcap позволяет детально разобрать проблему в Wireshark уже после инцидента. Освоив эти три команды и связав их с журналами служб, вы закроете большинство типовых сетевых проблем без перезагрузок и перенастроек вслепую.