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. | Проверять с того же хоста/сети, откуда идёт реальный трафик. |