Как диагностировать сетевые проблемы в Linux

Диагностика сетевых проблем в Linux: структурированный подход

Диагностика сетевых проблем в Linux — критически важный навык для DevOps-инженера. Я выработал системный подход, который начинается с проверки базовых слоёв и постепенно переходит к сложным взаимодействиям. Вот моя методология, проверенная на практике.

1. Проверка базовой сетевой конфигурации

Сначала убеждаемся, что сетевая конфигурация корректна. Используем ip (предпочтительно) или устаревший ifconfig.

# Проверка интерфейсов и их состояния
ip addr show
# или подробный вывод по конкретному интерфейсу
ip -4 addr show eth0

# Проверка маршрутов
ip route show
# Проверка таблицы маршрутизации для конкретного адреса
ip route get 8.8.8.8

Ключевые моменты:

• Интерфейс должен быть в состоянии UP.
• Присутствует корректный IP-адрес (нет конфликтов или неверных масок).
• Маршрут по умолчанию (default via) указан и ведёт на корректный шлюз.
• Если используется DHCP, проверяем журналы (journalctl -u NetworkManager или journalctl -u systemd-networkd).

2. Проверка доступности сетевых узлов (L3)

Далее тестируем связность на сетевом уровне. Начинаем с проверки доступности шлюза по умолчанию.

# Быстрый ping до шлюза (смотрим на потерю пакетов и время отклика)
ping -c 4 <шлюз>

# Если ping до шлюза не проходит, проверяем ARP-таблицу
ip neigh show
# Нужная запись должна быть в состоянии REACHABLE или STALE, а не FAILED

# Проверка доступности удалённого хоста (например, DNS-сервера Google)
ping -c 4 8.8.8.8

Важно: Если ping до IP-адреса проходит, но до имени хоста — нет, проблема почти гарантированно в DNS.

3. Диагностика DNS (разрешение имён)

Проблемы с DNS — одни из самых частых. Проверяем конфигурацию и сам процесс разрешения.

# Смотрим, какие DNS-серверы прописаны в системе
cat /etc/resolv.conf

# Проверяем работу DNS с помощью dig или nslookup
dig google.com
# Обращаем внимание на флаг "status: NOERROR" и время ответа

# Проверяем, как система резолвит имя (можно увидеть влияние /etc/hosts)
getent hosts google.com

Совет: Если /etc/resolv.conf постоянно перезаписывается (например, NetworkManager), конфигурацию DNS нужно менять в главном конфигурационном файле сетевого менеджера или через nmcli.

4. Проверка портов и сетевых служб (L4)

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

# Какие порты слушает система? (ss предпочтительнее netstat)
ss -tulnp
# Ключи: -t (TCP), -u (UDP), -l (listen), -n (numeric), -p (process)

# Пример фильтрации: что слушает порт 80?
ss -tlnp sport = :80

# Проверка извне: доступен ли порт на удалённом хосте?
# Используем netcat (nc) или telnet
nc -zv <удалённый_хост> 443
# Если соединение успешно, увидим "succeeded!"

5. Анализ трафика (глубокая диагностика)

Если проблема тонкая (обрыв соединений, странные таймауты, проблемы с производительностью), переходим к сниффингу трафика.

# Захват пакетов на интерфейсе в файл (требует прав root)
tcpdump -i eth0 -w capture.pcap host <целевой_хост> and port <целевой_порт>

# Более простой анализ в реальном времени для HTTP/HTTPS
# (покажет основные заголовки, но не расшифрует TLS)
tcpdump -i eth0 -A 'tcp port 80'

# Инструмент высшего уровня для анализа проблем с соединением
tcptraceroute <целевой_хост> 443

Для детального анализа открываем capture.pcap в Wireshark. Ищем:

• TCP retransmissions (повторные передачи) — указывают на потерю пакетов.
• SYN без ответа SYN-ACK — порт закрыт или блокируется фаерволом.
• Ненормально высокие задержки (ACK delay).

6. Проверка брандмауэра

Частая причина — неверные правила iptables/nftables или firewalld.

# Просмотр правил iptables для фильтрации (таблица filter)
iptables -L -n -v

# Просмотр правил NAT (таблица nat)
iptables -t nat -L -n -v

# Для современных систем с nftables
nft list ruleset

# Если используется firewalld
firewall-cmd --list-all

Совет: Для быстрой проверки можно временно отключить брандмауэр (systemctl stop firewalld), но НИКОГДА не оставляйте так в production! Правильнее — добавить разрешающее правило и логировать блокировки (iptables -A INPUT -p tcp --dport 80 -j LOG).

7. Анализ системных ограничений и производительности

Проблемы могут быть не в сети, а в ограничениях самой ОС.

# Проверка лимитов на количество открытых файлов (влияет на сокеты)
ulimit -n
# Для конкретного процесса
cat /proc/<PID>/limits | grep open.files

# Проверка статистики сети
# Ошибки, переполнения буферов (errs, drop)
ip -s link show eth0

# Мониторинг сетевых соединений в реальном времени (отличный инструмент)
iftop -i eth0
# Покажет, кто больше всего "качает"

Сводный чек-лист для быстрой реакции

Когда поступает алерт "сеть не работает", я иду по этому списку:

1. ip addr show — интерфейс UP? Есть IP?
2. ip route show — есть маршрут до цели/шлюза?
3. ping <шлюз> — есть ли L3-связность до первого хопа?
4. ping 8.8.8.8 — есть ли связность "наружу"?
5. dig google.com — работает ли DNS?
6. ss -tlnp — слушает ли моя служба на нужном порту и интерфейсе (0.0.0.0 или конкретный IP)?
7. nc -zv <хост> <порт> — могу ли я подключиться к удалённой службе?
8. iptables -L -n -v / firewall-cmd --list-all — не блокирует ли фаервол?
9. tcpdump... — если всё выше пройдено, проблема в самом обмене данными, нужен захват пакетов.

Главный принцип — двигаться от простого к сложному, от нижних слоёв (кабель, интерфейс) к верхним (приложение). Часто проблема оказывается в неверной маршрутизации или DNS, а не в "поломанной сети". Всегда проверяйте журналы (/var/log/syslog, journalctl) на предмет сетевых ошибок.