OPS Troubleshooting и packet capture — навык №1 на работе
Настроить сеть способен и junior по методичке. Чинить, когда «не работает» и неясно почему — вот за что платят. Это финальный модуль трека: он связывает всё предыдущее в единую методологию. Не «тыкать наугад», а действовать системно — сужать область, проверять гипотезы, читать пакеты. Это же мышление переносится в DevOps один в один.
«Приоритет ВЫСОКИЙ. После ночных работ в ЦО магазины региона не проводят оплату: кассовое ПО висит на „подключение к серверу…“. Интернет в магазинах есть, сервер в ЦО жив, мониторинг зелёный. Бизнес теряет деньги каждую минуту, на мосту — твой руководитель и директор розницы». Всё «зелёное», а ничего не работает — самый частый и самый неприятный тип инцидента. Паникующий инженер начинает перезагружать всё подряд. Методичный — за 15 минут доходит до причины. Этот урок — о том, как быть вторым. Инцидент разберём до конца в разделе 7.
- Вести поиск по циклу «симптом → гипотеза → одна проверка → вывод», а не тыкать наугад
- Выбрать методологию под симптом: bottom-up, top-down, follow-the-path, divide-and-conquer
- Пройти OSI-чеклист L1→L7 и назвать команду проверки для каждого уровня
- Прочитать TCP-рукопожатие и флаги (SYN/ACK/RST/FIN) в живом захвате
- Снять трафик tcpdump'ом с правильным фильтром и открыть его в Wireshark
- Отличить в захвате: молчаливый drop, reject, ретрансмиты, MTU-блэкхол, дубликат IP
- Разобрать инцидент «всё зелёное, ничего не работает» до причины — по шагам
- Перенести методологию в DevOps: отладка подов и сервисов тем же чеклистом
Модуль 2: ARP и MAC-таблицы — половина «странных» проблем живёт на L2.
Модуль 5: маршрут нужен туда и обратно; longest prefix match.
Модуль 10: stateful firewall помнит соединения — и ломается от асимметрии.
Модуль 11: ping … source и ping … df-bit есть у всех
вендоров — сегодня они главные герои. Если что-то забыл — вернись, этот модуль стоит на плечах
всех предыдущих.
1. Мышление: гипотеза, а не догадка
Разница между junior и senior — не в количестве известных команд, а в дисциплине поиска. Senior не «пробует всё подряд», он:
- точно формулирует симптом («что именно не работает, для кого, с какого момента»);
- выдвигает гипотезу («похоже, нет обратного маршрута»);
- делает одну проверку, которая гипотезу подтвердит или опровергнет;
- фиксирует результат и сужает область — и так до причины.
2. Четыре методологии
| Метод | Суть | Когда применять |
|---|---|---|
| Bottom-up | снизу вверх по OSI: кабель → линк → IP → транспорт → приложение | «вообще ничего не работает», физические подозрения |
| Top-down | сверху вниз: от приложения к физике | «одно приложение барахлит», остальное ок |
| Follow-the-path | идём по реальному пути пакета хоп за хопом | проблема «где-то между A и B» |
| Divide-and-conquer | проверяем середину пути/стека, отсекаем половину | длинный путь/стек, хотим быстро локализовать |
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-сертификат? что в логах приложения?
4. Инструменты: что когда
| Инструмент | Отвечает на вопрос |
|---|---|
ping | есть ли L3-связность и какая задержка/потери |
traceroute / mtr | по какому пути идёт трафик и на каком хопе проблема |
ip route get / show ip route | каким маршрутом пакет уйдёт (до отправки) |
ss / show ip ... brief | слушается ли порт, в каком состоянии соединения |
dig / nslookup | правильно ли резолвится DNS |
telnet host 443 / nc -zv | открывается ли конкретный TCP-порт (быстрее захвата) |
tcpdump / Wireshark | что РЕАЛЬНО летит по проводу — последняя инстанция истины |
5. Ликбез: TCP-рукопожатие и флаги — азбука чтения захватов
Чтобы читать захваты, нужен минимум теории TCP, который в этом треке ещё не звучал. Каждое TCP-соединение начинается с рукопожатия из трёх пакетов:
Словарь флагов, который покрывает 95% диагностики:
| Что видишь в захвате | Что это значит |
|---|---|
| SYN → SYN-ACK → ACK | соединение установилось — L1–L4 в порядке, ищи проблему выше |
| SYN → SYN → SYN (повторы) | ответа нет: порт за молчаливым firewall (drop) или пакет не доходит |
| SYN → RST | сервер жив, но порт закрыт (или reject на firewall) — до сервера пакет дошёл! |
| retransmission / dup ACK | потери на пути: физика, перегруз, полисер |
| RST посреди сессии | кто-то разорвал: приложение упало, firewall прибил idle-сессию, IPS вмешался |
6. Packet capture: «когда сомневаешься — захвати трафик»
Все show-команды показывают, что устройство думает. Захват пакетов показывает, что происходит на самом деле. Это конечная истина: «дошёл ли пакет», «кто ответил», «какие флаги», «где обрывается».
Как читать строку tcpdump — по кусочкам:
Главные display-фильтры Wireshark
7. Разбор руками: инцидент «всё зелёное, кассы стоят» до конца
Вернёмся к инциденту из начала урока и пройдём его по методологии, шаг за шагом:
ping 10.50.0.10 (сервер) — ходит! Значит L3 до сервера жив, ICMP
firewall пропускает. telnet 10.50.0.10 9443 — висит и отваливается по таймауту.
Тишина, не RST → похоже на молчаливый drop (раздел 5). Гипотеза №1 крепнет.tcpdump -ni eth0 port 9443. Ожидали тишину
(firewall дропает до сервера), а видим:
ip route get 10.20.3.5 → default через
старый шлюз! При переносе сервера маршрут на сети магазинов не переехал. Итог: SYN входит
через новый stateful firewall, SYN-ACK выходит через старый — новый firewall не видит ответа,
сессия не собирается, а старый дропает «незнакомый» SYN-ACK (модуль 10: stateful ломается от
асимметрии).8. Разбор типовых сценариев
Сценарий A: «сайт не открывается»
Идём bottom-up быстро: ping IP сервера — идёт? Значит L1–L3 ок, проблема выше. ping по
имени — не идёт? → DNS. Резолвится, но порт не открывается? → tcpdump покажет, кто молчит.
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-бит мешает фрагментации).
Проверка: ping -M do -s 1472 IP (Linux) — подбираешь максимальный проходящий размер. Лечение: правильный
MTU/MSS clamping на туннеле.
Сценарий D: «иногда не туда» — асимметрия/дубликат IP
Дубликат IP (две машины с одним адресом) — ARP «прыгает», часть трафика уходит не туда. Видно в захвате как ARP-ответы от разных MAC на один IP. Асимметричный маршрут ломает stateful firewall (ответ идёт другим путём) — ты видел это в разделе 7 на живом инциденте.
Сценарий E: «всё открывается, но с задержкой ровно в несколько секунд»
Подозрительно одинаковая задержка (2, 5, 10 секунд) перед каждым соединением — почти всегда
таймаут DNS: первый DNS-сервер в настройках мёртв, клиент ждёт таймаут и идёт ко второму.
Проверка: dig @первый-DNS имя (молчит?) и фильтр dns в Wireshark — виден запрос
без ответа и повтор к другому серверу. Лечение: убрать/починить мёртвый резолвер. Ровные «ступеньки»
задержки — это таймауты, а не «медленная сеть».
9. Боевой чеклист (распечатай и держи рядом)
- Сформулируй симптом точно: кто, что, куда, с каких пор, всем или одному.
- Воспроизводится ли? Менялось ли что-то недавно (главный подозреваемый)?
- Локализуй: один хост или все? одно приложение или всё? один сайт или весь интернет?
- ping по IP → ping по имени (отсекаешь DNS) → traceroute/mtr (где обрыв).
- Проверь маршрут туда и обратно (обратный забывают чаще всего).
- Порт: слушается? ACL/firewall/SG? (ss, telnet/nc на порт, захват SYN).
- Сомневаешься — захвати трафик в подозрительной точке.
- Меняй по одному. Зафиксируй, что починило. Запиши в заметки.
10. Мини-лаба: поймай свои первые пакеты сегодня
Всё, что нужно, — твой компьютер и бесплатный Wireshark. 20 минут:
tcp.flags.syn == 1. Найди пару SYN → SYN-ACK и следом ACK — ты видишь живое
рукопожатие из раздела 5. Посмотри время между SYN и SYN-ACK — это RTT до сервера.dns. Найди запрос A-записи и ответ с IP. Сколько миллисекунд
между ними? Теперь ты знаешь, как выглядит «нормальный» DNS — и узнаешь ненормальный
(запрос без ответа, сценарий E).http; если всё в TLS — открой
http://neverssl.com), ПКМ → Follow → TCP Stream. Перед тобой сессия целиком: запрос браузера
и ответ сервера как текст. Это главный приём чтения прикладных протоколов.telnet 8.8.8.8 4444). Смотри в захвате: SYN, SYN, SYN — и тишина (drop по пути).
Теперь на telnet localhost 4444: мгновенный RST (порт закрыт, reject). Ты только что
увидел разницу drop vs reject собственными глазами.ping 8.8.8.8 -f -l 1472, Linux/mac:
ping -M do -s 1472 8.8.8.8. Проходит? Уменьшай, если нет. Запусти при этом захват
с фильтром icmp — если по пути узкий MTU, увидишь «frag needed» своими глазами.11. Словарик урока
| Термин | По-английски | Смысл в одну строку |
|---|---|---|
| Рукопожатие | 3-way handshake | SYN → SYN-ACK → ACK: три пакета, открывающие любое TCP-соединение |
| Ретрансмит | retransmission | повтор пакета, на который не пришло подтверждение — маркер потерь |
| Drop / reject | — | молча выкинуть пакет (тишина) / отказать явно (RST или ICMP unreachable) |
| RST | reset | грубый разрыв соединения: «порт закрыт» или «сессию прибили» |
| Захват | packet capture, pcap | запись реальных пакетов с интерфейса; .pcap — её формат |
| Capture vs display filter | — | фильтр при записи (tcpdump/BPF) vs фильтр при просмотре (Wireshark) |
| SPAN / зеркало порта | port mirroring | коммутатор копирует трафик порта на порт с анализатором |
| Асимметричный маршрут | asymmetric routing | туда и обратно — разными путями; убийца stateful firewall |
| MSS clamping | TCP MSS adjust | принудительное уменьшение размера TCP-сегментов на туннеле — лечение MTU-блэкхола |
| Экспертная сводка | Expert Information | список всех аномалий захвата одним окном в Wireshark |
12. Мост в 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.
13. Вопросы с собеседования
ping -M do -s …, лечу MSS clamping / правильным MTU.ip route get <клиент>
на сервере и захватом на промежуточных точках обратного пути.14. Частые ошибки джунов
15. Задачи: поставь диагноз по захвату
Задача 1. В захвате: SYN → мгновенный RST от сервера. Порт 8080. Что это значит и куда идти дальше?
Пакет дошёл до сервера (сеть работает!), но порт 8080 никто не слушает — или локальный
firewall отвечает reject. Дальше — на сервер: ss -tlnp | grep 8080 — запущено ли
приложение. Это уже не сетевая проблема, а прикладная.
Задача 2. Пользователь: «всё открывается, но каждый сайт думает секунд пять, потом резко грузится». Диагноз?
Ровная задержка перед каждым соединением = таймаут, почти наверняка DNS: первый
резолвер в настройках мёртв, клиент ждёт и идёт ко второму. Проверка: dig @первый-DNS
и фильтр dns в Wireshark (запрос без ответа + повтор к другому серверу).
Задача 3. mtr до сервера показывает 30% потерь на хопе 4, но 0% на хопах 5–9 и на финальном. Сеть теряет пакеты?
Нет. Потери «в середине», которые исчезают на следующих хопах, — это роутер хопа 4 деприоритизирует ответы на TTL-exceeded (control plane policing), а транзитный трафик прогоняет без потерь. Смотри на потери последнего хопа — только они реальны для трафика. Классическая ловушка чтения mtr.
Задача 4. В Wireshark у одного IP в ARP-ответах то MAC aa:aa…, то MAC bb:bb…. Симптомы у пользователей: «то работает, то нет». Что происходит?
Дубликат IP: два устройства отвечают на один адрес (или кто-то поднял виртуалку со статическим IP шлюза). ARP-таблицы соседей «прыгают» между MAC. Найти оба устройства по MAC (таблицы коммутаторов, модуль 2) и разнести адреса.
Задача 5. SSH на сервер подключается, команды работают, но «cat большого файла» вешает сессию намертво. Что проверишь первым?
MTU: интерактивные команды — маленькие пакеты, вывод файла — большие, и они
гибнут на узком MTU (туннель по пути). ping -M do -s 1472 сервер, затем вниз до
проходящего размера; лечение — MSS clamping или починка MTU на туннеле.
Задача 6. После переноса VM «пинг до неё есть, а соединения не открываются ни на один порт». На VM захват: SYN приходят, SYN-ACK уходят. Диагноз без единой лишней команды?
Точная копия инцидента из раздела 7: обратный путь асимметричен — SYN-ACK уходит
не тем маршрутом (старый шлюз в конфиге VM) и гибнет на stateful firewall. Проверка:
ip route get <адрес клиента> на VM. Фикс: поправить шлюз/маршруты после переноса.
- Чинит быстро не тот, кто знает больше команд, а тот, кто действует методично: симптом → гипотеза → одна проверка.
- Методологии: bottom-up (всё лежит), top-down (барахлит приложение), follow-the-path, divide-and-conquer.
- OSI-чеклист L1→L7 — универсальная отмычка и в сети, и в Kubernetes.
- TCP-азбука: SYN→SYN-ACK→ACK; тишина = drop, RST = reject/порт закрыт; ретрансмиты = потери.
- Инструменты: ping (связность), mtr/traceroute (где обрыв), ss/dig/nc, tcpdump/Wireshark (истина на проводе).
- Захватывай в нескольких точках пути — сужаешь до конкретного устройства/отрезка; «запрос дошёл, ответ ушёл» = ищи обратный путь.
- Ключевые фильтры: SYN без ответа, retransmission, ICMP «frag needed» (MTU), дубликат ARP; Follow TCP Stream и Expert Info — вместо листания глазами.
- Меняй по одному, фиксируй гипотезу, спрашивай «что менялось», документируй. Это твой главный актив на пути в DevOps/SRE.