Диагностика сети в Linux: ip, ss, mtr и dig на практике
Учимся находить сетевые проблемы в Linux современными инструментами: ip, ss, mtr, dig.
Когда сеть барахлит, хочется тыкать наугад, но грамотная диагностика - это последовательность из нескольких проверок, каждая из которых отсекает часть причин. В этой статье соберём современный набор инструментов Linux и в конце пройдём весь путь на примере вечной жалобы "сайт не открывается". Забудьте про ifconfig и netstat - в актуальных дистрибутивах их место заняли ip и ss из пакета iproute2.
Смотрим интерфейсы: ip вместо ifconfig
Первым делом проверяем, что сетевые интерфейсы вообще подняты и получили адреса. Команда ip заменяет старый ifconfig и говорит на более строгом языке:
ip addr
ip -brief addr
ip linkФлаг -brief даёт компактную таблицу: имя интерфейса, состояние UP или DOWN и адрес. Если рядом с вашим Ethernet или Wi-Fi нет IP-адреса или интерфейс в состоянии DOWN, дальше идти бессмысленно - проблема на самом нижнем уровне.
Маршруты и шлюз
Даже с адресом трафик никуда не уйдёт без маршрута по умолчанию - шлюза. Проверяем таблицу маршрутизации:
ip route
ip route get 8.8.8.8Строка, начинающаяся с default, показывает адрес шлюза. Команда ip route get удобна тем, что говорит, через какой интерфейс и шлюз система отправит пакет к конкретному адресу - сразу видно, если маршрут ведёт не туда.
Проверяем связь: ping, traceroute и mtr
Дальше проверяем, доходят ли пакеты. Начинаем со шлюза, потом со внешнего адреса:
ping -c 4 8.8.8.8
traceroute 8.8.8.8
mtr 8.8.8.8Флаг -c 4 ограничивает ping четырьмя пакетами, иначе он будет пинговать бесконечно. Если ping до 8.8.8.8 идёт, а до имени сайта нет - виноват DNS, к нему вернёмся. Инструмент mtr объединяет ping и traceroute: он показывает весь путь до цели и в реальном времени считает потери на каждом узле. Если пакеты теряются на каком-то промежуточном хопе - там и узкое место.
DNS: dig и разрешение имён
Половина "поломок интернета" - это на самом деле проблемы с DNS. Проверяем, во что превращается доменное имя:
dig sllug.org
dig +short sllug.org
dig @8.8.8.8 sllug.orgФлаг +short оставляет только сам ответ - IP-адрес. Указав @8.8.8.8, вы спрашиваете конкретно у публичного DNS Google в обход системного. Если через 8.8.8.8 имя разрешается, а через ваш дефолтный сервер нет - проблема в настройках DNS вашей системы или роутера. Список используемых серверов смотрят в файле /etc/resolv.conf.
Порты и соединения: ss
Когда сеть жива, но конкретная служба недоступна, помогает ss - быстрая замена netstat. Она показывает открытые порты и активные соединения:
ss -tulpn
ss -tan
ss -tp state establishedНабор флагов -tulpn расшифровывается так: t - TCP, u - UDP, l - только слушающие сокеты, p - показать процесс, n - не резолвить имена в номера. Эта команда отвечает на вопрос "что вообще слушает на моей машине и на каких портах". Чтобы проверить доступность порта на удалённом хосте, удобен nc:
nc -zv sllug.org 443Флаг -z означает только проверку без передачи данных, -v - подробный вывод. Ответ "succeeded" говорит, что порт открыт и служба принимает соединения.
Пошаговый разбор: сайт не открывается
Соберём всё вместе. Пользователь жалуется, что сайт недоступен. Идём снизу вверх:
- Есть ли IP-адрес на интерфейсе? Проверяем ip -brief addr. Нет адреса - чиним подключение или DHCP.
- Есть ли маршрут по умолчанию? Смотрим ip route. Нет строки default - нет выхода наружу.
- Пингуется ли внешний IP? ping -c 4 8.8.8.8. Не идёт - проблема на шлюзе или у провайдера, зовём mtr.
- Разрешается ли имя? dig +short имя_сайта. Пусто - это DNS, пробуем через 8.8.8.8.
- Открыт ли порт сайта? nc -zv имя_сайта 443. Закрыт - сервер лежит или блокирует.
Каждый шаг отсекает целый класс причин, и вместо гадания вы за минуту локализуете проблему до конкретного уровня. Это и есть суть сетевой диагностики: не искать сразу везде, а идти по цепочке от своей машины к цели, пока не найдёте разрыв.