Сетевая диагностика

Что такое Сетевая диагностика

Сетевая диагностика — поиск ответа на вопрос «почему не работает» с помощью инструментов, показывающих, где именно рвётся путь между двумя узлами. Отдельного «прибора» тут нет: есть набор утилит, каждая из которых проверяет свой уровень.

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

L1  линк есть?              ip link show, ethtool eth0
L2  соседи видны?           ip neigh
L3  адрес, маршрут, пинг    ip addr, ip route, ping, mtr
L4  порт слушается?         ss -tlnp, nc -zv
L7  сервис отвечает?        curl -v, dig

Базовый набор

$ ping -c4 8.8.8.8            # есть ли связность и какая задержка
$ ip route get 8.8.8.8        # каким интерфейсом и шлюзом пойдёт пакет
$ dig +short example.com      # резолвится ли имя
$ ss -tlnp                    # что слушает на этой машине
$ nc -zv example.com 443      # открыт ли порт снаружи
$ curl -v https://example.com # что отвечает приложение

Порядок неслучаен: половина «сетевых» проблем оказывается DNS или закрытым портом. Пинг по IP идёт, а по имени нет — виноват резолвинг, а не сеть.

Полезная деталь про ping: он использует ICMP, а его часто режут. Молчание в ответ на пинг не доказывает, что хост недоступен, — проверяйте порт через nc.

MTR и WinMTR: где теряются пакеты

traceroute показывает маршрут одним снимком, mtr — непрерывно, совмещая трассировку с пингом каждого узла: именно он отвечает на вопрос «на каком участке начались потери». WinMTR — тот же инструмент для Windows с графическим интерфейсом; хостеры и провайдеры обычно просят прислать именно его вывод, потому что он показывает картину по всему пути, а не только конечную точку.

$ mtr -rwc 100 example.com
HOST: myserver                    Loss%   Snt   Last   Avg  Best  Wrst
  1. 10.0.0.1                      0.0%   100    0.4   0.5   0.3   1.2
  2. 203.0.113.1                   0.0%   100    1.2   1.4   1.1   8.3
  3. core-r1.isp.net              12.0%   100   14.8  15.1  14.2  22.7
  4. ix-peer.example.net           0.0%   100   41.2  41.5  40.8  49.1
  5. example.com                   0.0%   100   41.4  41.6  41.0  47.2

Как читать этот вывод — тут почти все ошибаются:

• Потери на промежуточном узле, которых нет дальше, — не проблема. Строка 3 показывает 12% потерь, но узлы 4 и 5 чистые. Значит, маршрутизатор просто не торопится отвечать на ICMP (это низкоприоритетная для него задача), а транзитный трафик идёт нормально.
• Реальная проблема — потери, которые начались и не исчезли до конца пути. Только тогда участок виноват.
• Рост задержки на узле — тоже норма, если дальше она не растёт: важна последняя строка.

Замер скорости: iperf

iperf3 — стандартный инструмент для измерения реальной пропускной способности между двумя узлами. В отличие от онлайн-спидтестов, он меряет ваш конкретный маршрут и не зависит от чужого перегруженного сервера.

Нужны обе стороны: сервер и клиент.

# на одной машине
$ iperf3 -s
Server listening on 5201

# на второй
$ iperf3 -c 10.0.0.5 -t 30 -P 4
[SUM]   0.00-30.00  sec  32.6 GBytes  9.34 Gbits/sec    0   sender
[SUM]   0.00-30.04  sec  32.6 GBytes  9.32 Gbits/sec        receiver

Практические тонкости:

• -P 4 (несколько потоков) обязателен на длинных плечах. Один TCP-поток не утилизирует «толстый и далёкий» канал из-за окна и контроля перегрузки. Гигабит внутри ЦОД одним потоком снимается, между континентами — нет.
• 9,3 Гбит/с на карте 10 Гбит/с — это отличный результат, а не потеря: накладные расходы заголовков никуда не деваются.
• -u для UDP покажет джиттер и потери — то, что важно для IP-телефонии.
• Порт 5201 должен быть открыт на сервере.

Что смотреть глубже

$ sudo tcpdump -i eth0 -nn port 443      # кто и куда реально ходит
$ ip -s link show eth0                   # дропы и ошибки на интерфейсе
$ ethtool -S eth0 | grep -i -E "drop|error"
$ nstat -az | grep -i retrans            # ретрансмиты TCP

Растущие rx_dropped и errors означают железо или кабель, а не приложение. Массовые ретрансмиты — потери на пути: связка mtr плюс iperf3 даёт готовый отчёт для провайдера.

Отдельно держите в голове MTU: пинг идёт, порт открыт, а большие ответы виснут — в общий чек-лист этот симптом не укладывается.

Связанные термины

• Модель OSI — порядок проверки уровней
• Сетевые порты — что проверяют через ss и nc
• DNS — виновник половины «сетевых» инцидентов
• MTU и MSS — проблемы, которые пингом не ловятся
• throughput — то, что меряет iperf
• Каналы связи — где ищут потери и задержку