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

Разбор сетевых проблем по пакетам

Когда адрес, маршрут и DNS выглядят корректно, но сервис не работает, анализ пакетов помогает определить, передаётся ли запрос вообще. В НАЙС.ОС CLOUD прежде всего исследуют systemd-networkd, iproute2, systemd-resolved и цепочки iptables/ip6tables. Инструмент tcpdump может отсутствовать в минимальном образе; проверяйте установку до использования.

Конфиденциальность

PCAP может содержать логины, токены, DNS-запросы, внутренние адреса и открытый прикладной трафик. Храните дампы в защищённом каталоге, задавайте ограничения по времени и объёму и обезличивайте перед передачей в поддержку.

1. Сбор контекста без захвата

ip -br addr
ip route
ip -6 route
networkctl list
resolvectl status
ss -lntup
iptables -S
ip6tables -S
journalctl -b -u systemd-networkd --no-pager -n 80

Если отсутствуют адрес и маршрут, начинайте с .network, а не с пакетного захвата.

2. Поиск инструмента

command -v tcpdump || echo 'tcpdump не установлен'
rpm -q tcpdump

Если пакет отсутствует и подключены доверенные репозитории, установите его штатным пакетным менеджером, ориентируясь на пакетное руководство. Не скачивайте случайные бинарные файлы из Интернета.

3. Ограниченный захват

# Только при наличии tcpdump, с правами администратора
mkdir -p /root/net-diagnostics
chmod 700 /root/net-diagnostics

tcpdump -i ens3 -nn -s 128 -c 100 \
  -w /root/net-diagnostics/ssh-handshake.pcap \
  'tcp port 22'

Здесь -c 100 ограничивает количество пакетов, -s 128 — размер захватываемой части пакета; однако даже заголовки могут быть чувствительны. Запускайте отдельный захват для DHCP udp port 67 or udp port 68, DNS port 53 или конкретного сервиса, а не бесконтрольный -i any на весь трафик.

4. Как интерпретировать TCP

  • SYN без SYN-ACK: запрос ушёл, но ответа не видно. Возможны firewall, неправильный маршрут, сервис недоступен, фильтрация провайдера.
  • RST в ответ: порт закрыт или соединение активно отклонено — перепроверьте слушающий процесс.
  • Есть установление TCP, потом TLS ошибка: сетевой уровень вероятно исправен; переходите к сертификатам и приложению.
  • SYN виден на сервере, но ответ не уходит: проверьте ss, iptables OUTPUT, обратный маршрут и приложение.

5. Счётчики правил

iptables -L INPUT -n -v --line-numbers
iptables -L OUTPUT -n -v --line-numbers
iptables -L FORWARD -n -v --line-numbers
ip6tables -L INPUT -n -v --line-numbers

Рост счётчика конкретного правила при тестовом запросе — сильная подсказка, однако он не доказывает, что именно оно вызвало весь симптом. Не обнуляйте счётчики (-Z) на производстве без согласования с мониторингом.

6. Трассировка до соседей

ip neigh show
ip route get 192.0.2.1
ip -6 neigh show

Вместо учебного 192.0.2.1 используйте реальный шлюз. Если сосед не разрешается на L2, проблема может быть в VLAN, гипервизоре или коммутаторе до iptables.

7. После диагностики

Удалите временные дампы в соответствии с локальной политикой хранения, сохраните обезличенный журнал выявленной причины и восстановите изменённые во время диагностики настройки. Дополнительные сценарии — диагностика сети и iptables.

Источники: типовые интерфейсы tcpdump, iproute2, iptables; версия iproute2 — Core/iproute2/SPECS/iproute2.spec.