Сетевая диагностика и устранение неполадок: от базовых проверок до анализа пакетов

Сетевую проблему быстрее всего локализует последовательная проверка: определить охват сбоя, проверить интерфейс и адресацию, маршрут, DNS, доступность нужного TCP- или UDP-порта, затем снять трафик на границах проблемного участка. Такой порядок отделяет сбой приложения от ошибки маршрутизации, фильтрации или разрешения имён за несколько проверок.

Начните с вопроса: недоступен один сервис или вся сеть, проблема возникает у одного клиента или у всех, не работает имя или IP-адрес, закрыт один порт или любой трафик. Затем выполните ip addr, ip route get <IP_назначения>, ping, проверку DNS и соединения с конкретным портом. Ping подтверждает достижимость по ICMP, но не доказывает доступность приложения: межсетевой экран может пропускать ICMP и блокировать TCP/443.

Не меняйте маршруты, правила firewall или MTU до фиксации исходного состояния. Сохраните время сбоя, адрес клиента, адрес назначения, имя, порт, протокол, идентификатор запроса и список недавних изменений. Эти сведения помогут сопоставить логи, счётчики интерфейсов и пакеты из нескольких точек сети.

1. Сузьте область поиска. Проверяйте проблему по осям «клиент», «сеть», «имя», «порт» и «время». Если сервис не открывается по имени, но открывается по IP-адресу, ищите сбой в DNS, поисковом суффиксе или кеше резолвера. Если доступ есть с одного сегмента, но отсутствует из другого, сравните маршруты, ACL, security groups и правила межсетевого экрана. Если сбой начался после релиза, изменения VPN, переноса подсети или замены балансировщика, начните с этой точки.

1. Зафиксируйте точный текст ошибки и время с часовым поясом.
2. Проверьте проблему с двух независимых узлов, желательно из разных подсетей.
3. Проверьте IP-адрес назначения и имя отдельно.
4. Проверьте конкретный порт и протокол, например TCP/443 или UDP/53.
5. Сравните состояние до и после проблемного сетевого узла.

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

ip -br link
ip -br addr
ip -s link show dev ens192
ethtool ens192
ip route
ip route get 10.20.30.40
ip neigh show

Статус UP не гарантирует рабочее подключение. Счётчики RX/TX errors, dropped, carrier и collisions нужно смотреть дважды с интервалом во время воспроизведения сбоя. Рост счётчиков указывает на физический канал, перегрузку очередей, несовпадение скорости или дуплекса. В выводе ethtool проверьте Link detected, Speed и Duplex. Скорость 100 Мбит/с вместо ожидаемого 1 Гбит/с часто связана с кабелем, портом коммутатора или автосогласованием.

Команда ip route get 10.20.30.40 показывает выбранный интерфейс, next hop и исходный IP. Это надёжнее чтения таблицы маршрутизации вручную, особенно при policy routing, нескольких шлюзах или VPN. Запись FAILED у соседа в ip neigh говорит о том, что хост не получил ответ ARP или NDP в локальном сегменте.

Для Windows используйте ipconfig /all, route print, Get-NetIPConfiguration и Test-NetConnection -ComputerName 10.20.30.40 -Port 443. Полный набор команд для сравнения IP, шлюза, DNS и маршрута в двух ОС собран в руководстве по диагностике сети в Windows и Linux.

3. Отделите маршрут от доступности приложения. Проверяйте связь последовательно: локальный шлюз, адрес в удалённой подсети, нужный TCP-порт, ответ самого протокола. Пример для Linux:

ping -c 4 192.0.2.1
ping -c 4 10.20.30.40
tracepath 10.20.30.40
traceroute -n 10.20.30.40
nc -vz -w 3 10.20.30.40 443
ss -ltnp

Потеря ответов на ping не всегда означает обрыв: ICMP часто ограничивают или отключают. Успешный nc на TCP/443 подтверждает трёхстороннее TCP-рукопожатие, но не работоспособность HTTP, TLS или авторизации. Если соединение установлено, а клиент получает ошибку приложения, проверьте журнал сервиса, конфигурацию прокси и сертификаты.

Traceroute и tracepath показывают предполагаемый путь, но промежуточные маршрутизаторы могут не отвечать на TTL-expired. Последний отвечающий hop не всегда виноват в сбое. Сравните трассировку с рабочего и проблемного сегмента, затем проверьте маршрут командой ip route get на каждом подконтрольном узле. Для сложных случаев с асимметричной маршрутизацией, VPN и ARP используйте чек-лист диагностики маршрутизации.

4. Проверьте DNS отдельным сценарием. Ошибка резолвинга часто маскируется под недоступность сервиса. Сравните ответ системного резолвера и конкретного DNS-сервера, проверьте тип записи, TTL, поисковый суффикс и IPv4/IPv6.

getent ahosts api.internal
resolvectl query api.internal
dig api.internal A +time=2 +tries=1
dig @10.10.0.53 api.internal A +time=2 +tries=1
cat /etc/resolv.conf

NXDOMAIN означает, что имя не найдено в запрошенной зоне. SERVFAIL указывает на ошибку обработки запроса сервером или его зависимостями. Тайм-аут говорит о недоступности DNS-сервера, фильтрации UDP/TCP 53 либо неверном маршруте. Если ответ по IP DNS-сервера приходит, а через системный резолвер нет, проверьте порядок серверов, split DNS, VPN-клиент, локальный кеш и search domain.

DNS-запросы с крупным ответом могут переключаться на TCP или фрагментироваться. Поэтому после проверки UDP/53 протестируйте TCP/53, если зона содержит DNSSEC-записи, крупные TXT-записи или много адресов. В контейнерных средах отдельно сравнивайте /etc/resolv.conf внутри контейнера и на хосте.

5. Найдите блокировку порта. Проверка должна охватывать процесс, локальный firewall, сетевой firewall и обратный путь. На сервере убедитесь, что процесс слушает нужный адрес, а не только 127.0.0.1:

ss -ltnp '( sport = :443 )'
sudo nft list ruleset
sudo iptables -S
sudo firewall-cmd --list-all

Повторяющиеся SYN от клиента без SYN-ACK в захвате на сервере означают, что запрос не дошёл до хоста. SYN виден на сервере, но ответ SYN-ACK отсутствует, проверьте listener и локальные правила. SYN-ACK уходит с сервера, но клиент его не получает, ищите асимметричный маршрут, фильтр обратного направления, неверный NAT или состояние connection tracking. Немедленный RST обычно указывает на закрытый порт, отсутствие listener или правило REJECT.

6. Исключите проблему MTU. MTU проявляется как зависание после успешного подключения: TCP-рукопожатие проходит, небольшие запросы работают, загрузка страницы, репликация или VPN-трафик обрываются. Для Ethernet с MTU 1500 IPv4-пакет ICMP обычно проверяют payload размером 1472 байта, потому что IP- и ICMP-заголовки занимают 28 байт.

ping -M do -s 1472 -c 3 10.20.30.40
ping -M do -s 1400 -c 3 10.20.30.40
tracepath 10.20.30.40
ip link show dev ens192

Если 1472 байта не проходят без фрагментации, а 1400 проходят, проверьте MTU туннелей, VLAN, PPPoE и оверлейной сети. Не снижайте MTU на одном интерфейсе без проверки обоих концов туннеля и маршрута. После изменения повторите тест передачи реальной нагрузки: ICMP-пакеты не заменяют TCP-сессию с TLS, крупными сегментами и MSS.

7. Снимите пакеты в точке принятия решения. Tcpdump нужен, когда команды показывают симптом, но не объясняют его причину. Захват начинайте с узкого фильтра, чтобы не получить гигабайты нерелевантного трафика.

sudo tcpdump -ni any -nn 'host 10.20.30.40 and tcp port 443'
sudo tcpdump -ni ens192 -nn -s 0 -w incident-443.pcap 'host 10.20.30.40 and tcp port 443'
sudo tcpdump -ni any -nn 'udp port 53'

Ключ -s 0 сохраняет полный пакет, что требуется для разбора заголовков и полезной нагрузки, если политика безопасности это допускает. Pcap-файл может содержать токены, cookie, персональные данные и внутренние адреса. Ограничьте доступ к файлу, задайте короткий интервал захвата и не передавайте запись за пределы разрешённого контура без очистки чувствительных данных.

В Wireshark применяйте фильтры tcp.flags.syn == 1 && tcp.flags.ack == 0, tcp.analysis.retransmission, tcp.analysis.duplicate_ack и dns.flags.rcode != 0. Повторные передачи вместе с duplicate ACK часто указывают на потери или нарушение порядка пакетов. Большая пауза между запросом и ответом при отсутствии ретрансляций сдвигает поиск к приложению, базе данных, upstream-сервису или перегруженному серверу.

Снимайте трафик одновременно на клиенте и сервере, если подозреваете сетевой участок. Синхронизируйте часы через корпоративный источник времени и сравните один TCP-поток по пятёрке параметров: source IP, source port, destination IP, destination port, protocol. Пакет, который есть на клиенте и отсутствует на сервере, исчезает по пути. Пакет, который сервер отправил, но клиент не увидел, требует проверки обратного маршрута.

8. Диагностируйте низкую скорость контролируемо. Подключите тестовый компьютер к роутеру по Ethernet, остановите фоновые загрузки, VPN, обновления и синхронизацию облачных хранилищ. Запускайте одинаковый тест утром, вечером и в часы пик через один сервер. Сохраняйте скорость загрузки, скорость отдачи, задержку и потери пакетов. Проблема на одном устройстве чаще связана с адаптером, драйвером или Wi-Fi; стабильное снижение скорости по кабелю на разных устройствах требует проверки канала и обращения к провайдеру.

9. Завершите проверкой уровня приложения. Если сеть и порт доступны, разберите коды ответов, время обработки и ошибки upstream. Для веб-сервисов сопоставьте время пакетов с access- и error-логами Nginx или Apache. Готовые команды поиска 404, 500, медленных запросов и признаков атак есть в шпаргалке по анализу логов Nginx и Apache.

Рабочий результат диагностики содержит причину, затронутые сервисы, проверку после исправления и безопасный способ отката. Формулировка «сеть восстановлена» без этих данных не помогает предотвратить повторный сбой.

После исправления повторите исходный сценарий с того же клиента, проверьте имя, IP, порт и прикладной запрос. Затем сохраните команды, pcap-фильтр, изменения конфигурации и итоговые показатели задержки или потерь в журнале инцидента. Эта запись сократит время поиска при следующем сбое.