Диагностика сетевых проблем [205.3]

Рейтинг: 72.2% · 10 голосов
Курс LPIC-2 (201-450 и 202-450): емкостное планирование, ядро, хранилище и RAID/LVM, продвинутая сеть, DNS/BIND, Apache/Nginx, Samba/NFS, DHCP/LDAP, почта, безопасность и VPN.
Ответить
Аватара пользователя
Sergey_Sysadmin
Сообщения: 134
Зарегистрирован: 11 май 2026, 05:31

Диагностика сетевых проблем [205.3]

Сообщение Sergey_Sysadmin »

Оглавление курса (41)
  1. Введение в LPIC-2 и уровень инженера
  2. Измерение и устранение проблем с ресурсами [200.1]
  3. Прогнозирование потребности в ресурсах
  4. Компоненты ядра Linux [201.1]
  5. Сборка ядра из исходников [201.2]
  6. Управление модулями ядра в рантайме [201.3]
  7. Кастомизация запуска системы [202.1]
  8. Восстановление системы [202.2]
  9. Альтернативные загрузчики [202.3]
  10. Работа с файловой системой Linux [203.1]
  11. Обслуживание файловых систем [203.2]
  12. Создание и настройка опций ФС [203.3]
  13. Программный RAID [204.1]
  14. Тюнинг доступа к устройствам хранения [204.2]
  15. Менеджер логических томов LVM [204.3]
  16. Базовая конфигурация сети [205.1]
  17. Продвинутая конфигурация сети [205.2]
  18. Диагностика сетевых проблем [205.3] (вы здесь)
  19. Сборка и установка программ из исходников [206.1]
  20. Резервное копирование [206.2]
  21. Оповещение пользователей о событиях
  22. DNS-сервер BIND: базовая настройка [207.1]
  23. Зоны DNS: создание и сопровождение [207.2]
  24. Безопасность DNS-сервера [207.3]
  25. Веб-сервер Apache: базовая настройка [208.1]
  26. Apache и HTTPS [208.2]
  27. Кэширующий прокси Squid [208.3]
  28. Веб-сервер и обратный прокси Nginx [208.4]
  29. Файловый сервер Samba [209.1]
  30. Файловый сервер NFS [209.2]
  31. DHCP-сервер [210.1]
  32. Аутентификация PAM и SSSD [210.2]
  33. Использование LDAP-клиента
  34. Сервер OpenLDAP [210.4]
  35. Почтовый сервер Postfix [211.1]
  36. Управление доставкой почты и Sieve [211.2]
  37. Доступ к почтовым ящикам: Dovecot [211.3]
  38. Linux как маршрутизатор и фильтр [212.1]
  39. FTP-серверы [212.2]
  40. SSH углублённо [212.3]
  41. Безопасность, IDS и VPN [212.4 + 212.5]
Урок 17. Диагностика сетевых проблем [205.3]

Сеть не работает - и это самый частый и самый размытый тикет в жизни администратора. Задача урока - научить вас не тыкать команды наугад, а двигаться по слоям снизу вверх: есть ли линк и адрес, видит ли машина шлюз, доходит ли пакет до удалённого хоста, не теряется ли он по дороге, отвечает ли нужный порт, резолвится ли имя. Каждый слой отсекает половину гипотез. В итоге вы локализуете проблему до конкретного звена, а не пересказываете начальству, что пинг не идёт.

Изображение

Как это работает

Сетевой стек - это уровни, и проблема всегда живёт на каком-то одном из них. Снизу вверх: физика и канальный уровень (линк, MAC, ARP), сетевой (IP-адрес, маршрут, шлюз), транспортный (TCP/UDP, порты, состояние сокетов), прикладной (DNS, сам сервис). Методика проста: проверяй слой за слоем и не лезь выше, пока нижний не подтверждён. Если у интерфейса нет IP, бессмысленно дебажить DNS.

Канальный уровень - это ARP. Чтобы отправить IP-пакет соседу в той же подсети, ядро должно знать его MAC. Оно спрашивает широковещательно who-has, кэширует ответ в ARP-таблице. Дубликат IP в сети проявляется именно здесь: два хоста отвечают на один ARP-запрос, и связь становится мерцающей в зависимости от того, чей ответ пришёл последним.

Сетевой уровень - маршрутизация. Ядро смотрит таблицу маршрутов и выбирает, в какой интерфейс и на какой next-hop отдать пакет. Тут возникает асимметричная маршрутизация: пакет уходит одним путём, а ответ возвращается другим. Само по себе это законно, но ломается на stateful-фаерволах и при включённом rp_filter (reverse path filtering), который отбрасывает пакет, пришедший не с того интерфейса, через который ушёл бы ответ.

Отдельная боль - MTU и фрагментация. MTU это максимальный размер кадра. Если на пути есть звено с меньшим MTU (типичный случай - VPN или PPPoE, где -50 или -80 байт), большой пакет с установленным флагом DF (Don't Fragment) должен породить ICMP-сообщение "fragmentation needed". Если файрвол по дороге режет весь ICMP, отправитель не узнаёт о проблеме - это PMTUD blackhole. Симптом классический: ping и ssh-логин проходят, а реальная передача данных (большие страницы, scp) виснет.

Команды и примеры

Слой 1-2: линк, адрес, ARP. Команда ip заменила ifconfig/arp/route везде.

Код: Выделить всё

ip -br link            # краткий статус интерфейсов: UP/DOWN
ip -br addr            # адреса в одну строку на интерфейс
ip neigh show          # ARP/NDP кэш (REACHABLE, STALE, FAILED)
ip -s link show eth0   # счётчики ошибок, дропов, коллизий
Дубликат IP ловится так: если ip neigh для соседа постоянно мигает между разными lladdr - в сети два хозяина одного адреса. Проверка вручную с помощью arping:

Код: Выделить всё

arping -D -I eth0 192.0.2.10   # -D: duplicate address detection
# ненулевой код возврата и ответ с чужого MAC = дубликат
Слой 3: маршруты и шлюз.

Код: Выделить всё

ip route get 8.8.8.8   # покажет, КАКОЙ маршрут и интерфейс выберет ядро
ip route show          # вся таблица
ip rule show           # policy routing, если маршрутизация многотабличная
ip route get - самая недооценённая команда: она показывает реальное решение ядра, а не то, что вы думаете о таблице.

Слой 4: сокеты и порты. ss заменил netstat.

Код: Выделить всё

ss -tlnp               # слушающие TCP-порты с именами процессов
ss -tn state established   # установленные соединения
ss -s                  # сводка по сокетам
Достижимость и потери. ping проверяет L3, traceroute и mtr показывают путь.

Код: Выделить всё

ping -c 4 -M do -s 1472 192.0.2.1   # тест MTU: DF + 1472+28=1500 байт
mtr -rwc 100 cyberlake.ru           # 100 циклов, отчёт по потерям на каждом хопе
traceroute -n -T -p 443 cyberlake.ru  # TCP-трейс на 443, обходит ICMP-фильтры
Если ping с -M do -s 1472 не проходит, а с меньшим размером проходит - проблема MTU на пути. В mtr смотрите не на потери на одном промежуточном хопе (роутеры часто деприоритизируют ICMP к себе - это нормально), а на потери, которые тянутся до конца пути.

DNS - прикладной слой. dig вместо устаревшего nslookup.

Код: Выделить всё

dig +short cyberlake.ru
dig @1.1.1.1 cyberlake.ru A     # спросить конкретный сервер в обход локального
dig +trace cyberlake.ru        # пройти делегирование от корня
dig -x 192.0.2.10              # обратная зона PTR
Различия дистрибутивов в основном в установке инструментов. Debian/Ubuntu:

Код: Выделить всё

apt install iproute2 iputils-ping traceroute mtr-tiny dnsutils
RHEL 10 / Fedora 41+:

Код: Выделить всё

dnf install iproute iputils traceroute mtr bind-utils
Для проверки L4 на хосте без telnet удобен встроенный bash /dev/tcp или ncat (nmap-ncat в RHEL, ncat/netcat-openbsd в Debian):

Код: Выделить всё

ncat -zv cyberlake.ru 443
echo > /dev/tcp/cyberlake.ru/443 && echo open
Частые грабли
  • Делать выводы по ICMP-потерям на промежуточном хопе mtr. Роутеры режут ICMP к себе - судите только по конечному хопу.
  • Списывать всё на DNS, не проверив L3. Если ip route get не даёт маршрут, dig вообще ни при чём.
  • Забыть про rp_filter при асимметрии. sysctl net.ipv4.conf.all.rp_filter в режиме 1 молча дропает обратный трафик - смотрите счётчик в /proc/net/netstat.
  • Тестировать MTU без флага DF. Без -M do ядро фрагментирует пакет само и вы ничего не увидите.
  • Путать "порт закрыт" и "порт фильтруется". ncat с reject (RST) - порт закрыт, таймаут - чаще файрвол.
  • Доверять кэшу ARP/DNS. STALE-запись или закэшенный старый адрес дают фантомные симптомы. Сбросьте: ip neigh flush dev eth0, resolvectl flush-caches.
  • Гонять ping до домена и думать, что проверили сервис. ICMP жив, а 443-й порт может лежать.
Мини-лаба
  • На стенде с двумя машинами в одной подсети снимите ip -br addr и ip neigh show, запомните MAC соседа.
  • Намеренно поднимите на второй машине IP первой (ip addr add), запустите arping -D с первой и зафиксируйте обнаружение дубликата. Уберите конфликт.
  • Уменьшите MTU на интерфейсе до 1400 (ip link set eth0 mtu 1400) и подберите ping -M do -s, при котором пакет перестаёт проходить. Посчитайте: размер + 28 = ваш реальный MTU.
  • Заблокируйте исходящий ICMP type 3 на промежуточном узле и воспроизведите PMTUD blackhole: маленький ping идёт, scp большого файла виснет.
  • Прогоните mtr -rwc 50 до внешнего хоста и до соседа, сравните, где появляются устойчивые потери.
  • Сравните dig +short и dig @8.8.8.8 для одного имени - найдите расхождение, если локальный резолвер кэширует старую запись.
Контрольные вопросы
  • В каком порядке вы проверяете слои при жалобе "не открывается сайт" и почему именно снизу вверх?
  • Чем ip route get отличается от ip route show и когда первая команда незаменима?
  • Как формула размера пакета связана с -s в ping и реальным MTU канала? Почему +28?
  • Почему потери на промежуточном хопе в mtr могут быть ложными, а на конечном - нет?
  • Что такое rp_filter и как он связан с асимметричной маршрутизацией?
  • Как отличить закрытый порт от отфильтрованного по поведению ncat?
👍4 ❤️2 🔥1 😄 🤔1
Аватара пользователя
envoyfan
Сообщения: 1
Зарегистрирован: 15 май 2026, 07:38

Re: Диагностика сетевых проблем [205.3]

Сообщение envoyfan »

А mtr -T под рутом обязательно? У меня обычный пользователь и ICMP-режим выдаёт permission denied, а TCP-режим вроде работает.
👍1 ❤️1 🔥 😄 🤔2
Аватара пользователя
vlad99
Сообщения: 1
Зарегистрирован: 22 май 2026, 00:12

Re: Диагностика сетевых проблем [205.3]

Сообщение vlad99 »

Поймал ровно тот случай с MTU на работе: через VPN сайты открывались наполовину, ssh летал. Снизил MTU до 1400 на туннеле и всё ожило. Респект за -28.
👍 ❤️ 🔥 😄 🤔
Ответить
← Предыдущая глава
Продвинутая конфигурация сети [205.2]
Следующая глава →
Сборка и установка программ из исходников [206.1]

Все главы курса «LPIC-2: инженер Linux (201 + 202)»

Поделиться темой: ✈ Telegram VK

Вернуться в «LPIC-2: инженер Linux»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость