Утилиты диагностики сети

Подход: лечим по симптому

Сеть работает слоями (см. урок про OSI/TCP-IP). Когда что-то не работает, не запускай сразу tcpdump. Иди снизу вверх (или сверху вниз, но систематически):

1. Адрес у меня правильный? (IP, маршрут)
2. До хоста долетает? (ping, ICMP)
3. Порт открыт? (nc, telnet)
4. Имя резолвится? (dig)
5. HTTP-ответ ожидаемый? (curl -v)
6. Где теряется? (mtr, traceroute)
7. Что вообще летит по проводу? (tcpdump)

Чаще всего диагностика заканчивается на шагах 1-4.

Что есть локально

ip a            # все интерфейсы и их IP
ip r            # таблица маршрутизации (куда какой пакет уйдёт)
ip n            # ARP-таблица (соответствие IP -> MAC в локалке)

ip a заменил старый ifconfig. Полезно проверить:

• получил ли DHCP-адрес,
• какой IP назначен на каком интерфейсе,
• есть ли link-local (169.254.x.x означает "DHCP не ответил").

ip r показывает default-gateway. Если его нет, наружу ничего не уйдёт, даже при правильном IP.

Кто слушает порты

ss -tulnp

Флаги:

• -t TCP, -u UDP,
• -l только listening,
• -n numeric (не резолвить порты в имена сервисов),
• -p показывать процесс.

Вывод:

Netid State  Local Address:Port  Peer Address:Port  Process
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=789))
tcp   LISTEN 127.0.0.1:5432      0.0.0.0:*          users:(("postgres",pid=1024))
tcp   LISTEN *:80                *:*                users:(("nginx",pid=2001))

Запись 0.0.0.0:22 значит, что sshd слушает все интерфейсы. А 127.0.0.1:5432 — postgres только локально (наружу не торчит, и хорошо).

ss пришёл на смену netstat. Знакомый по статьям netstat -tulnp делает то же самое, но живёт в пакете net-tools, а его давно не ставят по умолчанию: ни в Debian 10+, ни в Ubuntu 18.04+, ни в RHEL 8+, ни в Alpine. Так что netstat пригодится на старых системах, где net-tools ещё стоит, а на свежем сервере рассчитывай на ss.

Достижимость хоста: ping

ping -c 4 example.com

-c N — сколько пакетов отправить. На Linux без -c ping бесконечен; на macOS по умолчанию шлёт 56 пакетов и останавливается.

Что значит:

• ответы есть, latency стабильное — сеть в порядке,
• 100% loss — либо хост недоступен, либо ICMP режут (часто на cloud фаерволах),
• частичные потери — проблема канала.

Важно: отсутствие ответа на ping не значит "сервис не работает". Многие хосты режут ICMP, при этом TCP-порты открыты. Для проверки сервиса используй nc.

Достижимость порта: nc

Самая простая проверка TCP без специального клиента:

nc -zv example.com 443
# Connection to example.com 443 port [tcp/https] succeeded!

nc -zv example.com 5432
# nc: connect to example.com port 5432 (tcp) failed: Connection refused

Флаги:

• -z zero-IO mode (не отправлять данные, только проверить установление коннекта),
• -v verbose.

Три возможных результата:

• succeeded — порт открыт и кто-то на нём слушает,
• Connection refused — до хоста долетели, но порт закрыт (никто не слушает),
• timeout — вообще не долетели (фаервол молча дропает, хост лежит).

Нюанс: -z есть в BSD/OpenBSD-варианте nc и в ncat от Nmap (7.x и новее). А вот в busybox-варианте nc (Alpine и многие минимальные образы) флага -z нет. Если подходящего nc нет совсем, на bash-shell работает:

(echo > /dev/tcp/example.com/443) >/dev/null 2>&1 && echo open || echo closed

Старый аналог telnet host port до сих пор полезен на legacy.

Где теряется: traceroute и mtr

traceroute показывает путь пакета по hop'ам:

traceroute example.com
 1  192.168.1.1  0.5 ms
 2  10.0.0.1     2.1 ms
 3  * * *
 4  93.184.216.34  18 ms

* * * означает, что промежуточный hop не отвечает (часто намеренно).

mtr — это traceroute, который пингует каждый hop в реальном времени и показывает потери и latency по каждому. Незаменим, когда соединение лагает между конкретными точками:

mtr -r -c 100 example.com

-r report-mode, -c 100 — сто проб и итог. Где Loss% не нулевой - там проблема. mtr есть на Linux; на macOS его обычно надо ставить отдельно (brew install mtr), а флаги местами отличаются.

HTTP-диагностика: curl -v

curl -v https://example.com

Покажет:

• DNS-резолв (на какой IP пошли),
• TLS-handshake (какой сертификат, какая версия TLS),
• запрос и заголовки,
• ответ и заголовки.

Полезные варианты:

curl -I https://example.com                     # только response headers
curl -L https://example.com                     # пройти редиректы
curl --resolve host:443:1.2.3.4 https://host/   # подменить DNS-резолв
curl -w "%{time_total}\n" -o /dev/null -s https://example.com  # засечь время

--resolve особенно полезен при отладке миграций: ты ещё не сменил DNS, но уже хочешь проверить новый сервер: указываешь IP вручную.

DNS: dig

См. прошлый урок. Краткий рефреш:

dig +short example.com           # просто IP
dig example.com MX               # MX-записи
dig @8.8.8.8 example.com         # спросить конкретный resolver

Что летит по проводу: tcpdump

Когда всё остальное не помогло. tcpdump показывает пакеты:

sudo tcpdump -i any -nn 'host example.com'        # всё к/от хоста
sudo tcpdump -i any -nn 'port 5432'               # всё на порт
sudo tcpdump -i any -nn -A 'port 80'              # с расшифровкой текста (-A)
sudo tcpdump -i any -nn -w trace.pcap 'host x'    # дамп в файл (открыть в Wireshark)

Это уже не "ежедневный" инструмент. Полезен в случаях:

• "пакет уходит или нет?",
• "от меня ушло, а на той стороне не пришло",
• разбор странных задержек или ретрансмиссий.

Для нормального разбора .pcap открывай в Wireshark, он куда информативнее, чем сырой текст tcpdump.

Шпаргалка по симптомам

Симптом	Чем чинить
"сервер не отвечает"	ping, потом nc -zv host port
"у нас 502 от nginx"	ss -tulnp на backend'е, curl http://localhost:PORT оттуда же
"DNS отдаёт не тот IP"	dig, dig @8.8.8.8, проверить TTL
"ssh повис на установлении"	ssh -v, потом nc -zv host 22, потом mtr
"соединение работает медленно"	mtr -r host, curl -w '%{time_*}'
"запрос ушёл, ответ не пришёл"	tcpdump
"сервис должен быть запущен, но порт не отвечает"	ss -tulnp локально

Что важно запомнить

ip a / ip r — локальная сеть, маршруты.

ss -tulnp — кто слушает порты.

ping — базовая достижимость, но ICMP могут резать.

nc -zv host port — проверка TCP-порта без клиента протокола.

mtr — где теряется в пути.

curl -v — всё про HTTP-разговор.

tcpdump — последняя надежда, дампит сырые пакеты.

В следующем уроке разберём firewall и маршрутизацию: почему сервис жив, а снаружи недоступен, и отчего молчат ping с traceroute.