OPS Troubleshooting и packet capture — навык №1 на работе

Настроить сеть способен и junior по методичке. Чинить, когда «не работает» и неясно почему — вот за что платят. Это финальный модуль трека: он связывает всё предыдущее в единую методологию. Не «тыкать наугад», а действовать системно — сужать область, проверять гипотезы, читать пакеты. Это же мышление переносится в DevOps один в один.

Что узнаешь

Почему «методичный» инженер чинит в разы быстрее «интуитивного»
Четыре методологии: bottom-up, top-down, follow-the-path, divide-and-conquer
Как сужать проблему по модели OSI снизу вверх
Структурированный процесс: симптом → гипотеза → проверка → вывод
Инструменты: ping, traceroute/mtr, tcpdump, Wireshark — что когда
Где ставить захват пакетов, чтобы увидеть проблему
Главные display-фильтры Wireshark
Разбор реальных сценариев: «медленно», «рвётся», «не резолвится», «MTU»
Мост в DevOps: та же методология в отладке приложений и кластеров

1. Мышление: гипотеза, а не догадка

Разница между junior и senior — не в количестве известных команд, а в дисциплине поиска. Senior не «пробует всё подряд», он:

точно формулирует симптом («что именно не работает, для кого, с какого момента»);
выдвигает гипотезу («похоже, нет обратного маршрута»);
делает одну проверку, которая гипотезу подтвердит или опровергнет;
фиксирует результат и сужает область — и так до причины.

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

2. Четыре методологии

Метод	Суть	Когда применять
Bottom-up	снизу вверх по OSI: кабель → линк → IP → транспорт → приложение	«вообще ничего не работает», физические подозрения
Top-down	сверху вниз: от приложения к физике	«одно приложение барахлит», остальное ок
Follow-the-path	идём по реальному пути пакета хоп за хопом	проблема «где-то между A и B»
Divide-and-conquer	проверяем середину пути/стека, отсекаем половину	длинный путь/стек, хотим быстро локализовать

Bottom-up по OSI: проверяем уровень за уровнем

Самая частая стартовая стратегия: 80% проблем сидят на L1–L3, и их быстро видно снизу.

3. Вопросы на каждом уровне OSI

L1: линк up? есть свет/сигнал? правильный кабель/SFP? нет ли ошибок/CRC на порту (show interface)?
L2: в нужном ли VLAN порт? есть ли MAC в таблице? резолвится ARP? нет ли STP-блокировки/петли?
L3: правильный IP/маска? есть ли маршрут туда и обратно? верный gateway? не мешает ли NAT?
L4: порт реально слушается? не режет ли ACL/firewall? видны ли SYN без SYN-ACK?
L7: резолвится ли DNS в правильный IP? валиден ли TLS-сертификат? что в логах приложения?

🌉 Этот OSI-чеклист — универсальная отмычка и в DevOps. «Сервис в Kubernetes недоступен» проверяется тем же путём: под жив (L1/L7 контейнера) → Service/endpoints (L3/L4) → NetworkPolicy/SG (L4) → DNS (CoreDNS, L7) → Ingress/сертификат (L7).

4. Инструменты: что когда

Инструмент	Отвечает на вопрос
`ping`	есть ли L3-связность и какая задержка/потери
`traceroute` / `mtr`	по какому пути идёт трафик и на каком хопе проблема
`ip route get` / `show ip route`	каким маршрутом пакет уйдёт (до отправки)
`ss` / `show ip ... brief`	слушается ли порт, в каком состоянии соединения
`dig` / `nslookup`	правильно ли резолвится DNS
`tcpdump` / Wireshark	что РЕАЛЬНО летит по проводу — последняя инстанция истины

mtr = traceroute + ping в реальном времени. Показывает потери и задержку на каждом хопе непрерывно — идеален для «иногда тормозит». Часто это лучший первый инструмент после ping.

5. Packet capture: «когда сомневаешься — захвати трафик»

Все show-команды показывают, что устройство думает. Захват пакетов показывает, что происходит на самом деле. Это конечная истина: «дошёл ли пакет», «кто ответил», «какие флаги», «где обрывается».

Где ставить захват: в точке, где гипотеза проверяется

Запрос ушёл, но ответа нет? Захват на сервере покажет: «запрос дошёл, ответ ушёл» → теряется обратный путь.

# tcpdump: классика на сервере/Linux-роутере $ tcpdump -ni eth0 host 10.0.0.10 and port 443 # только нужный трафик $ tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0' # только SYN — кто стучится $ tcpdump -ni any icmp # весь ICMP (ping) $ tcpdump -ni eth0 -w capture.pcap # в файл → открыть в Wireshark # Cisco: встроенный захват (EPC) R1# monitor capture CAP interface gi0/0 both match ipv4 any any R1# monitor capture CAP start

Главные display-фильтры Wireshark

ip.addr == 10.0.0.10 # весь трафик с/на хост tcp.port == 443 # по порту tcp.flags.syn == 1 && tcp.flags.ack == 0 # только SYN (попытки соединения) tcp.analysis.retransmission # ретрансмиты → потери/перегруз dns # DNS-запросы и ответы tls.handshake.type == 1 # Client Hello (начало TLS) icmp # ping и ICMP-ошибки (в т.ч. fragmentation needed)

6. Разбор реальных сценариев

Сценарий A: «сайт не открывается»

Идём bottom-up быстро: ping IP сервера — идёт? Значит L1–L3 ок, проблема выше. ping по имени — не идёт? → DNS. Резолвится, но порт не открывается? → tcpdump покажет, кто молчит.

── tcpdump на клиенте: видим SYN без ответа ── 10.0.0.5.51002 > 10.0.0.10.443: Flags [S], seq 1 # SYN ушёл 10.0.0.5.51002 > 10.0.0.10.443: Flags [S], seq 1 # retransmit — ответа нет 10.0.0.5.51002 > 10.0.0.10.443: Flags [S], seq 1 # снова тишина → порт закрыт / firewall дропает

SYN уходит, SYN-ACK не приходит → либо порт не слушается, либо firewall/ACL молча дропает (если бы reject — пришёл бы RST). Дальше — захват на сервере: дошёл ли SYN туда вообще.

Сценарий B: «работает, но медленно/рвётся»

mtr покажет потери на конкретном хопе. В Wireshark — массовые tcp.analysis.retransmission и duplicate ack = потери. Если задержка скачет — jitter/перегрузка (вспомни QoS, модуль 9).

Сценарий C: «маленькие пакеты идут, большие — нет» — классика MTU

Симптом-маркер: ping обычным размером — ок, ping -s 1500 — теряется; SSH подключается, но «виснет» при выводе; сайт открывается, но картинки не грузятся. Это проблема MTU / fragmentation (туннель, VXLAN, PPPoE съели часть MTU, а DF-бит мешает фрагментации).

── ICMP подсказывает прямо ── ICMP 10.0.12.2 > 10.0.0.5: frag needed and DF set (mtu 1400) # роутер кричит: уменьши пакет!

Проверка: ping -M do -s 1472 IP (Linux) — подбираешь максимальный проходящий размер. Лечение: правильный MTU/MSS clamping на туннеле.

Сценарий D: «иногда не туда» — асимметрия/дубликат IP

Дубликат IP (две машины с одним адресом) — ARP «прыгает», часть трафика уходит не туда. Видно в захвате как ARP-ответы от разных MAC на один IP. Асимметричный маршрут ломает stateful firewall (ответ идёт другим путём).

7. Боевой чеклист (распечатай и держи рядом)

Когда «не работает»

Сформулируй симптом точно: кто, что, куда, с каких пор, всем или одному.
Воспроизводится ли? Менялось ли что-то недавно (главный подозреваемый)?
Локализуй: один хост или все? одно приложение или всё? один сайт или весь интернет?
ping по IP → ping по имени (отсекаешь DNS) → traceroute/mtr (где обрыв).
Проверь маршрут туда и обратно (обратный забывают чаще всего).
Порт: слушается? ACL/firewall/SG? (ss, telnet/nc на порт, захват SYN).
Сомневаешься — захвати трафик в подозрительной точке.
Меняй по одному. Зафиксируй, что починило. Запиши в заметки.

8. Мост в DevOps

Эта методология — самое ценное, что ты унесёшь в DevOps. Она не про Cisco, она про мышление:

«Под недоступен» отлаживается тем же OSI-чеклистом: контейнер жив → endpoints Service → NetworkPolicy → CoreDNS → Ingress/TLS.
tcpdump работает и в поде (kubectl debug, ephemeral containers) — те же фильтры.
«Медленный API» — тот же mtr/Wireshark подход: где задержка, ретрансмиты, MTU между нодами (VXLAN!).
Принцип «меняй по одному, фиксируй гипотезу» — основа blameless-постмортемов и SRE-культуры.

🌉 Финал трека

Ты прошёл путь от кабеля (модуль 1) до отладки целой сети. Сетевик, который понимает пакет и умеет его поймать, становится незаменимым в любой DevOps-команде — потому что «непонятные сетевые проблемы» есть везде, а решать их умеют единицы. Дальше — сетевая автоматизация (NetDevOps) и облако. У тебя теперь есть фундамент, которого нет у 90% входящих в DevOps.

9. Вопросы с собеседования

❓ «Пользователь говорит — интернет не работает». Твои первые шаги?

Уточнить симптом (всё или один сайт, один ПК или все). Затем: ping по IP (есть ли L3) → ping по имени (DNS?) → traceroute/mtr (где обрыв) → проверить gateway/маршрут. Сужаю область, не тыкаю наугад.

❓ Чем bottom-up отличается от top-down?

Bottom-up — от физики вверх по OSI (когда «всё лежит»). Top-down — от приложения вниз (когда барахлит одно приложение, а сеть в целом жива). Выбор зависит от симптома.

❓ Ping маленьким пакетом проходит, большим — нет. Что это?

Классическая проблема MTU (туннель/VXLAN/PPPoE уменьшили MTU, DF-бит мешает фрагментации). Проверяю ping -M do -s …, лечу MSS clamping / правильным MTU.

❓ SYN уходит, ответа нет. Drop или reject — как отличить?

Если firewall reject — придёт RST (или ICMP unreachable). Если drop — тишина, клиент ретрансмитит SYN и отваливается по таймауту. Тишина в захвате = молчаливый дроп.

10. Частые ошибки джунов

ошибка 1 Тыкают наугад и меняют всё разом. «Заработало», но непонятно почему — и проблема вернётся. Гипотеза → одна проверка.

ошибка 2 Верят show-командам больше, чем пакетам. Устройство «думает», что всё ок, а пакет не летит. Захват — последняя истина.

ошибка 3 Забывают обратный путь. «Запрос уходит, ответа нет» почти всегда = нет обратного маршрута/NAT/асимметрия.

ошибка 4 Игнорируют ICMP. А он часто прямо сообщает причину (frag needed, host unreachable, TTL exceeded). Не блокируй весь ICMP бездумно.

ошибка 5 Не спрашивают «что менялось». 80% инцидентов — следствие недавнего изменения. Это первый вопрос, а не последний.

Ключевое за этот урок

Чинит быстро не тот, кто знает больше команд, а тот, кто действует методично: симптом → гипотеза → одна проверка.
Методологии: bottom-up (всё лежит), top-down (барахлит приложение), follow-the-path, divide-and-conquer.
OSI-чеклист L1→L7 — универсальная отмычка и в сети, и в Kubernetes.
Инструменты: ping (связность), mtr/traceroute (где обрыв), ss/dig, tcpdump/Wireshark (истина на проводе).
Захватывай в нескольких точках пути — сужаешь до конкретного устройства/отрезка.
Ключевые фильтры: SYN без ответа, retransmission, ICMP «frag needed» (MTU), дубликат ARP.
Меняй по одному, фиксируй гипотезу, спрашивай «что менялось», документируй.
Эта методология — твой главный актив на пути в DevOps/SRE.