Диагностика сети в Linux: полный гайд по утилитам и настройке

Зачем нужна системная диагностика сети

Стабильное соединение критично для работы серверов, удалённого доступа и повседневных задач. Сетевые сбои редко возникают сами по себе: их триггерами становятся перегрузка маршрутизатора, конфликт портов, устаревшие DNS-кэши или некорректные правила фаервола. Понимание того, как последовательно проверять каждый уровень стека TCP/IP, сэкономит вам часы на поиск причины и исключит необходимость в слекой перезагрузке системы.

Подготовка среды

Для выполнения инструкций откройте терминал и убедитесь, что базовые утилиты доступны. В современных дистрибутивах iproute2 уже установлен по умолчанию. Остальные пакеты можно установить через менеджер пакетов:

# Debian/Ubuntu
sudo apt install mtr-tiny dnsutils curl

# Fedora/RHEL
sudo dnf install mtr bind-utils curl

💡 Совет: Запускайте команды анализа портов и трассировки через sudo или добавьте пользователя в группу netdev, чтобы избежать ошибок доступа к файлам /proc/net.

Шаг 1: Проверка базовой связности

Начните с простого теста доступности внешнего узла. Пинг до публичного DNS-сервера Google отсекает проблемы локального маршрутизатора:

ping -c 10 8.8.8.8

Флаг -c 10 ограничивает отправку десятью пакетами. Обратите внимание на процент packet loss и среднее время rtt min/avg/max. Если потери превышают 2–3%, переходите к анализу маршрута. Нулевой отклик обычно указывает на отключённый кабель, выключенный Wi-Fi или блокировку ICMP на уровне шлюза.

Шаг 2: Трассировка маршрута и анализ потерь

Команда mtr объединяет функционал ping и traceroute, показывая задержки на каждом промежуточном узле в реальном времени:

mtr -r -c 50 8.8.8.8

Ключ -r генерирует отчёт после завершения, а -c 50 задаёт количество запросов на хоп. Ищите строки, где значение Loss% резко возрастает. Если потери начинаются на первом узле (обычно это ваш роутер), проблема внутри локальной сети. Если потери появляются после выхода к провайдеру, зафиксируйте отчёт и передайте его в техническую поддержку.

Шаг 3: Мониторинг активных соединений и портов

После проверки внешнего канала убедитесь, что сама система не блокирует трафик и не исчерпала лимит сокетов:

sudo ss -tulnp | head -20

Команда выводит список прослушивающих (LISTEN) и установленных (ESTAB) соединений с привязкой к процессам. Столбцы Local Address:Port и Process помогут найти приложения, занимающие нужные порты. Если вы видите дубликаты или зависшие процессы в состоянии TIME-WAIT, перезапустите соответствующий сервис или освободите порт.

Шаг 4: Диагностика DNS и веб-доступа

Иногда канал работает идеально, но браузеры не открывают сайты. Разделите проблему: проверьте резолвинг отдельно от HTTP-соединения.

# Запрос A-записи
dig +short ya.ru A

# Проверка HTTP-заголовков с таймаутом 5 секунд
curl -I --connect-timeout 5 https://ya.ru

Если dig возвращает IP-адрес, но curl выводит ошибку Connection timed out или SSL handshake failed, проблема на уровне приложения, прокси или брандмауэра. Если dig не возвращает адрес, откройте /etc/resolv.conf и убедитесь, что указаны рабочие серверы (например, nameserver 1.1.1.1).

Проверка результата

После внесения правок запустите комплексный тест:

1. Выполните ping -c 20 8.8.8.8 и убедитесь, что packet loss равен 0%, а среднее время отклика стабильно.
2. Откройте веб-страницу через curl -I и проверьте код ответа HTTP/1.1 200 OK или 301 Moved Permanently.
3. Снова просмотрите вывод ss -tulnp, чтобы убедиться в отсутствии новых конфликтов.

Стабильные показатели на всех этапах подтверждают, что сетевой стек функционирует корректно.

Возможные проблемы при диагностике