База знаний
База знаний Справочник команд

Справочник сетевых команд

Короткие команды Linux для диагностики сети: интерфейсы, доступность, маршрут, сокеты, DNS, HTTP и журналы сервисов.

Принцип

Как работать с диагностикой

Начинайте с локального состояния: есть ли интерфейс, адрес и маршрут по умолчанию. Затем проверяйте шлюз, имя в DNS и только после этого — нужный сервис. Такой порядок помогает отделить проблему на узле от проблемы маршрутизации или приложения.

Осторожно. Команды ниже не меняют конфигурацию, но ping, traceroute, tracepath, dig и curl отправляют сетевые запросы. Выполняйте их только к разрешённым узлам и не вставляйте в командную строку пароли, токены или приватные адреса из журналов.

Во всех примерах значения в угловых скобках замените данными своей среды: например, <шлюз>, <имя_сервиса> или <dns-сервер>.

Локальная сеть

Интерфейсы и маршруты

Утилита ip показывает состояние интерфейсов, адреса, таблицу маршрутизации и соседей ARP/ND. Краткий формат удобен для первичной проверки.

# Состояние интерфейсов и назначенные адреса
ip -br link
ip -br addr

# Маршрут по умолчанию и путь до конкретного адреса
ip route
ip route get <ip-адрес>

# Таблица соседей: MAC-адреса шлюзов и других узлов
ip neigh show
Что проверитьПризнак исправностиЕсли не так
ИнтерфейсUP и LOWER_UPПроверьте кабель, VLAN, виртуальный адаптер и состояние порта.
IPv4/IPv6-адресАдрес ожидаемой подсетиПроверьте DHCP, статическую настройку и маску сети.
Маршрут по умолчаниюСтрока default via …Проверьте шлюз и приоритет маршрутов.
Сосед шлюзаMAC-адрес вместо FAILED или INCOMPLETEПроверьте L2-связность и принадлежность к VLAN.
Не спешите очищать ARP/ND-кэш. Команда ip neigh flush меняет состояние системы и здесь намеренно не используется. Сначала зафиксируйте текущую картину командой ip neigh show.

Связность

Проверка доступности с ping

ping помогает проверить, доходят ли ICMP-пакеты до узла. Успешный ответ означает, что путь работает для ICMP, но сам по себе не подтверждает доступность HTTP, SSH или другого прикладного сервиса.

# IPv4: сначала укажите адрес шлюза, затем при необходимости — внутренний адрес
ping -c 4 -W 2 <адрес>

# Если в сети используется IPv6
ping -6 -c 4 -W 2 <ipv6-адрес_или_имя>
  • -c 4 ограничивает проверку четырьмя пакетами.
  • -W 2 ограничивает ожидание каждого ответа двумя секундами.
  • Отсутствие ответа не всегда означает недоступность: ICMP может быть отключён правилами безопасности.

Маршрутизация

Путь до узла: tracepath и traceroute

Если шлюз отвечает, а удалённый адрес — нет, посмотрите, на каком участке прекращается путь. Для обычной проверки достаточно одного из двух инструментов.

# Часто доступен без дополнительных прав
tracepath -n <удалённый_узел>

# Подробный вывод; пакет traceroute может потребовать установки
traceroute -n -w 2 -q 1 <удалённый_узел>

Ключ -n отключает обратные DNS-запросы и делает вывод быстрее и понятнее. -q 1 в примере отправляет один пакет на каждый шаг, чтобы снизить объём диагностического трафика.

Интерпретация. Символы * не обязательно указывают на сбой: промежуточный маршрутизатор может не отвечать на такие запросы, но пропускать полезный трафик дальше.

Транспорт

Порты и соединения с ss

Утилита ss показывает слушающие порты и уже установленные TCP/UDP-соединения. Это удобная проверка, когда сетевой адрес доступен, но приложение не принимает подключения.

# Слушающие TCP и UDP-порты
ss -tuln

# Установленные TCP-соединения
ss -tan state established

# Привязка портов к процессам (часть имён может быть скрыта без прав администратора)
sudo ss -tulpn

# Проверка конкретного порта, например 443
ss -tln sport = :443
Данные процессов могут быть чувствительными. Не публикуйте вывод ss -p без просмотра: в имени команды или её аргументах иногда оказываются пути, имена пользователей и параметры запуска.

Имена

Проверка DNS: dig и nslookup

Сначала выясните, какой DNS-сервер настроен на узле, затем сравните ответ этого сервера с ожидаемой записью. Если имя разрешается в адрес, а подключение всё равно не работает, продолжайте проверку с curl или ss.

# Текущие DNS-серверы и поисковые домены
resolvectl status

# Короткий ответ для A-записи
dig +short <имя> A

# Запрос к конкретному DNS-серверу
dig @<dns-сервер> <имя_сервиса> A

# Альтернатива, если dig не установлен
nslookup <имя_сервиса> <dns-сервер>

На системах без resolvectl посмотрите /etc/resolv.conf. В контейнере этот файл нередко указывает на встроенный резолвер, поэтому для проверки внутренней зоны полезно явно задать DNS-сервер в команде dig.

Полезное различие. NXDOMAIN означает, что имя не существует на опрошенном сервере; SERVFAIL говорит об ошибке обработки запроса. Пустой ответ при NOERROR может означать, что запрошенный тип записи отсутствует.

Веб-сервисы

Проверка HTTP(S) с curl

curl проверяет именно прикладной уровень: DNS, соединение, TLS и HTTP-ответ. При диагностике достаточно заголовков или кода ответа — не нужно выводить содержимое страниц и приватные данные.

# Код ответа и итоговый адрес без сохранения тела
curl -sS -o /dev/null -w 'HTTP %{http_code} → %{url_effective}\n' \\
  --connect-timeout 5 --max-time 10 https://<имя_сервиса>/

# Проверка нужного Host-заголовка на конкретном IP
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \\
  --resolve <имя_сервиса>:443:<ip-адрес> \\
  https://<имя_сервиса>/
  • 2xx обычно означает успешный ответ, 3xx — перенаправление, 4xx — проблема в запросе или правах, 5xx — ошибка на стороне сервиса.
  • Не добавляйте -k для постоянной проверки: он отключает проверку TLS-сертификата и может скрыть важную проблему.
  • Не передавайте в командной строке заголовки Authorization, cookie или токены: они могут остаться в истории оболочки и списке процессов.

Наблюдаемость

Системные журналы с journalctl

Когда интерфейс, маршрут и порт выглядят правильно, журнал сервиса часто объясняет причину отказа: ошибку TLS, занятой порт, сбой получения адреса или неуспешную авторизацию.

# Сообщения текущей загрузки ядра и сети
journalctl -k -b --no-pager

# Журнал используемой в системе службы сети
journalctl -u <служба_сети> -b --no-pager

# Последние сообщения конкретного сервиса
journalctl -u <имя_сервиса> -n 100 --no-pager

# Наблюдение новых сообщений во время повторной проверки
journalctl -u <имя_сервиса> -f
Перед передачей журналов. Просмотрите вывод и удалите IP-адреса, имена пользователей, идентификаторы сессий, cookie и другие данные, которые нельзя публиковать. Для повторяемой диагностики сохраняйте только короткий фрагмент с отметками времени.

Шпаргалка

Быстрая последовательность проверки

↑ Наверх