Перейти к содержанию

9. Observability и отладка сети


Инструменты (tcpdump, Wireshark, mtr, curl, iperf) и системный подход к root cause: DNS → маршрутизация → firewall → L7.


Инструменты

tcpdump

Захват пакетов на интерфейсе, фильтрация по протоколу, хосту, порту. Работает в консоли без GUI; вывод можно сохранять в файл и открывать в Wireshark.

# Все пакеты на eth0
tcpdump -i eth0

# Только порт 443, с выводом в файл
tcpdump -i eth0 port 443 -w capture.pcap

# Хост и порт
tcpdump -i eth0 host 10.0.0.1 and port 80

Использование: проверить, доходят ли пакеты до интерфейса, есть ли ответы, ретрансмиты, RST. См. также раздел 1 и 3.

Wireshark

Графический анализатор трафика: открытие pcap-файлов (в т.ч. снятых tcpdump), разбор по уровням (L2–L7), фильтры, статистика. Удобен для разбора сложных кейсов и демонстраций. На серверах без GUI захват делают tcpdump, файл копируют и открывают в Wireshark локально.

mtr

Комбинация ping и traceroute: непрерывно показывает путь до хоста и потери/задержки на каждом прыжке. Полезно при нестабильной связи и определении узла, на котором теряются пакеты или растёт latency.

mtr -r -c 10 8.8.8.8   # отчёт за 10 циклов
mtr 8.8.8.8             # интерактивный режим

curl

Проверка L7: HTTP/HTTPS запросы, заголовки, коды ответа, таймауты. См. раздел 5.

curl -v https://example.com/
curl -v --connect-timeout 5 https://api.example.com/health

iperf3

Измерение пропускной способности и задержки между двумя хостами (TCP или UDP). Один узел — сервер (iperf3 -s), второй — клиент (iperf3 -c <server>). Используется для проверки «трубы» между серверами, выявления узких мест и потерь.

# Сервер
iperf3 -s

# Клиент (TCP, 10 сек)
iperf3 -c <server_ip> -t 10

# UDP, 100 Mbit/s
iperf3 -c <server_ip> -u -b 100M

Подход к отладке по шагам

Систематическая проверка снизу вверх (или от «клиента» к «серверу») сокращает время поиска причины.

1. Проверка DNS

Если приложение обращается по имени и не получает ответ:

  • Резолвится ли имя с проблемного хоста: nslookup <name>, dig <name>.
  • Резолвится ли через другой резолвер: dig @8.8.8.8 <name> — если да, проблема в локальном DNS или upstream.
  • Проверить /etc/resolv.conf, доступность резолвера (ping, порт 53).

Подробнее — раздел 4.

2. Проверка маршрутизации

Доходят ли пакеты до целевого хоста:

  • С проблемного узла: ip route get <IP_назначения> — какой интерфейс и next hop.
  • Есть ли связность: ping <IP>, mtr <IP> — потери, задержка, на каком прыжке обрыв.
  • С целевого узла обратно к источнику — маршрут может быть асимметричным; проверить default route и правила NAT (кто подменяет источник и куда пойдёт ответ).

Подробнее — разделы 2 и 6.

3. Проверка firewall

Пакеты доходят до интерфейса, но приложение не получает:

  • На целевом хосте: ss -tlnp — слушает ли приложение и на каком адресе (0.0.0.0 или 127.0.0.1).
  • Правила фильтрации: iptables -L -n -v, nft list ruleset — нет ли DROP/REJECT для нужного порта в INPUT (и для пересылаемого трафика — в FORWARD).
  • Conntrack: при использовании stateful правил и NAT проверить, что сессия видна (conntrack -L) и таблица не переполнена.

Подробнее — раздел 6.

4. Проверка L7

Связность есть, порт открыт, но приложение не отвечает или отдаёт ошибку:

  • curl -v по URL — код ответа, заголовки, таймаут. 502/504 — проблема за прокси (upstream); 4xx — запрос или авторизация.
  • TLS: openssl s_client -connect host:443 -servername host — handshake, цепочка сертификатов, имя в SNI.
  • Логи приложения и прокси (Nginx, Envoy) — на каком этапе отказ.

Подробнее — разделы 5 и 7.

!!! tip "Практика"

Чек-лист при инциденте «не работает связь»: (1) DNS — резолвится ли имя; (2) маршрут и связность — ping/mtr до IP; (3) firewall и слушающий порт — ss, iptables; (4) L7 — curl, код ответа, TLS. По месту обрыва сужаем зону и смотрим логи/метрики следующего уровня.

Паттерны и антипаттерны

Паттерн Описание
Идти по слоям (DNS → L3 → firewall → L7) Не перескакивать: если DNS не резолвит, L7 не поможет.
Проверять с обеих сторон С клиента и с сервера: tcpdump на обоих концах, маршрут в обе стороны.
Фиксировать трафик при воспроизведении tcpdump во время воспроизведения проблемы — потом разбор в Wireshark.
Антипаттерн Почему плохо Что делать
Сразу копать в приложении Часто причина в DNS, маршруте или firewall. Сначала быстрая проверка DNS, ping, ss, firewall.
Проверять только «со своей машины» Split-horizon DNS, другой маршрут, другой firewall. Проверять с того же хоста/сети, откуда идёт реальный трафик.

Дополнительные материалы