Сетевые команды Linux: ip, ss, ping, traceroute, dig и curl для диагностики сети

Сетевые команды Linux закрывают почти всю повседневную диагностику: ip показывает адреса и маршруты, ss — открытые порты и соединения, ping и traceroute проверяют доступность узла, dig — DNS, а curl — ответ веб-сервиса. Ниже — шпаргалка с флагами и пошаговый порядок, по которому удобно искать причину, когда «сеть не работает».

Шпаргалка: сетевые команды Linux одной таблицей

ip: адреса, интерфейсы и маршруты

Команда ip из пакета iproute2 заменила устаревшие ifconfig и route. Подкоманды можно сокращать: ip a = ip addr, ip r = ip route. Флаг -br даёт краткий вывод, -c раскрашивает его.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

Если у интерфейса нет адреса из нужной сети или он в состоянии DOWN, дальше можно не искать — проблема на этом уровне.

Как добавить IP-адрес и поднять интерфейс

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Изменения через ip живут до перезагрузки. Постоянные настройки задаются в конфигурации системы: netplan в Ubuntu, NetworkManager (nmcli) в Fedora и RHEL, systemd-networkd на серверах.

Маршруты и шлюз по умолчанию

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

Строка default via — шлюз, куда уходит всё, что не попало в более точные маршруты. Нет такой строки — интернета не будет, хотя локальная сеть работает. Добавить маршрут: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: какие порты открыты и кто их слушает

ss пришла на смену netstat и работает быстрее. Самая частая комбинация — ss -tulpn:

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Обратите внимание на адрес: 0.0.0.0 — сервис принимает подключения со всех интерфейсов, 127.0.0.1 — только локально. Это частая причина, почему база «не отвечает» с другой машины.

Как узнать, кто занял порт

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # соединения к конкретному адресу
ss -tan state time-wait | wc -l   # сколько сокетов в TIME-WAIT

В колонке State видно состояние TCP-соединения. LISTEN — сервис ждёт подключений, ESTABLISHED — рукопожатие SYN → SYN-ACK → ACK завершено. SYN-RECV — сервер ответил SYN-ACK и ждёт финальный ACK; сотни таких сокетов с множества разных IP — признак SYN-flood. TIME-WAIT — не утечка: так сторона, первой закрывшая соединение, страхуется от запоздалых пакетов. Сводку по состояниям даёт ss -s.

ping: доступен ли узел

ping отправляет ICMP echo-запросы и показывает время ответа и потери. В Linux он работает бесконечно, поэтому задавайте число пакетов флагом -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Полезные флаги: -i 0.2 — интервал, -W 2 — таймаут ответа, -4/-6 — версия протокола, -s 1472 -M do — проверить MTU без фрагментации. Помните, что многие серверы и облака блокируют ICMP: отсутствие ответа на ping ещё не значит, что узел недоступен.

traceroute и mtr: где теряются пакеты

traceroute показывает узлы по пути до цели. Звёздочки на отдельных хопах нормальны — промежуточный маршрутизатор может не отвечать. Тревожный признак — когда после какого-то хопа звёздочки идут до конца.

traceroute -n example.com        # без DNS-имён, быстрее
sudo traceroute -T -p 443 example.com   # TCP вместо UDP, проходит через фаерволы
tracepath example.com            # без root, заодно показывает MTU

mtr объединяет ping и traceroute и обновляет статистику потерь по каждому хопу в реальном времени. Для отчёта: mtr -rwc 50 example.com.

dig: проверка DNS

dig из пакета dnsutils (bind-utils в RHEL) — главный инструмент проверки DNS. Короткая форма возвращает только ответ:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # спросить конкретный сервер
$ dig -x 8.8.8.8 +short            # обратная запись (PTR)
$ dig +trace example.com           # пройти цепочку от корневых серверов

В полном выводе смотрите на status: NOERROR — запись найдена, NXDOMAIN — домена нет, SERVFAIL — сервер не смог ответить (часто проблема DNSSEC или недоступный авторитетный сервер). Если dig @8.8.8.8 отвечает, а обычный dig — нет, виноват локальный резолвер: проверьте /etc/resolv.conf и resolvectl status.

Учтите, что dig не читает /etc/hosts. Чтобы проверить разрешение имени так, как это сделает приложение, используйте getent hosts example.com: порядок источников (сначала /etc/hosts, потом DNS) задаёт строка hosts: в /etc/nsswitch.conf.

curl: проверка HTTP и API

curl отвечает на последний вопрос: сервис отвечает и что именно он возвращает.

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

Сообщения об ошибках curl хорошо указывают на слой: Could not resolve host — DNS, Connection refused — порт закрыт или никто не слушает, Connection timed out — пакеты режет фаервол или нет маршрута, SSL certificate problem — проблема с сертификатом.

Порядок диагностики: когда «не работает сеть»

1. Интерфейс и адрес: ip -br addr — интерфейс UP, адрес есть.
2. Шлюз: ip route — есть default via; ping -c 3 <шлюз>.
3. Внешняя сеть по IP: ping -c 3 1.1.1.1. Работает — маршрутизация в порядке.
4. DNS: dig +short example.com. Пусто или ошибка при работающем ping по IP — проблема в резолвере.
5. Порт: nc -zv host 443 или curl -v. На сервере — ss -tulpn, слушает ли сервис и на каком адресе.
6. Фаервол: sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Приложение: curl -I и логи сервиса (journalctl -u nginx).

Идите снизу вверх и не перескакивайте шаги: так вы за пару минут определите, на каком уровне проблема, а не будете перезапускать всё подряд.

Старые и новые команды

В свежих дистрибутивах net-tools часто не установлен вовсе, поэтому привыкайте к новым командам.

Итог

Для повседневной диагностики хватает шести сетевых команд Linux: ip, ss, ping, traceroute, dig и curl. Проверяйте по слоям — адрес, маршрут, DNS, порт, приложение — и ошибка находится быстро. Сетевые команды и разбор типичных сбоев на практике показаны в курсе по Linux.