- Измерение задержек
- Анализ маршрута
- Проверка DNS
- Тестирование
- Проверка сетевых интерфейсов
- Диагностика проблем
Сбои в работе сети – обычное дело, но реагировать на них вслепую неэффективно. Гораздо разумнее подойти к диагностике системно: с помощью проверенных инструментов выяснить, где возникла проблема – на локальном устройстве, в маршрутизаторе или за пределами вашей сети.
В Linux для этого уже есть все необходимое – набор команд, которые позволяют проверить соединение, проследить путь пакетов и оценить реальную скорость передачи данных. Вместо того чтобы перезагружать роутер и надеяться на лучшее, вы получаете возможность точно локализовать неисправность.
В этой статье мы собрали основные команды, которые стоит знать каждому, кто работает с Linux и хочет держать сеть под контролем.
Проверка доступности узлов
Даже если с интернетом нет проблем, это еще не означает, что нужный сервер действительно доступен. Соединение может обрываться на промежуточном узле, сервис – не отвечать на запросы, а порт – быть закрыт. Поэтому первое, с чего обычно начинают сетевую диагностику, – проверяют, отвечает ли удаленный хост и можно ли до него достучаться.
ping – базовая проверка связи
Самый простой и универсальный инструмент. Команда отправляет ICMP-пакеты на указанный адрес и показывает, приходит ли ответ.
По выводу сразу видно:
- доступен ли узел;
- есть ли потери пакетов;
- каково среднее время отклика.
Если ответы не приходят вовсе, это может означать проблемы с маршрутизацией, фильтрацию ICMP или недоступность самого узла.
В системах Linux эхо-запросы отправляются непрерывно и будут выполняться до тех пор, пока вы не остановите команду вручную. Для этого используется сочетание клавиш CTRL + C – после его нажатия ping завершит работу и выведет сводную статистику по отправленным и полученным пакетам.
Если нужен короткий тест, удобнее сразу ограничить количество запросов. Например:
fping – проверка сразу нескольких хостов
Если нужно проверить доступность не одного, а группы узлов (например, серверов или шлюзов), выручает fping:
Команда показывает, какие адреса отвечают, а какие нет, и делает это заметно быстрее.
nc (netcat) – доступность сервиса и порта
Иногда узел отвечает на ping, но нужный сервис все равно недоступен. Причина часто в закрытом или недоступном порте. Для таких проверок используют netcat.
Если соединение устанавливается – порт открыт и сервис принимает подключения. Если нет, проблема может быть в настройках сервера, файрволе или сетевых фильтрах.
telnet – простой тест соединения
Хотя telnet давно считается устаревшим инструментом и не используется для полноценной работы с сервисами, для диагностики он все еще бывает полезен. Его основная задача – проверить, удается ли установить TCP-соединение с нужным хостом и портом.
После этого может появиться пустой экран или ответ сервера (например, HTTP-заголовки или служебное сообщение). Сам факт появления строки Connected to ... означает, что порт доступен.
Если соединение установлено, значит порт открыт. Если нет – вывод ошибки сразу подскажет, что пошло не так.
Измерение задержек
Задержка – это время, которое тратит пакет, чтобы дойти до удаленного узла и вернуться обратно. Если задержка большая, вы это сразу чувствуете: сайт грузится долго, а команды в терминале выполняются с опозданием. Поэтому полезно уметь быстро оценить не только сам факт соединения, но и то, насколько оно стабильное.
ping – быстрая оценка задержки
Для первичной проверки задержки достаточно стандартного ping. Он показывает время отклика в миллисекундах и позволяет быстро понять, насколько стабильно соединение.
Чтобы оценить задержки, обратите внимание на значения time и итоговую статистику после остановки команды (CTRL + C):
- avg – средняя задержка, дает общее представление о качестве соединения;
- max и min – помогают заметить резкие скачки;
- mdev/stddev – показывает, насколько задержка нестабильна.
Если средняя задержка стабильна, а потерь нет, соединение можно считать предсказуемым.
mtr – задержки и потери по всему пути
Если ping показывает высокую задержку или потери, следующий вопрос – где конкретная проблема. mtr показывает промежуточные узлы и статистику по каждому из них.
На что смотреть в первую очередь:
- Loss% – потери (в идеале 0%);
- Last/Avg/Best/Wrst – текущая/средняя/лучшая/худшая задержка;
Также можно запустить mtr в режиме отчета с фиксированным числом пакетов:
Анализ маршрута
Бывает, что узел отвечает на запросы, но соединение работает нестабильно: страницы открываются с задержкой, соединение периодически обрывается, пакеты теряются. В таких ситуациях важно понять, каким путем трафик идет до удаленного хоста и на каком участке возникают проблемы. Для этого в Linux используется traceroute.
Команда поочередно определяет все промежуточные узлы между вашим компьютером и целевым хостом, увеличивая время жизни пакетов (TTL). Каждый шаг показывает очередной маршрутизатор и время отклика до него.
В выводе каждая строка – это отдельный хоп (маршрутизатор). Обычно отображаются:
- номер хопа;
- IP-адрес или имя узла;
- время отклика для нескольких попыток.
Если вместо времени отображаются символы * * *, это означает, что узел не отвечает на диагностические пакеты:
Чаще всего причина в фильтрации ICMP или ограничении ответов со стороны маршрутизатора. При этом сам маршрут может быть рабочим, поэтому наличие звездочек не всегда указывает на проблему.
Проверка DNS
Если IP-адрес доступен, а доменное имя – нет, проблема почти всегда связана с DNS. Сеть может работать корректно, но приложения, браузер или сервисы будут вести себя так, будто интернета нет.
Какие команды помогут в этой ситуации:
nslookup – быстрая проверка DNS-разрешения
nslookup позволяет быстро узнать, какой IP-адрес возвращается для домена и какой DNS-сервер дал ответ.
Как правило, в выводе видно:
- адрес DNS-сервера, который использовался для запроса;
- IP-адрес или несколько адресов, связанных с доменом.
Если вместо ответа появляется ошибка, это может указывать на проблемы с DNS-сервером, сетевые ограничения или некорректные настройки резолвера.
dig – детальный анализ DNS-ответов
dig дает гораздо больше информации и подходит, когда нужно разобраться глубже: проверить тип записи, время жизни (TTL) или ответ конкретного DNS-сервера.
Если тип записи не указан явно, dig по умолчанию запрашивает A-запись (IPv4-адрес). Чтобы проверить конкретный тип записи (например, MX), можно указать его явно:
Если ответ пустой или запрос выполняется слишком долго, проблема может быть в настройках DNS, кешировании или недоступности серверов имен.
С помощью dig можно:
- понять, какой тип записи возвращается;
- увидеть, отвечает ли авторитетный сервер;
- проверить, отличается ли ответ у разных DNS-серверов.
Тестирование
Скорость соединения – не всегда то же самое, что заявлено в тарифе провайдера. На нее влияют маршрут, загрузка канала, ограничения на стороне сервера и даже время суток. Поэтому при диагностике сети важно уметь измерять реальную скорость передачи данных, а не ориентироваться только на формальные цифры.
iperf / iperf3 – измерение пропускной способности между узлами
iperf и iperf3 используются для точного тестирования скорости между двумя хостами. Это один из самых надежных способов понять, на что реально способен канал.
На одном узле запускается сервер:
На другом – клиент:
В выводе вы получите скорость передачи данных, объем переданных данных и возможные потери (для UDP-тестов).
speedtest-cli – проверка скорости интернета
Если нужно быстро оценить скорость соединения с интернетом в целом, удобно использовать speedtest-cli. Утилита измеряет скорость загрузки и отдачи, выбирая ближайший тестовый сервер.
Команда автоматически выбирает ближайший сервер и показывает скорость загрузки (download), скорость отдачи (upload) и задержку.
wget – практическая оценка скорости загрузки
В некоторых случаях важно узнать реальную скорость скачивания файлов. Для этого подходит wget:
Во время загрузки wget показывает текущую скорость, по которой можно оценить, как соединение ведет себя на практике.
curl – контроль скорости и времени отклика
curl позволяет измерить скорость передачи данных и время отклика HTTP-сервисов.
Утилита показывает, как быстро начинается и происходит передача данных.
Проверка сетевых интерфейсов
Работа сети во многом зависит от состояния локальных интерфейсов: активен ли адаптер, получил ли он IP-адрес, на какой скорости установлен линк и нет ли ошибок на уровне драйвера. Проверка этих параметров позволяет быстро понять, связана ли проблема с самой системой или ее стоит искать дальше по сети.
|
Команда |
Что показывает |
Нужно использовать, когда |
|
ip addr |
Список сетевых интерфейсов, их состояние, IP-адреса |
Нужно проверить, есть ли у интерфейса IP-адрес и активен ли он |
|
ip link |
Состояние интерфейсов и статистику ошибок |
Соединение есть, но возникают обрывы или пакеты теряются |
|
ethtool <интерфейс> |
Скорость линка, дуплекс, состояние кабеля |
Есть подозрение на проблемы с физическим подключением |
|
nmcli device status |
Статус сетевых устройств в NetworkManager |
Сеть управляется NetworkManager и нужно понять текущее состояние |
|
nmcli connection show |
Активные и сохраненные сетевые подключения |
Интерфейс есть, но соединение не поднимается автоматически |
Диагностика проблем
Если соединение ведет себя странно – сервис не принимает подключения, порт вроде бы открыт, но клиенты не подключаются, или сеть зависает без явной на то причины – без диагностики на уровне системы не обойтись. Тогда полезно посмотреть, что происходит с сетевыми соединениями и какие ошибки фиксируются в логах:
netstat – классический инструмент диагностики
Несмотря на то что netstat считается устаревшим, он до сих пор встречается во многих системах и может быть полезен на старых дистрибутивах.
В выводе вы увидите открытые порты, сетевые интерфейсы, к которым они привязаны и текущие состояния соединений.
ss – анализ активных соединений и портов
ss – современная и быстрая утилита для просмотра сетевых сокетов. В большинстве дистрибутивов она пришла на смену netstat и показывает актуальную информацию почти мгновенно:
Команда показывает, какие порты открыты, какие сервисы их слушают и используются ли TCP или UDP.
journalctl – поиск сетевых ошибок в логах
Не все проблемы видны через состояние портов. Иногда причина кроется в ошибках служб, драйверов или сетевых менеджеров – тогда нужно просмотреть системные журналы через journalctl.
Посмотреть общие сообщения, связанные с сетью:
Или, например, логи сетевого сервиса:
Для анализа недавних ошибок удобно ограничить вывод по времени:
В логах можно найти сообщения о сбоях инициализации интерфейсов, проблемах с DHCP, ошибках драйверов и неожиданных обрывах соединений – то, что невозможно увидеть обычными сетевыми командами.
Заключение
Диагностика сети – важная часть работы с домашним компьютером или сервером на Linux. Зная, как проверить соединение, проследить маршрут пакетов и измерить скорость, вы быстро поймете, где возникла проблема.