Сеть либо работает, либо нет, и в момент аварии админу нужно быстро ответить на вопрос: на каком уровне сломалось. Есть линк? Назначен ли адрес? Есть ли маршрут до шлюза? Доходят ли пакеты? Отвечает ли нужный порт? В этом уроке разбираем набор iproute2 (ip), инструменты проверки связности (ping, traceroute, tracepath, mtr), просмотр сокетов (ss), проверку портов через netcat и низкоуровневую диагностику интерфейса через ethtool. Главное - не тыкать команды наугад, а идти по слоям модели снизу вверх.
Как это работает
Сетевая проблема почти всегда локализуется на одном из уровней. Физика и канал (L1/L2): есть ли электрический линк, поднят ли интерфейс, видит ли ядро MAC соседа. Сетевой уровень (L3): назначен ли IP, есть ли маршрут, доходят ли ICMP-пакеты. Транспорт и приложение (L4/L7): слушает ли сервис нужный порт, не режет ли его firewall. Диагностика - это движение по этой лестнице: бессмысленно проверять порт веб-сервера, если у машины нет даже IP-адреса.
Старый пакет net-tools (ifconfig, route, netstat, arp) в современных дистрибутивах не ставится по умолчанию и считается устаревшим. Его заменил iproute2 с единой утилитой ip, которая работает напрямую через netlink-сокет и показывает то, чего ifconfig не умел: несколько адресов на интерфейсе, политики маршрутизации, namespace. Запоминать стоит именно ip.
Ключевой момент про ICMP. ping и traceroute опираются на ICMP-сообщения, а многие хосты и firewall их фильтруют. Поэтому пропавший ping еще не значит, что узел мертв - возможно, просто запрещен ICMP. Для проверки конкретного TCP-порта надежнее netcat или ss, а не пинг.
Команды и примеры
Сначала L2/L3 - адреса, линк, маршруты, соседи (ARP/NDP):
Код: Выделить всё
ip addr show # адреса на всех интерфейсах (короче: ip a)
ip -br addr # компактная сводка: имя, состояние, адрес
ip link show eth0 # состояние линка, MAC, MTU
ip route # таблица маршрутов, ищем строку default
ip route get 8.8.8.8 # через какой маршрут и интерфейс пойдет пакет
ip neigh # кэш соседей: IP -> MAC (замена arp)
Код: Выделить всё
ip link set eth0 up
ip addr add 192.168.1.50/24 dev eth0
ip route add default via 192.168.1.1
Проверка связности по слоям. ping проверяет L3 до узла, traceroute показывает путь по хопам:
Код: Выделить всё
ping -c4 192.168.1.1 # 4 пакета и стоп
ping6 -c4 fe80::1%eth0 # IPv6, для link-local нужен %интерфейс
traceroute 8.8.8.8 # путь по UDP (по умолчанию)
traceroute -I 8.8.8.8 # тот же путь, но ICMP-эхо
tracepath example.com # как traceroute, но без root, плюс PMTU
mtr 8.8.8.8 # traceroute + ping в реальном времени
Сокеты и порты. ss - современная замена netstat, читает данные из ядра быстрее:
Код: Выделить всё
ss -tlnp # TCP (t), слушающие (l), без резолва (n), процессы (p)
ss -tunap # TCP+UDP, все состояния, с PID/именем процесса
ss -s # сводная статистика по сокетам
ss -t state established '( dport = :443 )' # фильтр по состоянию/порту
Проверка порта снаружи через netcat (в RHEL/Fedora команда обычно ncat из пакета nmap-ncat, в Debian/Ubuntu - nc из netcat-openbsd):
Код: Выделить всё
nc -zv 10.0.0.5 22 # -z только проверка, -v подробно
nc -zv 10.0.0.5 20-25 # диапазон портов
nc -zvu 10.0.0.5 53 # UDP-порт
Код: Выделить всё
ethtool eth0 # скорость, дуплекс, наличие линка
ethtool -S eth0 # счетчики ошибок и дропов на NIC
ethtool -i eth0 # драйвер и версия прошивки
Частые грабли
- Считать, что нет ответа на ping - значит узел недоступен. ICMP часто блокируют; проверяйте нужный порт через nc или ss.
- Искать ifconfig, route, netstat, arp - в свежих системах их нет. Ставить net-tools ради привычки не нужно, есть ip и ss.
- ping IPv6 link-local адреса без указания интерфейса (fe80::1) - будет ошибка, нужен суффикс %eth0.
- Менять адрес через ip addr и удивляться, что после перезагрузки все откатилось - это runtime-настройка, правьте Netplan или nmcli.
- nc -z с диапазоном работает только для TCP; для UDP результат часто ложноположительный, так как ответа нет.
- Смотреть ss без -n и тормозить на DNS-резолве портов и адресов; в диагностике почти всегда нужен -n.
- Путать tracepath и traceroute: tracepath не требует root и показывает PMTU, но не умеет выбирать протокол так гибко.
- Выведите ip -br addr и ip -br link, запишите состояние и адрес своего основного интерфейса.
- Удалите default-маршрут (ip route del default), убедитесь через ip route get 8.8.8.8, что наружу пути нет, верните маршрут обратно.
- Запустите ping -c4 до шлюза и до 8.8.8.8; затем mtr 8.8.8.8 на 20 секунд и найдите хоп с потерями, если он есть.
- Поднимите тестовый слушатель: nc -l 8080 в одном терминале, в другом проверьте nc -zv 127.0.0.1 8080.
- Через ss -tlnp найдите процесс, который держит этот порт, сверьте PID.
- Выполните ethtool на проводном интерфейсе и найдите Speed, Duplex и Link detected.
- Сравните ip neigh до и после ping соседа в локальной сети - увидите, как заполняется кэш.
- Какая команда iproute2 покажет, через какой интерфейс и шлюз уйдет пакет к конкретному адресу?
- Чем mtr принципиально удобнее обычного traceroute при диагностике плавающих потерь?
- Какие ключи ss нужны, чтобы увидеть слушающие TCP-порты с именами процессов и без резолва?
- Почему успешный ping не гарантирует, что нужный сервис доступен, и чем это проверить правильно?
- Что означает состояние интерфейса NO-CARRIER в выводе ip link и на каком уровне модели это проблема?
- Как с помощью netcat проверить, открыт ли TCP-порт 443 на удаленном хосте, не передавая данных?
